Hi list,
is anyone aware of Truffle/Graal from Oracle? Here some insightful slides: https://lafo.ssw.uni-linz.ac.at/pub/papers/2016_PLDI_Truffle.pdf
Since there's been talk about rewriting the ABCL compiler which is old, messy and not very optimizing, I wonder if Truffle can be a useful technology to base a new compiler on. Not as the default because it requires Java 9 (or perhaps 8), but at least as a future-proof solution. It seems to me that getting started is not hard - just map the Lisp S-expression based AST to a Truffle AST; optimizations can follow incrementally. What do you think? I don't have the resources to work on it anytime soon, I'm letting my own projects slip sadly - it would be great to work on it. Still, maybe someone else is interested. I can contribute some design and code reviews, if need be, but little actual coding.
Peace Alessio
On 2016/6/22 14:10, Alessio Stalla wrote:
Hi list,
is anyone aware of Truffle/Graal from Oracle? Here some insightful slides: https://lafo.ssw.uni-linz.ac.at/pub/papers/2016_PLDI_Truffle.pdf
Since there's been talk about rewriting the ABCL compiler which is old, messy and not very optimizing, I wonder if Truffle can be a useful technology to base a new compiler on. Not as the default because it requires Java 9 (or perhaps 8), but at least as a future-proof solution. It seems to me that getting started is not hard - just map the Lisp S-expression based AST to a Truffle AST; optimizations can follow incrementally. What do you think? I don't have the resources to work on it anytime soon, I'm letting my own projects slip sadly - it would be great to work on it. Still, maybe someone else is interested. I can contribute some design and code reviews, if need be, but little actual coding.
Mapping a Common Lisp S-expr to an AST is fairly trivial operation given that "everything is a cons" so there is not much to differentiate to "hang" semantics unto the syntax without a deeper analysis.
From [listening to the talk associated with the slides you posted][1],
it seems as if the resulting implementation that runs on the Truffle VM (the modified Hotspot VM, which will presumably be part of Java 9) proves too weak to do anything useful. Among other things, there is no reflection, no threads, and not all existing JVM code can be run on the Truffle VM.
Given the rate at which ORCL is EOL'ing old Javas, I wouldn't mind targeting say Java 8 or 9 for putative ABCL tooling rewrite.
My current plan of attack (if I had the time)
0. Restablish the mechanisms to run ABCL in pure interpreted mode, with a runtime API to configure the compilation policy.
1. Write a Java 6 classformat compatible class writer
2. Fork the current compiler. Hack the resulting fork not to depend on special variables during compilation. Assemble compiler tests.
3. Start hacking the "new" compiler to sanity, separating into proper layers, always having the original compiler to fall back upon.
[1]: http://medianetwork.oracle.com/video/player/2623645003001
armedbear-devel@common-lisp.net