Standalone Nashorn is coming for Java 15+
Mandy Chung
mandy.chung at oracle.com
Mon Oct 19 23:45:28 UTC 2020
On 10/19/20 11:44 AM, Remi Forax wrote:
>
>
> ------------------------------------------------------------------------
>
>
> 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.
>
I also had converted to use `Lookup::defineHiddenClass` but I missed
this stack trace issue.
http://hg.openjdk.java.net/valhalla/valhalla/file/fb5c34c883b5/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java#l321
How does the engine walk the stack frame and report "<eval>" as their
script name and anonymous functions? I wonder if StackWalker can help
here (as Remi mentions).
>
> 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");
>
jdk.unsupported exports and opens `sun.misc` and so `sun.misc.Unsafe`
should be accessible as in JDK 8.
> also, if you are modular, you need to requires jdk.unsupported,
> sun.misc.Unsafe is not in java.base.
>
That might be the cause of the issue.
>
>
> 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
>
Thank you.
My apology that I haven't had time to consider JDK-8212620 more. I
still think VISIBLE option is option while it is relevant to JDK-8212620
as well. It's better to consider them together.
As I ask above, would StackWalker with SHOW_HIDDEN_FRAMES option help to
find the stack frame with hidden class?
Mandy
More information about the nashorn-dev
mailing list