wrt: "A new execution model for Nashorn in Java 9"

Tue Jan 26 08:37:16 UTC 2016

Tim,

I’m sorry for my late reply. I’m taking the liberty of CC:ing the nashorn-dev list so the active development team are in the loop and can answer any further questions.

Maybe you can supply some info on your product and clients so we can better understand your needs here.

1) Lambda forms are hidden by default, but they are always there as part of the MethodHandle implementations. I don’t think they show up on a standard stack trace without debugging info enabled
2) You can already tell Nashorn to generate slimmer classes without debug info such as line numbers (—debug-lines=false) and local variables (—debug-locals=false). Check out the -xhelp documentation dump for command line options. I’m not sure to what extent this would serve your needs
3) Guess that shouldn’t be a problem for your filters either.

If you want any smallish or medium sized functionality, we can certainly discuss it and add it to the JIRA issue tracker. Please let us know more about what your specific application needs are

When it comes to Jigsaw, it is a complex beast, and has taken huge amounts of time to get right. It is the largest and only breaking change in the history of the JDK so far. I agree that it might not be something a “lazy user” like you wishes and wants for these kids of use case scenarios, but given the size of the JDK, and when it comes to smaller environments like embedded and docker virtualized containers and so on, it makes sense to drastically reduce footprint instead of having global dependencies on everything. Maybe you should spend some time on the jigsaw-dev list and see if anyone can help or alleviate some of your concerns.

Kind regards,
Marcus

I believe that you can already strip down line numbers with
> On 21 Jan 2016, at 01:34, Tim Griffith <tim.griffith.dev at gmail.com> wrote:
> 
> Hi Marcus,
> 
> I know the feeling! no particular hurry as even if it were JDK 9 - it's not going to effect our mediation strategy for the next year and a bit; although [obviously] I am very interested to hear more detail on the when and what. The impact assessment done today is that it's not as bad (on the JVM capture side) as we first thought and the post-processing can be boiled down into 3 fairly simple processing steps - where we will:
> 1. [eagerly] strip all LambdaForm's from the stacks (they provide no value to any of our clients)
> 2. [eagerly] simplify all 'jdk.nashorn.internal.scripts.Script$Recompilation$... to strip embedded line number components and host-specific generated components and render as nashorn.scripts.Script$ - the package namespace deliberate in order to allow us to...
> 3. [lazily] on display have a toggle to hide all (jdk.nashorn.internal.*) during visualization (turned on by default)
> 
> Which we believe will give us useful, legible display information for both our novice and advanced users. Very keen to hear your thoughts on the sensibility of this approach as well as any pointers to the authorative convention for the host-specific generated components for [2] to ensure we code our transforms "to spec".
> 
> finally please forgive me though but I can't resist a short rant re:Jigsaw causing the de-scope (feel free to ignore):
> 
> <rant>Jigsaw does seem to be the present that never fails to disappoint - I'm not even sure what it's solving anymore after Mark Reinholds "state of the module system" revealed to the 'lay interested party' such as myself that it would no longer be the solution to Jar Hell, enforced sensible [semantic] versioning (deferring to build tools), doing import-by-module rather than by package (and all the fragility that entails), public exports allowing transitive lazyness to endure, still thinking that ServiceLocator is sufficient to do services resolution... agnostic of all the improvements in DI over the last 2 decades, etc, etc. I mean I understand the #1 tenet of not breaking backwards compatibility... but I'm struggling to see now what Jigsaw is actually providing short of the new 'module private' protection - which is great; but if the only objective I'm pretty sure could have been delivered in a massively simpler and shorter timeline than the decade or so Jigsaw has been running *sigh* and whether the vast investment in intellectual capital, in retrospect, would have been better spent elsewhere *sigh*</rant>
> 
> -Tim
> 
> 
> [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/ <http://openjdk.java.net/projects/jigsaw/spec/sotms/>
> 
> On Wed, Jan 20, 2016 at 3:55 AM, Marcus Lagergren <marcus at lagergren.net <mailto:marcus at lagergren.net>> wrote:
> Hi Tim!
> 
> Sadly the execution model was bumped to Post 9, because there were a lot of resource required for Jigsaw. Let me get back to you with more information. I am in meetings all day.
> 
> Regards
> Marcus
> 
>> On 20 Jan 2016, at 03:46, Tim Griffith <tim.griffith.dev at gmail.com <mailto:tim.griffith.dev at gmail.com>> wrote:
>> 
>> Hi Marcus,
>> 
>> I came across your deck[1] whilst searching for approaches to tame the LambdaForm$... & jdk.nashorn.internal.scripts.Script$... dynamically named components. Excellent and informative presentation; I'm hoping its OK to ask a few quick questions:
>> 1. Is this committed for JDK 9 or speculative / looking for buy in? If committed whats the best place to track progress and find out when to pick up an Open JDK 9 build?
>> 2. Slide 128 talks about improvement (or removal) of LambdaForms... I was checking out JDK9 changes [2] but couldn't find anything that looked definitive [3] being the closest based on title.
>> 3. Slides 96 - 97, the interpreted before / after, the stack reduction and clean deterministic mapping makes sense... I couldn't see the same for the JIT'd frames - it wasn't clear if slide 95 was the target state (I'm assuming it was given the stacktace.js src reference and line #) and if so why do the arbitrary ($1, $2$31, $3) components still remain? - these are "worse than diagnostically useless" if they are not deterministic (such as JDK 8 Lamdba's being numbered by the order they are first encountered at runtime?); especially when dealing with aggregating sampled stack data from multiple machines (my current use case experiencing difficulty with Nashorn).
>> 
>> thanks once again for the deck and hope to hear from you
>> 
>> -Tim
>> 
>> 
>> [1] http://www.slideshare.net/lagergren/a-new-execution-model-for-nashorn-in-java-9 <http://www.slideshare.net/lagergren/a-new-execution-model-for-nashorn-in-java-9>
>> [2] http://download.java.net/jdk9/changes/jdk9-b31.html?q=download%2Fjdk9%2Fchanges%2Fjdk9-b31.html <http://download.java.net/jdk9/changes/jdk9-b31.html?q=download%2Fjdk9%2Fchanges%2Fjdk9-b31.html>
>> [3] https://bugs.openjdk.java.net/browse/JDK-8058147 <https://bugs.openjdk.java.net/browse/JDK-8058147>
> 
> 