Source Code to Build invokedynamic.jar
cr88192 at hotmail.com
Wed Dec 10 17:24:46 PST 2008
(sorry, I am not sure if this belongs on-list or not...).
----- Original Message -----
From: "John Rose" <John.Rose at Sun.COM>
To: "Da Vinci Machine Project" <mlvm-dev at openjdk.java.net>
Sent: Thursday, December 11, 2008 10:00 AM
Subject: Re: Source Code to Build invokedynamic.jar
> On Dec 10, 2008, at 2:50 AM, BGB wrote:
>> pardon my ignorance, but is there any plan to allow dynamic slot/
>> field access?...
> Yes, but not directly in this project. The dynalang.org project
> builds such things on top of Java. Invokedynamic (and later
> interface injection) will allow such things to be treated almost as
> if they were built into the JVM.
this is what I am looking forwards to.
I ask here mostly so that I can hopefully try to avoid going too far from
whatever is official/standard, even if my aims are unorthodox...
just details are hard to find...
my guess is that a lot of the technical details haven't really been entirely
(so, those of us doing custom VMs will have to wait until later to really
>> ok, I am starting out just implementing my own VM with little
>> familiarity with this framework in general (at this point I have
>> little idea if it will actually be compatible), my tweak was partly
>> to add the ability to have usable fields in interfaces (AFAIK, this
>> is not allowed in standard JVMs).
> No. Because you can build that on top of Java with getters and
> setters, JVM users do not (usually) feel that the JVM is missing
> anything on this score.
I guess this is worth looking into.
I had not considered this at the time, figuring that a getter/setter would
have a higher overhead than a direct slot access (esp via interfaces, where
in my current implementation, it takes close to around 1us to perform an
interface method call, but about 250ns or so to access a field via an
interface...). from what I remember an ordinary virtual method call was
taking around 750ns. note that an ordinary slot access takes 45ns (does not
lock mutexes, but most other calls do, note that I wrote my own mutex code
given the absurd slowness of the ones provided by Win32, namely, around
1.2us for a lock/unlock pair...).
granted all this is written in C with profiler settings, probably it would
be much faster if some parts were written in ASM, or at least compiled with
optimizations, or at least without debug and profiler options...
I guess it is also an issue with getters/setters that one would have to
settle on a naming convention (not sure if this is already standardized...).
>> ok, from what info I can find, interfaces in my case work a little
>> differently. there is actually almost no structural coupling
>> between interfaces and object methods. instead, a set of hash
>> tables is used, and the slot/method handle from the interface is
>> used to lookup the appropriate method in the object via the hash
>> tables (actually, a set of single largish hash tables is used for
>> managing the entire object system)....
> There are technical advantages to having slots as first-class objects
> in a VM, but most designs happily use coordinated pairs (get/set) of
> access functions.
> If you do reify slots, you might consider making them anonymous and
> anonymous and composable. I don't think it's enough of a win to
> reify them but restrict their use to implementing object (and
> interface) attributes. Perhaps you could unify them with local
> But this has little to do with what we are currently aiming at on the
as for the above: I am not sure how these could be done without violating
the standard in some non-trivial ways (potentially breaking backwards
yeah, the question came up partly becuase, well, I have my own
not sure if it can properly called a JVM, since it implements JBC, mostly
(exceptions and a few other things are still lacking), but not that much
else at present (no classs library, ...), and has not at this point actually
been tested running actual Java code (due mostly to lacking time at present
to dedicate to this project...).
it has all been more of a crash-course in reading through the documentation
and implementing it (actually, I wrote my C compiler in a similar manner,
but at least for this I had many years of prior C-experience...).
compiler to the thing, and being faced with the wide ranging and not so
subtle differences between the VM design and what the language does.
it is eased some by a good number of extensions I had added to the bytecode,
but I don't expect this to be adopted by standard JVMs (for targeting a
standard JVM, most of these would probably require the use of method calls).
but, then again, in a JIT-compiled VM, it is probably the case that things
like method calls will not carry such a severe overhead.
I guess this is the fault of not having looked into existing efforts compile
JS to the JVM.
note that in my case, the VM and object system are actually independent
(however the interface to the object system was heavily influenced by JNI),
and my object system has a good deal of "added" functionalilty (ability to
dynamically add slots to objects or modify the classes, multiple
inheritence, ability to use prototype-based delegation, ...).
the idea was to implement a single system which could effectively handle
Class/Instance OO, and was also capable of handling Prototype-OO (granted I
allow the performance to not be as good as with class/instance, and
internally a good deal of hackery is used here...).
interfaces were used here, under the idea of trying to make such extensions
hopefully usable from Java code. granted, I don't expect Java code to be
able to construct such objects, but Java is not the only language I am
running/intend to run on my framework (itself a rather "decentralized"
design), and it would be lame if it were solely some island off by itself...
the idea then is that I can use an interface to be able to "see" such
objects as if they were native, even though the actual implementation may
reside in a different language, and the objects' structure may itself be
> Best wishes,
> -- John
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
More information about the mlvm-dev