Standalone Nashorn is coming for Java 15+

[Remi Forax]

> De: "Attila Szegedi" <szegedia at gmail.com>
> À: "remi forax" <remi.forax at univ-eiffel.fr>
> Cc: "nashorn-dev" <nashorn-dev at openjdk.java.net>, "mandy chung"
> <mandy.chung at oracle.com>
> Envoyé: Lundi 19 Octobre 2020 20:28:53
> Objet: Re: Standalone Nashorn is coming for Java 15+

>> On 2020. Oct 19., at 18:06, Remi Forax < [ mailto:remi.forax at univ-eiffel.fr |
>> remi.forax at univ-eiffel.fr ] > wrote:

>> ----- Mail original -----

>>> De: "Attila Szegedi" < [ mailto:szegedia at gmail.com | szegedia at gmail.com ] >
>>> À: "nashorn-dev" < [ mailto:nashorn-dev at openjdk.java.net |
>>> nashorn-dev at openjdk.java.net ] >
>>> Envoyé: Lundi 19 Octobre 2020 17:16:55
>>> Objet: Re: Standalone Nashorn is coming for Java 15+

>>> Hi y’all,

>> Hi Attila,

>>> * for now, I disabled anonymous code loading. It’s a funny one. Nashorn has a
>>> feature called “anonymous code loading” that it uses for somewhat
>>> lighter-weight loading of code as it compiles JavaScript functions one-by-one
>>> into bytecode classes. Unfortunately, it uses Unsafe.defineAnonymousClass for
>>> that, and outside of JDK it can’t access Unsafe. So I switched to a new API,
>>> luckily available from Java 15, MethodHandles.Lookup.defineHiddenClass. It
>>> seems to work as it should, except with it, eval’d expressions no longer report
>>> “<eval>” as their script name and anonymous functions no longer report
>>> “<anonymous>” but rather their callers names, script names, and line numbers
>>> are reported. It’s quite maddening, and if I can’t get to the bottom of it in
>>> reasonable amount of time.

>> A hidden class is well, hidden, so it doesn't appear by default in the stack
>> trace (You have a special configuation of the StackWalker that shows the hidden
>> classes).
>> With an anonymous class, you can use the annotation @Hidden or not but with a
>> hidden class, you have no choice, a hidden class is always hidden.

> Thanks for chiming in, Remi! I just came back from an evening walk, and around
> halfway into it I actually had this lightbulb go on thinking “y’know, this
> feels like the the stack frames are hidden…”

>> Also, you can still use Unsafe.defineAnonymous class with Java 15, but using
>> sun.misc.Unsafe and not jdk.internal.misc.Unsafe.
>> But it's a short term solution given that sun.misc.Unsafe.defineAnonymous is now
>> deprecated.

> I gave it a brief try, but the compiler complained that the package sun.misc is
> not visible. And anyway I was hoping for using a supported public API :-) I
> might give it _another_ try. I’m not sure what else do I need to do, but I hope
> it can be done without users needing to screw around with JVM flags such as
> --add-exports etc.

you may not be able to access it directly, but you can still write 
Class<?> unsafe = Class.forName("sun.misc.unsafe"); 

also, if you are modular, you need to requires jdk.unsupported, sun.misc.Unsafe is not in java.base. 

>>> I’ll just keep anonymous code loading switched off
>>> for initial release. There’s not many drawbacks to it, maybe a bit higher
>>> memory utilization if you don’t use optimistic types. With optimistic types, it
>>> would preclude obsolete code versions from clearing up from memory when
>>> functions are repeatedly recompiled until the whole script gets unloaded.

>> I've added Mandy in CC, given you are not the first one to ask for a "visible"
>> hidden class, so maybe, the ClassOption could be extended to had a VISIBLE
>> option ?

> That’d be awesome! By the way, Mandy, it is already awesome that we have
> Lookup.defineHiddenClass !

yep, +1 

> Attila.

Rémi