dyn.js - invokedynamic-based js implementation

[Attila Szegedi]

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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev