Hi, Following Juby, my language "G7" is a Groovy-like language that also compiles to invokedynamic ;-) I use Groovy parser, remove its MOP layer and rewrite the code generation class. The idea of wiring up invokedynamic is taken from Juby implementation.
It runs on JDK 7-b61 and it is just enough to compile Fibonacci and some simple programs. Unfortunately, MethodHandles.collectArguments, and dropArguments are still NIY in b61. So, I separated fallback into 4 handles, rather than having the single fallback. Another thing is that I successfully made a call to static using the trick from John's blog by encoding callsite names with the "static:<class>:<method>" pattern. Here is its GIT repository: http://github.com/chanwit/g7/tree/parser For a quick look: http://gist.github.com/133661 Anyway, the Fib program can run Fib(31) successfully, but JVM crashes when I run Fib(32) and Fib(35). Chanwit On Mon, Jun 15, 2009 at 8:15 AM, Charles Oliver Nutter<[email protected]> wrote: > I thought I'd try building a simple Ruby-like dynamic language that uses > all Java types and invokedynamic. Turns out it's only a couple hour job. > > http://gist.github.com/129973 > > This is "Juby", a language that simply compiles Ruby's syntax to Java's > type system. All calls are made using invokedynamic. Operators are also > calls, and there's some special-cased logic in them to bootstrap > appropriate utility methods for doing +, ==, etc. Other than primitive > logics like "puts" compiling as a System.out.println, all calls are made > through invokedyanamic. This makes the bytecode trivial to construct, > and only requires a bit of work on the bootstrap side. > > http://github.com/headius/juby/tree/master > > A few points to note: > > * The first dyncall at a call site uses reflection to get an exact match > for the incoming *runtime* argument types, but unreflects and uses the > resulting handle for both the first invocation and all subsequent > invocations. Handles all the way down! > * The handle recovered by reflection has only convertArguments applied, > since in this language there are not yet any implicit coercion rules > (there must be an exact match on the target type). > * collectArguments is being used to allow a single "fallback" path for > the first time through. > * Once the correct target method is installed, no further checks are > made; this means that if the method is polymorphic, it would blow up > currently. > > The compiler is trivial, since it just uses invokedynamic and then > normal Java logic. If you want to have a look, go ahead...it's a good > example of BiteScript in action. > > The interesting bit for you folks may be > src/com/headius/juby/SimpleJavaBootstrap.java. > > It's obviously not covering a lot of cases, but it's a good example of > how trivially one can write a dynlang atop invokedynamic. It took me > literally only a couple hours to do this, aided by JRuby and BiteScript. > > This week I hope to get all the new handle types wired into JRuby, and > then I will cover the JRuby indy conversion process and Juby in a new > blog post. And assuming indy can be made as fast as interface impls, we > may build Juby out as an implementation language for parts of JRuby. > > - Charlie > _______________________________________________ > mlvm-dev mailing list > [email protected] > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Chanwit Kaewkasi PhD Candidate, Centre for Novel Computing School of Computer Science The University of Manchester Oxford Road Manchester M13 9PL, UK _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
