Re: dyn.js - invokedynamic-based js implementation
Remi, I've made the vtable + migration to some builtin j.l.* types Do you mind to take a look? https://github.com/dynjs/dyn.js/blob/master/src/main/java/org/dynjs/runtime/linker/PrimitivesLinker.java https://github.com/dynjs/dyn.js/blob/master/src/main/java/org/dynjs/runtime/linker/VTablePopulator.java#L13 https://github.com/dynjs/dyn.js/blob/master/src/main/java/org/dynjs/runtime/extensions/NumberOperations.java cheers -- qmx On Oct 13, 2011, at 11:34 AM, Rémi Forax wrote: On 10/13/2011 04:24 PM, Douglas Campos wrote: Remi, By example, for javascript Number, it should be a j.l.Double but with it's own vtable when you talk about having a vtable, you mean the verified-entrypoint recipe from jsr292 cookbook? (or something into these lines) So I would be providing more methods to a j.l.Double, linking with static methods via methodhandles? yes, but the vtable of the VEP tailor its method handles in a very special way, a vtable storing simple method handles is enough. cheers -- qmx Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: dyn.js - invokedynamic-based js implementation
Remi, By example, for javascript Number, it should be a j.l.Double but with it's own vtable when you talk about having a vtable, you mean the verified-entrypoint recipe from jsr292 cookbook? (or something into these lines) So I would be providing more methods to a j.l.Double, linking with static methods via methodhandles? cheers -- qmx ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: dyn.js - invokedynamic-based js implementation
On 10/13/2011 04:24 PM, Douglas Campos wrote: Remi, By example, for javascript Number, it should be a j.l.Double but with it's own vtable when you talk about having a vtable, you mean the verified-entrypoint recipe from jsr292 cookbook? (or something into these lines) So I would be providing more methods to a j.l.Double, linking with static methods via methodhandles? yes, but the vtable of the VEP tailor its method handles in a very special way, a vtable storing simple method handles is enough. cheers -- qmx Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: dyn.js - invokedynamic-based js implementation
Adding some thoughts of my own… On Oct 11, 2011, at 1:00 AM, Rémi Forax wrote: And at the end, all predefined Javascript objects should be re-written in Javascript, with some native calls to Java but it will be easier for providing the core API. By example, for javascript Number, it should be a j.l.Double but with it's own vtable to add all Javascript predefined methods. The idea is that j.l.Double and Javascript Number are the same object at runtime but are seen differently in Java and in Javascript. Yes. You can do this really nicely with Dynalink linkers, here's how: - in your invoke dynamic bootstrapped, define two linkers as your prioritized linkers. First one is the public one (the one whose class you export in META-INF/services). The other is a private linker that only acts on java.lang.Number, java.lang.String, and java.lang.Boolean, and provides extra JS operations on them. That way, if your runtime encounters any of these types + a JS only method invocation (or type conversion) on them, you can implement the required JS semantics in this private linker. Further to Remi's points, I was looking at your usage of the linker, and I think you might be using it wrong :-). First, all your linkages seem to be unconditional (there's never a guard). This doesn't seem right, as you can't relink if your call site gets a POJO instead of a JS object. You're also using the linker to link a static print method -- you shouldn't use a dynamic linker for that; you should just emit the INVOKESTATIC at the call site instead of making it an INVOKEDYNAMIC call. Alternatively, you can prefix that too with dynjs:, see below. In general, for every usage were you'd just unconditionally link, you should just have an INVOKESTATIC/INVOKESPECIAL to a method in your runtime and not go through Dynalink. Your linker should first check whether what it was given is a DynObject (it should in fact implement TypeBasedGuardingDynamicLinker and claim it only links DynObject (or maybe DynAtom), and if so, provide the linking for the standard dyn:* operations on them. Mind you, you can still have your private dynjs:* operations defined by linker, that's fine (i.e. if you want to, replace print with dynjs:print too), just don't link them unconditionally, always link them with a guard of instanceof DynAtom/Scope/DynObject, or what's applicable. That way, you make your system more interoperable by allowing users of your runtime to supply -- if they know how to and want to -- definitions for these operations in their own linkers for their own objects. Attila. cheers, Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
dyn.js - invokedynamic-based js implementation
Hello mlvm friends, just a heads up that dyn.js is released at https://github.com/dynjs/dyn.js feedback is more than welcome :) cheers! -- qmx ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: dyn.js - invokedynamic-based js implementation
On Oct 10, 2011, at 7:12 AM, Douglas Campos wrote: Hello mlvm friends, just a heads up that dyn.js is released at https://github.com/dynjs/dyn.js feedback is more than welcome :) Congratulations on getting this working... Nice, crunchy uses of invokedynamic, ASM, ANTLR, and dynalang. Remarkable leverage! -- John ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
