Source Code to Build invokedynamic.jar

[BGB]

(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.
>

yes.

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 
specified yet?...
(so, those of us doing custom VMs will have to wait until later to really 
know).


>> 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
> composable in the same way that Lisp or JavaScript functions are
> 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
> variables.
>
> But this has little to do with what we are currently aiming at on the
> JVM.
>

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 
compatibility?...).


yeah, the question came up partly becuase, well, I have my own 
experimental/extended VM.

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...).


the issue came up in trying to rework my existing partial JavaScript 
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 
mildly "alien".


> Best wishes,
> -- John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>