dyn.js - invokedynamic-based js implementation
szegedia at gmail.com
Tue Oct 11 09:18:13 PDT 2011
Adding some thoughts of my own…
On Oct 11, 2011, at 1:00 AM, Rémi Forax wrote:
> with some native calls to Java but it will be easier for providing the
> core API.
> it's own vtable
> runtime but
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.
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
More information about the mlvm-dev