<div dir="ltr">@Carter:<div><div><div>1) Actually, that would be harder. I've given the implementation without the new features a lot of thought and it's simpler to get done. I've only briefly given a thought on how the newer JVM features could be used, but I figured as I port more of the GHC's RTS/code generator, I'll know enough of the nuances to be able to judge where to apply these new features effectively.</div><div><br></div><div>2) Thanks for the suggestion. I don't use IRC that often, but if I could reach more people there then I'll give it a try.</div><div><br></div><div>3) Right now it doesn't do anything that is visible to the user so I'll hold off on that until I've ported a tiny but usable subset of the code generator. My target is to get the basic Java FFI and I/O working so that there's something new and interesting to play with.</div><div><br></div><div>@Edward: Thanks a lot! That would be great. </div><div><br></div><div>@Karel: Yeah it is, but the reward of being able to run Haskell anywhere is definitely worth it! I'm aware of the LambdaVM project. I didn't mention it because I wanted to focus on the present. I sent Brian Alliet an email asking for guidance on architectural decisions a while back, but have received no response. </div><div><br></div><div>I'd be interested in having a copy of the LambdaVM source, thanks. There are a couple of places in the design I'm iffy on, so it'd be nice to have a source of inspiration.</div><div><br></div><div>Frege is a great project in its own right, but GHC Haskell has become the standard and I find many of the extensions to be useful in eliminating many more classes of bugs at compile-time.</div><div><br></div><div>Thanks guys,</div><div>Rahul Muttineni</div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 9:59 PM, Karel Gardas <span dir="ltr"><<a href="mailto:karel.gardas@centrum.cz" target="_blank">karel.gardas@centrum.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Rahul,<br>
<br>
a lot of work in front of you. There was a similar project in the past, LambdaVM was it's name, author Brian Alliet -- unfortunately google can't reveal working site with it nor <a href="http://web.archive.org" rel="noreferrer" target="_blank">web.archive.org</a>. What I can offer you are some of the latest sources of this project. It's based on GHC 6.7 version so really an old base, but perhaps something would be usable even for your own work and even after all those years? Let me know if you are interested and I'll pack that and upload somewhere -- well assuming you have not heart about it since otherwise I would expect it to be noted somewhere in your email. Just let me know if you are interested...<br>
<br>
Anyway, I'm keeping my finger crossed for this your work! I'm personally very interested in seeing Haskell hosted in JVM and inter operable with Java...(yes, I know about Frege...)<br>
<br>
Cheers,<br>
Karel<div><div class="h5"><br>
<br>
On 05/ 2/16 05:26 PM, Rahul Muttineni wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi GHC Developers,<br>
<br>
I've started working on a JVM backend for GHC [1] and I'd love to work<br>
on it as my Summer of Haskell project.<br>
<br>
Currently, the build system is setup using a mix of Shake (for the RTS<br>
build) and Stack (for the main compiler build) and I ensure that most<br>
commits build successfully. I have ported the core part of the scheduler<br>
and ported over the fundamental types (Capability, StgTSO, Task,<br>
StgClosure, etc.) taking advantage of OOP in the implementation when I<br>
could.<br>
<br>
Additionally, I performed a non-trivial refactor of the hs-java package<br>
adding support for inner classes and fields which was very cumbersome to<br>
do in the original package. On the frontend, I have tapped into the STG<br>
code from the GHC 7.10.3 library and setup a CodeGen monad for<br>
generating JVM bytecode. The main task of generating the actual<br>
bytecode, porting the more critical parts of the RTS, and adding support<br>
for the threaded RTS remain.<br>
<br>
The strategy for compilation is as follows:<br>
- Intercept the STG code in the GHC pipeline<br>
- Convert from STG->JVM bytecode [2] in a similar manner as STG->Cmm<br>
preserving semantics as best as possible [3]<br>
- Port the GHC RTS (normal & threaded) to Java [4]<br>
- Put all the generated class files + RTS into a single jar to be run<br>
directly by the JVM.<br>
<br>
My objectives for the project during the summer are:<br>
- To implement the compilation strategy mentioned above<br>
- Implement the Java FFI for foreign imports. [5]<br>
- Implement the most important [6] PrimOps that GHC supports.<br>
- Port the base package replacing the C FFI imports with equivalent Java<br>
FFI imports. [7]<br>
<br>
A little bit about myself: I spent a lot of time studying functional<br>
language implementation by reading SPJ's famous book and reading<br>
research papers on related topics last summer as self-study.<br>
<br>
I took a break and resumed a couple months ago where I spent a lot of<br>
time plowing through the STG->Cmm code generator as well as the RTS and<br>
going back and forth between them to get a clear understanding of how<br>
everything works.<br>
<br>
Moreover, I compiled simple Haskell programs and observed the STG, Cmm,<br>
and assembly output (by decompiling the final executable with objdump)<br>
to understand bits of the code generator where the source code wasn't<br>
that clear.<br>
<br>
I also spent a great deal of time studying the JVM internals, reading<br>
the JVM spec, looking for any new features that could facilitate a high<br>
performance implementation [8].<br>
<br>
It would be great if someone with an understanding of nuances of the RTS<br>
and code generator could mentor me for this project. It has been a blast<br>
so far learning all the prerequisites and contemplating the design. I'd<br>
be very excited to take this on as a summer project.<br>
<br>
Also, given that I have hardly 5 days remaining, does anyone have<br>
suggestions on how I can structure the proposal without getting into too<br>
many details? There are still some parts of the design I haven't figured<br>
out, but I know I could find some solution when I get to it during the<br>
porting process.<br>
<br>
Thanks,<br>
Rahul Muttineni<br>
<br>
[1] <a href="http://github.com/rahulmutt/ghcvm" rel="noreferrer" target="_blank">http://github.com/rahulmutt/ghcvm</a><br>
<br>
[2] I intend to organically derive an IR at a later stage to allow for<br>
some optimizations by looking at the final working implementation<br>
without an IR and looking for patterns of repeated sequences of bytecode<br>
and assigning each sequence its own instruction in the IR.<br>
<br>
[3] Obviously, the lack of control of memory layouts (besides allocating<br>
off the JVM heap using DirectByteBuffers) and lack of general tail calls<br>
makes it tough to match the semantics of Cmm, but there are many<br>
solutions around it, as can be found in the few papers on translating<br>
STG to Java/JVM bytecode.<br>
<br>
[4] This is the GHC RTS without GC and profiling since the JVM has great<br>
support for those already. Also, lots of care must be taken to ensure<br>
that the lock semantics stays in tact during the port.<br>
<br>
[5] foreign exports will be dealt at a later stage, but I am taking care<br>
of naming the closures nicely so that in the future you don't have to<br>
type long names like the labels GHC compiles to call a Haskell function<br>
in Java.<br>
<br>
[6] Basically all the PrimOps that would be required to provide plumbing<br>
for the Prelude functions that can compile beginner-level programs found<br>
in books such as Learn You a Haskell for Great Good.<br>
<br>
[7] I know that it's a lot more complicated than just replacing FFI<br>
calls. I'd have to change around a lot of the code in base as well.<br>
<br>
[8] I found that the new "invokedynamic" instruction as well as the<br>
MethodHandle API (something like function pointers) that were introduced<br>
in JDK 7 could fit the bill. But as of now, I want to get a baseline<br>
implementation that is compatible with Java 5 so I will not be utilizing<br>
these newer features.<br>
<br>
<br>
<br></div></div><span class="">
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
<br>
</span></blockquote>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Rahul Muttineni</div>
</div>