From sundararajan.athijegannathan at oracle.com Fri Apr 3 12:36:12 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 03 Apr 2015 18:06:12 +0530 Subject: RFR 8076646: nashorn tests should avoid using package names used by nashorn sources Message-ID: <551E893C.60102@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8076646/ for https://bugs.openjdk.java.net/browse/JDK-8076646 Although webrev looks somewhat big, the changes are mainly renaming packages, directories, resources, script paths. -Sundar From hannes.wallnoefer at oracle.com Fri Apr 3 12:42:31 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 03 Apr 2015 14:42:31 +0200 Subject: RFR 8076646: nashorn tests should avoid using package names used by nashorn sources In-Reply-To: <551E893C.60102@oracle.com> References: <551E893C.60102@oracle.com> Message-ID: <551E8AB7.4020309@oracle.com> Looks good. Hannes Am 2015-04-03 um 14:36 schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8076646/ for > https://bugs.openjdk.java.net/browse/JDK-8076646 > > Although webrev looks somewhat big, the changes are mainly renaming > packages, directories, resources, script paths. > > > -Sundar From marcus.lagergren at oracle.com Fri Apr 3 15:41:49 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 3 Apr 2015 17:41:49 +0200 Subject: RFR 8076646: nashorn tests should avoid using package names used by nashorn sources In-Reply-To: <551E893C.60102@oracle.com> References: <551E893C.60102@oracle.com> Message-ID: <38407931-624A-48CE-9D1C-51463EB97352@oracle.com> +1 > On 03 Apr 2015, at 14:36, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8076646/ for https://bugs.openjdk.java.net/browse/JDK-8076646 > > Although webrev looks somewhat big, the changes are mainly renaming packages, directories, resources, script paths. > > > -Sundar From sundararajan.athijegannathan at oracle.com Mon Apr 6 09:33:10 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 06 Apr 2015 15:03:10 +0530 Subject: [8u60] Please approve 8076646: nashorn tests should avoid using package names used by nashorn sources Message-ID: <552252D6.6040707@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8076646 jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-April/004422.html jdk8u-dev webrev: http://cr.openjdk.java.net/~sundar/8076646/8u60/webrev.00/ ParserAPITest.java does not exist in jdk8 (that is jdk9 specific API test). Other than diff on that file, everything else is backported 'as is'. -Sundar From sean.coffey at oracle.com Mon Apr 6 10:37:34 2015 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Mon, 06 Apr 2015 11:37:34 +0100 Subject: [8u60] Please approve 8076646: nashorn tests should avoid using package names used by nashorn sources In-Reply-To: <552252D6.6040707@oracle.com> References: <552252D6.6040707@oracle.com> Message-ID: Approved. Regards, Sean. On 6 April 2015 10:33:10 GMT+01:00, "A. Sundararajan" wrote: >Please approve. > >Bug: https://bugs.openjdk.java.net/browse/JDK-8076646 >jdk9 review thread: >http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-April/004422.html >jdk8u-dev webrev: >http://cr.openjdk.java.net/~sundar/8076646/8u60/webrev.00/ > >ParserAPITest.java does not exist in jdk8 (that is jdk9 specific API >test). Other than diff on that file, everything else is backported 'as >is'. > >-Sundar From tonyzakula at gmail.com Mon Apr 6 13:56:24 2015 From: tonyzakula at gmail.com (Tony Zakula) Date: Mon, 6 Apr 2015 08:56:24 -0500 Subject: Reusing ScriptContext and Global Variables Message-ID: Hello, We are running scripts server side and using the multi-threaded example running the same ScriptEngine across multiple threads as per the recent blog posts and examples here: https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using If I understand the notes below correctly, we can: 1. Seed a ScriptContext.Global_Scope from the Java side with default variables and values shared between all scripts and threads. These could never be changed from JavaScript code directly. 2. We would use a new ScriptContext for each request that gets the default binding and any new bindings we may want to add using the example below. 3. Based on the example and notes in the link, if someone assigned a global variable with the same name as something in our ScriptContext.Global_Scope, it would only affect that request ScriptContext and not pollute our default ScriptContext. Did I interpret that all correctly? Another further optimization it seems we could make is to cache and associate a ScriptContext per user between requests. This would effectively give us a per user JS engine across multiple requests with very little overhead it would seem. Thanks, Tony https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes ScriptContext defCtx = engine.getContext(); defCtx.getBindings(ScriptContext.GLOBAL_SCOPE).put("foo", "hello"); ScriptContext myCtx = new SimpleScriptContext(); myCtx.setBindings(defCtx.getBindings(ScriptContext.ENGINE_SCOPE), ScriptContext.ENGINE_SCOPE); Bindings b = new SimpleBindings(); b.put("foo", "world"); myCtx.setBindings(b, ScriptContext.GLOBAL_SCOPE); From sundararajan.athijegannathan at oracle.com Mon Apr 6 18:30:35 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 07 Apr 2015 00:00:35 +0530 Subject: RFR 8076972: Several nashorn tests failing Message-ID: <5522D0CB.3090901@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8076972/ Thanks -Sundar From marcus.lagergren at oracle.com Mon Apr 6 18:33:18 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 6 Apr 2015 20:33:18 +0200 Subject: RFR 8076972: Several nashorn tests failing In-Reply-To: <5522D0CB.3090901@oracle.com> References: <5522D0CB.3090901@oracle.com> Message-ID: <3837EC48-3E42-445C-A2E0-25109BDE5F24@oracle.com> +1 > On 06 Apr 2015, at 20:30, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8076972/ > > Thanks > -Sundar From james.laskey at oracle.com Mon Apr 6 18:41:39 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 6 Apr 2015 15:41:39 -0300 Subject: RFR 8076972: Several nashorn tests failing In-Reply-To: <5522D0CB.3090901@oracle.com> References: <5522D0CB.3090901@oracle.com> Message-ID: +1 > On Apr 6, 2015, at 3:30 PM, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8076972/ > > Thanks > -Sundar From sundararajan.athijegannathan at oracle.com Tue Apr 7 05:44:52 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 07 Apr 2015 11:14:52 +0530 Subject: [8u60] approval request for 8076972: Several nashorn tests failing Message-ID: <55236ED4.5050305@oracle.com> Please approve. Bug: 8076972: Several nashorn tests failing Fix for https://bugs.openjdk.java.net/browse/JDK-8076646 resulted in a number of jtreg test failures. The current fix is to fix that regression. jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-April/004428.html jdk8 webrev: http://cr.openjdk.java.net/~sundar/8076972/8u60/ Apart from backporting fix for 8076972 "as is", I had to include one missing change in 8076446 fix. http://cr.openjdk.java.net/~sundar/8076646/webrev.00/test/src/jdk/nashorn/api/scripting/test/ScriptEngineTest.java.udiff.html @@ -539,11 +540,11 @@ @Test public void scriptObjectAutoConversionTest() throws ScriptException { final ScriptEngineManager m = new ScriptEngineManager(); final ScriptEngine e = m.getEngineByName("nashorn"); e.eval("obj = { foo: 'hello' }"); - e.put("Window", e.eval("Packages.jdk.nashorn.api.scripting.Window")); + e.put("Window", e.eval("Packages.jdk.nashorn.api.scripting.test.Window")); assertEquals(e.eval("Window.funcJSObject(obj)"), "hello"); assertEquals(e.eval("Window.funcScriptObjectMirror(obj)"), "hello"); assertEquals(e.eval("Window.funcMap(obj)"), "hello"); assertEquals(e.eval("Window.funcJSObject(obj)"), "hello"); } was missed. CC'ing nashorn team just in case if additional review is needed. Related fix: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-April/003347.html Thanks, -Sundar From sean.coffey at oracle.com Tue Apr 7 06:48:14 2015 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 07 Apr 2015 07:48:14 +0100 Subject: [8u60] approval request for 8076972: Several nashorn tests failing In-Reply-To: <55236ED4.5050305@oracle.com> References: <55236ED4.5050305@oracle.com> Message-ID: <020CD9AE-08F8-4818-9F40-954BCF2A8A9B@oracle.com> Please get a peer review before pushing. Approved. Regards, Sean. On 7 April 2015 06:44:52 GMT+01:00, "A. Sundararajan" wrote: >Please approve. > >Bug: 8076972: Several nashorn tests failing > >Fix for https://bugs.openjdk.java.net/browse/JDK-8076646 resulted in a >number of jtreg test failures. The current fix is to fix that >regression. > >jdk9 review thread: >http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-April/004428.html > >jdk8 webrev: http://cr.openjdk.java.net/~sundar/8076972/8u60/ > >Apart from backporting fix for 8076972 "as is", I had to include one >missing change in 8076446 fix. > >http://cr.openjdk.java.net/~sundar/8076646/webrev.00/test/src/jdk/nashorn/api/scripting/test/ScriptEngineTest.java.udiff.html >@@ -539,11 +540,11 @@ > @Test > public void scriptObjectAutoConversionTest() throws ScriptException { > final ScriptEngineManager m = new ScriptEngineManager(); > final ScriptEngine e = m.getEngineByName("nashorn"); > e.eval("obj = { foo: 'hello' }"); >- e.put("Window", >e.eval("Packages.jdk.nashorn.api.scripting.Window")); >+ e.put("Window", >e.eval("Packages.jdk.nashorn.api.scripting.test.Window")); > assertEquals(e.eval("Window.funcJSObject(obj)"), "hello"); > assertEquals(e.eval("Window.funcScriptObjectMirror(obj)"), >"hello"); > assertEquals(e.eval("Window.funcMap(obj)"), "hello"); > assertEquals(e.eval("Window.funcJSObject(obj)"), "hello"); > } > >was missed. CC'ing nashorn team just in case if additional review is >needed. > >Related fix: >http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-April/003347.html > >Thanks, >-Sundar -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From marcus.lagergren at oracle.com Tue Apr 7 08:17:56 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 7 Apr 2015 10:17:56 +0200 Subject: [8u60] approval request for 8076972: Several nashorn tests failing In-Reply-To: <55236ED4.5050305@oracle.com> References: <55236ED4.5050305@oracle.com> Message-ID: +1. Looks good to me! /M (reviewer) > On 07 Apr 2015, at 07:44, A. Sundararajan wrote: > > Please approve. > > Bug: 8076972: Several nashorn tests failing > > Fix for https://bugs.openjdk.java.net/browse/JDK-8076646 resulted in a number of jtreg test failures. The current fix is to fix that regression. > > jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-April/004428.html > > jdk8 webrev: http://cr.openjdk.java.net/~sundar/8076972/8u60/ > > Apart from backporting fix for 8076972 "as is", I had to include one missing change in 8076446 fix. > > http://cr.openjdk.java.net/~sundar/8076646/webrev.00/test/src/jdk/nashorn/api/scripting/test/ScriptEngineTest.java.udiff.html > @@ -539,11 +540,11 @@ > @Test > public void scriptObjectAutoConversionTest() throws ScriptException { > final ScriptEngineManager m = new ScriptEngineManager(); > final ScriptEngine e = m.getEngineByName("nashorn"); > e.eval("obj = { foo: 'hello' }"); > - e.put("Window", e.eval("Packages.jdk.nashorn.api.scripting.Window")); > + e.put("Window", e.eval("Packages.jdk.nashorn.api.scripting.test.Window")); > assertEquals(e.eval("Window.funcJSObject(obj)"), "hello"); > assertEquals(e.eval("Window.funcScriptObjectMirror(obj)"), "hello"); > assertEquals(e.eval("Window.funcMap(obj)"), "hello"); > assertEquals(e.eval("Window.funcJSObject(obj)"), "hello"); > } > > was missed. CC'ing nashorn team just in case if additional review is needed. > > Related fix: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-April/003347.html > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Tue Apr 7 08:54:45 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 07 Apr 2015 10:54:45 +0200 Subject: [8u60] approval request for 8076972: Several nashorn tests failing In-Reply-To: <55236ED4.5050305@oracle.com> References: <55236ED4.5050305@oracle.com> Message-ID: <55239B55.1000707@oracle.com> +1 Hannes Am 2015-04-07 um 07:44 schrieb A. Sundararajan: > Please approve. > > Bug: 8076972: Several nashorn tests failing > > Fix for https://bugs.openjdk.java.net/browse/JDK-8076646 resulted in a > number of jtreg test failures. The current fix is to fix that regression. > > jdk9 review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-April/004428.html > > jdk8 webrev: http://cr.openjdk.java.net/~sundar/8076972/8u60/ > > Apart from backporting fix for 8076972 "as is", I had to include one > missing change in 8076446 fix. > > http://cr.openjdk.java.net/~sundar/8076646/webrev.00/test/src/jdk/nashorn/api/scripting/test/ScriptEngineTest.java.udiff.html > > @@ -539,11 +540,11 @@ > @Test > public void scriptObjectAutoConversionTest() throws ScriptException { > final ScriptEngineManager m = new ScriptEngineManager(); > final ScriptEngine e = m.getEngineByName("nashorn"); > e.eval("obj = { foo: 'hello' }"); > - e.put("Window", > e.eval("Packages.jdk.nashorn.api.scripting.Window")); > + e.put("Window", > e.eval("Packages.jdk.nashorn.api.scripting.test.Window")); > assertEquals(e.eval("Window.funcJSObject(obj)"), "hello"); > assertEquals(e.eval("Window.funcScriptObjectMirror(obj)"), > "hello"); > assertEquals(e.eval("Window.funcMap(obj)"), "hello"); > assertEquals(e.eval("Window.funcJSObject(obj)"), "hello"); > } > > was missed. CC'ing nashorn team just in case if additional review is > needed. > > Related fix: > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-April/003347.html > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Tue Apr 7 10:22:14 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 07 Apr 2015 12:22:14 +0200 Subject: Reusing ScriptContext and Global Variables In-Reply-To: References: Message-ID: <5523AFD6.7090805@oracle.com> Hi Tony, Yes, I think your setup should work. ScriptEngine.ENGINE_SCOPE is equivalent to the JavaScript global object, while GLOBAL_SCOPE can be used to provide default values that are shared between JS globals. Hannes Am 2015-04-06 um 15:56 schrieb Tony Zakula: > Hello, > > We are running scripts server side and using the multi-threaded example > running the same ScriptEngine across multiple threads as per the recent > blog posts and examples here: > > https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using > > If I understand the notes below correctly, we can: > > 1. Seed a ScriptContext.Global_Scope from the Java side with default > variables and values shared between all scripts and threads. These could > never be changed from JavaScript code directly. > > 2. We would use a new ScriptContext for each request that gets the default > binding and any new bindings we may want to add using the example below. > > 3. Based on the example and notes in the link, if someone assigned a global > variable with the same name as something in our ScriptContext.Global_Scope, > it would only affect that request ScriptContext and not pollute our default > ScriptContext. > > Did I interpret that all correctly? > > Another further optimization it seems we could make is to cache and > associate a ScriptContext per user between requests. This would > effectively give us a per user JS engine across multiple requests with very > little overhead it would seem. > > Thanks, > > Tony > > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes > > ScriptContext defCtx = engine.getContext(); > defCtx.getBindings(ScriptContext.GLOBAL_SCOPE).put("foo", "hello"); > ScriptContext myCtx = new SimpleScriptContext(); > myCtx.setBindings(defCtx.getBindings(ScriptContext.ENGINE_SCOPE), > ScriptContext.ENGINE_SCOPE); > Bindings b = new SimpleBindings(); b.put("foo", "world"); > myCtx.setBindings(b, ScriptContext.GLOBAL_SCOPE); From hannes.wallnoefer at oracle.com Thu Apr 9 08:58:40 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 09 Apr 2015 10:58:40 +0200 Subject: Review request for JDK-8067215: Disable dual fields when not using optimistic types Message-ID: <55263F40.7050007@oracle.com> Please review JDK-8067215: Disable dual fields when not using optimistic types: http://cr.openjdk.java.net/~hannesw/8067215/ This makes single or dual field representation dependent on optimistic types setting (can be overridden with system properties). Since both dual and single field objects can coexist in the same VM and class loader and both have to be distinguishable at runtime (e.g. for caching getter and setter methodhandles in AccessorProperty) I had to use separate class names for both. I introduced jdk.nashorn.internal.scripts.JD for dual fields while using the existing JO name scheme for single field representation. I also added a new property flag as a property with dual fields must not be equal to the same property with object only fields. On the other hand, nasgen-generated properties always use their native type, i.e. primitive accessors if their type is primitive and object accessors otherwise. This is because nasgen-generated property maps are static and have to work in both modes, and using them in non-optimistic mode requires boxing/unboxing anyway. I also did some cleanup in related areas such as not creating a primitive spill in single field mode and removing ScriptObject.spillLength field which was not really needed. I see an improvement in non-optimistic performance with octane. As expected, optimistic performance does not seem to be affected. Thanks, Hannes From attila.szegedi at oracle.com Fri Apr 10 07:11:01 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 10 Apr 2015 09:11:01 +0200 Subject: Review request for JDK-8067215: Disable dual fields when not using optimistic types In-Reply-To: <55263F40.7050007@oracle.com> References: <55263F40.7050007@oracle.com> Message-ID: <3D452041-166C-48B7-A01C-806C12F09E28@oracle.com> +1 > On Apr 9, 2015, at 10:58 AM, Hannes Wallnoefer wrote: > > Please review JDK-8067215: Disable dual fields when not using optimistic types: > > http://cr.openjdk.java.net/~hannesw/8067215/ > > This makes single or dual field representation dependent on optimistic types setting (can be overridden with system properties). > > Since both dual and single field objects can coexist in the same VM and class loader and both have to be distinguishable at runtime (e.g. for caching getter and setter methodhandles in AccessorProperty) I had to use separate class names for both. I introduced jdk.nashorn.internal.scripts.JD for dual fields while using the existing JO name scheme for single field representation. I also added a new property flag as a property with dual fields must not be equal to the same property with object only fields. > > On the other hand, nasgen-generated properties always use their native type, i.e. primitive accessors if their type is primitive and object accessors otherwise. This is because nasgen-generated property maps are static and have to work in both modes, and using them in non-optimistic mode requires boxing/unboxing anyway. > > I also did some cleanup in related areas such as not creating a primitive spill in single field mode and removing ScriptObject.spillLength field which was not really needed. I see an improvement in non-optimistic performance with octane. As expected, optimistic performance does not seem to be affected. > > Thanks, > Hannes From marcus.lagergren at oracle.com Fri Apr 10 09:07:33 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 10 Apr 2015 11:07:33 +0200 Subject: Review request for JDK-8067215: Disable dual fields when not using optimistic types In-Reply-To: <55263F40.7050007@oracle.com> References: <55263F40.7050007@oracle.com> Message-ID: +1! Nicely done and well structured, Hannes! /M > On 09 Apr 2015, at 10:58, Hannes Wallnoefer wrote: > > Please review JDK-8067215: Disable dual fields when not using optimistic types: > > http://cr.openjdk.java.net/~hannesw/8067215/ > > This makes single or dual field representation dependent on optimistic types setting (can be overridden with system properties). > > Since both dual and single field objects can coexist in the same VM and class loader and both have to be distinguishable at runtime (e.g. for caching getter and setter methodhandles in AccessorProperty) I had to use separate class names for both. I introduced jdk.nashorn.internal.scripts.JD for dual fields while using the existing JO name scheme for single field representation. I also added a new property flag as a property with dual fields must not be equal to the same property with object only fields. > > On the other hand, nasgen-generated properties always use their native type, i.e. primitive accessors if their type is primitive and object accessors otherwise. This is because nasgen-generated property maps are static and have to work in both modes, and using them in non-optimistic mode requires boxing/unboxing anyway. > > I also did some cleanup in related areas such as not creating a primitive spill in single field mode and removing ScriptObject.spillLength field which was not really needed. I see an improvement in non-optimistic performance with octane. As expected, optimistic performance does not seem to be affected. > > Thanks, > Hannes From forax at univ-mlv.fr Mon Apr 13 07:08:30 2015 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 13 Apr 2015 09:08:30 +0200 Subject: JsJs Message-ID: <552B6B6E.4040905@univ-mlv.fr> Hi guys, I've written a simple AOT compiler [1] that takes a javascript file and transform it to a .class file that can run with a very small runtime. It uses the Nashorn Parser API and also Nashorn to bootstrap itself (the AOT is written in JavaScript). While the runtime is fairly naive, everything is considered as an java.lang.Object and JS Objects are hash maps (each field is accessed through a double indirection), I've found that Nashorn was really slow to run the AOT script (jsjs.js) compared to using jsjs to compile itself, given that some Nashorn stacktraces seems to show recompilation on top of recompilation on ... etc, I think there is a bug that lies somewhere in the runtime of Nashorn. You can run Nashorn on jsjs.js that way: jjs -J-Xbootclasspath/p:lib/nashorn.jar -cp classes:lib/asm-debug-all-5.0.3.jar jsjs.js -- jsjs.js and jsjs on jsjs.js that way: java -Xbootclasspath/p:lib/nashorn.jar -cp .:classes:lib/asm-debug-all-5.0.3.jar jsjs jsjs.js cheers, R?mi [1] https://github.com/forax/jsjs From daniel.smith at oracle.com Wed Apr 15 17:02:04 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 15 Apr 2015 11:02:04 -0600 Subject: Call for Speakers -- 2015 JVM Language Summit Message-ID: CALL FOR SPEAKERS -- JVM LANGUAGE SUMMIT, AUGUST 2015 We are pleased to announce the 2015 JVM Language Summit to be held at Oracle's Santa Clara campus on August 10-12, 2015. Registration is now open for speaker submissions (presentations and workshops) and will remain open until May 22, 2015. There is no registration fee for speakers. The JVM Language Summit is an open technical collaboration among language designers, compiler writers, tool builders, runtime engineers, and VM architects. We will share our experiences as creators of both the JVM and programming languages for the JVM. We also welcome non-JVM developers of similar technologies to attend or speak on their runtime, VM, or language of choice. Presentations will be recorded and made available to the public via the Oracle Technology Network. This event is being organized by language and JVM engineers; no marketers involved! So bring your slide rules and be prepared for some seriously geeky discussions. Format The summit is held in a single classroom-style room to support direct communication between participants. About 80-100 attendees are expected. As in previous years, we will divide the schedule between traditional presentations and "workshops." Workshops are informal, facilitated discussion groups among smaller, self-selected participants, and should enable deeper "dives" into the subject matter. If there is interest, there will also be impromptu "lightning talks." Traditional presentations (about 7 each day) will be given in a single track, while workshops (2?3 each day) will occur in parallel. Instructions for Speaker Registration If you'd like give a presentation or lead a workshop, please register as a Speaker and include a detailed abstract. There is no fee. You will be notified about whether your proposal has been accepted; if not, you will be able to register as a regular attendee. For a successful presentation or workshop submission, please note the following: - All talks should be deeply technical, given by designers and implementors to designers and implementors. We all speak Code here! - Each talk, we hope and expect, will inform the audience, in detail, about the state of the art of language design and implementation on the JVM, or will explore the present and future capabilities of the JVM itself. (Some will do so indirectly by discussing non-JVM technologies.) - Know your audience: attendees may not be likely to ever use your specific language or tool, but could learn something from your interactions with the JVM. A broad goal of the summit is to inspire us to work together on JVM-based technologies that enable a rich ecosystem at higher layers. We encourage speakers to submit both a presentation and a workshop; we will arrange to schedule the presentation before the workshop, so that the presentation can spark people's interest and the workshop will allow those who are really interested to go deeper into the subject area. Workshop facilitators may, but are not expected to, prepare presentation materials; in any case, they should come prepared to guide a deep technical discussion. To register: regonline.com/jvmls2015 For further information: jvmlangsummit.com Questions: inquire at jvmlangsummit.com We hope to see you in August! From hannes.wallnoefer at oracle.com Thu Apr 16 14:26:56 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 16 Apr 2015 16:26:56 +0200 Subject: Review request for JDK-8077955: Undeclared globals in eval code should not be handled as fast scope Message-ID: <552FC6B0.3040304@oracle.com> Please review JDK-8077955: Undeclared globals in eval code should not be handled as fast scope: http://cr.openjdk.java.net/~hannesw/8077955/ Thanks, Hannes From marcus.lagergren at oracle.com Thu Apr 16 15:13:05 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 16 Apr 2015 17:13:05 +0200 Subject: Review request for JDK-8077955: Undeclared globals in eval code should not be handled as fast scope In-Reply-To: <552FC6B0.3040304@oracle.com> References: <552FC6B0.3040304@oracle.com> Message-ID: <05902C7A-BD37-4E34-AEDE-1C7BD876628B@oracle.com> +1 > On 16 Apr 2015, at 16:26, Hannes Wallnoefer wrote: > > Please review JDK-8077955: Undeclared globals in eval code should not be handled as fast scope: > > http://cr.openjdk.java.net/~hannesw/8077955/ > > Thanks, > Hannes From attila.szegedi at oracle.com Thu Apr 16 15:13:48 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 16 Apr 2015 17:13:48 +0200 Subject: Review request for JDK-8077955: Undeclared globals in eval code should not be handled as fast scope In-Reply-To: <552FC6B0.3040304@oracle.com> References: <552FC6B0.3040304@oracle.com> Message-ID: <545D0D5E-DF6A-4609-A8F2-A2434FE83002@oracle.com> +1 > On Apr 16, 2015, at 4:26 PM, Hannes Wallnoefer wrote: > > Please review JDK-8077955: Undeclared globals in eval code should not be handled as fast scope: > > http://cr.openjdk.java.net/~hannesw/8077955/ > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Fri Apr 17 14:12:38 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 17 Apr 2015 16:12:38 +0200 Subject: Review request for JDK-8071928 and JDK-8073846 Message-ID: <553114D6.6090509@oracle.com> Please review JDK-8071928 and JDK-8073846: http://cr.openjdk.java.net/~hannesw/8071928/ http://cr.openjdk.java.net/~hannesw/8073846/ These are two test-only commits for bugs that are already fixed in both JDK9 and 8u60. Thanks, Hannes From attila.szegedi at oracle.com Fri Apr 17 14:18:58 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 17 Apr 2015 16:18:58 +0200 Subject: Review request for JDK-8071928 and JDK-8073846 In-Reply-To: <553114D6.6090509@oracle.com> References: <553114D6.6090509@oracle.com> Message-ID: +1 > On Apr 17, 2015, at 4:12 PM, Hannes Wallnoefer wrote: > > Please review JDK-8071928 and JDK-8073846: > > http://cr.openjdk.java.net/~hannesw/8071928/ > http://cr.openjdk.java.net/~hannesw/8073846/ > > These are two test-only commits for bugs that are already fixed in both JDK9 and 8u60. > > Thanks, > Hannes From sadhak001 at gmail.com Sat Apr 18 08:50:30 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Sat, 18 Apr 2015 09:50:30 +0100 Subject: How to load the Nashorn project in IntelliJ - by Dmitri Alexandrov Message-ID: Hi all, Dmitri has something to share with us, he has been hacking away with Nashorn for sometime and now has share with us the tricks to load Nashorn into IntellIj for all good reasons: http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/content/source-code/loading_openjdk_in_intellij.html Thanks Dmitri for adding it to the Adopt OpenJDK GSK gitbook, and hope you enjoy doing some Nashorn hacks over the weekend. Cheers, Mani -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From tonyzakula at gmail.com Sat Apr 18 15:02:00 2015 From: tonyzakula at gmail.com (Tony Zakula) Date: Sat, 18 Apr 2015 10:02:00 -0500 Subject: Question on Caching and Thank You Message-ID: Hey All, First off let me thank the Nashorn team for all the work on performance. The latest is extremely awesome and impressive to say the least. I have been working on a project to see if the same performance could be achieved by replacing a custom JSP system with a JS template system leveraging Nashorn, and I think it is just about there. I just had a quick question on caching. We are creating our engine for use on multiple threads with something like the following: System.setProperty("nashorn.typeInfo.maxFiles", "20000"); final ScriptEngine engine = new NashornScriptEngineFactory().getScriptEngine(new String[] {"-ccs=500", "-ot=true"}); and we will try the "-pcc" soon. We use a JS written template system. We compile the template to JS code in JS and the cache it in a Java Map that is available to all scripts on all threads. When a template is included, we use the compiled template from the Java Map and use *eval* to run the template. Since the template is always the same until it is changed, my assumption is Nashorn compiles and caches it for reuse. My questions is, what is the best way to leverage the caching? Is eval fine? Or should we potentially save the compiled JS templates to disk and then load them with the load command or URL to achieve better performance? Thanks, Tony From marcus.lagergren at oracle.com Mon Apr 20 07:12:39 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 20 Apr 2015 09:12:39 +0200 Subject: Review request for JDK-8071928 and JDK-8073846 In-Reply-To: References: <553114D6.6090509@oracle.com> Message-ID: <5F9095BC-4182-42D4-85E7-2AE9E8108AB3@oracle.com> +1 > On 17 Apr 2015, at 16:18, Attila Szegedi wrote: > > +1 > >> On Apr 17, 2015, at 4:12 PM, Hannes Wallnoefer wrote: >> >> Please review JDK-8071928 and JDK-8073846: >> >> http://cr.openjdk.java.net/~hannesw/8071928/ >> http://cr.openjdk.java.net/~hannesw/8073846/ >> >> These are two test-only commits for bugs that are already fixed in both JDK9 and 8u60. >> >> Thanks, >> Hannes > From marcus.lagergren at oracle.com Mon Apr 20 07:12:34 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 20 Apr 2015 09:12:34 +0200 Subject: How to load the Nashorn project in IntelliJ - by Dmitri Alexandrov In-Reply-To: References: Message-ID: This is great! Thanks Dmitri! Jim - can we do a blog entry on this on the official Nashorn block? /M > On 18 Apr 2015, at 10:50, Mani Sarkar wrote: > > Hi all, > > Dmitri has something to share with us, he has been hacking away with > Nashorn for sometime and now has share with us the tricks to load Nashorn > into IntellIj for all good reasons: > > http://neomatrix369.gitbooks.io/adoptopenjdk-getting-started-kit/content/source-code/loading_openjdk_in_intellij.html > > Thanks Dmitri for adding it to the Adopt OpenJDK GSK gitbook, and hope you > enjoy doing some Nashorn hacks over the weekend. > > Cheers, > Mani > > -- > @theNeomatrix369 * | **Blog > ** | *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > * | **Bitbucket > * * | **Github > * * | **LinkedIn > * > *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/ > > *Don't chase success, rather aim for "Excellence", and success will come > chasing after you!* From sundararajan.athijegannathan at oracle.com Mon Apr 20 13:05:29 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 20 Apr 2015 18:35:29 +0530 Subject: Question on Caching and Thank You In-Reply-To: References: Message-ID: <5534F999.1080905@oracle.com> You could create and reuse javax.script.CompiledScript instances on the same engine instance. That should work for you. -Sundar On Saturday 18 April 2015 08:32 PM, Tony Zakula wrote: > Hey All, > > First off let me thank the Nashorn team for all the work on performance. > The latest is extremely awesome and impressive to say the least. I have > been working on a project to see if the same performance could be achieved > by replacing a custom JSP system with a JS template system leveraging > Nashorn, and I think it is just about there. > > I just had a quick question on caching. We are creating our engine for use > on multiple threads with something like the following: > > System.setProperty("nashorn.typeInfo.maxFiles", "20000"); > final ScriptEngine engine = new > NashornScriptEngineFactory().getScriptEngine(new String[] {"-ccs=500", > "-ot=true"}); > > and we will try the "-pcc" soon. > > We use a JS written template system. We compile the template to JS code in > JS and the cache it in a Java Map that is available to all scripts on all > threads. When a template is included, we use the compiled template from > the Java Map and use *eval* to run the template. Since the template is > always the same until it is changed, my assumption is Nashorn compiles and > caches it for reuse. > > My questions is, what is the best way to leverage the caching? Is eval > fine? Or should we potentially save the compiled JS templates to disk and > then load them with the load command or URL to achieve better performance? > > Thanks, > > Tony From sundararajan.athijegannathan at oracle.com Mon Apr 20 13:55:12 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 20 Apr 2015 19:25:12 +0530 Subject: RFR 8078174: Add few FX and parser API samples for nashorn Message-ID: <55350540.1040001@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8078174/ Thanks, -Sundar From hannes.wallnoefer at oracle.com Mon Apr 20 13:59:55 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 20 Apr 2015 15:59:55 +0200 Subject: RFR 8078174: Add few FX and parser API samples for nashorn In-Reply-To: <55350540.1040001@oracle.com> References: <55350540.1040001@oracle.com> Message-ID: <5535065B.2000504@oracle.com> +1 Am 2015-04-20 um 15:55 schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8078174/ > > Thanks, > -Sundar From marcus.lagergren at oracle.com Mon Apr 20 15:04:01 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 20 Apr 2015 17:04:01 +0200 Subject: RFR 8078174: Add few FX and parser API samples for nashorn In-Reply-To: <55350540.1040001@oracle.com> References: <55350540.1040001@oracle.com> Message-ID: <528391F4-E9CB-42A7-B028-EB7F14A87C2A@oracle.com> +1 > On 20 Apr 2015, at 15:55, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8078174/ > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Wed Apr 22 16:53:18 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 22 Apr 2015 22:23:18 +0530 Subject: [8u60] approval request for 8078384:Test execution blocker: Nashorn testsuite failing due to compile error in jdk/nashorn/api/scripting/test/ScriptEngineTest.java In-Reply-To: <5537D1D7.10607@oracle.com> References: <5537D1D7.10607@oracle.com> Message-ID: <5537D1FE.7050905@oracle.com> On Wednesday 22 April 2015 10:22 PM, A. Sundararajan wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8078384 > Webrev: http://cr.openjdk.java.net/~sundar/8078384/ > > Not a backport. Taking care of an issue caused by a recent merge. > Removing duplicated code in a test. CC'ing nashorn team. > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Fri Apr 24 14:19:34 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 24 Apr 2015 16:19:34 +0200 Subject: Review request for JDK-8066407: Function with same body not reparsed after SyntaxError Message-ID: <553A50F6.6070802@oracle.com> Please review JDK-8066407: Function with same body not reparsed after SyntaxError: http://cr.openjdk.java.net/~hannesw/8066407/ Thanks, Hannes From attila.szegedi at oracle.com Fri Apr 24 14:30:08 2015 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 24 Apr 2015 16:30:08 +0200 Subject: Review request for JDK-8066407: Function with same body not reparsed after SyntaxError In-Reply-To: <553A50F6.6070802@oracle.com> References: <553A50F6.6070802@oracle.com> Message-ID: <86CD1524-5B72-475A-84C8-076D6926C3CA@oracle.com> +1 > On Apr 24, 2015, at 4:19 PM, Hannes Wallnoefer wrote: > > Please review JDK-8066407: Function with same body not reparsed after SyntaxError: > > http://cr.openjdk.java.net/~hannesw/8066407/ > > Thanks, > Hannes From marcus.lagergren at oracle.com Fri Apr 24 14:48:06 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 24 Apr 2015 16:48:06 +0200 Subject: Review request for JDK-8066407: Function with same body not reparsed after SyntaxError In-Reply-To: <553A50F6.6070802@oracle.com> References: <553A50F6.6070802@oracle.com> Message-ID: <68F181CA-0E1B-494A-A61A-5A3B9A4BE615@oracle.com> +1 > On 24 Apr 2015, at 16:19, Hannes Wallnoefer wrote: > > Please review JDK-8066407: Function with same body not reparsed after SyntaxError: > > http://cr.openjdk.java.net/~hannesw/8066407/ > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Fri Apr 24 14:49:36 2015 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 24 Apr 2015 16:49:36 +0200 Subject: Review request for JDK-8053905: Eager code generation fails for earley boyer with split threshold set to 1000 Message-ID: <553A5800.4020704@oracle.com> Please review JDK-8053905: Eager code generation fails for earley boyer with split threshold set to 1000: http://cr.openjdk.java.net/~hannesw/8053905/ This involves a bit of refactoring around StoredScript which makes the handling of persisted scripts a bit cleaner and allows us to restore the old sanity check we had in place when setting code in RecompilableScriptFunctionData. Thanks, Hannes From marcus.lagergren at oracle.com Mon Apr 27 06:14:04 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 27 Apr 2015 08:14:04 +0200 Subject: Review request for JDK-8053905: Eager code generation fails for earley boyer with split threshold set to 1000 In-Reply-To: <553A5800.4020704@oracle.com> References: <553A5800.4020704@oracle.com> Message-ID: +1 > On 24 Apr 2015, at 16:49, Hannes Wallnoefer wrote: > > Please review JDK-8053905: Eager code generation fails for earley boyer with split threshold set to 1000: > > http://cr.openjdk.java.net/~hannesw/8053905/ > > This involves a bit of refactoring around StoredScript which makes the handling of persisted scripts a bit cleaner and allows us to restore the old sanity check we had in place when setting code in RecompilableScriptFunctionData. > > Thanks, > Hannes From cnewland at chrisnewland.com Tue Apr 28 17:24:00 2015 From: cnewland at chrisnewland.com (Chris Newland) Date: Tue, 28 Apr 2015 18:24:00 +0100 Subject: Nashorn Octane JMH code publicly available? Message-ID: <44d8657fa857d44be1301f0b0c8cd225.squirrel@excalibur.xssl.net> Hi, https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+Performance indicates the JMH microbenchmarks for octane are internal to Oracle (VPN needed). I can't see them elsewhere in the OpenJDK repos, are they public? Asking because the results I'm getting from nashorn/test/script/external/octane$ jjs run.js are wildly variable (as per above wiki page). Thanks, Chris From marcus.lagergren at oracle.com Wed Apr 29 07:08:06 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 29 Apr 2015 09:08:06 +0200 Subject: Nashorn Octane JMH code publicly available? In-Reply-To: <44d8657fa857d44be1301f0b0c8cd225.squirrel@excalibur.xssl.net> References: <44d8657fa857d44be1301f0b0c8cd225.squirrel@excalibur.xssl.net> Message-ID: <935E1B44-954F-4001-BFC2-72CDCE22991C@oracle.com> The benchmark code itself is public, but I don?t know if the benchmarks as part of JMH are. CC Aleksey /M > On 28 Apr 2015, at 19:24, Chris Newland wrote: > > Hi, > > https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+Performance > indicates the JMH microbenchmarks for octane are internal to Oracle (VPN > needed). > > I can't see them elsewhere in the OpenJDK repos, are they public? > > Asking because the results I'm getting from > > nashorn/test/script/external/octane$ jjs run.js > > are wildly variable (as per above wiki page). > > Thanks, > > Chris > From marcus.lagergren at oracle.com Wed Apr 29 08:13:27 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 29 Apr 2015 10:13:27 +0200 Subject: Nashorn Octane JMH code publicly available? In-Reply-To: <935E1B44-954F-4001-BFC2-72CDCE22991C@oracle.com> References: <44d8657fa857d44be1301f0b0c8cd225.squirrel@excalibur.xssl.net> <935E1B44-954F-4001-BFC2-72CDCE22991C@oracle.com> Message-ID: <0BB75B06-BBE6-4B74-B2F2-E6679B6D04E5@oracle.com> And I should really CC Aleksey this time. > On 29 Apr 2015, at 09:08, Marcus Lagergren wrote: > > The benchmark code itself is public, but I don?t know if the benchmarks as part of JMH are. CC Aleksey > /M > >> On 28 Apr 2015, at 19:24, Chris Newland wrote: >> >> Hi, >> >> https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+Performance >> indicates the JMH microbenchmarks for octane are internal to Oracle (VPN >> needed). >> >> I can't see them elsewhere in the OpenJDK repos, are they public? >> >> Asking because the results I'm getting from >> >> nashorn/test/script/external/octane$ jjs run.js >> >> are wildly variable (as per above wiki page). >> >> Thanks, >> >> Chris >> > From marcus.lagergren at oracle.com Thu Apr 30 07:18:54 2015 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 30 Apr 2015 09:18:54 +0200 Subject: Nashorn Octane JMH code publicly available? In-Reply-To: <935E1B44-954F-4001-BFC2-72CDCE22991C@oracle.com> References: <44d8657fa857d44be1301f0b0c8cd225.squirrel@excalibur.xssl.net> <935E1B44-954F-4001-BFC2-72CDCE22991C@oracle.com> Message-ID: > On 29 Apr 2015, at 09:08, Marcus Lagergren wrote: > > The benchmark code itself is public, but I don?t know if the benchmarks as part of JMH are. CC Aleksey > /M > >> On 28 Apr 2015, at 19:24, Chris Newland wrote: >> >> Hi, >> >> https://wiki.openjdk.java.net/display/Nashorn/Monitoring+Nashorn+Performance >> indicates the JMH microbenchmarks for octane are internal to Oracle (VPN >> needed). >> >> I can't see them elsewhere in the OpenJDK repos, are they public? >> >> Asking because the results I'm getting from >> >> nashorn/test/script/external/octane$ jjs run.js >> >> are wildly variable (as per above wiki page). >> >> Thanks, >> >> Chris >> > From jfleming at linkedin.com Thu Apr 30 13:32:00 2015 From: jfleming at linkedin.com (Josh Fleming) Date: Thu, 30 Apr 2015 13:32:00 +0000 Subject: Nashorn heap profiling Message-ID: Hi folks, What's the best way to do heap profiling of JavaScript code in Nashorn? We're running a large JavaScript framework on Nashorn, and recently I had to track down a couple memory leaks. This turned out to be a painful process. When using a heap profiler like YourKit, it's very tedious to find the correspondence between what you see in a JVM retention path and the exact JavaScript code it originates from: there are multiple layers of JVM representation, and the naming is a bit cryptic. Eventually I fell back on a manual process of drilling down to the "JO* -> map -> properties -> list" linked list to find a unique property name within each JavaScript object, and used what I found there to grep the JavaScript code. The situation is better if you happen to come upon a closure, because the "data -> functionName" property in ScriptFunctionImpl includes a line number. But it seems like there must be a better way. Any guidance would be much appreciated. Thanks, jf