> De: "Attila Szegedi" <szege...@gmail.com> > À: "remi forax" <remi.fo...@univ-eiffel.fr> > Cc: "nashorn-dev" <nashorn-dev@openjdk.java.net>, "mandy chung" > <mandy.ch...@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.fo...@univ-eiffel.fr | >> remi.fo...@univ-eiffel.fr ] > wrote: >> ----- Mail original ----- >>> De: "Attila Szegedi" < [ mailto:szege...@gmail.com | szege...@gmail.com ] > >>> À: "nashorn-dev" < [ mailto:nashorn-dev@openjdk.java.net | >>> nashorn-dev@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
