From sundararajan.athijegannathan at oracle.com Sat Nov 1 13:19:19 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Sat, 01 Nov 2014 18:49:19 +0530 Subject: Passing objects between Nashorn engines In-Reply-To: <5453A84E.4070904@gmail.com> References: <5453A84E.4070904@gmail.com> Message-ID: <5454DDD7.8070905@oracle.com> Yes, ScriptObjectMirror keeps the underlying ScriptObject and Global instance in whose scope that object was created. So long as a ScriptObjectMirror is alive, the ScriptObject and associated Global instance (and any transitive data) would be alive. -Sundar On Friday 31 October 2014 08:48 PM, Serguei Mourachov wrote: > I'm working on implementing automatic javascript code reloading. > The process is implemented using following sequence: when I'm seeing > any modification our our JS files, I'm preserving state of our system > calling a function returning ScriptObjectMirror, creating new > ScriptEngine, and initializing its state passing the > ScriptObjectMirror to it. > Apparently, it It works as expected in my simple tests, but it seems > that the initial ScriptObjectMirror keeps reference to its original > global and potentially to other old engine internals. > So my question is: is that safe in to share ScriptObjectMirror objects > between multiple engines and can I assume it's not going to create a > memory leak, keeping all the previous engines in memory after I > stopped using them? > > SM > > From lagergren at gmail.com Sun Nov 2 12:29:38 2014 From: lagergren at gmail.com (Marcus Lagergren) Date: Sun, 2 Nov 2014 13:29:38 +0100 Subject: Remove warnings Message-ID: <591049CE-54B5-4BFD-B2DF-064F8BD33192@gmail.com> Please review JDK-8060204 - Remove warnings in Joni and other places Got rid of ~1400 warnings Webrev at: http://cr.openjdk.java.net/~lagergren/8060204/ /M From marcus.lagergren at oracle.com Sun Nov 2 15:31:12 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Sun, 2 Nov 2014 16:31:12 +0100 Subject: Please review JDK-8060204 Message-ID: <52050DFC-7FA1-47E8-96B1-EB86CF85DBA1@oracle.com> Please review JDK-8060204 - Remove warnings in Joni and other places Got rid of ~1400 warnings Webrev at: http://cr.openjdk.java.net/~lagergren/8060204/ /M From kishori.sharan at gmail.com Sun Nov 2 16:31:52 2014 From: kishori.sharan at gmail.com (Kishori Sharan) Date: Sun, 2 Nov 2014 10:31:52 -0600 Subject: The printf() function in jjs Message-ID: Hello, Why is the printf() function not available in jjs or when I run the script from NetBeans IDE? It is available when I run the script using embedded Nashorn engine and using jrunscript command. Thanks Kishori From attila.szegedi at oracle.com Mon Nov 3 06:32:58 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 3 Nov 2014 07:32:58 +0100 Subject: Please review JDK-8060204 In-Reply-To: <52050DFC-7FA1-47E8-96B1-EB86CF85DBA1@oracle.com> References: <52050DFC-7FA1-47E8-96B1-EB86CF85DBA1@oracle.com> Message-ID: Indentation in JSObjectLinker @@ -120,12 +120,10 @@ change looks odd. Other than that, +1. On Nov 2, 2014, at 4:31 PM, Marcus Lagergren wrote: > Please review JDK-8060204 - Remove warnings in Joni and other places > > Got rid of ~1400 warnings > > Webrev at: http://cr.openjdk.java.net/~lagergren/8060204/ > > /M From attila.szegedi at oracle.com Mon Nov 3 07:25:56 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 3 Nov 2014 08:25:56 +0100 Subject: Review request for JDK-8059443 Message-ID: <94068688-F2D8-4101-BF47-19C7416E4874@oracle.com> Please review JDK-8059443 at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Mon Nov 3 08:18:33 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 03 Nov 2014 13:48:33 +0530 Subject: Review request for JDK-8059443 In-Reply-To: <94068688-F2D8-4101-BF47-19C7416E4874@oracle.com> References: <94068688-F2D8-4101-BF47-19C7416E4874@oracle.com> Message-ID: <54573A59.6090607@oracle.com> +1 On Monday 03 November 2014 12:55 PM, Attila Szegedi wrote: > Please review JDK-8059443 at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Nov 3 08:25:02 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 03 Nov 2014 13:55:02 +0530 Subject: Please review JDK-8060204 In-Reply-To: References: <52050DFC-7FA1-47E8-96B1-EB86CF85DBA1@oracle.com> Message-ID: <54573BDE.1040802@oracle.com> +1 Please run "ant javadoc" and "ant javadocapi". I recall couple of -> character issues in couple of places (and hence javadoc target build failed - even before your changes.). -Sundar On Monday 03 November 2014 12:02 PM, Attila Szegedi wrote: > Indentation in JSObjectLinker @@ -120,12 +120,10 @@ change looks odd. Other than that, +1. > > On Nov 2, 2014, at 4:31 PM, Marcus Lagergren wrote: > >> Please review JDK-8060204 - Remove warnings in Joni and other places >> >> Got rid of ~1400 warnings >> >> Webrev at: http://cr.openjdk.java.net/~lagergren/8060204/ >> >> /M From marcus.lagergren at oracle.com Mon Nov 3 08:53:28 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 3 Nov 2014 09:53:28 +0100 Subject: Review request for JDK-8059443 In-Reply-To: <94068688-F2D8-4101-BF47-19C7416E4874@oracle.com> References: <94068688-F2D8-4101-BF47-19C7416E4874@oracle.com> Message-ID: <4DEF692F-3A8E-47D6-8F5F-0135AD4C2DE8@oracle.com> +1 > On 03 Nov 2014, at 08:25, Attila Szegedi wrote: > > Please review JDK-8059443 at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Mon Nov 3 08:56:49 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 03 Nov 2014 09:56:49 +0100 Subject: Please review JDK-8060204 In-Reply-To: <52050DFC-7FA1-47E8-96B1-EB86CF85DBA1@oracle.com> References: <52050DFC-7FA1-47E8-96B1-EB86CF85DBA1@oracle.com> Message-ID: <54574351.9040300@oracle.com> Wow, this is one massive cleanup! To my knowledge we still have a blank line between static and non-static imports, right? Based on that, below is my list of nitpicks. Otherwise +1. objects/ArrayBufferView: linker/BrowserJSObjectLinker: joni/ast/QuantifierNode: joni/Analyzer: joni/ArrayCompiler: joni/ByteCodeMachine: joni/Lexer: joni/Matcher: joni/Parser: joni/ScanEnvironment: joni/StackMachine: joni/Syntax: runtime/RecompilableScriptFunctionData: plus many test classes: Keep black line between static and normal imports. linker/JSObjectLinker: Indentation of former else branch in line 124 joni/ast/Node: Indentation of getChild end bracket joni/ByteCodeMachine: opening bracket in new line in line 882 joni/Matcher: please preserve /* check only */ comment test/.../OctaneTest: you're adding tests for mandreel, typescript and zlib - not sure if this is intentional? Am 2014-11-02 um 16:31 schrieb Marcus Lagergren: > Please review JDK-8060204 - Remove warnings in Joni and other places > > Got rid of ~1400 warnings > > Webrev at: http://cr.openjdk.java.net/~lagergren/8060204/ > > /M From marcus.lagergren at oracle.com Mon Nov 3 11:00:31 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 3 Nov 2014 12:00:31 +0100 Subject: Please review JDK-8062381 Message-ID: <1CD7F171-D805-407E-9828-5B535416C036@oracle.com> Used the wrong index for the index in charCodeAt at link time. http://cr.openjdk.java.net/~lagergren/8062381/ /M From attila.szegedi at oracle.com Mon Nov 3 11:01:32 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 3 Nov 2014 12:01:32 +0100 Subject: Please review JDK-8062381 In-Reply-To: <1CD7F171-D805-407E-9828-5B535416C036@oracle.com> References: <1CD7F171-D805-407E-9828-5B535416C036@oracle.com> Message-ID: <68605DF4-1F7F-47BD-9B18-B472ADC2BC61@oracle.com> +1 On Nov 3, 2014, at 12:00 PM, Marcus Lagergren wrote: > Used the wrong index for the index in charCodeAt at link time. > > http://cr.openjdk.java.net/~lagergren/8062381/ > > /M > From hannes.wallnoefer at oracle.com Mon Nov 3 11:01:50 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 03 Nov 2014 12:01:50 +0100 Subject: Please review JDK-8062381 In-Reply-To: <1CD7F171-D805-407E-9828-5B535416C036@oracle.com> References: <1CD7F171-D805-407E-9828-5B535416C036@oracle.com> Message-ID: <5457609E.5090802@oracle.com> +1 Am 2014-11-03 um 12:00 schrieb Marcus Lagergren: > Used the wrong index for the index in charCodeAt at link time. > > http://cr.openjdk.java.net/~lagergren/8062381/ > > /M > From marcus.lagergren at oracle.com Mon Nov 3 12:56:53 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 3 Nov 2014 13:56:53 +0100 Subject: Please review JDK-8061959.js Message-ID: <18012DE8-03FF-4D28-B465-6D59C57E4690@oracle.com> ArrayBuffer was lacking isView static method contrary to what the spec says. Webrev at http://cr.openjdk.java.net/~lagergren/8061959/ /M From attila.szegedi at oracle.com Mon Nov 3 12:58:08 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 3 Nov 2014 13:58:08 +0100 Subject: Please review JDK-8061959.js In-Reply-To: <18012DE8-03FF-4D28-B465-6D59C57E4690@oracle.com> References: <18012DE8-03FF-4D28-B465-6D59C57E4690@oracle.com> Message-ID: <9821EC42-E657-4BE0-8EEE-18EBEFE42FD8@oracle.com> +1 On Nov 3, 2014, at 1:56 PM, Marcus Lagergren wrote: > ArrayBuffer was lacking isView static method contrary to what the spec says. > > Webrev at http://cr.openjdk.java.net/~lagergren/8061959/ > > /M > From marcus.lagergren at oracle.com Mon Nov 3 13:57:38 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 3 Nov 2014 14:57:38 +0100 Subject: Please review JDK-8062490 Message-ID: UntouchedArrayData didn?t expand to SparseArrayData directly, for large index, but rather through VERY LARGE IntArrayDatas. That, of course, is fatal. Webrev: http://cr.openjdk.java.net/~lagergren/8062490/ /M From hannes.wallnoefer at oracle.com Mon Nov 3 14:00:59 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 03 Nov 2014 15:00:59 +0100 Subject: Please review JDK-8062490 In-Reply-To: References: Message-ID: <54578A9B.6060702@oracle.com> +1 Am 2014-11-03 um 14:57 schrieb Marcus Lagergren: > UntouchedArrayData didn?t expand to SparseArrayData directly, for large index, but rather through VERY LARGE IntArrayDatas. That, of course, is fatal. > > Webrev: http://cr.openjdk.java.net/~lagergren/8062490/ > > /M > From attila.szegedi at oracle.com Mon Nov 3 14:02:22 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 3 Nov 2014 15:02:22 +0100 Subject: Please review JDK-8062490 In-Reply-To: References: Message-ID: <67DBA798-AE0E-42B1-8BD4-2ED396528D0F@oracle.com> +1 On Nov 3, 2014, at 2:57 PM, Marcus Lagergren wrote: > UntouchedArrayData didn?t expand to SparseArrayData directly, for large index, but rather through VERY LARGE IntArrayDatas. That, of course, is fatal. > > Webrev: http://cr.openjdk.java.net/~lagergren/8062490/ > > /M > From aleksey.shipilev at oracle.com Mon Nov 3 14:08:23 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 03 Nov 2014 17:08:23 +0300 Subject: Please review JDK-8062490 In-Reply-To: References: Message-ID: <54578C57.5090609@oracle.com> On 03.11.2014 16:57, Marcus Lagergren wrote: > UntouchedArrayData didn?t expand to SparseArrayData directly, for > large index, but rather through VERY LARGE IntArrayDatas. That, of > course, is fatal. > > Webrev: http://cr.openjdk.java.net/~lagergren/8062490/ Two questions about the same line: 39 static final long MAX_DENSE_LENGTH = 16 * 512 * 1024; 1) This is a weird magic number: should be 8 * 1024 * 1024? 2) Why not make it "int MAX_DENSE_LENGTH" and remove the asserts in static initializer? -Aleksey. From marcus.lagergren at oracle.com Mon Nov 3 14:11:12 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 3 Nov 2014 15:11:12 +0100 Subject: Please review JDK-8062490 In-Reply-To: <54578C57.5090609@oracle.com> References: <54578C57.5090609@oracle.com> Message-ID: Good questions. I can certainly do those trivial things in the next checkin. I didn?t want to change overly much for 8u40. > On 03 Nov 2014, at 15:08, Aleksey Shipilev wrote: > > On 03.11.2014 16:57, Marcus Lagergren wrote: >> UntouchedArrayData didn?t expand to SparseArrayData directly, for >> large index, but rather through VERY LARGE IntArrayDatas. That, of >> course, is fatal. >> >> Webrev: http://cr.openjdk.java.net/~lagergren/8062490/ > > Two questions about the same line: > 39 static final long MAX_DENSE_LENGTH = 16 * 512 * 1024; > > 1) This is a weird magic number: should be 8 * 1024 * 1024? > 2) Why not make it "int MAX_DENSE_LENGTH" and remove the asserts in > static initializer? > > -Aleksey. > From yikesaroni at gmail.com Mon Nov 3 20:25:13 2014 From: yikesaroni at gmail.com (yikes aroni) Date: Mon, 3 Nov 2014 15:25:13 -0500 Subject: Relationship between "global" and "engine" scope Message-ID: It appears that nashorn has named stuff in a non-intuitive way and I just want to confirm that I understand things correctly. Ordinarily, I would assume that "global" scope is a broader scope than "engine" scope, meaning that anything defined in "global" scope would be available to the engine scope. That would be great news! But i fear that it's not the case -- or at least not in the specific way i'm trying to use it. Furthermore, it appears that "engine" and "global" scope have no relationship to oneanother whatsoever. I'm attempting to evaluate a library in a ScriptEngine's "engine" scope (call this engine "baseEngine"), then set baseEngine's engine scope to the "global" scope for another ScriptEngine ("tempEngine"). Why would I want to do that? So that I can do the expensive eval on my script once and reuse it by shoving it into another script engine's scope. That is, I then eval some script in tempEngine's "engine" scope and assume that the library I shoved into tempEngine's "global" scope can be found and leveraged by the script. This appears not to be the case. Consider this test code: NashornScriptEngineFactory engineFactory = new NashornScriptEngineFactory(); ScriptEngine baseEngine = engineFactory.getScriptEngine(); // Here's the script we ultimately want in the "global" scope of tempEngine String script = "var test = (function() {" + "var publ = {};" + "var priv = {};" + "publ.hello = function() {" + " print('hello ' + eval('nnn'));" + "};" + "return publ;" + "})();"; // Load the script into baseEngine's ENGINE bindings baseEngine.eval(script); // The "library" script is now in base engine's ENGINE scope. Get a handle on ENGINE // bindings to try to inject them... Bindings engineScopeBase = baseEngine.getBindings(ScriptContext.ENGINE_SCOPE); // Get the tempEngine ScriptEngine tempEngine = engineFactory.getScriptEngine(); // eval the variable 'nnn' into tempEngine's ENGINE scope tempEngine.eval("var nnn = 'fellow';", tempEngine.getBindings(ScriptContext.ENGINE_SCOPE)); // Explicitly set the bindings to the temp context. // Comment out the first two lines to put the variable in global scope and the script in engine scope // Comment the 2nd two lines to put the variable in tempEngine's ENGINE scope and the script in its GLOBAL scope ScriptContext ctxTemp = new SimpleScriptContext(); ctxTemp.setBindings(engineScopeBase, ScriptContext.ENGINE_SCOPE); ctxTemp.setBindings(tempEngine.getBindings(ScriptContext.ENGINE_SCOPE), ScriptContext.GLOBAL_SCOPE); //ctxTemp.setBindings(engineScopeBase, ScriptContext.GLOBAL_SCOPE); //ctxTemp.setBindings(tempEngine.getBindings(ScriptContext.ENGINE_SCOPE), ScriptContext.ENGINE_SCOPE); System.out.println("is nnn in engine scope?: nnn=" + ctxTemp.getBindings(ScriptContext.ENGINE_SCOPE).get("nnn")); System.out.println("is nnn in global scope?: nnn=" + ctxTemp.getBindings(ScriptContext.GLOBAL_SCOPE).get("nnn")); System.out.println("is test in engine scope?: test=" + ctxTemp.getBindings(ScriptContext.ENGINE_SCOPE).get("test")); System.out.println("is test in global scope?: test=" + ctxTemp.getBindings(ScriptContext.GLOBAL_SCOPE).get("test")); tempEngine.eval("print(test.hello());", ctxTemp); The output either looks like this: is nnn in engine scope?: nnn=null is nnn in global scope?: nnn=fellow is test in engine scope?: test=[object Object] is test in global scope?: test=null or like this: is nnn in engine scope?: nnn=fellow is nnn in global scope?: nnn=null is test in engine scope?: test=null is test in global scope?: test=[object Object] When the last line runs, I get the error Exception in thread "main" javax.script.ScriptException: ReferenceError: "nnn" is not defined in #1:95@0 at line number 1 In other words, the script can never find the variable 'nnn' -- not in the global scope nor in the engine scope regardless of how i set up global / engine bindings. Is there any way to make this work? Before I give up, I want to make sure that i'm not missing something and have exhausted all possibilities.... thanks! From marcus.lagergren at oracle.com Tue Nov 4 11:50:09 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 4 Nov 2014 12:50:09 +0100 Subject: Please review JDK-8057825 Message-ID: Logic in RecompilableScriptFunctionData 1) Apply transform succeeds when a callsite is first encountered 2) It is the best callsite available when we do another call, but the fit isn?t exact, which it has to be for apply2call to work - i.e. exactly the right number of parameters with the exact types 3) In that case recompile a specialization 4) Do addCode on it iff it was a successful apply2call transform Basically the problem was that 4 should be 4) Do addcode on it, always As Attila?s excellent repro managed to capture. We reuse the apply2call specialization for one object argument, undefined, for the array apply, which fits and doesn?t cause a linkage error since Object holds anything, even [?foo?, ?bar?]. Also some housekeeping on the apply2call transform, not making it iterate over the code for applies if there are none, better logging sanitized output and so on. Webrev at: http://cr.openjdk.java.net/~lagergren/8057825/ Issue at: https://bugs.openjdk.java.net/browse/JDK-8057825 Regards Marcus From hannes.wallnoefer at oracle.com Tue Nov 4 12:57:42 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 04 Nov 2014 13:57:42 +0100 Subject: Please review JDK-8057825 In-Reply-To: References: Message-ID: <5458CD46.1080108@oracle.com> I think the NodeVisitor in ApplySpecialization#hasApplies will enter into nested functions. Shouldn't it just look at the current function? I wonder how hot the TransformFailedException constructor may get. Should we worry about string concatenation there? Otherwise looks good. Hannes Am 2014-11-04 um 12:50 schrieb Marcus Lagergren: > Logic in RecompilableScriptFunctionData > > 1) Apply transform succeeds when a callsite is first encountered > 2) It is the best callsite available when we do another call, but the fit isn?t exact, which it has to be for apply2call to work - i.e. exactly the right number of parameters with the exact types > 3) In that case recompile a specialization > 4) Do addCode on it iff it was a successful apply2call transform > > Basically the problem was that 4 should be > > 4) Do addcode on it, always > > As Attila?s excellent repro managed to capture. We reuse the apply2call specialization for one object argument, undefined, for the array apply, which fits and doesn?t cause a linkage error since Object holds anything, even [?foo?, ?bar?]. > > Also some housekeeping on the apply2call transform, not making it iterate over the code for applies if there are none, better logging sanitized output and so on. > > Webrev at: http://cr.openjdk.java.net/~lagergren/8057825/ > Issue at: https://bugs.openjdk.java.net/browse/JDK-8057825 > > Regards > Marcus > From attila.szegedi at oracle.com Tue Nov 4 13:47:18 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 4 Nov 2014 14:47:18 +0100 Subject: Please review JDK-8057825 In-Reply-To: References: Message-ID: <4FE941A5-8451-48BD-9F47-4A69F6FC2600@oracle.com> +1 On Nov 4, 2014, at 12:50 PM, Marcus Lagergren wrote: > Logic in RecompilableScriptFunctionData > > 1) Apply transform succeeds when a callsite is first encountered > 2) It is the best callsite available when we do another call, but the fit isn?t exact, which it has to be for apply2call to work - i.e. exactly the right number of parameters with the exact types > 3) In that case recompile a specialization > 4) Do addCode on it iff it was a successful apply2call transform > > Basically the problem was that 4 should be > > 4) Do addcode on it, always > > As Attila?s excellent repro managed to capture. We reuse the apply2call specialization for one object argument, undefined, for the array apply, which fits and doesn?t cause a linkage error since Object holds anything, even [?foo?, ?bar?]. > > Also some housekeeping on the apply2call transform, not making it iterate over the code for applies if there are none, better logging sanitized output and so on. > > Webrev at: http://cr.openjdk.java.net/~lagergren/8057825/ > Issue at: https://bugs.openjdk.java.net/browse/JDK-8057825 > > Regards > Marcus > From smourachov at gmail.com Tue Nov 4 23:44:10 2014 From: smourachov at gmail.com (Serguei Mourachov) Date: Tue, 04 Nov 2014 15:44:10 -0800 Subject: Native Nashorn Object vs JSObject Message-ID: <545964CA.6060000@gmail.com> It looks like some operations that are available for native Nashorn objects, are not implemented for JSObject. For example, following script works and prints '6': engine.eval("var obj={};var key={}; obj[key]=6;print(obj[key])"); In case when 'obj' is an implementation of JSObject, the script runs without any error, printing 'null'. SM From hannes.wallnoefer at oracle.com Wed Nov 5 15:26:08 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 05 Nov 2014 16:26:08 +0100 Subject: Review request for JDK-8062386: Place where code cache will be saved don't change after change nashorn.jar Message-ID: <545A4190.7020704@oracle.com> Please review JDK-8062386: Place where code cache will be saved don't change after change nashorn.jar http://cr.openjdk.java.net/~hannesw/8062386/ Thanks, Hannes From marcus.lagergren at oracle.com Wed Nov 5 15:40:23 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 5 Nov 2014 16:40:23 +0100 Subject: Review request for JDK-8062386: Place where code cache will be saved don't change after change nashorn.jar In-Reply-To: <545A4190.7020704@oracle.com> References: <545A4190.7020704@oracle.com> Message-ID: +1 s/don?t/doesn?t/g /M > On 05 Nov 2014, at 16:26, Hannes Wallnoefer wrote: > > Please review JDK-8062386: Place where code cache will be saved don't change after change nashorn.jar > > http://cr.openjdk.java.net/~hannesw/8062386/ > > Thanks, > Hannes From marcus.lagergren at oracle.com Wed Nov 5 17:52:35 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 5 Nov 2014 18:52:35 +0100 Subject: Missing ArrayBuffer.isView() Method In-Reply-To: <4A84E57B-9110-4FB9-A68C-7645DE7ECD3C@oracle.com> References: <4A84E57B-9110-4FB9-A68C-7645DE7ECD3C@oracle.com> Message-ID: <676B7810-8B58-4A03-AB92-7C5B256FD89F@oracle.com> Fixed and backported to 8u40. Thanks for the report. http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/4ac6934c6cc2 Regards Marcus > On 23 Oct 2014, at 17:12, Jim Laskey (Oracle) wrote: > > Filed as https://bugs.openjdk.java.net/browse/JDK-8061959 > > On Oct 22, 2014, at 9:23 PM, Kishori Sharan wrote: > >> Hello, >> Why did Nashorn not implement the ArrayBuffer.isView() static method? The >> page at >> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions >> describes that Nashorn implements the specification at >> https://www.khronos.org/registry/typedarray/specs/latest/ that conatins >> this method. However, this method is missing. The following statement >> throws an exception: >> >> ArrayBuffer.isView(new Int8Array(4)); >> >> >> Thanks >> Kishori > From hannes.wallnoefer at oracle.com Thu Nov 6 06:29:59 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 06 Nov 2014 07:29:59 +0100 Subject: Review request for JDK-8062624: java.lang.String methods not available on concatenated strings Message-ID: <545B1567.2010505@oracle.com> Please review JDK-8062624: java.lang.String methods not available on concatenated strings: http://cr.openjdk.java.net/~hannesw/8062624/ Thanks, Hannes From marcus.lagergren at oracle.com Thu Nov 6 07:17:18 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 6 Nov 2014 08:17:18 +0100 Subject: Review request for JDK-8062624: java.lang.String methods not available on concatenated strings In-Reply-To: <545B1567.2010505@oracle.com> References: <545B1567.2010505@oracle.com> Message-ID: <53CEB67F-A2C4-4512-A5F2-260782858494@oracle.com> +1 > On 06 Nov 2014, at 07:29, Hannes Wallnoefer wrote: > > Please review JDK-8062624: java.lang.String methods not available on concatenated strings: > > http://cr.openjdk.java.net/~hannesw/8062624/ > > Thanks, > Hannes From attila.szegedi at oracle.com Thu Nov 6 10:53:41 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 6 Nov 2014 11:53:41 +0100 Subject: Review request for JDK-8062624: java.lang.String methods not available on concatenated strings In-Reply-To: <545B1567.2010505@oracle.com> References: <545B1567.2010505@oracle.com> Message-ID: +1 On Nov 6, 2014, at 7:29 AM, Hannes Wallnoefer wrote: > Please review JDK-8062624: java.lang.String methods not available on concatenated strings: > > http://cr.openjdk.java.net/~hannesw/8062624/ > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Thu Nov 6 11:50:53 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 06 Nov 2014 12:50:53 +0100 Subject: Review request for JDK-8047365: Very long function names break codegen Message-ID: <545B609D.10800@oracle.com> Please review JDK-8047365: Very long function names break codegen: http://cr.openjdk.java.net/~hannesw/8047365/ Thanks, Hannes From attila.szegedi at oracle.com Thu Nov 6 11:58:30 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 6 Nov 2014 12:58:30 +0100 Subject: Review request for JDK-8047365: Very long function names break codegen In-Reply-To: <545B609D.10800@oracle.com> References: <545B609D.10800@oracle.com> Message-ID: <164A7B4E-BD09-4A3F-9EF1-7EDB22EF4A9E@oracle.com> +1 On Nov 6, 2014, at 12:50 PM, Hannes Wallnoefer wrote: > Please review JDK-8047365: Very long function names break codegen: > > http://cr.openjdk.java.net/~hannesw/8047365/ > > Thanks, > Hannes From marcus.lagergren at oracle.com Thu Nov 6 12:15:09 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 6 Nov 2014 13:15:09 +0100 Subject: Review request for JDK-8047365: Very long function names break codegen In-Reply-To: <545B609D.10800@oracle.com> References: <545B609D.10800@oracle.com> Message-ID: <8EB53F34-C45D-4F88-ABAB-852B8AAF3121@oracle.com> +1 > On 06 Nov 2014, at 12:50, Hannes Wallnoefer wrote: > > Please review JDK-8047365: Very long function names break codegen: > > http://cr.openjdk.java.net/~hannesw/8047365/ > > Thanks, > Hannes From attila.szegedi at oracle.com Thu Nov 6 13:41:43 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 6 Nov 2014 14:41:43 +0100 Subject: Review request for JDK-8062308 Message-ID: <8F73B96D-9D43-4D35-8117-40B9D0025EEB@oracle.com> Please review JDK-8062308 at for The gist of the issue is that we must maintain GlobalConstants objects per Context, and not as a single systemwide static in Global. Furthermore, as soon as the Context creates its second Global, we must disable the constant linking forever in that Context. Constant linking creates an intimate coupling between a Global and the compiled code, and is thus not compatible with multi-Global Contexts. I have also reduced the synchronization burden in GlobalConstants somewhat (only synchronizing when state needs to be accessed), and reduced the need to even access GlobalConstants from ScriptObject when it's clear that the script object in question is not a Global. Thanks, Attila. From sundararajan.athijegannathan at oracle.com Thu Nov 6 13:48:10 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 06 Nov 2014 19:18:10 +0530 Subject: Review request for JDK-8062308 In-Reply-To: <8F73B96D-9D43-4D35-8117-40B9D0025EEB@oracle.com> References: <8F73B96D-9D43-4D35-8117-40B9D0025EEB@oracle.com> Message-ID: <545B7C1A.6020309@oracle.com> +1 Please appropriate noreg- label to the bug - especially if you are thinking of backporting this to jdk8u in future. -Sundar On Thursday 06 November 2014 07:11 PM, Attila Szegedi wrote: > Please review JDK-8062308 at for > > The gist of the issue is that we must maintain GlobalConstants objects per Context, and not as a single systemwide static in Global. Furthermore, as soon as the Context creates its second Global, we must disable the constant linking forever in that Context. Constant linking creates an intimate coupling between a Global and the compiled code, and is thus not compatible with multi-Global Contexts. > > I have also reduced the synchronization burden in GlobalConstants somewhat (only synchronizing when state needs to be accessed), and reduced the need to even access GlobalConstants from ScriptObject when it's clear that the script object in question is not a Global. > > Thanks, > Attila. From marcus.lagergren at oracle.com Thu Nov 6 13:57:58 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 6 Nov 2014 14:57:58 +0100 Subject: Review request for JDK-8062308 In-Reply-To: <8F73B96D-9D43-4D35-8117-40B9D0025EEB@oracle.com> References: <8F73B96D-9D43-4D35-8117-40B9D0025EEB@oracle.com> Message-ID: <9873C599-42F5-4B36-A640-402B872294AD@oracle.com> Nicely done, Attila! I will follow up with the bugs you have found as soon as I?m done with the one I?m currently working on. For a sanity check, can you run some octane benchmarks and make sure we didn?t lose any performance. I don?t think you need a full run. It should suffice to compare 3-4 iterations with ?log=const and diff against same in tip to make sure that no callsites are missed that were picked up before. +1 in that case. Regard Marcus > On 06 Nov 2014, at 14:41, Attila Szegedi wrote: > > Please review JDK-8062308 at for > > The gist of the issue is that we must maintain GlobalConstants objects per Context, and not as a single systemwide static in Global. Furthermore, as soon as the Context creates its second Global, we must disable the constant linking forever in that Context. Constant linking creates an intimate coupling between a Global and the compiled code, and is thus not compatible with multi-Global Contexts. > > I have also reduced the synchronization burden in GlobalConstants somewhat (only synchronizing when state needs to be accessed), and reduced the need to even access GlobalConstants from ScriptObject when it's clear that the script object in question is not a Global. > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Thu Nov 6 16:22:29 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 06 Nov 2014 21:52:29 +0530 Subject: Native Nashorn Object vs JSObject In-Reply-To: <545964CA.6060000@gmail.com> References: <545964CA.6060000@gmail.com> Message-ID: <545BA045.60004@oracle.com> Will you please post full source of your JSObject? (just enough to reproduce issue you're talking about). -Sundar On Wednesday 05 November 2014 05:14 AM, Serguei Mourachov wrote: > It looks like some operations that are available for native Nashorn > objects, are not implemented for JSObject. > For example, following script works and prints '6': engine.eval("var > obj={};var key={}; obj[key]=6;print(obj[key])"); > In case when 'obj' is an implementation of JSObject, the script runs > without any error, printing 'null'. > > SM > > From smourachov at gmail.com Thu Nov 6 18:19:27 2014 From: smourachov at gmail.com (Serguei Mourachov) Date: Thu, 06 Nov 2014 10:19:27 -0800 Subject: Native Nashorn Object vs JSObject In-Reply-To: <545BA045.60004@oracle.com> References: <545964CA.6060000@gmail.com> <545BA045.60004@oracle.com> Message-ID: <545BBBAF.7090808@gmail.com> On 11/6/2014 8:22 AM, A. Sundararajan wrote: > Will you please post full source of your JSObject? (just enough to > reproduce issue you're talking about). > > -Sundar > > On Wednesday 05 November 2014 05:14 AM, Serguei Mourachov wrote: >> It looks like some operations that are available for native Nashorn >> objects, are not implemented for JSObject. >> For example, following script works and prints '6': engine.eval("var >> obj={};var key={}; obj[key]=6;print(obj[key])"); >> In case when 'obj' is an implementation of JSObject, the script runs >> without any error, printing 'null'. >> >> SM >> >> > here is the sample code: public static void main(String[] args) throws Exception { NashornScriptEngineFactory factory = new NashornScriptEngineFactory(); ScriptEngine engine = factory.getScriptEngine(); Bindings b = engine.getBindings(ScriptContext.ENGINE_SCOPE); AbstractJSObject jsobj = new AbstractJSObject(){ Map map = new HashMap<>(); @Override public void setMember(String name, Object value) { map.put(name, value); } @Override public Object getMember(String name) { return map.get(name); } @Override public void removeMember(String name) { map.remove(name); } @Override public boolean hasMember(String name) { return map.containsKey(name); } }; b.put("jsobj", jsobj); engine.eval("var obj={}; var key={}; obj[key]=6;print(obj[key])"); engine.eval("jsobj[key]=6;print(jsobj[key])"); } if you replace var key={} with var key='foo' the code works as expected SM From knsk.mtzk at gmail.com Fri Nov 7 10:19:50 2014 From: knsk.mtzk at gmail.com (Kensuke Matsuzaki) Date: Fri, 7 Nov 2014 19:19:50 +0900 Subject: Is there nashorn.internal.objects JavaDoc? Message-ID: Hello, There are Nashorn Documentation(https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation), but I can't find any reference or API specification. JavaDoc of Global.java, NativeJavaImporter.java and NativeJava.java seems useful. Is html documents available? Regards -- Kensuke Matsuzaki From sundararajan.athijegannathan at oracle.com Fri Nov 7 10:34:35 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 07 Nov 2014 16:04:35 +0530 Subject: Is there nashorn.internal.objects JavaDoc? In-Reply-To: References: Message-ID: <545CA03B.7070303@oracle.com> If you are looking for documentation for Nashorn javascript extensions (like "load" function, "Java.type" etc.), please visit https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions Anything else in these classes are internal implementation details and therefore subject to change between releases without notice. If you do want do check out docs on these for better understanding of internal implementation details, you can check out nashorn repo and generate javadoc using ant javadoc command Hope this helps, -Sundar Kensuke Matsuzaki wrote: > Hello, > > There are Nashorn > Documentation(https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation), > but I can't find any reference or API specification. > > JavaDoc of Global.java, NativeJavaImporter.java and NativeJava.java > seems useful. > Is html documents available? > > Regards > From sundararajan.athijegannathan at oracle.com Fri Nov 7 11:07:00 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 07 Nov 2014 16:37:00 +0530 Subject: Native Nashorn Object vs JSObject In-Reply-To: <545BBBAF.7090808@gmail.com> References: <545964CA.6060000@gmail.com> <545BA045.60004@oracle.com> <545BBBAF.7090808@gmail.com> Message-ID: <545CA7D4.6010404@oracle.com> By design, JSObject properties are either Strings or integers. When you use jsobj.foo = 33 or jsobj["foo"] = 33 JSObject.setMember(String, Object) method will be called for the same by Nashorn's linker. If you use jobj[1] = 33; then JSObject.setSlot(int, Object) method will be called If you use anything else as property (say a script object as in your example), that would be ignored. Hope this explains, -Sundar Serguei Mourachov wrote: > On 11/6/2014 8:22 AM, A. Sundararajan wrote: >> Will you please post full source of your JSObject? (just enough to >> reproduce issue you're talking about). >> >> -Sundar >> >> On Wednesday 05 November 2014 05:14 AM, Serguei Mourachov wrote: >>> It looks like some operations that are available for native Nashorn >>> objects, are not implemented for JSObject. >>> For example, following script works and prints '6': engine.eval("var >>> obj={};var key={}; obj[key]=6;print(obj[key])"); >>> In case when 'obj' is an implementation of JSObject, the script >>> runs without any error, printing 'null'. >>> >>> SM >>> >>> >> > here is the sample code: > > public static void main(String[] args) throws Exception { > NashornScriptEngineFactory factory = new > NashornScriptEngineFactory(); > ScriptEngine engine = factory.getScriptEngine(); > > Bindings b = engine.getBindings(ScriptContext.ENGINE_SCOPE); > > AbstractJSObject jsobj = new AbstractJSObject(){ > Map map = new HashMap<>(); > > @Override > public void setMember(String name, Object value) { > map.put(name, value); > } > > @Override > public Object getMember(String name) { > return map.get(name); > } > > @Override > public void removeMember(String name) { > map.remove(name); > } > > @Override > public boolean hasMember(String name) { > return map.containsKey(name); > } > }; > b.put("jsobj", jsobj); > engine.eval("var obj={}; var key={}; > obj[key]=6;print(obj[key])"); > engine.eval("jsobj[key]=6;print(jsobj[key])"); > > } > > if you replace var key={} with var key='foo' the code works as expected > > SM > > From knsk.mtzk at gmail.com Fri Nov 7 13:06:49 2014 From: knsk.mtzk at gmail.com (Kensuke Matsuzaki) Date: Fri, 7 Nov 2014 22:06:49 +0900 Subject: Is there nashorn.internal.objects JavaDoc? In-Reply-To: <545CA03B.7070303@oracle.com> References: <545CA03B.7070303@oracle.com> Message-ID: I wanted to know whether or not features are implementation dependent or spec. If the wiki page isn't just example and it is complete and exhaustive, it is what I desired. Thank you. 2014-11-07 19:34 GMT+09:00 A. Sundararajan : > If you are looking for documentation for Nashorn javascript extensions (like > "load" function, "Java.type" etc.), please visit > > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > > Anything else in these classes are internal implementation details and > therefore subject to change between releases without notice. > > If you do want do check out docs on these for better understanding of > internal implementation details, you can check out nashorn repo and generate > javadoc using > > > ant javadoc > > command > > Hope this helps, > -Sundar > > > Kensuke Matsuzaki wrote: >> >> Hello, >> >> There are Nashorn >> >> Documentation(https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation), >> but I can't find any reference or API specification. >> >> JavaDoc of Global.java, NativeJavaImporter.java and NativeJava.java >> seems useful. >> Is html documents available? >> >> Regards >> > > From sundararajan.athijegannathan at oracle.com Fri Nov 7 13:54:00 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 07 Nov 2014 19:24:00 +0530 Subject: Is there nashorn.internal.objects JavaDoc? In-Reply-To: References: <545CA03B.7070303@oracle.com> Message-ID: <545CCEF8.8000503@oracle.com> We try to document every extension in wiki + scripting docs (which are linked from wiki start page) https://wiki.openjdk.java.net/display/Nashorn/Nashorn%3A+Articles%2C+Documents%2C+Slides+and+Videos -Sundar On Friday 07 November 2014 06:36 PM, Kensuke Matsuzaki wrote: > I wanted to know whether or not features are implementation dependent or spec. > If the wiki page isn't just example and it is complete and exhaustive, > it is what I desired. > > Thank you. > > 2014-11-07 19:34 GMT+09:00 A. Sundararajan > : >> If you are looking for documentation for Nashorn javascript extensions (like >> "load" function, "Java.type" etc.), please visit >> >> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions >> >> Anything else in these classes are internal implementation details and >> therefore subject to change between releases without notice. >> >> If you do want do check out docs on these for better understanding of >> internal implementation details, you can check out nashorn repo and generate >> javadoc using >> >> >> ant javadoc >> >> command >> >> Hope this helps, >> -Sundar >> >> >> Kensuke Matsuzaki wrote: >>> Hello, >>> >>> There are Nashorn >>> >>> Documentation(https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation), >>> but I can't find any reference or API specification. >>> >>> JavaDoc of Global.java, NativeJavaImporter.java and NativeJava.java >>> seems useful. >>> Is html documents available? >>> >>> Regards >>> >> From smourachov at gmail.com Fri Nov 7 23:34:00 2014 From: smourachov at gmail.com (Serguei Mourachov) Date: Fri, 07 Nov 2014 15:34:00 -0800 Subject: Native Nashorn Object vs JSObject In-Reply-To: <545CA7D4.6010404@oracle.com> References: <545964CA.6060000@gmail.com> <545BA045.60004@oracle.com> <545BBBAF.7090808@gmail.com> <545CA7D4.6010404@oracle.com> Message-ID: <545D56E8.1090108@gmail.com> Sundar In case of native Nashorn object, runtime converts objects, when they are used as "keys", to strings (according to JavaScript spec). I think the same approach should be used for JSObject. From the api doc for JSObject: " Nashorn will treat objects of such classes just like nashorn script objects." In my case, inability to use objects as "keys" makes it impossible to implement iterable JSObject, because in that case Symbol.iterator object is used to access the iterator function. SM On 11/7/2014 3:07 AM, A. Sundararajan wrote: > By design, JSObject properties are either Strings or integers. When > you use > > jsobj.foo = 33 > > or > > jsobj["foo"] = 33 > > JSObject.setMember(String, Object) method will be called for the same > by Nashorn's linker. If you use > > jobj[1] = 33; > > then JSObject.setSlot(int, Object) method will be called > > If you use anything else as property (say a script object as in your > example), that would be ignored. > > Hope this explains, > -Sundar > > Serguei Mourachov wrote: >> On 11/6/2014 8:22 AM, A. Sundararajan wrote: >>> Will you please post full source of your JSObject? (just enough to >>> reproduce issue you're talking about). >>> >>> -Sundar >>> >>> On Wednesday 05 November 2014 05:14 AM, Serguei Mourachov wrote: >>>> It looks like some operations that are available for native Nashorn >>>> objects, are not implemented for JSObject. >>>> For example, following script works and prints '6': >>>> engine.eval("var obj={};var key={}; obj[key]=6;print(obj[key])"); >>>> In case when 'obj' is an implementation of JSObject, the script >>>> runs without any error, printing 'null'. >>>> >>>> SM >>>> >>>> >>> >> here is the sample code: >> >> public static void main(String[] args) throws Exception { >> NashornScriptEngineFactory factory = new >> NashornScriptEngineFactory(); >> ScriptEngine engine = factory.getScriptEngine(); >> >> Bindings b = engine.getBindings(ScriptContext.ENGINE_SCOPE); >> >> AbstractJSObject jsobj = new AbstractJSObject(){ >> Map map = new HashMap<>(); >> >> @Override >> public void setMember(String name, Object value) { >> map.put(name, value); >> } >> >> @Override >> public Object getMember(String name) { >> return map.get(name); >> } >> >> @Override >> public void removeMember(String name) { >> map.remove(name); >> } >> >> @Override >> public boolean hasMember(String name) { >> return map.containsKey(name); >> } >> }; >> b.put("jsobj", jsobj); >> engine.eval("var obj={}; var key={}; >> obj[key]=6;print(obj[key])"); >> engine.eval("jsobj[key]=6;print(jsobj[key])"); >> >> } >> >> if you replace var key={} with var key='foo' the code works as expected >> >> SM >> >> > From sundararajan.athijegannathan at oracle.com Mon Nov 10 03:12:37 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 10 Nov 2014 08:42:37 +0530 Subject: Native Nashorn Object vs JSObject In-Reply-To: <545D56E8.1090108@gmail.com> References: <545964CA.6060000@gmail.com> <545BA045.60004@oracle.com> <545BBBAF.7090808@gmail.com> <545CA7D4.6010404@oracle.com> <545D56E8.1090108@gmail.com> Message-ID: <54602D25.4040300@oracle.com> That comment is meant for String and int keys. Obviously, JSObjects can not be exactly same as native ScriptObjects. For eg. there is no notion of proto for arbitrary JSObjects and so on. Property (string key) access/set, indexed access/set and delete work like script objects. -Sundar On Saturday 08 November 2014 05:04 AM, Serguei Mourachov wrote: > Sundar > > In case of native Nashorn object, runtime converts objects, when they > are used as "keys", to strings (according to JavaScript spec). > I think the same approach should be used for JSObject. > From the api doc for JSObject: " Nashorn will treat objects of such > classes just like nashorn script objects." > > In my case, inability to use objects as "keys" makes it impossible to > implement iterable JSObject, because in that case Symbol.iterator > object is used to access the iterator function. > > SM > > > On 11/7/2014 3:07 AM, A. Sundararajan wrote: >> By design, JSObject properties are either Strings or integers. When >> you use >> >> jsobj.foo = 33 >> >> or >> >> jsobj["foo"] = 33 >> >> JSObject.setMember(String, Object) method will be called for the same >> by Nashorn's linker. If you use >> >> jobj[1] = 33; >> >> then JSObject.setSlot(int, Object) method will be called >> >> If you use anything else as property (say a script object as in your >> example), that would be ignored. >> >> Hope this explains, >> -Sundar >> >> Serguei Mourachov wrote: >>> On 11/6/2014 8:22 AM, A. Sundararajan wrote: >>>> Will you please post full source of your JSObject? (just enough to >>>> reproduce issue you're talking about). >>>> >>>> -Sundar >>>> >>>> On Wednesday 05 November 2014 05:14 AM, Serguei Mourachov wrote: >>>>> It looks like some operations that are available for native >>>>> Nashorn objects, are not implemented for JSObject. >>>>> For example, following script works and prints '6': >>>>> engine.eval("var obj={};var key={}; obj[key]=6;print(obj[key])"); >>>>> In case when 'obj' is an implementation of JSObject, the script >>>>> runs without any error, printing 'null'. >>>>> >>>>> SM >>>>> >>>>> >>>> >>> here is the sample code: >>> >>> public static void main(String[] args) throws Exception { >>> NashornScriptEngineFactory factory = new >>> NashornScriptEngineFactory(); >>> ScriptEngine engine = factory.getScriptEngine(); >>> >>> Bindings b = engine.getBindings(ScriptContext.ENGINE_SCOPE); >>> >>> AbstractJSObject jsobj = new AbstractJSObject(){ >>> Map map = new HashMap<>(); >>> >>> @Override >>> public void setMember(String name, Object value) { >>> map.put(name, value); >>> } >>> >>> @Override >>> public Object getMember(String name) { >>> return map.get(name); >>> } >>> >>> @Override >>> public void removeMember(String name) { >>> map.remove(name); >>> } >>> >>> @Override >>> public boolean hasMember(String name) { >>> return map.containsKey(name); >>> } >>> }; >>> b.put("jsobj", jsobj); >>> engine.eval("var obj={}; var key={}; >>> obj[key]=6;print(obj[key])"); >>> engine.eval("jsobj[key]=6;print(jsobj[key])"); >>> >>> } >>> >>> if you replace var key={} with var key='foo' the code works as expected >>> >>> SM >>> >>> >> > From sergey.lugovoy at oracle.com Mon Nov 10 09:37:20 2014 From: sergey.lugovoy at oracle.com (Sergey Lugovoy) Date: Mon, 10 Nov 2014 12:37:20 +0300 Subject: RFR 8062638: RuntimeException when run command from js with -scripting on Cygwin Message-ID: <54608750.60700@oracle.com> Please review : http://cr.openjdk.java.net/~slugovoy/8062638/webrev.00/ bug : https://bugs.openjdk.java.net/browse/JDK-8062638 -- Thanks, Sergey From attila.szegedi at oracle.com Tue Nov 11 13:42:05 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 11 Nov 2014 14:42:05 +0100 Subject: Review request for JDK-8064467 Message-ID: <4309C122-3CAE-4710-AB64-2FE120401181@oracle.com> Please review JDK-8064467 at for Thanks, Attila. From hannes.wallnoefer at oracle.com Tue Nov 11 14:22:37 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 11 Nov 2014 15:22:37 +0100 Subject: Review request for JDK-8064467 In-Reply-To: <4309C122-3CAE-4710-AB64-2FE120401181@oracle.com> References: <4309C122-3CAE-4710-AB64-2FE120401181@oracle.com> Message-ID: <54621BAD.2020006@oracle.com> +1 Am 2014-11-11 um 14:42 schrieb Attila Szegedi: > Please review JDK-8064467 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Tue Nov 11 15:17:13 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 11 Nov 2014 16:17:13 +0100 Subject: Review request for JDK-8064467 In-Reply-To: <4309C122-3CAE-4710-AB64-2FE120401181@oracle.com> References: <4309C122-3CAE-4710-AB64-2FE120401181@oracle.com> Message-ID: +1 > On 11 Nov 2014, at 14:42, Attila Szegedi wrote: > > Please review JDK-8064467 at for > > Thanks, > Attila. From attila.szegedi at oracle.com Tue Nov 11 15:30:37 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 11 Nov 2014 16:30:37 +0100 Subject: Review request for JDK-8062799 Message-ID: <49EC5E09-4B0A-48F2-A098-EB33855F48E2@oracle.com> Please review JDK-8062799 at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Tue Nov 11 15:34:26 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 11 Nov 2014 21:04:26 +0530 Subject: Review request for JDK-8062799 In-Reply-To: <49EC5E09-4B0A-48F2-A098-EB33855F48E2@oracle.com> References: <49EC5E09-4B0A-48F2-A098-EB33855F48E2@oracle.com> Message-ID: <54622C82.90807@oracle.com> +1 On Tuesday 11 November 2014 09:00 PM, Attila Szegedi wrote: > Please review JDK-8062799 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Tue Nov 11 16:01:32 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 11 Nov 2014 17:01:32 +0100 Subject: Review request for JDK-8062799 In-Reply-To: <49EC5E09-4B0A-48F2-A098-EB33855F48E2@oracle.com> References: <49EC5E09-4B0A-48F2-A098-EB33855F48E2@oracle.com> Message-ID: +1 > On 11 Nov 2014, at 16:30, Attila Szegedi wrote: > > Please review JDK-8062799 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Tue Nov 11 16:37:28 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 11 Nov 2014 17:37:28 +0100 Subject: Please review JDK-8035312 Message-ID: <07275425-4463-470D-935A-32B57FDC58A7@oracle.com> Please review https://bugs.openjdk.java.net/browse/JDK-8035312 There were several corner cases related to length in general and setting length in arrays to not writable in particular. None of the existing run times pass all the tests, so this was a very hard area to get right (added 6 new unit tests) I?ve also gotten rid of the special casey length not writable SwitchPoint in NativeArray - now that I have a filter for LengtNotWritableArray that can?t be cast to a ContinuousArrayData in the fast paths, this handles itself anyway. webrev at: http://cr.openjdk.java.net/~lagergren/8035312/ /M From hannes.wallnoefer at oracle.com Wed Nov 12 10:41:59 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 12 Nov 2014 11:41:59 +0100 Subject: Please review JDK-8035312 In-Reply-To: <07275425-4463-470D-935A-32B57FDC58A7@oracle.com> References: <07275425-4463-470D-935A-32B57FDC58A7@oracle.com> Message-ID: <54633977.804@oracle.com> A few minor remarks: - Shouldn't ArrayData.increaseLength and .decreaseLength be protected instead of public? - Javadoc of ArrayData.length is missing # for link: {@link #setLength} (although it's a private field anyway...) - Is the (index >= len) check needed in NativeArray.sort? Does not ArrayData.indexIterator take care of this? - Some of the new tests use a mix of spaces/tabs for indentation. Otherwise looks good. Hannes Am 2014-11-11 um 17:37 schrieb Marcus Lagergren: > Please review > > https://bugs.openjdk.java.net/browse/JDK-8035312 > > There were several corner cases related to length in general and setting length in arrays to not writable in particular. > None of the existing run times pass all the tests, so this was a very hard area to get right (added 6 new unit tests) > > I?ve also gotten rid of the special casey length not writable SwitchPoint in NativeArray - now that I have a filter for LengtNotWritableArray that can?t be cast to a ContinuousArrayData in the fast paths, this handles itself anyway. > > webrev at: http://cr.openjdk.java.net/~lagergren/8035312/ > > /M > From marcus.lagergren at oracle.com Wed Nov 12 10:58:49 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 12 Nov 2014 11:58:49 +0100 Subject: Please review JDK-8035312 In-Reply-To: <54633977.804@oracle.com> References: <07275425-4463-470D-935A-32B57FDC58A7@oracle.com> <54633977.804@oracle.com> Message-ID: <9FC6BBB9-35FD-477C-BA10-DA8A02B96553@oracle.com> Fixing and integrating. > On 12 Nov 2014, at 11:41, Hannes Wallnoefer wrote: > > A few minor remarks: > > - Shouldn't ArrayData.increaseLength and .decreaseLength be protected instead of public? > - Javadoc of ArrayData.length is missing # for link: {@link #setLength} (although it's a private field anyway...) > - Is the (index >= len) check needed in NativeArray.sort? Does not ArrayData.indexIterator take care of this? > - Some of the new tests use a mix of spaces/tabs for indentation. > > Otherwise looks good. > > Hannes > > Am 2014-11-11 um 17:37 schrieb Marcus Lagergren: >> Please review >> >> https://bugs.openjdk.java.net/browse/JDK-8035312 >> >> There were several corner cases related to length in general and setting length in arrays to not writable in particular. >> None of the existing run times pass all the tests, so this was a very hard area to get right (added 6 new unit tests) >> >> I?ve also gotten rid of the special casey length not writable SwitchPoint in NativeArray - now that I have a filter for LengtNotWritableArray that can?t be cast to a ContinuousArrayData in the fast paths, this handles itself anyway. >> >> webrev at: http://cr.openjdk.java.net/~lagergren/8035312/ >> >> /M >> > From marcus.lagergren at oracle.com Wed Nov 12 11:00:01 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 12 Nov 2014 12:00:01 +0100 Subject: Please review JDK-8035312 In-Reply-To: <54633977.804@oracle.com> References: <07275425-4463-470D-935A-32B57FDC58A7@oracle.com> <54633977.804@oracle.com> Message-ID: Third issue: no it doesn?t . For example for a LengthNotWritableData there can be elements larger then length that can be returned > On 12 Nov 2014, at 11:41, Hannes Wallnoefer wrote: > > A few minor remarks: > > - Shouldn't ArrayData.increaseLength and .decreaseLength be protected instead of public? > - Javadoc of ArrayData.length is missing # for link: {@link #setLength} (although it's a private field anyway...) > - Is the (index >= len) check needed in NativeArray.sort? Does not ArrayData.indexIterator take care of this? > - Some of the new tests use a mix of spaces/tabs for indentation. > > Otherwise looks good. > > Hannes > > Am 2014-11-11 um 17:37 schrieb Marcus Lagergren: >> Please review >> >> https://bugs.openjdk.java.net/browse/JDK-8035312 >> >> There were several corner cases related to length in general and setting length in arrays to not writable in particular. >> None of the existing run times pass all the tests, so this was a very hard area to get right (added 6 new unit tests) >> >> I?ve also gotten rid of the special casey length not writable SwitchPoint in NativeArray - now that I have a filter for LengtNotWritableArray that can?t be cast to a ContinuousArrayData in the fast paths, this handles itself anyway. >> >> webrev at: http://cr.openjdk.java.net/~lagergren/8035312/ >> >> /M >> > From attila.szegedi at oracle.com Wed Nov 12 11:00:35 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 12 Nov 2014 12:00:35 +0100 Subject: Please review JDK-8035312 In-Reply-To: <54633977.804@oracle.com> References: <07275425-4463-470D-935A-32B57FDC58A7@oracle.com> <54633977.804@oracle.com> Message-ID: <754DA48D-8A54-44E9-A095-16DC3AF373AF@oracle.com> My remarks: - NativeArray instances no longer need PushLinkLogic, PopLinkLogic, and ConcatLinkLogic objects. These objects are no longer instance-specific (their state is only in LinkLogic.switchpoints, but none of the ArrayLinkLogic subclasses override getOrCreateModificationSwitchpoint, so it's always null. You could just have NativeArray.getLinkLogic return static instances of these three that'd eliminate three reference fields from every array instance (similar to how CharCodeLinkingLogic only has one instance). - Related: LinkLogic switch points are no longer used, the logic for handling them should be removed (or moved into a patch until needed again). - LengthNotWritableFilter(ArrayData, TreeMap) construtor shouldn't be copying the map; its invokers should ensure that data structures are copied when needed. - LengthNotWritableFilter.sliceMap(from, to) is not needed, it should be replaced with simply new TreeMap(extraElements.subMap(from, to)). - LengthNotWritableFilter.indexIterator() could just use "final List keys = computeIteratorKeys();" as the first line. The construction guarantees that the elements will be stricty monotonously ordered even after adding in the extraElements keySet. If needed, an "assert isStrictlyMonotonous(keys)" could be added, writing a simple linear function "boolean isStrictlyMonotonous(List)". On Nov 12, 2014, at 11:41 AM, Hannes Wallnoefer wrote: > A few minor remarks: > > - Shouldn't ArrayData.increaseLength and .decreaseLength be protected instead of public? > - Javadoc of ArrayData.length is missing # for link: {@link #setLength} (although it's a private field anyway...) > - Is the (index >= len) check needed in NativeArray.sort? Does not ArrayData.indexIterator take care of this? > - Some of the new tests use a mix of spaces/tabs for indentation. > > Otherwise looks good. > > Hannes > > Am 2014-11-11 um 17:37 schrieb Marcus Lagergren: >> Please review >> >> https://bugs.openjdk.java.net/browse/JDK-8035312 >> >> There were several corner cases related to length in general and setting length in arrays to not writable in particular. >> None of the existing run times pass all the tests, so this was a very hard area to get right (added 6 new unit tests) >> >> I?ve also gotten rid of the special casey length not writable SwitchPoint in NativeArray - now that I have a filter for LengtNotWritableArray that can?t be cast to a ContinuousArrayData in the fast paths, this handles itself anyway. >> >> webrev at: http://cr.openjdk.java.net/~lagergren/8035312/ >> >> /M >> > From marcus.lagergren at oracle.com Wed Nov 12 11:15:54 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 12 Nov 2014 12:15:54 +0100 Subject: Please review JDK-8035312 In-Reply-To: <754DA48D-8A54-44E9-A095-16DC3AF373AF@oracle.com> References: <07275425-4463-470D-935A-32B57FDC58A7@oracle.com> <54633977.804@oracle.com> <754DA48D-8A54-44E9-A095-16DC3AF373AF@oracle.com> Message-ID: <2703A85F-821D-4F22-887B-24AAFB78622D@oracle.com> Done. rerunning tests. > On 12 Nov 2014, at 12:00, Attila Szegedi wrote: > > My remarks: > > - NativeArray instances no longer need PushLinkLogic, PopLinkLogic, and ConcatLinkLogic objects. These objects are no longer instance-specific (their state is only in LinkLogic.switchpoints, but none of the ArrayLinkLogic subclasses override getOrCreateModificationSwitchpoint, so it's always null. You could just have NativeArray.getLinkLogic return static instances of these three that'd eliminate three reference fields from every array instance (similar to how CharCodeLinkingLogic only has one instance). > - Related: LinkLogic switch points are no longer used, the logic for handling them should be removed (or moved into a patch until needed again). > - LengthNotWritableFilter(ArrayData, TreeMap) construtor shouldn't be copying the map; its invokers should ensure that data structures are copied when needed. > - LengthNotWritableFilter.sliceMap(from, to) is not needed, it should be replaced with simply new TreeMap(extraElements.subMap(from, to)). > - LengthNotWritableFilter.indexIterator() could just use "final List keys = computeIteratorKeys();" as the first line. The construction guarantees that the elements will be stricty monotonously ordered even after adding in the extraElements keySet. If needed, an "assert isStrictlyMonotonous(keys)" could be added, writing a simple linear function "boolean isStrictlyMonotonous(List)". > > On Nov 12, 2014, at 11:41 AM, Hannes Wallnoefer wrote: > >> A few minor remarks: >> >> - Shouldn't ArrayData.increaseLength and .decreaseLength be protected instead of public? >> - Javadoc of ArrayData.length is missing # for link: {@link #setLength} (although it's a private field anyway...) >> - Is the (index >= len) check needed in NativeArray.sort? Does not ArrayData.indexIterator take care of this? >> - Some of the new tests use a mix of spaces/tabs for indentation. >> >> Otherwise looks good. >> >> Hannes >> >> Am 2014-11-11 um 17:37 schrieb Marcus Lagergren: >>> Please review >>> >>> https://bugs.openjdk.java.net/browse/JDK-8035312 >>> >>> There were several corner cases related to length in general and setting length in arrays to not writable in particular. >>> None of the existing run times pass all the tests, so this was a very hard area to get right (added 6 new unit tests) >>> >>> I?ve also gotten rid of the special casey length not writable SwitchPoint in NativeArray - now that I have a filter for LengtNotWritableArray that can?t be cast to a ContinuousArrayData in the fast paths, this handles itself anyway. >>> >>> webrev at: http://cr.openjdk.java.net/~lagergren/8035312/ >>> >>> /M >>> >> > From attila.szegedi at oracle.com Wed Nov 12 13:52:03 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 12 Nov 2014 14:52:03 +0100 Subject: Review request for JDK-8063037 Message-ID: <41DBB858-666A-445D-98A4-C74FD76C39D1@oracle.com> Please review JDK-8063037 at for Thanks, Attila. From hannes.wallnoefer at oracle.com Wed Nov 12 13:54:30 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 12 Nov 2014 14:54:30 +0100 Subject: Review request for JDK-8063037 In-Reply-To: <41DBB858-666A-445D-98A4-C74FD76C39D1@oracle.com> References: <41DBB858-666A-445D-98A4-C74FD76C39D1@oracle.com> Message-ID: <54636696.80005@oracle.com> +1 Am 2014-11-12 um 14:52 schrieb Attila Szegedi: > Please review JDK-8063037 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Wed Nov 12 13:59:03 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 12 Nov 2014 14:59:03 +0100 Subject: Review request for JDK-8063037 In-Reply-To: <41DBB858-666A-445D-98A4-C74FD76C39D1@oracle.com> References: <41DBB858-666A-445D-98A4-C74FD76C39D1@oracle.com> Message-ID: <7B80300A-3DD7-40F3-9C36-0447092DE5FD@oracle.com> +1 > On 12 Nov 2014, at 14:52, Attila Szegedi wrote: > > From attila.szegedi at oracle.com Wed Nov 12 14:08:42 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 12 Nov 2014 15:08:42 +0100 Subject: Review request for JDK-8064707 Message-ID: Please review JDK-8064707 at for Thanks, Attila. From marcus.lagergren at oracle.com Wed Nov 12 14:11:21 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 12 Nov 2014 15:11:21 +0100 Subject: Review request for JDK-8064707 In-Reply-To: References: Message-ID: <035F40D5-4924-4BB1-A272-36DC6662CFE9@oracle.com> +1 > On 12 Nov 2014, at 15:08, Attila Szegedi wrote: > > Please review JDK-8064707 at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Wed Nov 12 14:13:06 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 12 Nov 2014 15:13:06 +0100 Subject: Review request for JDK-8064707 In-Reply-To: References: Message-ID: <54636AF2.6000908@oracle.com> +1 Am 2014-11-12 um 15:08 schrieb Attila Szegedi: > Please review JDK-8064707 at for > > Thanks, > Attila. From lagergren at gmail.com Wed Nov 12 16:03:31 2014 From: lagergren at gmail.com (Marcus Lagergren) Date: Wed, 12 Nov 2014 17:03:31 +0100 Subject: Please review JDK-8063036 Message-ID: <08B1FE0A-BE67-4104-9964-F66FE8774C1D@gmail.com> Some small pretty printing issues with ?log=recompile, including duplicated lines for method lookups. Moved a lot of the text spewing to log level fine, and formatted type transitions in a lot more readable fashion. https://bugs.openjdk.java.net/browse/JDK-8063036 webrev: http://cr.openjdk.java.net/~lagergren/8063036/ /M From james.laskey at oracle.com Wed Nov 12 16:11:19 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 12 Nov 2014 12:11:19 -0400 Subject: Please review JDK-8063036 In-Reply-To: <08B1FE0A-BE67-4104-9964-F66FE8774C1D@gmail.com> References: <08B1FE0A-BE67-4104-9964-F66FE8774C1D@gmail.com> Message-ID: <55B8C114-F749-410F-B904-9F915C86BF97@oracle.com> +1 On Nov 12, 2014, at 12:03 PM, Marcus Lagergren wrote: > Some small pretty printing issues with ?log=recompile, including duplicated lines for method lookups. > Moved a lot of the text spewing to log level fine, and formatted type transitions in a lot more readable fashion. > > https://bugs.openjdk.java.net/browse/JDK-8063036 > > webrev: http://cr.openjdk.java.net/~lagergren/8063036/ > > /M > From hannes.wallnoefer at oracle.com Wed Nov 12 16:18:43 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 12 Nov 2014 17:18:43 +0100 Subject: Please review JDK-8063036 In-Reply-To: <08B1FE0A-BE67-4104-9964-F66FE8774C1D@gmail.com> References: <08B1FE0A-BE67-4104-9964-F66FE8774C1D@gmail.com> Message-ID: <54638863.2050304@oracle.com> +1 Am 2014-11-12 um 17:03 schrieb Marcus Lagergren: > Some small pretty printing issues with ?log=recompile, including duplicated lines for method lookups. > Moved a lot of the text spewing to log level fine, and formatted type transitions in a lot more readable fashion. > > https://bugs.openjdk.java.net/browse/JDK-8063036 > > webrev: http://cr.openjdk.java.net/~lagergren/8063036/ > > /M > From hannes.wallnoefer at oracle.com Thu Nov 13 12:18:23 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 13 Nov 2014 13:18:23 +0100 Subject: Review request for JDK-8064789: Nashorn should just warn on code store instantiation error Message-ID: <5464A18F.8090801@oracle.com> Please review JDK-8064789: Nashorn should just warn on code store instantiation error: http://cr.openjdk.java.net/~hannesw/8064789/ Thanks, Hannes From attila.szegedi at oracle.com Thu Nov 13 12:49:22 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 13 Nov 2014 13:49:22 +0100 Subject: Review request for JDK-8064789: Nashorn should just warn on code store instantiation error In-Reply-To: <5464A18F.8090801@oracle.com> References: <5464A18F.8090801@oracle.com> Message-ID: <5746FEFB-8A28-455E-BA95-98A9E18B337B@oracle.com> +1 On Nov 13, 2014, at 1:18 PM, Hannes Wallnoefer wrote: > Please review JDK-8064789: Nashorn should just warn on code store instantiation error: > > http://cr.openjdk.java.net/~hannesw/8064789/ > > Thanks, > Hannes From marcus.lagergren at oracle.com Thu Nov 13 15:20:03 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 13 Nov 2014 16:20:03 +0100 Subject: Please review JDK-8062937 Message-ID: Conservatively invalidating global properties from constant replacement if they are set with defineProperty, deleted or set with an accessor that varies at runtime, e.g. indexed setters. There is no performance regression on the octane benchmarks. For 8u40 I chose to use this conservative strategy, as it was simplest and it didn?t reduce performance for now. We?ll work on optimising indexed setters as part of the avatar performance project shortly anyway. Webrev at: http://cr.openjdk.java.net/~lagergren/8062937/webrev/ (please ignore runopt.sh, where I happened to flip the x bit - I?ve reverted that) /M ' From james.laskey at oracle.com Thu Nov 13 15:47:41 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 13 Nov 2014 11:47:41 -0400 Subject: Please review JDK-8062937 In-Reply-To: References: Message-ID: <6184C5E1-173C-4E8D-988D-803000DEB0CE@oracle.com> +1 On Nov 13, 2014, at 11:20 AM, Marcus Lagergren wrote: > Conservatively invalidating global properties from constant replacement if they are set with defineProperty, deleted or set with an accessor that varies at runtime, e.g. indexed setters. > There is no performance regression on the octane benchmarks. For 8u40 I chose to use this conservative strategy, as it was simplest and it didn?t reduce performance for now. > We?ll work on optimising indexed setters as part of the avatar performance project shortly anyway. > > Webrev at: > > http://cr.openjdk.java.net/~lagergren/8062937/webrev/ > > (please ignore runopt.sh, where I happened to flip the x bit - I?ve reverted that) > > /M > ' From hannes.wallnoefer at oracle.com Thu Nov 13 15:52:56 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 13 Nov 2014 16:52:56 +0100 Subject: Please review JDK-8062937 In-Reply-To: References: Message-ID: <5464D3D8.7070107@oracle.com> +1 Am 2014-11-13 um 16:20 schrieb Marcus Lagergren: > Conservatively invalidating global properties from constant replacement if they are set with defineProperty, deleted or set with an accessor that varies at runtime, e.g. indexed setters. > There is no performance regression on the octane benchmarks. For 8u40 I chose to use this conservative strategy, as it was simplest and it didn?t reduce performance for now. > We?ll work on optimising indexed setters as part of the avatar performance project shortly anyway. > > Webrev at: > > http://cr.openjdk.java.net/~lagergren/8062937/webrev/ > > (please ignore runopt.sh, where I happened to flip the x bit - I?ve reverted that) > > /M > ' From sergey.lugovoy at oracle.com Fri Nov 14 11:20:53 2014 From: sergey.lugovoy at oracle.com (Sergey Lugovoy) Date: Fri, 14 Nov 2014 14:20:53 +0300 Subject: RFR 8062638: RuntimeException when run command from js with -scripting on Cygwin In-Reply-To: <54608750.60700@oracle.com> References: <54608750.60700@oracle.com> Message-ID: <5465E595.3020802@oracle.com> Hi all, Could you review this change, please. It's blocking testing nashorn on Windows. On 10.11.2014 12:37, Sergey Lugovoy wrote: > Please review : http://cr.openjdk.java.net/~slugovoy/8062638/webrev.00/ > bug : https://bugs.openjdk.java.net/browse/JDK-8062638 > -- Thanks, Sergey From hannes.wallnoefer at oracle.com Fri Nov 14 11:29:17 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 14 Nov 2014 12:29:17 +0100 Subject: RFR 8062638: RuntimeException when run command from js with -scripting on Cygwin In-Reply-To: <5465E595.3020802@oracle.com> References: <54608750.60700@oracle.com> <5465E595.3020802@oracle.com> Message-ID: <5465E78D.7000802@oracle.com> +1 Am 2014-11-14 um 12:20 schrieb Sergey Lugovoy: > Hi all, > Could you review this change, please. > It's blocking testing nashorn on Windows. > > On 10.11.2014 12:37, Sergey Lugovoy wrote: >> Please review : http://cr.openjdk.java.net/~slugovoy/8062638/webrev.00/ >> bug : https://bugs.openjdk.java.net/browse/JDK-8062638 >> > From bliang at linkedin.com Thu Nov 13 22:01:19 2014 From: bliang at linkedin.com (Bernard Liang) Date: Thu, 13 Nov 2014 22:01:19 +0000 Subject: Nashorn performance regression from JDK8u5 to JDK8u25? Message-ID: Hello, After running some performance tests on the Cartesian product of ([JDK8u5, JDK8u25] x [simple template, complex templates] x [all-or-nothing, streaming chunks] x [single dust instance per thread, pooled dust instances] x [blank Dust instances, Dust instances with templates preloaded]), we find that JDK8u25 performance is very consistently considerably worse than JDK8u5 (by roughly 10-100%, with the average falling somewhere between there). The relevant code has been executed enough times (on the order of 10,000 times) to reach reasonably warmed-up states. If some of the items on the axes of the Cartesian product don?t make much sense, you can ignore the fuzzy parts of the detailed breakdown for now, with the general understanding that various different environments have been tested and shown to yield the same results. Some additional high-level context: Dust is basically a templating language used to render JSON data into HTML with compilable ?templates": https://github.com/linkedin/dustjs (we are at the v2.4.2 tag) ?simple template? = ~150 bytes each of one (precompiled) template + context JSON (attached) ?complex templates? = ~350 compiled templates spanning ~245KB in compiled JS + ~75KB of JSON context (proprietary data) >From https://blogs.oracle.com/nashorn/entry/latest_news_from_the_nashorn, it sounded like there were some recent updates made to Nashorn performance around the u20 mark, but that seems to have caused a regression rather than an improvement. Is this something that nashorn-dev is aware of? Is there any way we can help diagnose the issue further using publicly safe data? (If you?re looking for a way to reproduce this, the attached basic Dust template + JSON context should be adequate under almost any environment.) Regards, Bernard Liang From marcus.lagergren at oracle.com Mon Nov 17 11:21:05 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 17 Nov 2014 12:21:05 +0100 Subject: Please review JDK-8049407 Message-ID: <3B0BE9B5-29D7-4295-A9E9-A505A791C783@oracle.com> Typed Arrays produce different results on big endian and little endian platforms. This is per spec (https://www.khronos.org/registry/typedarray/specs/latest/ ), however NASHORN-377.js.EXPECTED assumes a little endian system for the output to be the same. Added @bigendian and @littleendian test properties and a verification test for both platforms, along with a NASHORN-377 version for big endian systems. Webrev is at: http://cr.openjdk.java.net/~lagergren/8049407/ /M From sundararajan.athijegannathan at oracle.com Mon Nov 17 11:38:23 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 17 Nov 2014 17:08:23 +0530 Subject: Please review JDK-8049407 In-Reply-To: <3B0BE9B5-29D7-4295-A9E9-A505A791C783@oracle.com> References: <3B0BE9B5-29D7-4295-A9E9-A505A791C783@oracle.com> Message-ID: <5469DE2F.6040104@oracle.com> +1 On Monday 17 November 2014 04:51 PM, Marcus Lagergren wrote: > Typed Arrays produce different results on big endian and little endian platforms. This is per spec (https://www.khronos.org/registry/typedarray/specs/latest/ ), however NASHORN-377.js.EXPECTED assumes a little endian system for the output to be the same. > > Added @bigendian and @littleendian test properties and a verification test for both platforms, along with a NASHORN-377 version for big endian systems. > > Webrev is at: http://cr.openjdk.java.net/~lagergren/8049407/ > > /M > From hannes.wallnoefer at oracle.com Mon Nov 17 11:41:50 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 17 Nov 2014 12:41:50 +0100 Subject: Please review JDK-8049407 In-Reply-To: <3B0BE9B5-29D7-4295-A9E9-A505A791C783@oracle.com> References: <3B0BE9B5-29D7-4295-A9E9-A505A791C783@oracle.com> Message-ID: <5469DEFE.3080303@oracle.com> +1 Am 2014-11-17 um 12:21 schrieb Marcus Lagergren: > Typed Arrays produce different results on big endian and little endian platforms. This is per spec (https://www.khronos.org/registry/typedarray/specs/latest/ ), however NASHORN-377.js.EXPECTED assumes a little endian system for the output to be the same. > > Added @bigendian and @littleendian test properties and a verification test for both platforms, along with a NASHORN-377 version for big endian systems. > > Webrev is at: http://cr.openjdk.java.net/~lagergren/8049407/ > > /M > From marcus.lagergren at oracle.com Mon Nov 17 11:41:56 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 17 Nov 2014 12:41:56 +0100 Subject: RFR 8062638: RuntimeException when run command from js with -scripting on Cygwin In-Reply-To: <5465E595.3020802@oracle.com> References: <54608750.60700@oracle.com> <5465E595.3020802@oracle.com> Message-ID: +1 > On 14 Nov 2014, at 12:20, Sergey Lugovoy wrote: > > Hi all, > Could you review this change, please. > It's blocking testing nashorn on Windows. > > On 10.11.2014 12:37, Sergey Lugovoy wrote: >> Please review : http://cr.openjdk.java.net/~slugovoy/8062638/webrev.00/ >> bug : https://bugs.openjdk.java.net/browse/JDK-8062638 >> > > -- > Thanks, > Sergey > From marcus.lagergren at oracle.com Mon Nov 17 11:46:31 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 17 Nov 2014 12:46:31 +0100 Subject: Review request for JDK-8064789: Nashorn should just warn on code store instantiation error In-Reply-To: <5464A18F.8090801@oracle.com> References: <5464A18F.8090801@oracle.com> Message-ID: +1 > On 13 Nov 2014, at 13:18, Hannes Wallnoefer wrote: > > Please review JDK-8064789: Nashorn should just warn on code store instantiation error: > > http://cr.openjdk.java.net/~hannesw/8064789/ > > Thanks, > Hannes From sergey.lugovoy at oracle.com Mon Nov 17 12:57:20 2014 From: sergey.lugovoy at oracle.com (Sergey Lugovoy) Date: Mon, 17 Nov 2014 15:57:20 +0300 Subject: [8u40] request for approval to backport of nashorn changesets Message-ID: <5469F0B0.8060606@oracle.com> Hi, Please approve backport of the following 2 changesets from jdk9 to jdk8u40. All changesets appled "as is" Bug: https://bugs.openjdk.java.net/browse/JDK-8062638 changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0c9f3369f3d3 Bug: https://bugs.openjdk.java.net/browse/JDK-8054343 changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/2520d5e7bc5f -- Thanks, Sergey From sean.coffey at oracle.com Mon Nov 17 14:35:52 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 17 Nov 2014 14:35:52 +0000 Subject: [8u40] 8062638 ,8054343 - request for approval to backport of nashorn changesets In-Reply-To: <5469F0B0.8060606@oracle.com> References: <5469F0B0.8060606@oracle.com> Message-ID: <546A07C8.20808@oracle.com> I've added the bugIDs to the subject line. I notice the review links are missing also. Please remember for the next time.[1] Can you add a 'testbug' or 'noreg-self' label to both bug reports ? Approved. regards, Sean. [1] http://openjdk.java.net/projects/jdk8u/approval-template.html On 17/11/14 12:57, Sergey Lugovoy wrote: > Hi, > Please approve backport of the following 2 changesets from jdk9 to > jdk8u40. > All changesets appled "as is" > > Bug: https://bugs.openjdk.java.net/browse/JDK-8062638 > changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0c9f3369f3d3 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8054343 > changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/2520d5e7bc5f > From bliang at linkedin.com Tue Nov 18 02:21:16 2014 From: bliang at linkedin.com (Bernard Liang) Date: Tue, 18 Nov 2014 02:21:16 +0000 Subject: Nashorn performance regression from JDK8u5 to JDK8u25? In-Reply-To: <546A64C8.9040503@oracle.com> References: <546A64C8.9040503@oracle.com> Message-ID: Michel et al, I?ve run our local test battery using the link you provided, and while in some cases there is improvement, overall the performance still seems to be closer to u25 levels than u5 levels. For what it?s worth, I did notice that the performance improvements from u25 to u40 were generally better in pooled environments than ones where a single instance of the execution environment was running per thread. This leads itself to a few questions, some of which are reiterated from the original inquiry: * Is anyone familiar with (significant) specific changes in the Nashorn libraries from u5 => u25 => u40 that might be related to this regression and could explain the u25 and/or u40 changes in more detail (that might have led to the recommendation to use u40)? * Do you have any performance suites (internal or other) that test various Nashorn benchmarks across different releases (of JDK8, for instance)? Do the results of those correlate with our findings? Regards, Bernard Liang PS. The output of `java -version` most recently tested was as follows: java version "1.8.0_40-ea" Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b16, mixed mode) Previous versions tested: java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) java version "1.8.0_05" Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) From: Michel Trudeau > Date: Monday, November 17, 2014 at 1:12 PM To: Bernard Liang > Cc: "nashorn-dev at openjdk.java.net" > Subject: Re: Nashorn performance regression from JDK8u5 to JDK8u25? Bernard, It'd be great if you could try the latest 8u40 stable build. We are planning to release 8u40 early in the new year. https://jdk8.java.net/download.html We also have an optional optimizer in 8u40, enable it with the command line argument '-ot'. Thanks, Michel Bernard Liang wrote: Hello, After running some performance tests on the Cartesian product of ([JDK8u5, JDK8u25] x [simple template, complex templates] x [all-or-nothing, streaming chunks] x [single dust instance per thread, pooled dust instances] x [blank Dust instances, Dust instances with templates preloaded]), we find that JDK8u25 performance is very consistently considerably worse than JDK8u5 (by roughly 10-100%, with the average falling somewhere between there). The relevant code has been executed enough times (on the order of 10,000 times) to reach reasonably warmed-up states. If some of the items on the axes of the Cartesian product don?t make much sense, you can ignore the fuzzy parts of the detailed breakdown for now, with the general understanding that various different environments have been tested and shown to yield the same results. Some additional high-level context: Dust is basically a templating language used to render JSON data into HTML with compilable ?templates": https://github.com/linkedin/dustjs (we are at the v2.4.2 tag) ?simple template? = ~150 bytes each of one (precompiled) template + context JSON (attached) ?complex templates? = ~350 compiled templates spanning ~245KB in compiled JS + ~75KB of JSON context (proprietary data) >From https://blogs.oracle.com/nashorn/entry/latest_news_from_the_nashorn, it sounded like there were some recent updates made to Nashorn performance around the u20 mark, but that seems to have caused a regression rather than an improvement. Is this something that nashorn-dev is aware of? Is there any way we can help diagnose the issue further using publicly safe data? (If you?re looking for a way to reproduce this, the attached basic Dust template + JSON context should be adequate under almost any environment.) Regards, Bernard Liang From benjamin.sieffert at metrigo.de Wed Nov 19 09:40:08 2014 From: benjamin.sieffert at metrigo.de (Benjamin Sieffert) Date: Wed, 19 Nov 2014 10:40:08 +0100 Subject: A certain (type of?) callsite seems to always require relinking Message-ID: Hello everyone, it started with a peculiar obversion about our nashorn-utilising application, that I made: It continues to load around a hundred new anonymous classes *per second*, even without new scripts being introduced ? i.e. we are just running the same javascripts over and over again, with different arguments. So I ran the application with -tcs=miss and from what I see, eventually there will be only a single call left that is producing all the output and therefor, I believe, all the memory load. (Am I correct in this assumption?) What I can say about the call is the following: - return type is an array of differing length (but always of the same type) - there are two arguments, of which the first one will always exactly match the declaration, the second one is a subclass of the one used in the declaration ? but always the same subclass - method is implemented in an abstract class - receiver is one of about a dozen classes that inherit from this abstract class - none of the receivers overwrite the original implementation or overload the method When I look into the trace output, there's often a bunch of "TAG MISS library:212 dyn:getMethod|getProp|getElem: ?" in a row, then a whole lot of "TAG MISS library:212 dyn:call([jdk.internal.dynalink.beans.SimpleDynamicMethod ?" with a bit of the first one inbetween. Is this a known issue? Is there something I can do to alleviate the problem? As it is, I might just end up implementing the whole chunk in Java and be done with it, but I thought this might be worthy of some discussion. If there's some important information that I have left out, I'll be glad to follow up with it. Regards, Benjamin -- Benjamin Sieffert metrigo GmbH Sternstr. 106 20357 Hamburg Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, Martin Rie? Die Gesellschaft ist eingetragen beim Registergericht Hamburg Nr. HRB 120447. From hannes.wallnoefer at oracle.com Wed Nov 19 10:06:55 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 19 Nov 2014 11:06:55 +0100 Subject: A certain (type of?) callsite seems to always require relinking In-Reply-To: References: Message-ID: <546C6BBF.5010904@oracle.com> Hi Benjamin, Thanks for the report. There is indeed something going wrong here. Ideally, an app would not (or only occasionally) relink once it has stabilized. I think we should be able to reproduce the problem from your description: method in abstract class, about a dozen subclasses none of which overwrites the original method. One question: How is the script evaluated? Does all this take place within a single script engine eval()? Or are you repeatedly evaluating/calling into the script engine? Thanks, Hannes Am 2014-11-19 um 10:40 schrieb Benjamin Sieffert: > Hello everyone, > > it started with a peculiar obversion about our nashorn-utilising > application, that I made: It continues to load around a hundred new > anonymous classes *per second*, even without new scripts being introduced ? > i.e. we are just running the same javascripts over and over again, with > different arguments. > So I ran the application with -tcs=miss and from what I see, eventually > there will be only a single call left that is producing all the output and > therefor, I believe, all the memory load. (Am I correct in this assumption?) > > What I can say about the call is the following: > > - return type is an array of differing length (but always of the same type) > - there are two arguments, of which the first one will always exactly match > the declaration, the second one is a subclass of the one used in the > declaration ? but always the same subclass > - method is implemented in an abstract class > - receiver is one of about a dozen classes that inherit from this abstract > class > - none of the receivers overwrite the original implementation or overload > the method > > When I look into the trace output, there's often a bunch of > "TAG MISS library:212 dyn:getMethod|getProp|getElem: ?" > in a row, then a whole lot of > "TAG MISS library:212 > dyn:call([jdk.internal.dynalink.beans.SimpleDynamicMethod ?" > with a bit of the first one inbetween. > > Is this a known issue? Is there something I can do to alleviate the > problem? As it is, I might just end up implementing the whole chunk in Java > and be done with it, but I thought this might be worthy of some discussion. > If there's some important information that I have left out, I'll be glad to > follow up with it. > > Regards, > Benjamin > From benjamin.sieffert at metrigo.de Wed Nov 19 10:25:01 2014 From: benjamin.sieffert at metrigo.de (Benjamin Sieffert) Date: Wed, 19 Nov 2014 11:25:01 +0100 Subject: A certain (type of?) callsite seems to always require relinking In-Reply-To: <546C6BBF.5010904@oracle.com> References: <546C6BBF.5010904@oracle.com> Message-ID: Hello again, it is always the same script engine being used, and multi-threaded at that. There is no shared state being manipulated in the javascript, though ? the relevant state of each thread is completely method-scoped. Entry is therefor not done via eval(), but by using callMember() on an object previously retrieved from an eval() call. Another relevant thing here might be that the problematic call itself is a bit on the expensive side (up to 5ms, mostly under 1ms) and requires some amount of synchronization (accessing a cache and an in-memory lucene index). I can't gauge whether this might possibly have any impact on the linking. - Benjamin On 19 November 2014 11:06, Hannes Wallnoefer wrote: > Hi Benjamin, > > Thanks for the report. There is indeed something going wrong here. > Ideally, an app would not (or only occasionally) relink once it has > stabilized. > > I think we should be able to reproduce the problem from your description: > method in abstract class, about a dozen subclasses none of which overwrites > the original method. > > One question: How is the script evaluated? Does all this take place within > a single script engine eval()? Or are you repeatedly evaluating/calling > into the script engine? > > Thanks, > Hannes > > Am 2014-11-19 um 10:40 schrieb Benjamin Sieffert: > > Hello everyone, >> >> it started with a peculiar obversion about our nashorn-utilising >> application, that I made: It continues to load around a hundred new >> anonymous classes *per second*, even without new scripts being introduced >> ? >> i.e. we are just running the same javascripts over and over again, with >> different arguments. >> So I ran the application with -tcs=miss and from what I see, eventually >> there will be only a single call left that is producing all the output and >> therefor, I believe, all the memory load. (Am I correct in this >> assumption?) >> >> What I can say about the call is the following: >> >> - return type is an array of differing length (but always of the same >> type) >> - there are two arguments, of which the first one will always exactly >> match >> the declaration, the second one is a subclass of the one used in the >> declaration ? but always the same subclass >> - method is implemented in an abstract class >> - receiver is one of about a dozen classes that inherit from this abstract >> class >> - none of the receivers overwrite the original implementation or overload >> the method >> >> When I look into the trace output, there's often a bunch of >> "TAG MISS library:212 dyn:getMethod|getProp|getElem: ?" >> in a row, then a whole lot of >> "TAG MISS library:212 >> dyn:call([jdk.internal.dynalink.beans.SimpleDynamicMethod ?" >> with a bit of the first one inbetween. >> >> Is this a known issue? Is there something I can do to alleviate the >> problem? As it is, I might just end up implementing the whole chunk in >> Java >> and be done with it, but I thought this might be worthy of some >> discussion. >> If there's some important information that I have left out, I'll be glad >> to >> follow up with it. >> >> Regards, >> Benjamin >> >> > -- Benjamin Sieffert metrigo GmbH Sternstr. 106 20357 Hamburg Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, Martin Rie? Die Gesellschaft ist eingetragen beim Registergericht Hamburg Nr. HRB 120447. From attila.szegedi at oracle.com Wed Nov 19 14:41:46 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 19 Nov 2014 15:41:46 +0100 Subject: A certain (type of?) callsite seems to always require relinking In-Reply-To: References: Message-ID: Hi Benjamin, I've been thinking about this, and I believe I know what the issue might be. Unfortunately, I don't currently have a good solution for it (although I'll be thinking some more about it). Basically, call sites are linked with method handles that are guarded with a test for exact receiver type (basically obj.getClass() == X.class). Call sites further can have up to 8 methods linked into them (in a LRU fashion) in a waterfall cascade of guard-with-tests. If your call site sees more than 8 receiver types (this number is fixed right now), it'll keep relinking as it'll only remember the most recent 8. Even if you don't override the method in subclasses, we can't use a more generic guard because we can't prove that there won't ever be a new subclass that won't overload the method. Note I said overload, not override: that's not a mistake. Here's a scenario: public class A { public void foo(Object o) { ... } } public class B extends A { } Now imagine a script call site "a.foo('Hello')". When it's hit with an instance of B, we'll use "a.getClass() == B.class" as the guard. Now, if you have a bunch of subclasses B1?B12 all extending A, you'll end up with 12 linkages to the same method, but all guarded with a different "a.getClass() == Bn.class" guard. Actually, as I said above, you'll end up with a call site incorporating the 8 most recently used ones, and force relinking when the 9th comes along. You could ask "what'd be the harm in linking to "A.foo(Object)" method just once with "a instanceof A" guard? The harm becomes apparent if we now define public class B extends A { public void foo(String s) { ... } } With instanceof linkage, invocation at the call site with an instance of C would pass the guard, and invoke A.foo(Object), which is incorrect as it'd be expected to invoke C.foo(String) instead. As you can see, this is not a matter of a subclass overriding foo(Object), but rather it's a matter of the subclass overloading the "foo" name with a new signature. The only strategy we have for avoiding this is at the moment is almost always linking with exact receiver class guards :-( On a sidenote, I said "almost always" above as there's a special class of methods we can, in fact, link with "instanceof" guards on the most generic declaring superclass: methods taking zero arguments (e.g. all property getters). Since overload choice is actually per-arity, zero-argument methods can't effectively be overloaded, so for them we actually use "instanceof" guards. But, sadly, we can't use them for any other methods. One strategy to cope with the issue would be to check during linking if none of the currently known subclasses add new overloads to the method (or even, not overload it in a manner where a different method would be chosen for the static type at the call site), and if they don't, then link with a switch point representing this invariant. Then, whenever a subclass is loaded into the VM that invalidates the assumption, invalidate the switch points. Unfortunately, this strategy requires whole-VM knowledge of loaded classes, and we could only do it if we added a java.lang.instrument agent as a mandatory component in Nashorn. (Another sidenote: we're trying very hard to keep Nashorn from relying on any implementation-specific or undocumented platform or VM features; so far we have always managed to rely solely on public Java APIs also because we'd like to prove that they're sufficient for a dynamic language implementation on the JVM.) Alternatively, we could also try to prove a weaker assumption that the chosen method would always be the one invoked at the call site (e.g. the method type of the call site guarantees that there can't ever be a more specific method to invoke), but in reality this'd be quite hard and since Nashorn internally mostly only uses boolean, int, long, double, and Object as the call site signatures, it probably also wouldn't be effective (e.g. we could nearly never prove this invariant). So that's probably not worth it. As a yet another solution, we might give you a system property or other configuration means of allowing link chains longer than 8 (in your case, if you have 12 subclasses, then 12 should be enough). Sorry for not having a better answer? Attila. On Nov 19, 2014, at 10:40 AM, Benjamin Sieffert wrote: > Hello everyone, > > it started with a peculiar obversion about our nashorn-utilising > application, that I made: It continues to load around a hundred new > anonymous classes *per second*, even without new scripts being introduced ? > i.e. we are just running the same javascripts over and over again, with > different arguments. > So I ran the application with -tcs=miss and from what I see, eventually > there will be only a single call left that is producing all the output and > therefor, I believe, all the memory load. (Am I correct in this assumption?) > > What I can say about the call is the following: > > - return type is an array of differing length (but always of the same type) > - there are two arguments, of which the first one will always exactly match > the declaration, the second one is a subclass of the one used in the > declaration ? but always the same subclass > - method is implemented in an abstract class > - receiver is one of about a dozen classes that inherit from this abstract > class > - none of the receivers overwrite the original implementation or overload > the method > > When I look into the trace output, there's often a bunch of > "TAG MISS library:212 dyn:getMethod|getProp|getElem: ?" > in a row, then a whole lot of > "TAG MISS library:212 > dyn:call([jdk.internal.dynalink.beans.SimpleDynamicMethod ?" > with a bit of the first one inbetween. > > Is this a known issue? Is there something I can do to alleviate the > problem? As it is, I might just end up implementing the whole chunk in Java > and be done with it, but I thought this might be worthy of some discussion. > If there's some important information that I have left out, I'll be glad to > follow up with it. > > Regards, > Benjamin > > -- > Benjamin Sieffert > metrigo GmbH > Sternstr. 106 > 20357 Hamburg > > Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, > Martin Rie? > Die Gesellschaft ist eingetragen beim Registergericht Hamburg > Nr. HRB 120447. From forax at univ-mlv.fr Wed Nov 19 16:25:32 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 19 Nov 2014 17:25:32 +0100 Subject: A certain (type of?) callsite seems to always require relinking In-Reply-To: References: Message-ID: <546CC47C.1010405@univ-mlv.fr> Hi Attila, I've had the very same issue with a runtime of a proprietary language. What I've proposed in the JSR 292 cookbook for this case is to use a dispatch table https://code.google.com/p/jsr292-cookbook/source/browse/trunk/bimorphic-cache/src/jsr292/cookbook/bicache/RT.java https://code.google.com/p/jsr292-cookbook/source/browse/trunk/bimorphic-cache/src/jsr292/cookbook/bicache/DispatchMap.java It's a hash table which associate a Class to a method handle, so the code avoid a linear check that you have with a tree of GWT and can share method handle trees between subclasses. Obviously, there is no inlining from the callsite to a method handle chain (the JIT can not see through the hash table). I also think Groovy use something similar because Jochen found a bug in the dispatch table code last year. cheers, R?mi On 11/19/2014 03:41 PM, Attila Szegedi wrote: > Hi Benjamin, > > I've been thinking about this, and I believe I know what the issue might be. Unfortunately, I don't currently have a good solution for it (although I'll be thinking some more about it). > > Basically, call sites are linked with method handles that are guarded with a test for exact receiver type (basically obj.getClass() == X.class). Call sites further can have up to 8 methods linked into them (in a LRU fashion) in a waterfall cascade of guard-with-tests. If your call site sees more than 8 receiver types (this number is fixed right now), it'll keep relinking as it'll only remember the most recent 8. > > Even if you don't override the method in subclasses, we can't use a more generic guard because we can't prove that there won't ever be a new subclass that won't overload the method. Note I said overload, not override: that's not a mistake. Here's a scenario: > > public class A { > public void foo(Object o) { ... } > } > > public class B extends A { > } > > Now imagine a script call site "a.foo('Hello')". When it's hit with an instance of B, we'll use "a.getClass() == B.class" as the guard. Now, if you have a bunch of subclasses B1?B12 all extending A, you'll end up with 12 linkages to the same method, but all guarded with a different "a.getClass() == Bn.class" guard. Actually, as I said above, you'll end up with a call site incorporating the 8 most recently used ones, and force relinking when the 9th comes along. > > You could ask "what'd be the harm in linking to "A.foo(Object)" method just once with "a instanceof A" guard? The harm becomes apparent if we now define > > public class B extends A { > public void foo(String s) { ... } > } > > With instanceof linkage, invocation at the call site with an instance of C would pass the guard, and invoke A.foo(Object), which is incorrect as it'd be expected to invoke C.foo(String) instead. As you can see, this is not a matter of a subclass overriding foo(Object), but rather it's a matter of the subclass overloading the "foo" name with a new signature. > > The only strategy we have for avoiding this is at the moment is almost always linking with exact receiver class guards :-( > > On a sidenote, I said "almost always" above as there's a special class of methods we can, in fact, link with "instanceof" guards on the most generic declaring superclass: methods taking zero arguments (e.g. all property getters). Since overload choice is actually per-arity, zero-argument methods can't effectively be overloaded, so for them we actually use "instanceof" guards. But, sadly, we can't use them for any other methods. > > One strategy to cope with the issue would be to check during linking if none of the currently known subclasses add new overloads to the method (or even, not overload it in a manner where a different method would be chosen for the static type at the call site), and if they don't, then link with a switch point representing this invariant. Then, whenever a subclass is loaded into the VM that invalidates the assumption, invalidate the switch points. Unfortunately, this strategy requires whole-VM knowledge of loaded classes, and we could only do it if we added a java.lang.instrument agent as a mandatory component in Nashorn. > > (Another sidenote: we're trying very hard to keep Nashorn from relying on any implementation-specific or undocumented platform or VM features; so far we have always managed to rely solely on public Java APIs also because we'd like to prove that they're sufficient for a dynamic language implementation on the JVM.) > > Alternatively, we could also try to prove a weaker assumption that the chosen method would always be the one invoked at the call site (e.g. the method type of the call site guarantees that there can't ever be a more specific method to invoke), but in reality this'd be quite hard and since Nashorn internally mostly only uses boolean, int, long, double, and Object as the call site signatures, it probably also wouldn't be effective (e.g. we could nearly never prove this invariant). So that's probably not worth it. > > As a yet another solution, we might give you a system property or other configuration means of allowing link chains longer than 8 (in your case, if you have 12 subclasses, then 12 should be enough). > > Sorry for not having a better answer? > Attila. > > On Nov 19, 2014, at 10:40 AM, Benjamin Sieffert wrote: > >> Hello everyone, >> >> it started with a peculiar obversion about our nashorn-utilising >> application, that I made: It continues to load around a hundred new >> anonymous classes *per second*, even without new scripts being introduced ? >> i.e. we are just running the same javascripts over and over again, with >> different arguments. >> So I ran the application with -tcs=miss and from what I see, eventually >> there will be only a single call left that is producing all the output and >> therefor, I believe, all the memory load. (Am I correct in this assumption?) >> >> What I can say about the call is the following: >> >> - return type is an array of differing length (but always of the same type) >> - there are two arguments, of which the first one will always exactly match >> the declaration, the second one is a subclass of the one used in the >> declaration ? but always the same subclass >> - method is implemented in an abstract class >> - receiver is one of about a dozen classes that inherit from this abstract >> class >> - none of the receivers overwrite the original implementation or overload >> the method >> >> When I look into the trace output, there's often a bunch of >> "TAG MISS library:212 dyn:getMethod|getProp|getElem: ?" >> in a row, then a whole lot of >> "TAG MISS library:212 >> dyn:call([jdk.internal.dynalink.beans.SimpleDynamicMethod ?" >> with a bit of the first one inbetween. >> >> Is this a known issue? Is there something I can do to alleviate the >> problem? As it is, I might just end up implementing the whole chunk in Java >> and be done with it, but I thought this might be worthy of some discussion. >> If there's some important information that I have left out, I'll be glad to >> follow up with it. >> >> Regards, >> Benjamin >> >> -- >> Benjamin Sieffert >> metrigo GmbH >> Sternstr. 106 >> 20357 Hamburg >> >> Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, >> Martin Rie? >> Die Gesellschaft ist eingetragen beim Registergericht Hamburg >> Nr. HRB 120447. From pradeep at yantranet.com Thu Nov 20 05:19:24 2014 From: pradeep at yantranet.com (Pradeep Dantuluri) Date: Thu, 20 Nov 2014 10:49:24 +0530 Subject: ClassNotFoundException with ScriptObjectMirror Message-ID: Hi, When I use nashorn with ScriptObjectMirror to pass an a JS object to java, I get a runtime exception although it compiles just fine. java.lang.NoClassDefFoundError: jdk/nashorn/api/scripting/ScriptObjectMirror at actors.rules.RuleEngine$$anonfun$receive$1.applyOrElse(RuleEngine.scala:86) ~[classes/:na] at akka.actor.Actor$class.aroundReceive(Actor.scala:465) ~[akka-actor_2.10-2.3.6.jar:na] at actors.rules.RuleEngine.aroundReceive(RuleEngine.scala:16) ~[classes/:na] at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516) [akka-actor_2.10-2.3.6.jar:na] at akka.actor.ActorCell.invoke(ActorCell.scala:487) [akka-actor_2.10-2.3.6.jar:na] at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:238) [akka-actor_2.10-2.3.6.jar:na] at akka.dispatch.Mailbox.run(Mailbox.scala:220) [akka-actor_2.10-2.3.6.jar:na] at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:393) [akka-actor_2.10-2.3.6.jar:na] at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) [scala-library.jar:na] at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339) [scala-library.jar:na] at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) [scala-library.jar:na] at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107) [scala-library.jar:na] Caused by: java.lang.ClassNotFoundException: jdk.nashorn.api.scripting.ScriptObjectMirror at java.net.URLClassLoader$1.run(URLClassLoader.java:372) ~[na:1.8.0_05] at java.net.URLClassLoader$1.run(URLClassLoader.java:361) ~[na:1.8.0_05] at java.security.AccessController.doPrivileged(Native Method) ~[na:1.8.0_05] at java.net.URLClassLoader.findClass(URLClassLoader.java:360) ~[na:1.8.0_05] at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[na:1.8.0_05] at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[na:1.8.0_05] ... 12 common frames omitted My Environment Scala 2.10.4 Java 1.8..0_05 Ubuntu 14.04 LTS 64-bit Did you notice any similar behaviour ? -- Pradeep From benjamin.sieffert at metrigo.de Thu Nov 20 08:47:15 2014 From: benjamin.sieffert at metrigo.de (Benjamin Sieffert) Date: Thu, 20 Nov 2014 09:47:15 +0100 Subject: A certain (type of?) callsite seems to always require relinking In-Reply-To: References: Message-ID: Hi, well, thanks for the interesting insight into nashorn's inner workings. I was quickly able to verify that this was indeed what was causing the phenomenon. With exactly 8 different receiver-classes, the loaded class count now remains stable. The one thing I'm left wondering, though, is: Accepting the performance impact for now, isn't there a better resource to channel it through? What I mean is, in this stable application state, there are about 22.000 classes loaded. With more than 8 receiver classes, the count will go up to 700.000, where a full GC kicks in and collects all but (those) 22k classes, because all the others are obviously discarded linkages of the problematic callsite. Now this is with a CodeCache of 800M, where we only need about 100M. One can easily imagine how with more tightly tuned settings (say, a 120M cap on the CodeCache, or some low cap on the Metaspace), the frequency of full GCs would become quite scary. Even more so when we introduce a second problematic callsite. And in profiling the application then, I think this would be very hard to make out for a "na?ve user" that this is, in a way, "normal behaviour". I also seem to remember, from an earlier discussion, that there are megamorphic callsites in nashorn. Would this not qualify as one? - Benjamin On 19 November 2014 15:41, Attila Szegedi wrote: > Hi Benjamin, > > I've been thinking about this, and I believe I know what the issue might > be. Unfortunately, I don't currently have a good solution for it (although > I'll be thinking some more about it). > > Basically, call sites are linked with method handles that are guarded with > a test for exact receiver type (basically obj.getClass() == X.class). > Call sites further can have up to 8 methods linked into them (in a LRU > fashion) in a waterfall cascade of guard-with-tests. If your call site sees > more than 8 receiver types (this number is fixed right now), it'll keep > relinking as it'll only remember the most recent 8. > > Even if you don't override the method in subclasses, we can't use a more > generic guard because we can't prove that there won't ever be a new > subclass that won't overload the method. Note I said *overload*, not > *override*: that's not a mistake. Here's a scenario: > > public class A { > public void foo(Object o) { ... } > } > > public class B extends A { > } > > Now imagine a script call site "a.foo('Hello')". When it's hit with an > instance of B, we'll use "a.getClass() == B.class" as the guard. Now, if > you have a bunch of subclasses B1?B12 all extending A, you'll end up with > 12 linkages to the same method, but all guarded with a different "a.getClass() > == B*n*.class" guard. Actually, as I said above, you'll end up with a > call site incorporating the 8 most recently used ones, and force relinking > when the 9th comes along. > > You could ask "what'd be the harm in linking to "A.foo(Object)" method > just once with "a instanceof A" guard? The harm becomes apparent if we > now define > > public class B extends A { > public void foo(String s) { ... } > } > > With instanceof linkage, invocation at the call site with an instance of C > would pass the guard, and invoke A.foo(Object), which is incorrect as > it'd be expected to invoke C.foo(String) instead. As you can see, this is > not a matter of a subclass *overriding* foo(Object), but rather it's a > matter of the subclass *overloading* the "foo" name with a new signature. > > The only strategy we have for avoiding this is at the moment is almost > always linking with exact receiver class guards :-( > > On a sidenote, I said "almost always" above as there's a special class of > methods we can, in fact, link with "instanceof" guards on the most generic > declaring superclass: methods taking zero arguments (e.g. all property > getters). Since overload choice is actually per-arity, zero-argument > methods can't effectively be overloaded, so for them we actually use > "instanceof" guards. But, sadly, we can't use them for any other methods. > > One strategy to cope with the issue would be to check during linking if > none of the currently known subclasses add new overloads to the method (or > even, not overload it in a manner where a different method would be chosen > for the static type at the call site), and if they don't, then link with a > switch point representing this invariant. Then, whenever a subclass is > loaded into the VM that invalidates the assumption, invalidate the switch > points. Unfortunately, this strategy requires whole-VM knowledge of loaded > classes, and we could only do it if we added a java.lang.instrument agent > as a mandatory component in Nashorn. > > (Another sidenote: we're trying very hard to keep Nashorn from relying on > any implementation-specific or undocumented platform or VM features; so far > we have always managed to rely solely on public Java APIs also because we'd > like to prove that they're sufficient for a dynamic language implementation > on the JVM.) > > Alternatively, we could also try to prove a weaker assumption that the > chosen method would always be the one invoked at the call site (e.g. the > method type of the call site guarantees that there can't ever be a more > specific method to invoke), but in reality this'd be quite hard and since > Nashorn internally mostly only uses boolean, int, long, double, and Object > as the call site signatures, it probably also wouldn't be effective (e.g. > we could nearly never prove this invariant). So that's probably not worth > it. > > As a yet another solution, we might give you a system property or other > configuration means of allowing link chains longer than 8 (in your case, if > you have 12 subclasses, then 12 should be enough). > > Sorry for not having a better answer? > Attila. > > On Nov 19, 2014, at 10:40 AM, Benjamin Sieffert < > benjamin.sieffert at metrigo.de> wrote: > > Hello everyone, > > it started with a peculiar obversion about our nashorn-utilising > application, that I made: It continues to load around a hundred new > anonymous classes *per second*, even without new scripts being introduced ? > i.e. we are just running the same javascripts over and over again, with > different arguments. > So I ran the application with -tcs=miss and from what I see, eventually > there will be only a single call left that is producing all the output and > therefor, I believe, all the memory load. (Am I correct in this > assumption?) > > What I can say about the call is the following: > > - return type is an array of differing length (but always of the same type) > - there are two arguments, of which the first one will always exactly match > the declaration, the second one is a subclass of the one used in the > declaration ? but always the same subclass > - method is implemented in an abstract class > - receiver is one of about a dozen classes that inherit from this abstract > class > - none of the receivers overwrite the original implementation or overload > the method > > When I look into the trace output, there's often a bunch of > "TAG MISS library:212 dyn:getMethod|getProp|getElem: ?" > in a row, then a whole lot of > "TAG MISS library:212 > dyn:call([jdk.internal.dynalink.beans.SimpleDynamicMethod ?" > with a bit of the first one inbetween. > > Is this a known issue? Is there something I can do to alleviate the > problem? As it is, I might just end up implementing the whole chunk in Java > and be done with it, but I thought this might be worthy of some discussion. > If there's some important information that I have left out, I'll be glad to > follow up with it. > > Regards, > Benjamin > > -- > Benjamin Sieffert > metrigo GmbH > Sternstr. 106 > 20357 Hamburg > > Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, > Martin Rie? > Die Gesellschaft ist eingetragen beim Registergericht Hamburg > Nr. HRB 120447. > > > -- Benjamin Sieffert metrigo GmbH Sternstr. 106 20357 Hamburg Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, Martin Rie? Die Gesellschaft ist eingetragen beim Registergericht Hamburg Nr. HRB 120447. From attila.szegedi at oracle.com Thu Nov 20 10:23:00 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 20 Nov 2014 11:23:00 +0100 Subject: A certain (type of?) callsite seems to always require relinking In-Reply-To: References: Message-ID: On Nov 20, 2014, at 9:47 AM, Benjamin Sieffert wrote: > Hi, > > well, thanks for the interesting insight into nashorn's inner workings. I was quickly able to verify that this was indeed what was causing the phenomenon. With exactly 8 different receiver-classes, the loaded class count now remains stable. > > The one thing I'm left wondering, though, is: Accepting the performance impact for now, isn't there a better resource to channel it through? > What I mean is, in this stable application state, there are about 22.000 classes loaded. With more than 8 receiver classes, the count will go up to 700.000, where a full GC kicks in and collects all but (those) 22k classes, because all the others are obviously discarded linkages of the problematic callsite. Now this is with a CodeCache of 800M, where we only need about 100M. One can easily imagine how with more tightly tuned settings (say, a 120M cap on the CodeCache, or some low cap on the Metaspace), the frequency of full GCs would become quite scary. Even more so when we introduce a second problematic callsite. Hm? it's strange that you see so many classes generated, though. Relinking a call site will generate new LambdaForms, and initially they start out being interpreted (they have their own little interpreter), not compiled to bytecode. Given how the relinking seems to be constantly ongoing, I would've hoped that these regenerated LambdaForms would not ever cross the compilation threshold. Apparently, you're in a bad territory where you relink often (so LambdaForms behind MethodHandles can't stabilize), but the linkages are still around for long enough to cross a compilation threshold. FWIW, there's the system property "java.lang.invoke.MethodHandle.COMPILE_THRESHOLD" that you can tweak (defaults to 30 invocations of the LambdaForm) to experimentally find a threshold that'll prevent these LFs from compiling before they're thrown away during a relink. > And in profiling the application then, I think this would be very hard to make out for a "na?ve user" that this is, in a way, "normal behaviour". Well, I wouldn't say it's normal. I'd need some class hierarchy analysis APIs that the standard Java library currently doesn't provide in order to be able to write linker logic that's smarter than this. > I also seem to remember, from an earlier discussion, that there are megamorphic callsites in nashorn. Would this not qualify as one? Nashorn has separate linker classes for linking different kinds of objects. The linker for JS objects indeed has a strategy for changing linkage on frequently relinked sites. The POJO linker does not (it'll just ignore the flag - TBH, the POJO linker code predates the existence of "hey, this call site is relinked too often" flag and just never got reworked). Someone (probably me) should find some time to write a megamorphic linking strategy for POJO methods, in the vein of what R?mi sent us (I actually have something similar already for dispatching between overloaded methods at invocation time, when we can't choose just one at link time - basically a method selector folded into an invoker.) Attila. > > - Benjamin > > On 19 November 2014 15:41, Attila Szegedi wrote: > Hi Benjamin, > > I've been thinking about this, and I believe I know what the issue might be. Unfortunately, I don't currently have a good solution for it (although I'll be thinking some more about it). > > Basically, call sites are linked with method handles that are guarded with a test for exact receiver type (basically obj.getClass() == X.class). Call sites further can have up to 8 methods linked into them (in a LRU fashion) in a waterfall cascade of guard-with-tests. If your call site sees more than 8 receiver types (this number is fixed right now), it'll keep relinking as it'll only remember the most recent 8. > > Even if you don't override the method in subclasses, we can't use a more generic guard because we can't prove that there won't ever be a new subclass that won't overload the method. Note I said overload, not override: that's not a mistake. Here's a scenario: > > public class A { > public void foo(Object o) { ... } > } > > public class B extends A { > } > > Now imagine a script call site "a.foo('Hello')". When it's hit with an instance of B, we'll use "a.getClass() == B.class" as the guard. Now, if you have a bunch of subclasses B1?B12 all extending A, you'll end up with 12 linkages to the same method, but all guarded with a different "a.getClass() == Bn.class" guard. Actually, as I said above, you'll end up with a call site incorporating the 8 most recently used ones, and force relinking when the 9th comes along. > > You could ask "what'd be the harm in linking to "A.foo(Object)" method just once with "a instanceof A" guard? The harm becomes apparent if we now define > > public class B extends A { > public void foo(String s) { ... } > } > > With instanceof linkage, invocation at the call site with an instance of C would pass the guard, and invoke A.foo(Object), which is incorrect as it'd be expected to invoke C.foo(String) instead. As you can see, this is not a matter of a subclass overriding foo(Object), but rather it's a matter of the subclass overloading the "foo" name with a new signature. > > The only strategy we have for avoiding this is at the moment is almost always linking with exact receiver class guards :-( > > On a sidenote, I said "almost always" above as there's a special class of methods we can, in fact, link with "instanceof" guards on the most generic declaring superclass: methods taking zero arguments (e.g. all property getters). Since overload choice is actually per-arity, zero-argument methods can't effectively be overloaded, so for them we actually use "instanceof" guards. But, sadly, we can't use them for any other methods. > > One strategy to cope with the issue would be to check during linking if none of the currently known subclasses add new overloads to the method (or even, not overload it in a manner where a different method would be chosen for the static type at the call site), and if they don't, then link with a switch point representing this invariant. Then, whenever a subclass is loaded into the VM that invalidates the assumption, invalidate the switch points. Unfortunately, this strategy requires whole-VM knowledge of loaded classes, and we could only do it if we added a java.lang.instrument agent as a mandatory component in Nashorn. > > (Another sidenote: we're trying very hard to keep Nashorn from relying on any implementation-specific or undocumented platform or VM features; so far we have always managed to rely solely on public Java APIs also because we'd like to prove that they're sufficient for a dynamic language implementation on the JVM.) > > Alternatively, we could also try to prove a weaker assumption that the chosen method would always be the one invoked at the call site (e.g. the method type of the call site guarantees that there can't ever be a more specific method to invoke), but in reality this'd be quite hard and since Nashorn internally mostly only uses boolean, int, long, double, and Object as the call site signatures, it probably also wouldn't be effective (e.g. we could nearly never prove this invariant). So that's probably not worth it. > > As a yet another solution, we might give you a system property or other configuration means of allowing link chains longer than 8 (in your case, if you have 12 subclasses, then 12 should be enough). > > Sorry for not having a better answer? > Attila. > > On Nov 19, 2014, at 10:40 AM, Benjamin Sieffert wrote: > >> Hello everyone, >> >> it started with a peculiar obversion about our nashorn-utilising >> application, that I made: It continues to load around a hundred new >> anonymous classes *per second*, even without new scripts being introduced ? >> i.e. we are just running the same javascripts over and over again, with >> different arguments. >> So I ran the application with -tcs=miss and from what I see, eventually >> there will be only a single call left that is producing all the output and >> therefor, I believe, all the memory load. (Am I correct in this assumption?) >> >> What I can say about the call is the following: >> >> - return type is an array of differing length (but always of the same type) >> - there are two arguments, of which the first one will always exactly match >> the declaration, the second one is a subclass of the one used in the >> declaration ? but always the same subclass >> - method is implemented in an abstract class >> - receiver is one of about a dozen classes that inherit from this abstract >> class >> - none of the receivers overwrite the original implementation or overload >> the method >> >> When I look into the trace output, there's often a bunch of >> "TAG MISS library:212 dyn:getMethod|getProp|getElem: ?" >> in a row, then a whole lot of >> "TAG MISS library:212 >> dyn:call([jdk.internal.dynalink.beans.SimpleDynamicMethod ?" >> with a bit of the first one inbetween. >> >> Is this a known issue? Is there something I can do to alleviate the >> problem? As it is, I might just end up implementing the whole chunk in Java >> and be done with it, but I thought this might be worthy of some discussion. >> If there's some important information that I have left out, I'll be glad to >> follow up with it. >> >> Regards, >> Benjamin >> >> -- >> Benjamin Sieffert >> metrigo GmbH >> Sternstr. 106 >> 20357 Hamburg >> >> Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, >> Martin Rie? >> Die Gesellschaft ist eingetragen beim Registergericht Hamburg >> Nr. HRB 120447. > > > > > -- > Benjamin Sieffert > metrigo GmbH > Sternstr. 106 > 20357 Hamburg > > Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, Martin Rie? > Die Gesellschaft ist eingetragen beim Registergericht Hamburg > Nr. HRB 120447. From hannes.wallnoefer at oracle.com Fri Nov 21 12:45:52 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 21 Nov 2014 13:45:52 +0100 Subject: Review request for JDK-8057691: Nashorn: let & const declarations are not shared between scripts Message-ID: <546F3400.9010101@oracle.com> Please review JDK-8057691: Nashorn: let & const declarations are not shared between scripts: http://cr.openjdk.java.net/~hannesw/8057691/ This implements global top-lexical scope as per the latest ES6 spec. When running with --language=es6 this will add a switchpoint to non-constant global scope properties that will be invalidated when a script adds global lexical bindings. I've tested with Octane and there are no performance regressions when running with --language=es6 compared to default settings. Hannes From marcus.lagergren at oracle.com Fri Nov 21 13:49:48 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 21 Nov 2014 14:49:48 +0100 Subject: Review request for JDK-8057691: Nashorn: let & const declarations are not shared between scripts In-Reply-To: <546F3400.9010101@oracle.com> References: <546F3400.9010101@oracle.com> Message-ID: <9A0697F7-AAC3-4D88-89CD-A3B03EC00EBF@oracle.com> +1 > On 21 Nov 2014, at 13:45, Hannes Wallnoefer wrote: > > Please review JDK-8057691: Nashorn: let & const declarations are not shared between scripts: > > http://cr.openjdk.java.net/~hannesw/8057691/ > > This implements global top-lexical scope as per the latest ES6 spec. When running with --language=es6 this will add a switchpoint to non-constant global scope properties that will be invalidated when a script adds global lexical bindings. I've tested with Octane and there are no performance regressions when running with --language=es6 compared to default settings. > > Hannes From attila.szegedi at oracle.com Fri Nov 21 16:25:44 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 21 Nov 2014 17:25:44 +0100 Subject: Review request for JDK-8057691: Nashorn: let & const declarations are not shared between scripts In-Reply-To: <546F3400.9010101@oracle.com> References: <546F3400.9010101@oracle.com> Message-ID: <709A836D-0B59-423E-8058-09A7803880F5@oracle.com> +1 On Nov 21, 2014, at 1:45 PM, Hannes Wallnoefer wrote: > Please review JDK-8057691: Nashorn: let & const declarations are not shared between scripts: > > http://cr.openjdk.java.net/~hannesw/8057691/ > > This implements global top-lexical scope as per the latest ES6 spec. When running with --language=es6 this will add a switchpoint to non-constant global scope properties that will be invalidated when a script adds global lexical bindings. I've tested with Octane and there are no performance regressions when running with --language=es6 compared to default settings. > > Hannes From hannes.wallnoefer at oracle.com Mon Nov 24 10:46:09 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 24 Nov 2014 11:46:09 +0100 Subject: Review request for 8u-dev backport of JDK-8057691 Message-ID: <54730C71.2020901@oracle.com> The changes to Parser.java in JDK-8057691 did not apply cleanly to 8u-dev because of changes in 9. Please review manual backport: JDK9: http://cr.openjdk.java.net/~hannesw/8057691/webrev/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java.udiff.html JDK8u http://cr.openjdk.java.net/~hannesw/8057691/webrev-8u-dev/src/jdk/nashorn/internal/parser/Parser.java.udiff.html The resulting code is identical (no more nested scope for top-level let/const). Thanks, Hannes From attila.szegedi at oracle.com Mon Nov 24 10:47:09 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 24 Nov 2014 11:47:09 +0100 Subject: Review request for 8u-dev backport of JDK-8057691 In-Reply-To: <54730C71.2020901@oracle.com> References: <54730C71.2020901@oracle.com> Message-ID: +1 On Nov 24, 2014, at 11:46 AM, Hannes Wallnoefer wrote: > The changes to Parser.java in JDK-8057691 did not apply cleanly to 8u-dev because of changes in 9. Please review manual backport: > > JDK9: > http://cr.openjdk.java.net/~hannesw/8057691/webrev/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java.udiff.html > JDK8u > http://cr.openjdk.java.net/~hannesw/8057691/webrev-8u-dev/src/jdk/nashorn/internal/parser/Parser.java.udiff.html > > The resulting code is identical (no more nested scope for top-level let/const). > > Thanks, > Hannes From marcus.lagergren at oracle.com Mon Nov 24 10:54:47 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 24 Nov 2014 11:54:47 +0100 Subject: Review request for 8u-dev backport of JDK-8057691 In-Reply-To: <54730C71.2020901@oracle.com> References: <54730C71.2020901@oracle.com> Message-ID: +1 > On 24 Nov 2014, at 11:46, Hannes Wallnoefer wrote: > > The changes to Parser.java in JDK-8057691 did not apply cleanly to 8u-dev because of changes in 9. Please review manual backport: > > JDK9: > http://cr.openjdk.java.net/~hannesw/8057691/webrev/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java.udiff.html > JDK8u > http://cr.openjdk.java.net/~hannesw/8057691/webrev-8u-dev/src/jdk/nashorn/internal/parser/Parser.java.udiff.html > > The resulting code is identical (no more nested scope for top-level let/const). > > Thanks, > Hannes From sergey.lugovoy at oracle.com Mon Nov 24 13:46:14 2014 From: sergey.lugovoy at oracle.com (Sergey Lugovoy) Date: Mon, 24 Nov 2014 16:46:14 +0300 Subject: [8u40] 8062638 ,8054343 - request for approval to backport of nashorn changesets In-Reply-To: <546A07C8.20808@oracle.com> References: <5469F0B0.8060606@oracle.com> <546A07C8.20808@oracle.com> Message-ID: <547336A6.9090507@oracle.com> Hi all, Could you approve these changes, please? JDK-8062638 is blocking testing nashorn on Windows. review links: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-November/003831.html http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-September/003369.html On 17.11.2014 17:35, Se?n Coffey wrote: > I've added the bugIDs to the subject line. I notice the review links > are missing also. Please remember for the next time.[1] > Can you add a 'testbug' or 'noreg-self' label to both bug reports ? > > Approved. > > regards, > Sean. > > [1] http://openjdk.java.net/projects/jdk8u/approval-template.html > > On 17/11/14 12:57, Sergey Lugovoy wrote: >> Hi, >> Please approve backport of the following 2 changesets from jdk9 to >> jdk8u40. >> All changesets appled "as is" >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8062638 >> changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0c9f3369f3d3 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8054343 >> changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/2520d5e7bc5f >> > -- Thanks, Sergey From sean.coffey at oracle.com Mon Nov 24 14:06:15 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 24 Nov 2014 14:06:15 +0000 Subject: [8u40] 8062638 ,8054343 - request for approval to backport of nashorn changesets In-Reply-To: <547336A6.9090507@oracle.com> References: <5469F0B0.8060606@oracle.com> <546A07C8.20808@oracle.com> <547336A6.9090507@oracle.com> Message-ID: <54733B57.7050209@oracle.com> JDK-8062638 was approved in my last mail! thanks for adding the necessary labels. regards, Sean. On 24/11/14 13:46, Sergey Lugovoy wrote: > Hi all, > Could you approve these changes, please? > JDK-8062638 is blocking testing nashorn on Windows. > > > review links: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-November/003831.html > > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-September/003369.html > > > > On 17.11.2014 17:35, Se?n Coffey wrote: >> I've added the bugIDs to the subject line. I notice the review links >> are missing also. Please remember for the next time.[1] >> Can you add a 'testbug' or 'noreg-self' label to both bug reports ? >> >> Approved. >> >> regards, >> Sean. >> >> [1] http://openjdk.java.net/projects/jdk8u/approval-template.html >> >> On 17/11/14 12:57, Sergey Lugovoy wrote: >>> Hi, >>> Please approve backport of the following 2 changesets from jdk9 to >>> jdk8u40. >>> All changesets appled "as is" >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8062638 >>> changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/0c9f3369f3d3 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8054343 >>> changeset: http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/2520d5e7bc5f >>> >> > From hannes.wallnoefer at oracle.com Tue Nov 25 10:30:36 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 25 Nov 2014 11:30:36 +0100 Subject: Nashorn performance regression from JDK8u5 to JDK8u25? In-Reply-To: References: <546A64C8.9040503@oracle.com> Message-ID: <54745A4C.3060106@oracle.com> Hi Bernard, I'm trying to reproduce your problems. In your first mail to the list you wrote you attached a Dust template and JSON data. I think you either forgot to attach it, or it was stripped by the list software. Can you please try to send it again, or put it somewhere we can download it? Thanks, Hannes Am 2014-11-18 um 03:21 schrieb Bernard Liang: > Michel et al, > > I?ve run our local test battery using the link you provided, and while in some cases there is improvement, overall the performance still seems to be closer to u25 levels than u5 levels. For what it?s worth, I did notice that the performance improvements from u25 to u40 were generally better in pooled environments than ones where a single instance of the execution environment was running per thread. This leads itself to a few questions, some of which are reiterated from the original inquiry: > > * Is anyone familiar with (significant) specific changes in the Nashorn libraries from u5 => u25 => u40 that might be related to this regression and could explain the u25 and/or u40 changes in more detail (that might have led to the recommendation to use u40)? > * Do you have any performance suites (internal or other) that test various Nashorn benchmarks across different releases (of JDK8, for instance)? Do the results of those correlate with our findings? > > Regards, > Bernard Liang > > PS. The output of `java -version` most recently tested was as follows: > > java version "1.8.0_40-ea" > > Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b12) > > Java HotSpot(TM) 64-Bit Server VM (build 25.40-b16, mixed mode) > > Previous versions tested: > > java version "1.8.0_25" > > Java(TM) SE Runtime Environment (build 1.8.0_25-b17) > > Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) > > java version "1.8.0_05" > > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > From: Michel Trudeau > > Date: Monday, November 17, 2014 at 1:12 PM > To: Bernard Liang > > Cc: "nashorn-dev at openjdk.java.net" > > Subject: Re: Nashorn performance regression from JDK8u5 to JDK8u25? > > Bernard, > > It'd be great if you could try the latest 8u40 stable build. We are planning to release 8u40 early in the new year. > > https://jdk8.java.net/download.html > > We also have an optional optimizer in 8u40, enable it with the command line argument '-ot'. > > Thanks, > Michel > > > > > > Bernard Liang wrote: > > Hello, > > After running some performance tests on the Cartesian product of ([JDK8u5, JDK8u25] x [simple template, complex templates] x [all-or-nothing, streaming chunks] x [single dust instance per thread, pooled dust instances] x [blank Dust instances, Dust instances with templates preloaded]), we find that JDK8u25 performance is very consistently considerably worse than JDK8u5 (by roughly 10-100%, with the average falling somewhere between there). The relevant code has been executed enough times (on the order of 10,000 times) to reach reasonably warmed-up states. If some of the items on the axes of the Cartesian product don?t make much sense, you can ignore the fuzzy parts of the detailed breakdown for now, with the general understanding that various different environments have been tested and shown to yield the same results. > > Some additional high-level context: > > Dust is basically a templating language used to render JSON data into HTML with compilable ?templates": https://github.com/linkedin/dustjs (we are at the v2.4.2 tag) > > ?simple template? = ~150 bytes each of one (precompiled) template + context JSON (attached) > ?complex templates? = ~350 compiled templates spanning ~245KB in compiled JS + ~75KB of JSON context (proprietary data) > > >From https://blogs.oracle.com/nashorn/entry/latest_news_from_the_nashorn, it sounded like there were some recent updates made to Nashorn performance around the u20 mark, but that seems to have caused a regression rather than an improvement. Is this something that nashorn-dev is aware of? Is there any way we can help diagnose the issue further using publicly safe data? (If you?re looking for a way to reproduce this, the attached basic Dust template + JSON context should be adequate under almost any environment.) > > Regards, > Bernard Liang > From bliang at linkedin.com Tue Nov 25 19:28:35 2014 From: bliang at linkedin.com (Bernard Liang) Date: Tue, 25 Nov 2014 19:28:35 +0000 Subject: Nashorn performance regression from JDK8u5 to JDK8u25? In-Reply-To: <54745A4C.3060106@oracle.com> References: <546A64C8.9040503@oracle.com> <54745A4C.3060106@oracle.com> Message-ID: Hannes, Sure, I?ve reproduced the data you requested below, as they are small enough to fit comfortably in a standard message. However, in addition I would still like to reiterate the questions from my previous reply, regarding across-build Nashorn-related changes and performance benchmarks. Your reply also suggests that you have some familiarity with Dust, but if that is not the case, I can certainly provide some more details. Regards, Bernard Liang ===== begin basic.tl ===== {~n} {~n} {page_title}{~n} {~n} {~n}
    {~n} {#names}
  • {title} {name}
  • {~n} {/names}
{~n} {~n} ===== end basic.tl ===== ===== begin basic.json ===== { "page_title": "Benchmark", "title": "Sir", "names": [{ "name": "Moe" }, { "name": "Larry" }, { "name": "Curly" }] } ===== end basic.json ===== On 11/25/14, 2:30 AM, "Hannes Wallnoefer" wrote: >Hi Bernard, > >I'm trying to reproduce your problems. In your first mail to the list >you wrote you attached a Dust template and JSON data. I think you either >forgot to attach it, or it was stripped by the list software. Can you >please try to send it again, or put it somewhere we can download it? > >Thanks, >Hannes > >Am 2014-11-18 um 03:21 schrieb Bernard Liang: >> Michel et al, >> >> I?ve run our local test battery using the link you provided, and while >>in some cases there is improvement, overall the performance still seems >>to be closer to u25 levels than u5 levels. For what it?s worth, I did >>notice that the performance improvements from u25 to u40 were generally >>better in pooled environments than ones where a single instance of the >>execution environment was running per thread. This leads itself to a few >>questions, some of which are reiterated from the original inquiry: >> >> * Is anyone familiar with (significant) specific changes in the >>Nashorn libraries from u5 => u25 => u40 that might be related to this >>regression and could explain the u25 and/or u40 changes in more detail >>(that might have led to the recommendation to use u40)? >> * Do you have any performance suites (internal or other) that test >>various Nashorn benchmarks across different releases (of JDK8, for >>instance)? Do the results of those correlate with our findings? >> >> Regards, >> Bernard Liang >> >> PS. The output of `java -version` most recently tested was as follows: >> >> java version "1.8.0_40-ea" >> >> Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b12) >> >> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b16, mixed mode) >> >> Previous versions tested: >> >> java version "1.8.0_25" >> >> Java(TM) SE Runtime Environment (build 1.8.0_25-b17) >> >> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) >> >> java version "1.8.0_05" >> >> Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >> >> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >> >> From: Michel Trudeau >>> >> Date: Monday, November 17, 2014 at 1:12 PM >> To: Bernard Liang > >> Cc: "nashorn-dev at openjdk.java.net" >>> >> Subject: Re: Nashorn performance regression from JDK8u5 to JDK8u25? >> >> Bernard, >> >> It'd be great if you could try the latest 8u40 stable build. We are >>planning to release 8u40 early in the new year. >> >> https://jdk8.java.net/download.html >> >> We also have an optional optimizer in 8u40, enable it with the command >>line argument '-ot'. >> >> Thanks, >> Michel >> >> >> >> >> >> Bernard Liang wrote: >> >> Hello, >> >> After running some performance tests on the Cartesian product of >>([JDK8u5, JDK8u25] x [simple template, complex templates] x >>[all-or-nothing, streaming chunks] x [single dust instance per thread, >>pooled dust instances] x [blank Dust instances, Dust instances with >>templates preloaded]), we find that JDK8u25 performance is very >>consistently considerably worse than JDK8u5 (by roughly 10-100%, with >>the average falling somewhere between there). The relevant code has been >>executed enough times (on the order of 10,000 times) to reach reasonably >>warmed-up states. If some of the items on the axes of the Cartesian >>product don?t make much sense, you can ignore the fuzzy parts of the >>detailed breakdown for now, with the general understanding that various >>different environments have been tested and shown to yield the same >>results. >> >> Some additional high-level context: >> >> Dust is basically a templating language used to render JSON data into >>HTML with compilable ?templates": https://github.com/linkedin/dustjs (we >>are at the v2.4.2 tag) >> >> ?simple template? = ~150 bytes each of one (precompiled) template + >>context JSON (attached) >> ?complex templates? = ~350 compiled templates spanning ~245KB in >>compiled JS + ~75KB of JSON context (proprietary data) >> >> >From >>https://blogs.oracle.com/nashorn/entry/latest_news_from_the_nashorn, it >>sounded like there were some recent updates made to Nashorn performance >>around the u20 mark, but that seems to have caused a regression rather >>than an improvement. Is this something that nashorn-dev is aware of? Is >>there any way we can help diagnose the issue further using publicly safe >>data? (If you?re looking for a way to reproduce this, the attached basic >>Dust template + JSON context should be adequate under almost any >>environment.) >> >> Regards, >> Bernard Liang >> > From marcus.lagergren at oracle.com Wed Nov 26 08:51:43 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 26 Nov 2014 09:51:43 +0100 Subject: Nashorn performance regression from JDK8u5 to JDK8u25? In-Reply-To: References: <546A64C8.9040503@oracle.com> Message-ID: <7555D0F2-74E1-4E8A-9653-19E279A43B66@oracle.com> Are you running with optimistic types enabled? (?optimistic-types=true) and the compiler team is still working on various performance regressions that appeared when Lambda Form caching came in to HotSpot (b30->b31 for 9), backported to 8. Regards Marcus > On 18 Nov 2014, at 03:21, Bernard Liang wrote: > > Michel et al, > > I?ve run our local test battery using the link you provided, and while in some cases there is improvement, overall the performance still seems to be closer to u25 levels than u5 levels. For what it?s worth, I did notice that the performance improvements from u25 to u40 were generally better in pooled environments than ones where a single instance of the execution environment was running per thread. This leads itself to a few questions, some of which are reiterated from the original inquiry: > > * Is anyone familiar with (significant) specific changes in the Nashorn libraries from u5 => u25 => u40 that might be related to this regression and could explain the u25 and/or u40 changes in more detail (that might have led to the recommendation to use u40)? > * Do you have any performance suites (internal or other) that test various Nashorn benchmarks across different releases (of JDK8, for instance)? Do the results of those correlate with our findings? > > Regards, > Bernard Liang > > PS. The output of `java -version` most recently tested was as follows: > > java version "1.8.0_40-ea" > > Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b12) > > Java HotSpot(TM) 64-Bit Server VM (build 25.40-b16, mixed mode) > > Previous versions tested: > > java version "1.8.0_25" > > Java(TM) SE Runtime Environment (build 1.8.0_25-b17) > > Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) > > java version "1.8.0_05" > > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > From: Michel Trudeau > > Date: Monday, November 17, 2014 at 1:12 PM > To: Bernard Liang > > Cc: "nashorn-dev at openjdk.java.net" > > Subject: Re: Nashorn performance regression from JDK8u5 to JDK8u25? > > Bernard, > > It'd be great if you could try the latest 8u40 stable build. We are planning to release 8u40 early in the new year. > > https://jdk8.java.net/download.html > > We also have an optional optimizer in 8u40, enable it with the command line argument '-ot'. > > Thanks, > Michel > > > > > > Bernard Liang wrote: > > Hello, > > After running some performance tests on the Cartesian product of ([JDK8u5, JDK8u25] x [simple template, complex templates] x [all-or-nothing, streaming chunks] x [single dust instance per thread, pooled dust instances] x [blank Dust instances, Dust instances with templates preloaded]), we find that JDK8u25 performance is very consistently considerably worse than JDK8u5 (by roughly 10-100%, with the average falling somewhere between there). The relevant code has been executed enough times (on the order of 10,000 times) to reach reasonably warmed-up states. If some of the items on the axes of the Cartesian product don?t make much sense, you can ignore the fuzzy parts of the detailed breakdown for now, with the general understanding that various different environments have been tested and shown to yield the same results. > > Some additional high-level context: > > Dust is basically a templating language used to render JSON data into HTML with compilable ?templates": https://github.com/linkedin/dustjs (we are at the v2.4.2 tag) > > ?simple template? = ~150 bytes each of one (precompiled) template + context JSON (attached) > ?complex templates? = ~350 compiled templates spanning ~245KB in compiled JS + ~75KB of JSON context (proprietary data) > >> From https://blogs.oracle.com/nashorn/entry/latest_news_from_the_nashorn, it sounded like there were some recent updates made to Nashorn performance around the u20 mark, but that seems to have caused a regression rather than an improvement. Is this something that nashorn-dev is aware of? Is there any way we can help diagnose the issue further using publicly safe data? (If you?re looking for a way to reproduce this, the attached basic Dust template + JSON context should be adequate under almost any environment.) > > Regards, > Bernard Liang > From vladimir.x.ivanov at oracle.com Wed Nov 26 10:44:51 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 26 Nov 2014 14:44:51 +0400 Subject: [9, 8u40] RFR (XS): 8065985: Inlining failure of Number.doubleValue() in JSType.toNumeric() causes 15% peak perf regresion on Box2D Message-ID: <5475AF23.4030000@oracle.com> http://cr.openjdk.java.net/~vlivanov/8065985/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8065985 Inlining failure of Number.doubleValue() for Double case in JSType.toNumeric() costs ~15% peak performance on some of the Octane benchmarks (e.g. Box2D). Current inlining heuristics in HotSpot aren't stable enough for this particular case. Depending on the execution sequence and gathered profile data, Number.doubleValue() can be devirtualized to Double.doubleValue() or emitted as a pure virtual call. The problem is that Number.doubleValue() is a polymorphic call site. Most of the time it has Double receiver, but sometimes it's Integer and (very) rarely something else. Most of the time, Double case matches major receiver heuristic ( TypeProfileMajorReceiverPercent [=90%]), but if compilation is triggered earlier, profile data could be "incomplete" (Double cases <90% of all cases). Bimorphic inlining doesn't work here, because the call site has >2 receivers. The fix is to introduce a special case for Double and separate it from other cases. After the fix JSType.toNumeric() method size (35) still fits MaxInlineSize[=35] in HotSpot. I want to integrate this fix into 9 & 8u40. LambdaForm sharing-related changes (JEP-210) triggers inlining failures in JSType.toNumeric() much more frequently. Testing: nashorn unit tests, octane. Thanks! Best regards, Vladimir Ivanov From marcus.lagergren at oracle.com Wed Nov 26 13:09:47 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 26 Nov 2014 14:09:47 +0100 Subject: [9, 8u40] RFR (XS): 8065985: Inlining failure of Number.doubleValue() in JSType.toNumeric() causes 15% peak perf regresion on Box2D In-Reply-To: <5475AF23.4030000@oracle.com> References: <5475AF23.4030000@oracle.com> Message-ID: <69A36515-E09E-4183-B86D-A98BFF472D6F@oracle.com> I previously ran this and seem to recall some benchmark regressions, possibly due to the larger byte code size of the very common method JSType.toNumeric. If you can no longer reproduce this (this was a while ago), and your cutoff flag increases may have helped this, you get a +1 from me. Thanks for analyzing this. /M > On 26 Nov 2014, at 11:44, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8065985/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8065985 > > Inlining failure of Number.doubleValue() for Double case in JSType.toNumeric() costs ~15% peak performance on some of the Octane benchmarks (e.g. Box2D). > > Current inlining heuristics in HotSpot aren't stable enough for this particular case. Depending on the execution sequence and gathered profile data, Number.doubleValue() can be devirtualized to Double.doubleValue() or emitted as a pure virtual call. > > The problem is that Number.doubleValue() is a polymorphic call site. Most of the time it has Double receiver, but sometimes it's Integer and (very) rarely something else. > > Most of the time, Double case matches major receiver heuristic ( TypeProfileMajorReceiverPercent [=90%]), but if compilation is triggered earlier, profile data could be "incomplete" (Double cases <90% of all cases). > > Bimorphic inlining doesn't work here, because the call site has >2 receivers. > > The fix is to introduce a special case for Double and separate it from other cases. After the fix JSType.toNumeric() method size (35) still fits MaxInlineSize[=35] in HotSpot. > > I want to integrate this fix into 9 & 8u40. LambdaForm sharing-related changes (JEP-210) triggers inlining failures in JSType.toNumeric() much more frequently. > > Testing: nashorn unit tests, octane. > > Thanks! > > Best regards, > Vladimir Ivanov From hannes.wallnoefer at oracle.com Wed Nov 26 16:43:00 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 26 Nov 2014 17:43:00 +0100 Subject: Nashorn performance regression from JDK8u5 to JDK8u25? In-Reply-To: References: <546A64C8.9040503@oracle.com> <54745A4C.3060106@oracle.com> Message-ID: <54760314.9000101@oracle.com> Thanks Bernard. As to your question about differences between u5, u25 and u40, there are quite a few, and it's hard to guess what caused a regression without looking at the code running. We mostly rely on Octane for performance benchmarking, it's quite possible that this is a bit too narrow and leaves a few blind spots. I have used Dust before and I think I can get it running. I'll let you know when I find out more. Regards, Hannes Am 2014-11-25 um 20:28 schrieb Bernard Liang: > Hannes, > > Sure, I?ve reproduced the data you requested below, as they are small > enough to fit comfortably in a standard message. However, in addition I > would still like to reiterate the questions from my previous reply, > regarding across-build Nashorn-related changes and performance benchmarks. > > Your reply also suggests that you have some familiarity with Dust, but if > that is not the case, I can certainly provide some more details. > > Regards, > Bernard Liang > > ===== begin basic.tl ===== > {~n} > {~n} > {page_title}{~n} > {~n} > {~n} >
    {~n} > {#names} >
  • {title} {name}
  • {~n} > {/names} >
{~n} > {~n} > > > ===== end basic.tl ===== > ===== begin basic.json ===== > { > "page_title": "Benchmark", > "title": "Sir", > "names": [{ > "name": "Moe" > }, > { > "name": "Larry" > }, > { > "name": "Curly" > }] > } > ===== end basic.json ===== > > > On 11/25/14, 2:30 AM, "Hannes Wallnoefer" > wrote: > >> Hi Bernard, >> >> I'm trying to reproduce your problems. In your first mail to the list >> you wrote you attached a Dust template and JSON data. I think you either >> forgot to attach it, or it was stripped by the list software. Can you >> please try to send it again, or put it somewhere we can download it? >> >> Thanks, >> Hannes >> >> Am 2014-11-18 um 03:21 schrieb Bernard Liang: >>> Michel et al, >>> >>> I?ve run our local test battery using the link you provided, and while >>> in some cases there is improvement, overall the performance still seems >>> to be closer to u25 levels than u5 levels. For what it?s worth, I did >>> notice that the performance improvements from u25 to u40 were generally >>> better in pooled environments than ones where a single instance of the >>> execution environment was running per thread. This leads itself to a few >>> questions, some of which are reiterated from the original inquiry: >>> >>> * Is anyone familiar with (significant) specific changes in the >>> Nashorn libraries from u5 => u25 => u40 that might be related to this >>> regression and could explain the u25 and/or u40 changes in more detail >>> (that might have led to the recommendation to use u40)? >>> * Do you have any performance suites (internal or other) that test >>> various Nashorn benchmarks across different releases (of JDK8, for >>> instance)? Do the results of those correlate with our findings? >>> >>> Regards, >>> Bernard Liang >>> >>> PS. The output of `java -version` most recently tested was as follows: >>> >>> java version "1.8.0_40-ea" >>> >>> Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b12) >>> >>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b16, mixed mode) >>> >>> Previous versions tested: >>> >>> java version "1.8.0_25" >>> >>> Java(TM) SE Runtime Environment (build 1.8.0_25-b17) >>> >>> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) >>> >>> java version "1.8.0_05" >>> >>> Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >>> >>> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >>> >>> From: Michel Trudeau >>> > >>> Date: Monday, November 17, 2014 at 1:12 PM >>> To: Bernard Liang > >>> Cc: "nashorn-dev at openjdk.java.net" >>> > >>> Subject: Re: Nashorn performance regression from JDK8u5 to JDK8u25? >>> >>> Bernard, >>> >>> It'd be great if you could try the latest 8u40 stable build. We are >>> planning to release 8u40 early in the new year. >>> >>> https://jdk8.java.net/download.html >>> >>> We also have an optional optimizer in 8u40, enable it with the command >>> line argument '-ot'. >>> >>> Thanks, >>> Michel >>> >>> >>> >>> >>> >>> Bernard Liang wrote: >>> >>> Hello, >>> >>> After running some performance tests on the Cartesian product of >>> ([JDK8u5, JDK8u25] x [simple template, complex templates] x >>> [all-or-nothing, streaming chunks] x [single dust instance per thread, >>> pooled dust instances] x [blank Dust instances, Dust instances with >>> templates preloaded]), we find that JDK8u25 performance is very >>> consistently considerably worse than JDK8u5 (by roughly 10-100%, with >>> the average falling somewhere between there). The relevant code has been >>> executed enough times (on the order of 10,000 times) to reach reasonably >>> warmed-up states. If some of the items on the axes of the Cartesian >>> product don?t make much sense, you can ignore the fuzzy parts of the >>> detailed breakdown for now, with the general understanding that various >>> different environments have been tested and shown to yield the same >>> results. >>> >>> Some additional high-level context: >>> >>> Dust is basically a templating language used to render JSON data into >>> HTML with compilable ?templates": https://github.com/linkedin/dustjs (we >>> are at the v2.4.2 tag) >>> >>> ?simple template? = ~150 bytes each of one (precompiled) template + >>> context JSON (attached) >>> ?complex templates? = ~350 compiled templates spanning ~245KB in >>> compiled JS + ~75KB of JSON context (proprietary data) >>> >>> >From >>> https://blogs.oracle.com/nashorn/entry/latest_news_from_the_nashorn, it >>> sounded like there were some recent updates made to Nashorn performance >>> around the u20 mark, but that seems to have caused a regression rather >>> than an improvement. Is this something that nashorn-dev is aware of? Is >>> there any way we can help diagnose the issue further using publicly safe >>> data? (If you?re looking for a way to reproduce this, the attached basic >>> Dust template + JSON context should be adequate under almost any >>> environment.) >>> >>> Regards, >>> Bernard Liang >>> From vladimir.x.ivanov at oracle.com Wed Nov 26 16:19:50 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 26 Nov 2014 20:19:50 +0400 Subject: [9, 8u40] RFR (XS): 8065985: Inlining failure of Number.doubleValue() in JSType.toNumeric() causes 15% peak perf regresion on Box2D In-Reply-To: <69A36515-E09E-4183-B86D-A98BFF472D6F@oracle.com> References: <5475AF23.4030000@oracle.com> <69A36515-E09E-4183-B86D-A98BFF472D6F@oracle.com> Message-ID: <5475FDA6.90506@oracle.com> Thanks, Marcus. I ran Octane with increased compilation limits (MaxNodeLimit/LiveNodeCountInliningCutoff) and I didn't see any regressions due to this change. Best regards, Vladimir Ivanov On 11/26/14, 5:09 PM, Marcus Lagergren wrote: > I previously ran this and seem to recall some benchmark regressions, possibly due to the larger byte code size of the very common method JSType.toNumeric. If you can no longer reproduce this (this was a while ago), and your cutoff flag increases may have helped this, you get a +1 from me. > > Thanks for analyzing this. > > /M > > >> On 26 Nov 2014, at 11:44, Vladimir Ivanov wrote: >> >> http://cr.openjdk.java.net/~vlivanov/8065985/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8065985 >> >> Inlining failure of Number.doubleValue() for Double case in JSType.toNumeric() costs ~15% peak performance on some of the Octane benchmarks (e.g. Box2D). >> >> Current inlining heuristics in HotSpot aren't stable enough for this particular case. Depending on the execution sequence and gathered profile data, Number.doubleValue() can be devirtualized to Double.doubleValue() or emitted as a pure virtual call. >> >> The problem is that Number.doubleValue() is a polymorphic call site. Most of the time it has Double receiver, but sometimes it's Integer and (very) rarely something else. >> >> Most of the time, Double case matches major receiver heuristic ( TypeProfileMajorReceiverPercent [=90%]), but if compilation is triggered earlier, profile data could be "incomplete" (Double cases <90% of all cases). >> >> Bimorphic inlining doesn't work here, because the call site has >2 receivers. >> >> The fix is to introduce a special case for Double and separate it from other cases. After the fix JSType.toNumeric() method size (35) still fits MaxInlineSize[=35] in HotSpot. >> >> I want to integrate this fix into 9 & 8u40. LambdaForm sharing-related changes (JEP-210) triggers inlining failures in JSType.toNumeric() much more frequently. >> >> Testing: nashorn unit tests, octane. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From attila.szegedi at oracle.com Wed Nov 26 17:31:37 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 26 Nov 2014 18:31:37 +0100 Subject: Review request for JDK-8051778 Message-ID: <1FC68DBC-1D5C-4584-AFB5-49938B251392@oracle.com> Please review JDK-8051778 at for Thanks, Attila. From marcus.lagergren at oracle.com Wed Nov 26 19:20:41 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 26 Nov 2014 20:20:41 +0100 Subject: Review request for JDK-8051778 In-Reply-To: <1FC68DBC-1D5C-4584-AFB5-49938B251392@oracle.com> References: <1FC68DBC-1D5C-4584-AFB5-49938B251392@oracle.com> Message-ID: <8AB28AEE-8462-4604-9BE8-037B2FC8D159@oracle.com> +1. Finally got my head around how it worked. Nicely done - comparably little code for this generalization of functionality. This proves (again) that the Dynalink architecture is very flexible. /M > On 26 Nov 2014, at 18:31, Attila Szegedi wrote: > > Please review JDK-8051778 at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Wed Nov 26 19:37:27 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 26 Nov 2014 20:37:27 +0100 Subject: [9, 8u40] RFR (XS): 8065985: Inlining failure of Number.doubleValue() in JSType.toNumeric() causes 15% peak perf regresion on Box2D In-Reply-To: <5475AF23.4030000@oracle.com> References: <5475AF23.4030000@oracle.com> Message-ID: <54762BF7.4040708@oracle.com> +1 Thanks for looking into this! Hannes Am 2014-11-26 um 11:44 schrieb Vladimir Ivanov: > http://cr.openjdk.java.net/~vlivanov/8065985/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8065985 > > Inlining failure of Number.doubleValue() for Double case in > JSType.toNumeric() costs ~15% peak performance on some of the Octane > benchmarks (e.g. Box2D). > > Current inlining heuristics in HotSpot aren't stable enough for this > particular case. Depending on the execution sequence and gathered > profile data, Number.doubleValue() can be devirtualized to > Double.doubleValue() or emitted as a pure virtual call. > > The problem is that Number.doubleValue() is a polymorphic call site. > Most of the time it has Double receiver, but sometimes it's Integer > and (very) rarely something else. > > Most of the time, Double case matches major receiver heuristic ( > TypeProfileMajorReceiverPercent [=90%]), but if compilation is > triggered earlier, profile data could be "incomplete" (Double cases > <90% of all cases). > > Bimorphic inlining doesn't work here, because the call site has >2 > receivers. > > The fix is to introduce a special case for Double and separate it from > other cases. After the fix JSType.toNumeric() method size (35) still > fits MaxInlineSize[=35] in HotSpot. > > I want to integrate this fix into 9 & 8u40. LambdaForm sharing-related > changes (JEP-210) triggers inlining failures in JSType.toNumeric() > much more frequently. > > Testing: nashorn unit tests, octane. > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed Nov 26 19:35:08 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 26 Nov 2014 23:35:08 +0400 Subject: [9, 8u40] RFR (XS): 8065985: Inlining failure of Number.doubleValue() in JSType.toNumeric() causes 15% peak perf regresion on Box2D In-Reply-To: <54762BF7.4040708@oracle.com> References: <5475AF23.4030000@oracle.com> <54762BF7.4040708@oracle.com> Message-ID: <54762B6C.8030306@oracle.com> Hannes, Marcus, thanks for the reviews. Best regards, Vladimir Ivanov On 11/26/14, 11:37 PM, Hannes Wallnoefer wrote: > +1 > > Thanks for looking into this! > > Hannes > > Am 2014-11-26 um 11:44 schrieb Vladimir Ivanov: >> http://cr.openjdk.java.net/~vlivanov/8065985/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8065985 >> >> Inlining failure of Number.doubleValue() for Double case in >> JSType.toNumeric() costs ~15% peak performance on some of the Octane >> benchmarks (e.g. Box2D). >> >> Current inlining heuristics in HotSpot aren't stable enough for this >> particular case. Depending on the execution sequence and gathered >> profile data, Number.doubleValue() can be devirtualized to >> Double.doubleValue() or emitted as a pure virtual call. >> >> The problem is that Number.doubleValue() is a polymorphic call site. >> Most of the time it has Double receiver, but sometimes it's Integer >> and (very) rarely something else. >> >> Most of the time, Double case matches major receiver heuristic ( >> TypeProfileMajorReceiverPercent [=90%]), but if compilation is >> triggered earlier, profile data could be "incomplete" (Double cases >> <90% of all cases). >> >> Bimorphic inlining doesn't work here, because the call site has >2 >> receivers. >> >> The fix is to introduce a special case for Double and separate it from >> other cases. After the fix JSType.toNumeric() method size (35) still >> fits MaxInlineSize[=35] in HotSpot. >> >> I want to integrate this fix into 9 & 8u40. LambdaForm sharing-related >> changes (JEP-210) triggers inlining failures in JSType.toNumeric() >> much more frequently. >> >> Testing: nashorn unit tests, octane. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From timvolpe at gmail.com Wed Nov 26 21:45:26 2014 From: timvolpe at gmail.com (Tim Fox) Date: Wed, 26 Nov 2014 21:45:26 +0000 Subject: Forcing elements of List to be converted as java.lang.Long Message-ID: <547649F6.3060905@gmail.com> Hello folks, I have a Java method: public void foo(List list) { System.out.println("elem0 is " + list.get(0)); } Which I call from JS with a JS array: obj.foo([123]); This results in a ClassCastException as Nashorn converts the JS Array into a java.util.List instance which contains a java.lang.Integer element (not java.lang.Long) Is there any way to force Nashorn to convert the array elements as Longs not Integers? Thanks. From attila.szegedi at oracle.com Wed Nov 26 21:50:39 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 26 Nov 2014 22:50:39 +0100 Subject: Forcing elements of List to be converted as java.lang.Long In-Reply-To: <547649F6.3060905@gmail.com> References: <547649F6.3060905@gmail.com> Message-ID: <56DEF7CA-8D1B-409D-867E-532D27856302@oracle.com> I don't think so. As the types are erased at run time all we see is a method with signature foo(List list). I think if you tried to add two methods to a class: public void foo(List x) { } public void foo(List x) { } then javac would refuse to compile it saying that both have the same erasure. Attila. On Nov 26, 2014, at 10:45 PM, Tim Fox wrote: > Hello folks, > > I have a Java method: > > public void foo(List list) { > System.out.println("elem0 is " + list.get(0)); > } > > Which I call from JS with a JS array: > > obj.foo([123]); > > This results in a ClassCastException as Nashorn converts the JS Array into a java.util.List instance which contains a java.lang.Integer element (not java.lang.Long) > > Is there any way to force Nashorn to convert the array elements as Longs not Integers? > > Thanks. From timvolpe at gmail.com Wed Nov 26 23:37:11 2014 From: timvolpe at gmail.com (Tim Fox) Date: Wed, 26 Nov 2014 23:37:11 +0000 Subject: Forcing elements of List to be converted as java.lang.Long In-Reply-To: <56DEF7CA-8D1B-409D-867E-532D27856302@oracle.com> References: <547649F6.3060905@gmail.com> <56DEF7CA-8D1B-409D-867E-532D27856302@oracle.com> Message-ID: <54766427.7000208@gmail.com> Hi Attila, I understand the generic type info is erased, but my question was whether there is any way I can "force" Nashorn to convert the elements as Long rather than Integer when doing the conversion, e.g. using some special Nashorn specific syntax, e.g. var arr = [123]; arr.forceConversionAsLong = true; // A contrived example but you get the point :) obj.foo(arr); (or whatever) On 26/11/14 21:50, Attila Szegedi wrote: > I don't think so. As the types are erased at run time all we see is a method with signature foo(List list). I think if you tried to add two methods to a class: > > public void foo(List x) { } > public void foo(List x) { } > > then javac would refuse to compile it saying that both have the same erasure. > > Attila. > > On Nov 26, 2014, at 10:45 PM, Tim Fox wrote: > >> Hello folks, >> >> I have a Java method: >> >> public void foo(List list) { >> System.out.println("elem0 is " + list.get(0)); >> } >> >> Which I call from JS with a JS array: >> >> obj.foo([123]); >> >> This results in a ClassCastException as Nashorn converts the JS Array into a java.util.List instance which contains a java.lang.Integer element (not java.lang.Long) >> >> Is there any way to force Nashorn to convert the array elements as Longs not Integers? >> >> Thanks. From forax at univ-mlv.fr Wed Nov 26 23:59:19 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 27 Nov 2014 00:59:19 +0100 Subject: Forcing elements of List to be converted as java.lang.Long In-Reply-To: <54766427.7000208@gmail.com> References: <547649F6.3060905@gmail.com> <56DEF7CA-8D1B-409D-867E-532D27856302@oracle.com> <54766427.7000208@gmail.com> Message-ID: <54766957.7010201@univ-mlv.fr> On 11/27/2014 12:37 AM, Tim Fox wrote: > Hi Attila, > > I understand the generic type info is erased, but my question was > whether there is any way I can "force" Nashorn to convert the elements > as Long rather than Integer when doing the conversion, e.g. using some > special Nashorn specific syntax, e.g. > > var arr = [123]; > arr.forceConversionAsLong = true; // A contrived example but you get > the point :) > obj.foo(arr); > > (or whatever) BTW, generic info like this one are preserved because javac need them to cross compile. so nashorn could inspect the generic signature and if there is one try to do the suitable conversion. R?mi > > > On 26/11/14 21:50, Attila Szegedi wrote: >> I don't think so. As the types are erased at run time all we see is a >> method with signature foo(List list). I think if you tried to add two >> methods to a class: >> >> public void foo(List x) { } >> public void foo(List x) { } >> >> then javac would refuse to compile it saying that both have the same >> erasure. >> >> Attila. >> >> On Nov 26, 2014, at 10:45 PM, Tim Fox wrote: >> >>> Hello folks, >>> >>> I have a Java method: >>> >>> public void foo(List list) { >>> System.out.println("elem0 is " + list.get(0)); >>> } >>> >>> Which I call from JS with a JS array: >>> >>> obj.foo([123]); >>> >>> This results in a ClassCastException as Nashorn converts the JS >>> Array into a java.util.List instance which contains a >>> java.lang.Integer element (not java.lang.Long) >>> >>> Is there any way to force Nashorn to convert the array elements as >>> Longs not Integers? >>> >>> Thanks. > From timvolpe at gmail.com Thu Nov 27 09:41:52 2014 From: timvolpe at gmail.com (Tim Fox) Date: Thu, 27 Nov 2014 09:41:52 +0000 Subject: Passing Java lists into JS Message-ID: <5476F1E0.7010906@gmail.com> Hello again, I am a bit confused about how Lists passed from Java into JS are converted. I have a Java class as follows: public class SomeClass { public List provideList() { List list = new ArrayList<>(); list.add("foo"); list.add("bar"); return list; } } I call this from JavaScript: var io = Packages.io; var someObject = new io.vertx.scratchpad.SomeClass(); var arr = someObject.provideList(); console.log(arr[0]); // prints: foo console.log(typeof arr.length); // undefined console.log(arr instanceof Array); // false I was under the impression that Nashorn automatically converted Java lists passed into JS into JS Arrays. The object arr returned in some ways resembles a JavaScript array - the operators [] and []= work on it, however it doesn't have the array property "length" and it's not an instanceof Array. Can anyone clarify to me what this object is? Any reason why Nashorn doesn't just wrap it as a real JS Array? Cheers From attila.szegedi at oracle.com Thu Nov 27 10:33:14 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 27 Nov 2014 11:33:14 +0100 Subject: Passing Java lists into JS In-Reply-To: <5476F1E0.7010906@gmail.com> References: <5476F1E0.7010906@gmail.com> Message-ID: Nashorn explicitly allows [] operator on java lists and it also supports for?in on them. ".length" is also supported since 8u20, see . We indeed don't implicitly convert Lists into JS Array objects in Nashorn. The reason is that JS Array has a Java array as backing storage; wrapping a large list would incur a lot of copying. You can use "Java.from(someObject.provideList())" to explicitly convert a Java List to a JS array. We think it's better to provide an explicit conversion API than incur a linear conversion cost whenever a List object passes into the JS context. The Java.from created copy is shallow; if you have a List of Lists, the nested List objects are not converted. Typically you'll want to create a real Array if you want to use Array functionality that points beyond [], .length, and for?in, e.g. JS Array comprehension operations (arguably, we *could* implement even those so that Array.prototype.forEach.call(javaList, ...) works as expected, but we aren't there yet.) Attila. On Nov 27, 2014, at 10:41 AM, Tim Fox wrote: > Hello again, > > I am a bit confused about how Lists passed from Java into JS are converted. > > I have a Java class as follows: > > public class SomeClass { > > public List provideList() { > List list = new ArrayList<>(); > list.add("foo"); > list.add("bar"); > return list; > } > } > > I call this from JavaScript: > > var io = Packages.io; > var someObject = new io.vertx.scratchpad.SomeClass(); > > var arr = someObject.provideList(); > > console.log(arr[0]); // prints: foo > console.log(typeof arr.length); // undefined > console.log(arr instanceof Array); // false > > I was under the impression that Nashorn automatically converted Java lists passed into JS into JS Arrays. > > The object arr returned in some ways resembles a JavaScript array - the operators [] and []= work on it, however it doesn't have the array property "length" and it's not an instanceof Array. > > Can anyone clarify to me what this object is? Any reason why Nashorn doesn't just wrap it as a real JS Array? > > Cheers From sundararajan.athijegannathan at oracle.com Thu Nov 27 10:56:00 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 27 Nov 2014 16:26:00 +0530 Subject: Passing Java lists into JS In-Reply-To: <5476F1E0.7010906@gmail.com> References: <5476F1E0.7010906@gmail.com> Message-ID: <54770340.7080400@oracle.com> List return values from Java are not converted to JS Arrays. But usual 'indexing' to get elements and ".length" to get size work (later added in 8u20 or 8u40 - need to check). And usual for..in and for..each..in (extension) work on Lists. Rational is to avoid wrapping Lists as another Script object. -Sundar Tim Fox wrote: > Hello again, > > I am a bit confused about how Lists passed from Java into JS are > converted. > > I have a Java class as follows: > > public class SomeClass { > > public List provideList() { > List list = new ArrayList<>(); > list.add("foo"); > list.add("bar"); > return list; > } > } > > I call this from JavaScript: > > var io = Packages.io; > var someObject = new io.vertx.scratchpad.SomeClass(); > > var arr = someObject.provideList(); > > console.log(arr[0]); // prints: foo > console.log(typeof arr.length); // undefined > console.log(arr instanceof Array); // false > > I was under the impression that Nashorn automatically converted Java > lists passed into JS into JS Arrays. > > The object arr returned in some ways resembles a JavaScript array - > the operators [] and []= work on it, however it doesn't have the array > property "length" and it's not an instanceof Array. > > Can anyone clarify to me what this object is? Any reason why Nashorn > doesn't just wrap it as a real JS Array? > > Cheers From timvolpe at gmail.com Thu Nov 27 11:18:04 2014 From: timvolpe at gmail.com (Tim Fox) Date: Thu, 27 Nov 2014 11:18:04 +0000 Subject: Passing Java lists into JS In-Reply-To: References: <5476F1E0.7010906@gmail.com> Message-ID: <5477086C.1010904@gmail.com> On 27/11/14 10:33, Attila Szegedi wrote: > Nashorn explicitly allows [] operator on java lists and it also supports for?in on them. ".length" is also supported since 8u20, see . > > We indeed don't implicitly convert Lists into JS Array objects in Nashorn. The reason is that JS Array has a Java array as backing storage; wrapping a large list would incur a lot of copying. To avoid the copying, could the Nashorn JS Array implementation be changed so it backs either: a) A Java Array (as it does currently) - this would the case if you created the JS array directly in JS code. b) A Java List - this would be the case if a List was passed from Java to JS, providing the user with a JS array Then we can have our cake and eat it? I.e. we have a real JS Array object (not a half way house with some of the functions and properties but not all), and no copying overhead. > You can use "Java.from(someObject.provideList())" to explicitly convert a Java List to a JS array. We think it's better to provide an explicit conversion API than incur a linear conversion cost whenever a List object passes into the JS context. > The Java.from created copy is shallow; if you have a List of Lists, the nested List objects are not converted. > > Typically you'll want to create a real Array if you want to use Array functionality that points beyond [], .length, and for?in, e.g. JS Array comprehension operations (arguably, we *could* implement even those so that Array.prototype.forEach.call(javaList, ...) works as expected, but we aren't there yet.) > > Attila. > > On Nov 27, 2014, at 10:41 AM, Tim Fox wrote: > >> Hello again, >> >> I am a bit confused about how Lists passed from Java into JS are converted. >> >> I have a Java class as follows: >> >> public class SomeClass { >> >> public List provideList() { >> List list = new ArrayList<>(); >> list.add("foo"); >> list.add("bar"); >> return list; >> } >> } >> >> I call this from JavaScript: >> >> var io = Packages.io; >> var someObject = new io.vertx.scratchpad.SomeClass(); >> >> var arr = someObject.provideList(); >> >> console.log(arr[0]); // prints: foo >> console.log(typeof arr.length); // undefined >> console.log(arr instanceof Array); // false >> >> I was under the impression that Nashorn automatically converted Java lists passed into JS into JS Arrays. >> >> The object arr returned in some ways resembles a JavaScript array - the operators [] and []= work on it, however it doesn't have the array property "length" and it's not an instanceof Array. >> >> Can anyone clarify to me what this object is? Any reason why Nashorn doesn't just wrap it as a real JS Array? >> >> Cheers From attila.szegedi at oracle.com Thu Nov 27 11:24:32 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 27 Nov 2014 12:24:32 +0100 Subject: Forcing elements of List to be converted as java.lang.Long In-Reply-To: <54766427.7000208@gmail.com> References: <547649F6.3060905@gmail.com> <56DEF7CA-8D1B-409D-867E-532D27856302@oracle.com> <54766427.7000208@gmail.com> Message-ID: <3F1B39C9-409D-48FE-8AC6-C023459B43AB@oracle.com> Thinking of it, yes, there is: var asList = java.util.Arrays.asList; var LongType = Java.type("java.lang.Long[]"); then: asList(Java.to(arr, LongType)) Attila. On Nov 27, 2014, at 12:37 AM, Tim Fox wrote: > Hi Attila, > > I understand the generic type info is erased, but my question was whether there is any way I can "force" Nashorn to convert the elements as Long rather than Integer when doing the conversion, e.g. using some special Nashorn specific syntax, e.g. > > var arr = [123]; > arr.forceConversionAsLong = true; // A contrived example but you get the point :) > obj.foo(arr); > > (or whatever) > > > On 26/11/14 21:50, Attila Szegedi wrote: >> I don't think so. As the types are erased at run time all we see is a method with signature foo(List list). I think if you tried to add two methods to a class: >> >> public void foo(List x) { } >> public void foo(List x) { } >> >> then javac would refuse to compile it saying that both have the same erasure. >> >> Attila. >> >> On Nov 26, 2014, at 10:45 PM, Tim Fox wrote: >> >>> Hello folks, >>> >>> I have a Java method: >>> >>> public void foo(List list) { >>> System.out.println("elem0 is " + list.get(0)); >>> } >>> >>> Which I call from JS with a JS array: >>> >>> obj.foo([123]); >>> >>> This results in a ClassCastException as Nashorn converts the JS Array into a java.util.List instance which contains a java.lang.Integer element (not java.lang.Long) >>> >>> Is there any way to force Nashorn to convert the array elements as Longs not Integers? >>> >>> Thanks. > From hannes.wallnoefer at oracle.com Thu Nov 27 11:38:05 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 27 Nov 2014 12:38:05 +0100 Subject: Review request for JDK-8051778 In-Reply-To: <1FC68DBC-1D5C-4584-AFB5-49938B251392@oracle.com> References: <1FC68DBC-1D5C-4584-AFB5-49938B251392@oracle.com> Message-ID: <54770D1D.5080900@oracle.com> +1 That's a very nice enhancement! Am 2014-11-26 um 18:31 schrieb Attila Szegedi: > Please review JDK-8051778 at for > > Thanks, > Attila. From timvolpe at gmail.com Thu Nov 27 11:43:57 2014 From: timvolpe at gmail.com (Tim Fox) Date: Thu, 27 Nov 2014 11:43:57 +0000 Subject: Forcing elements of List to be converted as java.lang.Long In-Reply-To: <3F1B39C9-409D-48FE-8AC6-C023459B43AB@oracle.com> References: <547649F6.3060905@gmail.com> <56DEF7CA-8D1B-409D-867E-532D27856302@oracle.com> <54766427.7000208@gmail.com> <3F1B39C9-409D-48FE-8AC6-C023459B43AB@oracle.com> Message-ID: <54770E7D.9090002@gmail.com> Great, that works. And it's a lot faster than manually converting the elements of the list in JS before sending it to Java :) On 27/11/14 11:24, Attila Szegedi wrote: > Thinking of it, yes, there is: > > var asList = java.util.Arrays.asList; > var LongType = Java.type("java.lang.Long[]"); > > then: > > asList(Java.to(arr, LongType)) > > Attila. > > On Nov 27, 2014, at 12:37 AM, Tim Fox wrote: > >> Hi Attila, >> >> I understand the generic type info is erased, but my question was whether there is any way I can "force" Nashorn to convert the elements as Long rather than Integer when doing the conversion, e.g. using some special Nashorn specific syntax, e.g. >> >> var arr = [123]; >> arr.forceConversionAsLong = true; // A contrived example but you get the point :) >> obj.foo(arr); >> >> (or whatever) >> >> >> On 26/11/14 21:50, Attila Szegedi wrote: >>> I don't think so. As the types are erased at run time all we see is a method with signature foo(List list). I think if you tried to add two methods to a class: >>> >>> public void foo(List x) { } >>> public void foo(List x) { } >>> >>> then javac would refuse to compile it saying that both have the same erasure. >>> >>> Attila. >>> >>> On Nov 26, 2014, at 10:45 PM, Tim Fox wrote: >>> >>>> Hello folks, >>>> >>>> I have a Java method: >>>> >>>> public void foo(List list) { >>>> System.out.println("elem0 is " + list.get(0)); >>>> } >>>> >>>> Which I call from JS with a JS array: >>>> >>>> obj.foo([123]); >>>> >>>> This results in a ClassCastException as Nashorn converts the JS Array into a java.util.List instance which contains a java.lang.Integer element (not java.lang.Long) >>>> >>>> Is there any way to force Nashorn to convert the array elements as Longs not Integers? >>>> >>>> Thanks. From sundararajan.athijegannathan at oracle.com Thu Nov 27 11:48:52 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 27 Nov 2014 17:18:52 +0530 Subject: Passing Java lists into JS In-Reply-To: <5477086C.1010904@gmail.com> References: <5476F1E0.7010906@gmail.com> <5477086C.1010904@gmail.com> Message-ID: <54770FA4.4020607@oracle.com> * On backed storage being non-array. jdk.nashorn.internal.runtime.arrays.ArrayData is "backing store" impl for array storage - apart from Java array based impls there is on based on nio ByteBuffer. Not sure how feasible is to have one based on List. Also, even with one based on List, it would involve wrapping (ArrayData, NativeArray instance). But, right now dynalink's magic + nashorn runtime magic provides most of what JS Array offers on Java Lists - without wrapping as JS arrays. * And btw, Array.prototype.forEach etc. do work on Java lists var a = new java.util.ArrayList(); a.add("hello"); a.add("world"); Array.prototype.forEach.call(a, print); print(Array.prototype.map.call(a, function(e) e.toUpperCase())); -Sundar Tim Fox wrote: > On 27/11/14 10:33, Attila Szegedi wrote: >> Nashorn explicitly allows [] operator on java lists and it also >> supports for?in on them. ".length" is also supported since 8u20, see >> . >> >> We indeed don't implicitly convert Lists into JS Array objects in >> Nashorn. The reason is that JS Array has a Java array as backing >> storage; wrapping a large list would incur a lot of copying. > > To avoid the copying, could the Nashorn JS Array implementation be > changed so it backs either: > > a) A Java Array (as it does currently) - this would the case if you > created the JS array directly in JS code. > b) A Java List - this would be the case if a List was passed from Java > to JS, providing the user with a JS array > > Then we can have our cake and eat it? I.e. we have a real JS Array > object (not a half way house with some of the functions and properties > but not all), and no copying overhead. > >> You can use "Java.from(someObject.provideList())" to explicitly >> convert a Java List to a JS array. We think it's better to provide an >> explicit conversion API than incur a linear conversion cost whenever >> a List object passes into the JS context. >> The Java.from created copy is shallow; if you have a List of Lists, >> the nested List objects are not converted. >> >> Typically you'll want to create a real Array if you want to use Array >> functionality that points beyond [], .length, and for?in, e.g. JS >> Array comprehension operations (arguably, we *could* implement even >> those so that Array.prototype.forEach.call(javaList, ...) works as >> expected, but we aren't there yet.) >> >> Attila. >> >> On Nov 27, 2014, at 10:41 AM, Tim Fox wrote: >> >>> Hello again, >>> >>> I am a bit confused about how Lists passed from Java into JS are >>> converted. >>> >>> I have a Java class as follows: >>> >>> public class SomeClass { >>> >>> public List provideList() { >>> List list = new ArrayList<>(); >>> list.add("foo"); >>> list.add("bar"); >>> return list; >>> } >>> } >>> >>> I call this from JavaScript: >>> >>> var io = Packages.io; >>> var someObject = new io.vertx.scratchpad.SomeClass(); >>> >>> var arr = someObject.provideList(); >>> >>> console.log(arr[0]); // prints: foo >>> console.log(typeof arr.length); // undefined >>> console.log(arr instanceof Array); // false >>> >>> I was under the impression that Nashorn automatically converted Java >>> lists passed into JS into JS Arrays. >>> >>> The object arr returned in some ways resembles a JavaScript array - >>> the operators [] and []= work on it, however it doesn't have the >>> array property "length" and it's not an instanceof Array. >>> >>> Can anyone clarify to me what this object is? Any reason why Nashorn >>> doesn't just wrap it as a real JS Array? >>> >>> Cheers > From attila.szegedi at oracle.com Thu Nov 27 11:57:19 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 27 Nov 2014 12:57:19 +0100 Subject: Passing Java lists into JS In-Reply-To: <5477086C.1010904@gmail.com> References: <5476F1E0.7010906@gmail.com> <5477086C.1010904@gmail.com> Message-ID: <18A6C216-C2DC-4722-A495-42D116768BC9@oracle.com> I'd still refrain from automatically wrapping into an Array anything that implements a List interface because it might be implementing other interfaces too, and it might be passed back to Java and have semantics dependent on referential identity. There's also the issue that currently, we don't do automatic wrapping of anything; Nashorn uses POJOs without wrappers and doesn't try to pretend that POJOs are native JS objects. Speaking of, some people would expect to be able to invoke Java collection API methods on the List object (stream, spliterator, removeIf, etc.) so automatic wrapping would foil that too (except of course if we had special JS Arrays that also expose these operations?) There's also the issue of passing such a List-wrapping-Array back to a Java API: do we unwrap it? Of course, we can have a filter that unwraps the Array back to a List when it goes back, although the current policy is that whenever a native JS object passes an API boundary back to Java, it becomes a ScriptObjectMirror, so we'd then violate that policy for some Arrays (but not for others). So, that's a number of issues :-) Of course, none of these issues are arguments against having an Array backed by a List, only arguments against automatic conversion. Now, speaking about a potential List-backed Array implementation: Nashorn arrays abstract their backing storage into ArrayData objects, so every JS Array normally looks like this: NativeArray->ArrayData->[actual storage]. This additional indirection allows us to switch between dense and sparse representations, and between different types of representations; e.g. if you only have ints in your array, you'll have NativeArray->IntArrayData->int[], with getters and setters linked as fast pass-through array element getters and setters (MethodHandles.arrayElementGetter). Only when you set an element to a double will it evolve into NativeArray->NumberArrayData->double[]. I can imagine having a ListArrayData. It'd have few surprising properties, though. E.g. writes to the array would of course write through to the List, and writes to the List would mostly be reflected in the Array. I say "mostly" because JS arrays aren't necessarily continuos after a delete operation. In Nashorn, we implement deletion by adding a DeletedArrayFilter (a special ArrayData that filters underlying ArrayData) into the chain, so if you did "delete arrayFromList[5]" then your NativeArray->ListArray->List becomes NativeArray->DeletedArrayFilter->ListArray->List, and even if you later set list.set(5, ...) from Java, on JS level the filter will intercept any [] operations and still claim the element doesn't exist. Also, such an Array would still need to behave as a JS Array for indices in range of 2^31?2^32-1, which can't be represented in a java.util.List, so a backup storage might be required for those indices, further creating a discrepancy between Array.length and list.size(). So anyway, none of these are arguments against having a List-backed Array, just saying that it's not possible to entirely reconcile the collection models, so there'll always be corner cases where abstraction leaks through. JS arrays are heterogenous and non-continuos, with max capacity of 2^32-1. Java Lists are heterogeneous and continuous, with max capacity of 2^31-1. They're still a better match than Java arrays, which are homogenous and continuous with max capacity of 2^31-1 :-) Attila. On Nov 27, 2014, at 12:18 PM, Tim Fox wrote: > On 27/11/14 10:33, Attila Szegedi wrote: >> Nashorn explicitly allows [] operator on java lists and it also supports for?in on them. ".length" is also supported since 8u20, see . >> >> We indeed don't implicitly convert Lists into JS Array objects in Nashorn. The reason is that JS Array has a Java array as backing storage; wrapping a large list would incur a lot of copying. > > To avoid the copying, could the Nashorn JS Array implementation be changed so it backs either: > > a) A Java Array (as it does currently) - this would the case if you created the JS array directly in JS code. > b) A Java List - this would be the case if a List was passed from Java to JS, providing the user with a JS array > > Then we can have our cake and eat it? I.e. we have a real JS Array object (not a half way house with some of the functions and properties but not all), and no copying overhead. > >> You can use "Java.from(someObject.provideList())" to explicitly convert a Java List to a JS array. We think it's better to provide an explicit conversion API than incur a linear conversion cost whenever a List object passes into the JS context. >> The Java.from created copy is shallow; if you have a List of Lists, the nested List objects are not converted. >> >> Typically you'll want to create a real Array if you want to use Array functionality that points beyond [], .length, and for?in, e.g. JS Array comprehension operations (arguably, we *could* implement even those so that Array.prototype.forEach.call(javaList, ...) works as expected, but we aren't there yet.) >> >> Attila. >> >> On Nov 27, 2014, at 10:41 AM, Tim Fox wrote: >> >>> Hello again, >>> >>> I am a bit confused about how Lists passed from Java into JS are converted. >>> >>> I have a Java class as follows: >>> >>> public class SomeClass { >>> >>> public List provideList() { >>> List list = new ArrayList<>(); >>> list.add("foo"); >>> list.add("bar"); >>> return list; >>> } >>> } >>> >>> I call this from JavaScript: >>> >>> var io = Packages.io; >>> var someObject = new io.vertx.scratchpad.SomeClass(); >>> >>> var arr = someObject.provideList(); >>> >>> console.log(arr[0]); // prints: foo >>> console.log(typeof arr.length); // undefined >>> console.log(arr instanceof Array); // false >>> >>> I was under the impression that Nashorn automatically converted Java lists passed into JS into JS Arrays. >>> >>> The object arr returned in some ways resembles a JavaScript array - the operators [] and []= work on it, however it doesn't have the array property "length" and it's not an instanceof Array. >>> >>> Can anyone clarify to me what this object is? Any reason why Nashorn doesn't just wrap it as a real JS Array? >>> >>> Cheers > From hannes.wallnoefer at oracle.com Thu Nov 27 12:09:56 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 27 Nov 2014 13:09:56 +0100 Subject: Review request for JDK-8057980: let & const: remaining issues with lexical scoping Message-ID: <54771494.1010409@oracle.com> Please review JDK-8057980: let & const: remaining issues with lexical scoping: http://cr.openjdk.java.net/~hannesw/8057980/ Summary of changes: - Throw error when let/const declaration is used in single-statement context as it is not a statement - Implement per-iteration scope in for(let ; ;) loop - Throw error for let/const in top-level switch statement. This should be supported, but we can't implement this correctly without a bigger rewrite of switch statement handling. - Overwriting const binding from different script should throw type error also in non-strict mode. - Removed unused flags: VarNode.IS_STATEMENT and ForNode.IS_FOR Thanks, Hannes From marcus.lagergren at oracle.com Thu Nov 27 12:29:57 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 27 Nov 2014 13:29:57 +0100 Subject: Review request for JDK-8057980: let & const: remaining issues with lexical scoping In-Reply-To: <54771494.1010409@oracle.com> References: <54771494.1010409@oracle.com> Message-ID: <94BCD11C-7200-4D7B-9AD6-E965A64EC9AB@oracle.com> +1 Please file a CR to like scoped consts as MethodHandle.constant in the future! Regards Marcus > On 27 Nov 2014, at 13:09, Hannes Wallnoefer wrote: > > Please review JDK-8057980: let & const: remaining issues with lexical scoping: > > http://cr.openjdk.java.net/~hannesw/8057980/ > > Summary of changes: > - Throw error when let/const declaration is used in single-statement context as it is not a statement > - Implement per-iteration scope in for(let ; ;) loop > - Throw error for let/const in top-level switch statement. This should be supported, but we can't implement this correctly without a bigger rewrite of switch statement handling. > - Overwriting const binding from different script should throw type error also in non-strict mode. > - Removed unused flags: VarNode.IS_STATEMENT and ForNode.IS_FOR > > Thanks, > Hannes From timvolpe at gmail.com Thu Nov 27 13:11:57 2014 From: timvolpe at gmail.com (Tim Fox) Date: Thu, 27 Nov 2014 13:11:57 +0000 Subject: Fast passing of JSON between JS and Java (and vice versa) Message-ID: <5477231D.8090304@gmail.com> As you know.. In JS, a JSON Object is represented by a JS object, and in the Java world it's often represented by Map. In JS a JSON array is represented by a JS array, and in the Java world it's often represented by a List. I'd love to be able to pass JSON between JS and Java and vice versa with the minimum of performance overhead. This is particularly important in Vert.x as we chuck a lot of JSON around. Let's say I have a Java interface which expects some JSON: interface SomeInterface { void expectsJSON(Map json); } Right now I am converting from JS-->Java as follows. var someJson = { foo: "bar"}; String encoded = JSON.stringify(someJson); Map map = SomeJavaJSONLibrary.decode(encoded); myObject.expectsJSON(map); As you can see it's pretty clunky. The other direction is equally as clunky. And it's slow as we're encoding/decoding everything via String. Then I realised that if I pass a JS object directly into the expectsJSON method Nashorn will provide me with a Map that backs the original object. I.e. I can do this: var someJson = { foo: "bar"}; myObject.expectsJSON(map); Yay! No encoding overhead. Fast. :) And it works with nested json: var someJson = { foo: "bar", nested: { wibble: "blah"}}; Just when I was getting my hopes up that this would be a great super fast way of transferring JSON betwen Java and JS, I tried it with a nest array: var someJson = { foo: "bar", nestedArray: [123, 456]}; But in Java, map.get("nestedArray") returns a ScriptObjectMirror not a List as I was hoping. :( So.. passing from JS to Java: JS Object maps to Map, but JS Array maps to ScriptObjectMirror. (Seems a bit asymmetric?). Any reason why we can't map JS Array to Java list when calling JS->Java? (Perhaps this is related to my previous question backing a JS Array with a List...) Do you have any other suggestions for transferring JSON between JS and Java without too much encoding overhead? Thanks again! From attila.szegedi at oracle.com Thu Nov 27 13:40:19 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 27 Nov 2014 14:40:19 +0100 Subject: Fast passing of JSON between JS and Java (and vice versa) In-Reply-To: <5477231D.8090304@gmail.com> References: <5477231D.8090304@gmail.com> Message-ID: We wrap every native JS object into a ScriptObjectMirror for passing back to Java. Now, even for the top-level object, you'll just get a ScriptObjectMirror, but it happens to implement javax.script.Bindings, which is an interface that extends Map. Unfortunately, we can't subclass ScriptObjectMirror to give you an ArrayMirror as no Java class can simultaneously implement both List and Map interfaces due to incompatibility in return types of "Object Map.remove(Object)" and "boolean List.remove(Object)" :-( Trust me, I was quite mad when I first realized this. Arguably, we could have a separate ArrayMirror that doesn't subclass ScriptObjectMirror (and thus doesn't expose Map interface), just a List interface. You'd then lose the ability to treat a JS Array as a Map from the Java side -- admittedly, it might be worth it. Got to discuss this a bit more with the team. Attila. On Nov 27, 2014, at 2:11 PM, Tim Fox wrote: > As you know.. > > In JS, a JSON Object is represented by a JS object, and in the Java world it's often represented by Map. > In JS a JSON array is represented by a JS array, and in the Java world it's often represented by a List. > > I'd love to be able to pass JSON between JS and Java and vice versa with the minimum of performance overhead. This is particularly important in Vert.x as we chuck a lot of JSON around. > > Let's say I have a Java interface which expects some JSON: > > interface SomeInterface { > > void expectsJSON(Map json); > } > > Right now I am converting from JS-->Java as follows. > > var someJson = { foo: "bar"}; > String encoded = JSON.stringify(someJson); > Map map = SomeJavaJSONLibrary.decode(encoded); > myObject.expectsJSON(map); > > As you can see it's pretty clunky. The other direction is equally as clunky. And it's slow as we're encoding/decoding everything via String. > > Then I realised that if I pass a JS object directly into the expectsJSON method Nashorn will provide me with a Map that backs the original object. I.e. I can do this: > > var someJson = { foo: "bar"}; > myObject.expectsJSON(map); > > Yay! No encoding overhead. Fast. :) > > And it works with nested json: > > var someJson = { foo: "bar", nested: { wibble: "blah"}}; > > Just when I was getting my hopes up that this would be a great super fast way of transferring JSON betwen Java and JS, I tried it with a nest array: > > var someJson = { foo: "bar", nestedArray: [123, 456]}; > > But in Java, map.get("nestedArray") returns a ScriptObjectMirror not a List as I was hoping. :( > > So.. passing from JS to Java: JS Object maps to Map, but JS Array maps to ScriptObjectMirror. (Seems a bit asymmetric?). > > Any reason why we can't map JS Array to Java list when calling JS->Java? (Perhaps this is related to my previous question backing a JS Array with a List...) > > Do you have any other suggestions for transferring JSON between JS and Java without too much encoding overhead? > > Thanks again! > > > > > > > From attila.szegedi at oracle.com Thu Nov 27 13:46:58 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 27 Nov 2014 14:46:58 +0100 Subject: Fast passing of JSON between JS and Java (and vice versa) In-Reply-To: References: <5477231D.8090304@gmail.com> Message-ID: <28461712-A70E-445E-B788-870886027EBE@oracle.com> Also, the documentation for both List and Map interfaces prescribes an exact algorithm[1][2] that every implementation of them must use to calculate their hashCode(), and they too are incompatible. This is not as insurmountable as a javac error, but still not a good idea to violate. FWIW, having a separate ArrayMirror that implements only List might still be workable. Attila. --- [1] http://docs.oracle.com/javase/8/docs/api/java/util/List.html#hashCode-- [2] http://docs.oracle.com/javase/8/docs/api/java/util/Map.html#hashCode-- On Nov 27, 2014, at 2:40 PM, Attila Szegedi wrote: > [...] > > Unfortunately, we can't subclass ScriptObjectMirror to give you an ArrayMirror as no Java class can simultaneously implement both List and Map interfaces due to incompatibility in return types of "Object Map.remove(Object)" and "boolean List.remove(Object)" :-( Trust me, I was quite mad when I first realized this. > > [...] > > Attila. > > On Nov 27, 2014, at 2:11 PM, Tim Fox wrote: > >> As you know.. >> >> In JS, a JSON Object is represented by a JS object, and in the Java world it's often represented by Map. >> In JS a JSON array is represented by a JS array, and in the Java world it's often represented by a List. >> >> I'd love to be able to pass JSON between JS and Java and vice versa with the minimum of performance overhead. This is particularly important in Vert.x as we chuck a lot of JSON around. >> >> Let's say I have a Java interface which expects some JSON: >> >> interface SomeInterface { >> >> void expectsJSON(Map json); >> } >> >> Right now I am converting from JS-->Java as follows. >> >> var someJson = { foo: "bar"}; >> String encoded = JSON.stringify(someJson); >> Map map = SomeJavaJSONLibrary.decode(encoded); >> myObject.expectsJSON(map); >> >> As you can see it's pretty clunky. The other direction is equally as clunky. And it's slow as we're encoding/decoding everything via String. >> >> Then I realised that if I pass a JS object directly into the expectsJSON method Nashorn will provide me with a Map that backs the original object. I.e. I can do this: >> >> var someJson = { foo: "bar"}; >> myObject.expectsJSON(map); >> >> Yay! No encoding overhead. Fast. :) >> >> And it works with nested json: >> >> var someJson = { foo: "bar", nested: { wibble: "blah"}}; >> >> Just when I was getting my hopes up that this would be a great super fast way of transferring JSON betwen Java and JS, I tried it with a nest array: >> >> var someJson = { foo: "bar", nestedArray: [123, 456]}; >> >> But in Java, map.get("nestedArray") returns a ScriptObjectMirror not a List as I was hoping. :( >> >> So.. passing from JS to Java: JS Object maps to Map, but JS Array maps to ScriptObjectMirror. (Seems a bit asymmetric?). >> >> Any reason why we can't map JS Array to Java list when calling JS->Java? (Perhaps this is related to my previous question backing a JS Array with a List...) >> >> Do you have any other suggestions for transferring JSON between JS and Java without too much encoding overhead? >> >> Thanks again! >> >> >> >> >> >> >> > From attila.szegedi at oracle.com Thu Nov 27 14:01:11 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 27 Nov 2014 15:01:11 +0100 Subject: Forcing elements of List to be converted as java.lang.Long In-Reply-To: <54766957.7010201@univ-mlv.fr> References: <547649F6.3060905@gmail.com> <56DEF7CA-8D1B-409D-867E-532D27856302@oracle.com> <54766427.7000208@gmail.com> <54766957.7010201@univ-mlv.fr> Message-ID: You're right about that, R?mi. However, even in Java you can twist things with unchecked casts so that you pass a List to this method and force it into a ClassCastException, so I'm not sure if us going out of our way to inject a suitable conversion would be desired. On Nov 27, 2014, at 12:59 AM, Remi Forax wrote: > > On 11/27/2014 12:37 AM, Tim Fox wrote: >> Hi Attila, >> >> I understand the generic type info is erased, but my question was whether there is any way I can "force" Nashorn to convert the elements as Long rather than Integer when doing the conversion, e.g. using some special Nashorn specific syntax, e.g. >> >> var arr = [123]; >> arr.forceConversionAsLong = true; // A contrived example but you get the point :) >> obj.foo(arr); >> >> (or whatever) > > BTW, generic info like this one are preserved because javac need them to cross compile. > so nashorn could inspect the generic signature and if there is one try to do the suitable conversion. > > R?mi > >> >> >> On 26/11/14 21:50, Attila Szegedi wrote: >>> I don't think so. As the types are erased at run time all we see is a method with signature foo(List list). I think if you tried to add two methods to a class: >>> >>> public void foo(List x) { } >>> public void foo(List x) { } >>> >>> then javac would refuse to compile it saying that both have the same erasure. >>> >>> Attila. >>> >>> On Nov 26, 2014, at 10:45 PM, Tim Fox wrote: >>> >>>> Hello folks, >>>> >>>> I have a Java method: >>>> >>>> public void foo(List list) { >>>> System.out.println("elem0 is " + list.get(0)); >>>> } >>>> >>>> Which I call from JS with a JS array: >>>> >>>> obj.foo([123]); >>>> >>>> This results in a ClassCastException as Nashorn converts the JS Array into a java.util.List instance which contains a java.lang.Integer element (not java.lang.Long) >>>> >>>> Is there any way to force Nashorn to convert the array elements as Longs not Integers? >>>> >>>> Thanks. >> > From attila.szegedi at oracle.com Thu Nov 27 14:48:06 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 27 Nov 2014 15:48:06 +0100 Subject: Fast passing of JSON between JS and Java (and vice versa) In-Reply-To: <28461712-A70E-445E-B788-870886027EBE@oracle.com> References: <5477231D.8090304@gmail.com> <28461712-A70E-445E-B788-870886027EBE@oracle.com> Message-ID: <1D868CC1-342A-4972-AABA-7666382FE90C@oracle.com> So, some initial discussion of this with my team leads to following conclusions: - We can't stop wrapping all objects in ScriptObjectMirror, as ScriptObjectMirror is a public class, and we allow people to expect it. If we now started returning ScriptObjectMirror sometimes and ArrayMirror (provisional name) other times, that'd be an API breaking change. That's sad, really ? we should've probably never made ScriptObjectMirror public and instead forced people to only program against the JSObject interface instead. - We've been thinking of creating a separate "class ArrayMirror implements JSObject, List" for wrapping JS Arrays, but you'd need to explicitly ask a mirror that'll return these transitively, e.g. we could give you a Java.toJSONCompatible(obj) API that you'd use as: "myObject.expectsJSON(Java.toJSONCompatible(someJson));" You'd still be getting a ScriptObjectMirror on the top level (as long as it ain't an array in which case the top level would itself be an ArrayMirror), but it'd be carrying a hidden flag that'd change its behavior so whenever you retrieve an Array from it, it gets wrapped into ArrayMirror and not ScriptObjectMirror. Also, if you retrieve an Object from it, you'd get a ScriptObjectMirror with this flag propagated, so Arrays at any nesting depth would always be exposed as Lists. Arguably, this could be the default behaviour except for the fact that it isn't how it worked since the initial 8 release and we can't break backwards compatibility? How's that sound? Attila. On Nov 27, 2014, at 2:46 PM, Attila Szegedi wrote: > Also, the documentation for both List and Map interfaces prescribes an exact algorithm[1][2] that every implementation of them must use to calculate their hashCode(), and they too are incompatible. This is not as insurmountable as a javac error, but still not a good idea to violate. FWIW, having a separate ArrayMirror that implements only List might still be workable. > > Attila. > > --- > [1] http://docs.oracle.com/javase/8/docs/api/java/util/List.html#hashCode-- > [2] http://docs.oracle.com/javase/8/docs/api/java/util/Map.html#hashCode-- > > On Nov 27, 2014, at 2:40 PM, Attila Szegedi wrote: > >> [...] >> >> Unfortunately, we can't subclass ScriptObjectMirror to give you an ArrayMirror as no Java class can simultaneously implement both List and Map interfaces due to incompatibility in return types of "Object Map.remove(Object)" and "boolean List.remove(Object)" :-( Trust me, I was quite mad when I first realized this. >> >> [...] >> >> Attila. >> >> On Nov 27, 2014, at 2:11 PM, Tim Fox wrote: >> >>> As you know.. >>> >>> In JS, a JSON Object is represented by a JS object, and in the Java world it's often represented by Map. >>> In JS a JSON array is represented by a JS array, and in the Java world it's often represented by a List. >>> >>> I'd love to be able to pass JSON between JS and Java and vice versa with the minimum of performance overhead. This is particularly important in Vert.x as we chuck a lot of JSON around. >>> >>> Let's say I have a Java interface which expects some JSON: >>> >>> interface SomeInterface { >>> >>> void expectsJSON(Map json); >>> } >>> >>> Right now I am converting from JS-->Java as follows. >>> >>> var someJson = { foo: "bar"}; >>> String encoded = JSON.stringify(someJson); >>> Map map = SomeJavaJSONLibrary.decode(encoded); >>> myObject.expectsJSON(map); >>> >>> As you can see it's pretty clunky. The other direction is equally as clunky. And it's slow as we're encoding/decoding everything via String. >>> >>> Then I realised that if I pass a JS object directly into the expectsJSON method Nashorn will provide me with a Map that backs the original object. I.e. I can do this: >>> >>> var someJson = { foo: "bar"}; >>> myObject.expectsJSON(map); >>> >>> Yay! No encoding overhead. Fast. :) >>> >>> And it works with nested json: >>> >>> var someJson = { foo: "bar", nested: { wibble: "blah"}}; >>> >>> Just when I was getting my hopes up that this would be a great super fast way of transferring JSON betwen Java and JS, I tried it with a nest array: >>> >>> var someJson = { foo: "bar", nestedArray: [123, 456]}; >>> >>> But in Java, map.get("nestedArray") returns a ScriptObjectMirror not a List as I was hoping. :( >>> >>> So.. passing from JS to Java: JS Object maps to Map, but JS Array maps to ScriptObjectMirror. (Seems a bit asymmetric?). >>> >>> Any reason why we can't map JS Array to Java list when calling JS->Java? (Perhaps this is related to my previous question backing a JS Array with a List...) >>> >>> Do you have any other suggestions for transferring JSON between JS and Java without too much encoding overhead? >>> >>> Thanks again! >>> >>> >>> >>> >>> >>> >>> >> > From attila.szegedi at oracle.com Thu Nov 27 15:20:55 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 27 Nov 2014 16:20:55 +0100 Subject: Review request for JDK-8057980: let & const: remaining issues with lexical scoping In-Reply-To: <54771494.1010409@oracle.com> References: <54771494.1010409@oracle.com> Message-ID: +1 On Nov 27, 2014, at 1:09 PM, Hannes Wallnoefer wrote: > Please review JDK-8057980: let & const: remaining issues with lexical scoping: > > http://cr.openjdk.java.net/~hannesw/8057980/ > > Summary of changes: > - Throw error when let/const declaration is used in single-statement context as it is not a statement > - Implement per-iteration scope in for(let ; ;) loop > - Throw error for let/const in top-level switch statement. This should be supported, but we can't implement this correctly without a bigger rewrite of switch statement handling. > - Overwriting const binding from different script should throw type error also in non-strict mode. > - Removed unused flags: VarNode.IS_STATEMENT and ForNode.IS_FOR > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Thu Nov 27 16:26:23 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 27 Nov 2014 17:26:23 +0100 Subject: Review request for JDK-8057980: let & const: remaining issues with lexical scoping In-Reply-To: References: <54771494.1010409@oracle.com> Message-ID: <547750AF.1030703@oracle.com> Unfortunately changes in Parser.java did not apply cleanly to 8u-dev. Can you please review the webrev for 8u-dev? http://cr.openjdk.java.net/~hannesw/8057980/webrev-8u/ I also had to add a ForNode.setPerIterationScope method because of the lack of ParserContextNodes in 8u. Thanks, Hannes Am 2014-11-27 um 16:20 schrieb Attila Szegedi: > +1 > > On Nov 27, 2014, at 1:09 PM, Hannes Wallnoefer wrote: > >> Please review JDK-8057980: let & const: remaining issues with lexical scoping: >> >> http://cr.openjdk.java.net/~hannesw/8057980/ >> >> Summary of changes: >> - Throw error when let/const declaration is used in single-statement context as it is not a statement >> - Implement per-iteration scope in for(let ; ;) loop >> - Throw error for let/const in top-level switch statement. This should be supported, but we can't implement this correctly without a bigger rewrite of switch statement handling. >> - Overwriting const binding from different script should throw type error also in non-strict mode. >> - Removed unused flags: VarNode.IS_STATEMENT and ForNode.IS_FOR >> >> Thanks, >> Hannes From marcus.lagergren at oracle.com Thu Nov 27 16:30:44 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 27 Nov 2014 17:30:44 +0100 Subject: Review request for JDK-8057980: let & const: remaining issues with lexical scoping In-Reply-To: <547750AF.1030703@oracle.com> References: <54771494.1010409@oracle.com> <547750AF.1030703@oracle.com> Message-ID: +1 > On 27 Nov 2014, at 17:26, Hannes Wallnoefer wrote: > > Unfortunately changes in Parser.java did not apply cleanly to 8u-dev. Can you please review the webrev for 8u-dev? > > http://cr.openjdk.java.net/~hannesw/8057980/webrev-8u/ > > I also had to add a ForNode.setPerIterationScope method because of the lack of ParserContextNodes in 8u. > > Thanks, > Hannes > > Am 2014-11-27 um 16:20 schrieb Attila Szegedi: >> +1 >> >> On Nov 27, 2014, at 1:09 PM, Hannes Wallnoefer wrote: >> >>> Please review JDK-8057980: let & const: remaining issues with lexical scoping: >>> >>> http://cr.openjdk.java.net/~hannesw/8057980/ >>> >>> Summary of changes: >>> - Throw error when let/const declaration is used in single-statement context as it is not a statement >>> - Implement per-iteration scope in for(let ; ;) loop >>> - Throw error for let/const in top-level switch statement. This should be supported, but we can't implement this correctly without a bigger rewrite of switch statement handling. >>> - Overwriting const binding from different script should throw type error also in non-strict mode. >>> - Removed unused flags: VarNode.IS_STATEMENT and ForNode.IS_FOR >>> >>> Thanks, >>> Hannes > From timvolpe at gmail.com Thu Nov 27 19:08:25 2014 From: timvolpe at gmail.com (Tim Fox) Date: Thu, 27 Nov 2014 19:08:25 +0000 Subject: Fast passing of JSON between JS and Java (and vice versa) In-Reply-To: <1D868CC1-342A-4972-AABA-7666382FE90C@oracle.com> References: <5477231D.8090304@gmail.com> <28461712-A70E-445E-B788-870886027EBE@oracle.com> <1D868CC1-342A-4972-AABA-7666382FE90C@oracle.com> Message-ID: <547776A9.1070805@gmail.com> On 27/11/14 14:48, Attila Szegedi wrote: > So, some initial discussion of this with my team leads to following conclusions: > > - We can't stop wrapping all objects in ScriptObjectMirror, as ScriptObjectMirror is a public class, and we allow people to expect it. If we now started returning ScriptObjectMirror sometimes and ArrayMirror (provisional name) other times, that'd be an API breaking change. That's sad, really ? we should've probably never made ScriptObjectMirror public and instead forced people to only program against the JSObject interface instead. > > - We've been thinking of creating a separate "class ArrayMirror implements JSObject, List" for wrapping JS Arrays, but you'd need to explicitly ask a mirror that'll return these transitively, e.g. we could give you a Java.toJSONCompatible(obj) API that you'd use as: "myObject.expectsJSON(Java.toJSONCompatible(someJson));" You'd still be getting a ScriptObjectMirror on the top level (as long as it ain't an array in which case the top level would itself be an ArrayMirror), but it'd be carrying a hidden flag that'd change its behavior so whenever you retrieve an Array from it, it gets wrapped into ArrayMirror and not ScriptObjectMirror. Also, if you retrieve an Object from it, you'd get a ScriptObjectMirror with this flag propagated, so Arrays at any nesting depth would always be exposed as Lists. Arguably, this could be the default behaviour except for the fact that it isn't how it worked since the initial 8 release and we can't break backwards compatibility? > > How's that sound? Sounds good. Thanks for taking time to look at this :) > > Attila. > > On Nov 27, 2014, at 2:46 PM, Attila Szegedi wrote: > >> Also, the documentation for both List and Map interfaces prescribes an exact algorithm[1][2] that every implementation of them must use to calculate their hashCode(), and they too are incompatible. This is not as insurmountable as a javac error, but still not a good idea to violate. FWIW, having a separate ArrayMirror that implements only List might still be workable. >> >> Attila. >> >> --- >> [1] http://docs.oracle.com/javase/8/docs/api/java/util/List.html#hashCode-- >> [2] http://docs.oracle.com/javase/8/docs/api/java/util/Map.html#hashCode-- >> >> On Nov 27, 2014, at 2:40 PM, Attila Szegedi wrote: >> >>> [...] >>> >>> Unfortunately, we can't subclass ScriptObjectMirror to give you an ArrayMirror as no Java class can simultaneously implement both List and Map interfaces due to incompatibility in return types of "Object Map.remove(Object)" and "boolean List.remove(Object)" :-( Trust me, I was quite mad when I first realized this. >>> >>> [...] >>> >>> Attila. >>> >>> On Nov 27, 2014, at 2:11 PM, Tim Fox wrote: >>> >>>> As you know.. >>>> >>>> In JS, a JSON Object is represented by a JS object, and in the Java world it's often represented by Map. >>>> In JS a JSON array is represented by a JS array, and in the Java world it's often represented by a List. >>>> >>>> I'd love to be able to pass JSON between JS and Java and vice versa with the minimum of performance overhead. This is particularly important in Vert.x as we chuck a lot of JSON around. >>>> >>>> Let's say I have a Java interface which expects some JSON: >>>> >>>> interface SomeInterface { >>>> >>>> void expectsJSON(Map json); >>>> } >>>> >>>> Right now I am converting from JS-->Java as follows. >>>> >>>> var someJson = { foo: "bar"}; >>>> String encoded = JSON.stringify(someJson); >>>> Map map = SomeJavaJSONLibrary.decode(encoded); >>>> myObject.expectsJSON(map); >>>> >>>> As you can see it's pretty clunky. The other direction is equally as clunky. And it's slow as we're encoding/decoding everything via String. >>>> >>>> Then I realised that if I pass a JS object directly into the expectsJSON method Nashorn will provide me with a Map that backs the original object. I.e. I can do this: >>>> >>>> var someJson = { foo: "bar"}; >>>> myObject.expectsJSON(map); >>>> >>>> Yay! No encoding overhead. Fast. :) >>>> >>>> And it works with nested json: >>>> >>>> var someJson = { foo: "bar", nested: { wibble: "blah"}}; >>>> >>>> Just when I was getting my hopes up that this would be a great super fast way of transferring JSON betwen Java and JS, I tried it with a nest array: >>>> >>>> var someJson = { foo: "bar", nestedArray: [123, 456]}; >>>> >>>> But in Java, map.get("nestedArray") returns a ScriptObjectMirror not a List as I was hoping. :( >>>> >>>> So.. passing from JS to Java: JS Object maps to Map, but JS Array maps to ScriptObjectMirror. (Seems a bit asymmetric?). >>>> >>>> Any reason why we can't map JS Array to Java list when calling JS->Java? (Perhaps this is related to my previous question backing a JS Array with a List...) >>>> >>>> Do you have any other suggestions for transferring JSON between JS and Java without too much encoding overhead? >>>> >>>> Thanks again! >>>> >>>> >>>> >>>> >>>> >>>> >>>> From marcus.lagergren at oracle.com Fri Nov 28 08:23:48 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 28 Nov 2014 09:23:48 +0100 Subject: Please review JDK-8066119 Message-ID: Bug report at: https://bugs.openjdk.java.net/browse/JDK-8066119 Webrev at: http://cr.openjdk.java.net/~lagergren/8066119/ When experimenting with 9 code, I accidentally generated a corrupt NativeDataView that didn?t contain an ArrayBuffer, something that should be impossible given that the buffer field is constant and assigned at instantiation time only, and checks are done at instantiation time, Hence this is noreg-trivial. I can?t recreate the state in working code. It can be easily hand verified. Regards Marcus From hannes.wallnoefer at oracle.com Fri Nov 28 08:27:03 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 28 Nov 2014 09:27:03 +0100 Subject: Please review JDK-8066119 In-Reply-To: References: Message-ID: <547831D7.6030509@oracle.com> +1 Am 2014-11-28 um 09:23 schrieb Marcus Lagergren: > Bug report at: https://bugs.openjdk.java.net/browse/JDK-8066119 > Webrev at: http://cr.openjdk.java.net/~lagergren/8066119/ > > When experimenting with 9 code, I accidentally generated a corrupt NativeDataView that didn?t contain an ArrayBuffer, something that should be impossible given that the buffer field is constant and assigned at instantiation time only, and checks are done at instantiation time, Hence this is noreg-trivial. I can?t recreate the state in working code. > > It can be easily hand verified. > > Regards > Marcus > > From sundararajan.athijegannathan at oracle.com Fri Nov 28 10:41:36 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 28 Nov 2014 16:11:36 +0530 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs Message-ID: <54785160.3070501@oracle.com> Hi, Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8066146 Thanks, -Sundar From erik.joelsson at oracle.com Fri Nov 28 10:58:04 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 28 Nov 2014 11:58:04 +0100 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <54785160.3070501@oracle.com> References: <54785160.3070501@oracle.com> Message-ID: <5478553C.8040408@oracle.com> Hello, Should: 1140 NASHORNAPI2COREAPI := ../../$(JDKJRE2COREAPI) be? 1140 NASHORNAPI2COREAPI := ../$(JDKJRE2COREAPI) I assume it's relative to DOCDIR defined on the line above. /Erik On 2014-11-28 11:41, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8066146 > > Thanks, > -Sundar From attila.szegedi at oracle.com Fri Nov 28 11:20:11 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 28 Nov 2014 12:20:11 +0100 Subject: Review request for JDK-8057980: let & const: remaining issues with lexical scoping In-Reply-To: <547750AF.1030703@oracle.com> References: <54771494.1010409@oracle.com> <547750AF.1030703@oracle.com> Message-ID: +1 on backport On Nov 27, 2014, at 5:26 PM, Hannes Wallnoefer wrote: > Unfortunately changes in Parser.java did not apply cleanly to 8u-dev. Can you please review the webrev for 8u-dev? > > http://cr.openjdk.java.net/~hannesw/8057980/webrev-8u/ > > I also had to add a ForNode.setPerIterationScope method because of the lack of ParserContextNodes in 8u. > > Thanks, > Hannes > > Am 2014-11-27 um 16:20 schrieb Attila Szegedi: >> +1 >> >> On Nov 27, 2014, at 1:09 PM, Hannes Wallnoefer wrote: >> >>> Please review JDK-8057980: let & const: remaining issues with lexical scoping: >>> >>> http://cr.openjdk.java.net/~hannesw/8057980/ >>> >>> Summary of changes: >>> - Throw error when let/const declaration is used in single-statement context as it is not a statement >>> - Implement per-iteration scope in for(let ; ;) loop >>> - Throw error for let/const in top-level switch statement. This should be supported, but we can't implement this correctly without a bigger rewrite of switch statement handling. >>> - Overwriting const binding from different script should throw type error also in non-strict mode. >>> - Removed unused flags: VarNode.IS_STATEMENT and ForNode.IS_FOR >>> >>> Thanks, >>> Hannes > From sundararajan.athijegannathan at oracle.com Fri Nov 28 11:50:24 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 28 Nov 2014 17:20:24 +0530 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <5478553C.8040408@oracle.com> References: <54785160.3070501@oracle.com> <5478553C.8040408@oracle.com> Message-ID: <54786180.60503@oracle.com> Hi, Thanks for catching that! Please review updated http://cr.openjdk.java.net/~sundar/8066146/webrev.01/ Thanks, -Sundar Erik Joelsson wrote: > Hello, > > Should: > > 1140 NASHORNAPI2COREAPI := ../../$(JDKJRE2COREAPI) > > be? > > 1140 NASHORNAPI2COREAPI := ../$(JDKJRE2COREAPI) > > I assume it's relative to DOCDIR defined on the line above. > > /Erik > > On 2014-11-28 11:41, A. Sundararajan wrote: >> Hi, >> >> Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8066146 >> >> Thanks, >> -Sundar > From erik.joelsson at oracle.com Fri Nov 28 11:54:24 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 28 Nov 2014 12:54:24 +0100 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <54786180.60503@oracle.com> References: <54785160.3070501@oracle.com> <5478553C.8040408@oracle.com> <54786180.60503@oracle.com> Message-ID: <54786270.5060309@oracle.com> Looks good to me. /Erik On 2014-11-28 12:50, A. Sundararajan wrote: > Hi, > > Thanks for catching that! > > Please review updated > http://cr.openjdk.java.net/~sundar/8066146/webrev.01/ > > Thanks, > -Sundar > > Erik Joelsson wrote: >> Hello, >> >> Should: >> >> 1140 NASHORNAPI2COREAPI := ../../$(JDKJRE2COREAPI) >> >> be? >> >> 1140 NASHORNAPI2COREAPI := ../$(JDKJRE2COREAPI) >> >> I assume it's relative to DOCDIR defined on the line above. >> >> /Erik >> >> On 2014-11-28 11:41, A. Sundararajan wrote: >>> Hi, >>> >>> Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ >>> for https://bugs.openjdk.java.net/browse/JDK-8066146 >>> >>> Thanks, >>> -Sundar >> > From james.laskey at oracle.com Fri Nov 28 12:06:03 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 28 Nov 2014 08:06:03 -0400 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <54785160.3070501@oracle.com> References: <54785160.3070501@oracle.com> Message-ID: <6E7A15A8-A01E-459B-B510-C1C485C50D9E@oracle.com> +1 On Nov 28, 2014, at 6:41 AM, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8066146 > > Thanks, > -Sundar From marcus.lagergren at oracle.com Fri Nov 28 12:50:25 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 28 Nov 2014 13:50:25 +0100 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <54786180.60503@oracle.com> References: <54785160.3070501@oracle.com> <5478553C.8040408@oracle.com> <54786180.60503@oracle.com> Message-ID: +1 > On 28 Nov 2014, at 12:50, A. Sundararajan wrote: > > Hi, > > Thanks for catching that! > > Please review updated http://cr.openjdk.java.net/~sundar/8066146/webrev.01/ > > Thanks, > -Sundar > > Erik Joelsson wrote: >> Hello, >> >> Should: >> >> 1140 NASHORNAPI2COREAPI := ../../$(JDKJRE2COREAPI) >> >> be? >> >> 1140 NASHORNAPI2COREAPI := ../$(JDKJRE2COREAPI) >> >> I assume it's relative to DOCDIR defined on the line above. >> >> /Erik >> >> On 2014-11-28 11:41, A. Sundararajan wrote: >>> Hi, >>> >>> Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8066146 >>> >>> Thanks, >>> -Sundar >> > From sergey.lugovoy at oracle.com Fri Nov 28 14:34:25 2014 From: sergey.lugovoy at oracle.com (Sergey Lugovoy) Date: Fri, 28 Nov 2014 17:34:25 +0300 Subject: [8u40] Request for approval: 8057779: Tests failed on Windows when in output contains path to script Message-ID: <547887F1.40103@oracle.com> Please approve. Changes apply cleanly. bug: https://bugs.openjdk.java.net/browse/JDK-8057779 jdk9 webrev: http://cr.openjdk.java.net/~yan/8057779/webrev.00/ review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-September/003491.html -- Thanks, Sergey From sean.coffey at oracle.com Fri Nov 28 14:39:55 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 28 Nov 2014 14:39:55 +0000 Subject: [8u40] Request for approval: 8057779: Tests failed on Windows when in output contains path to script In-Reply-To: <547887F1.40103@oracle.com> References: <547887F1.40103@oracle.com> Message-ID: <5478893B.1010801@oracle.com> Approved. regards, Sean. On 28/11/2014 14:34, Sergey Lugovoy wrote: > Please approve. > Changes apply cleanly. > > bug: https://bugs.openjdk.java.net/browse/JDK-8057779 > jdk9 webrev: http://cr.openjdk.java.net/~yan/8057779/webrev.00/ > review thread: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-September/003491.html > > From andrebargull at googlemail.com Fri Nov 28 16:16:36 2014 From: andrebargull at googlemail.com (=?UTF-8?B?QW5kcsOpIEJhcmd1bGw=?=) Date: Fri, 28 Nov 2014 17:16:36 +0100 Subject: Fuzzer bugs Message-ID: <54789FE4.6010608@googlemail.com> It's been a while since the last jsfunfuzz round. :-) - Andr? Environment: jdk9-dev-nashorn parent: 1109:0c9f3369f3d3 tip jdk8u-dev-nashorn parent: 1096:fc37699ddc0e tip java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) Stacktraces are from jdk9-dev-nashorn, but unless otherwise noted the bugs are also reproducible under jdk8u-dev-nashorn. --- Note: Spec compliance and other issues. jjs> try{ Object.prototype.toLocaleString.call(0) } catch (e) { e.printStackTrace() } java.lang.ClassCastException: java.lang.Integer cannot be cast to jdk.nashorn.internal.runtime.ScriptObject at jdk.nashorn.internal.objects.NativeObject.toLocaleString(NativeObject.java:501) at jdk.nashorn.internal.scripts.Script$3$\^shell\_.:program(:1) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:636) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387) at jdk.nashorn.internal.runtime.Context.eval(Context.java:715) at jdk.nashorn.internal.runtime.Context.eval(Context.java:645) at jdk.nashorn.tools.Shell.readEvalPrint(Shell.java:450) at jdk.nashorn.tools.Shell.run(Shell.java:158) at jdk.nashorn.tools.Shell.main(Shell.java:133) ... Expected: Returns "0" Actual: ClassCastException jjs> Object.defineProperty([], "length", {value: {valueOf: function(){ print("(????)?? ???"); return 0; }}}) Expected: Two tables flipped ;-) Actual: print() only called once Note: ES5 15.4.5.1, steps 3.c and 3.d require two ToNumber conversions. jjs> function defLen(arr, len, f) { var c = false; Object.defineProperty(arr, "length", {value: { valueOf: function(){ (!c && (c = true)) && f && f(); return len; } }}); } jjs> var a = new Array(0); jjs> defLen(a, 1, function() {defLen(a, 5); a[2] = "test"; Object.seal(a); }); Expected: Throws TypeError, `a.length` is 3 Actual: No TypeError, `a.length` is 1 Note: There is a ES5 spec bug you need to workaround, fixed in ES6 draft (https://bugs.ecmascript.org/show_bug.cgi?id=1200). jjs> new ArrayBuffer(); Expected: Throws TypeError (ES6 rev28) or create zero-length buffer (see SpiderMonkey, V8, JSC) Actual: Throws java.lang.RuntimeException jjs> Function("this = null")() Expected: Error string does not contain {U%} Actual: Error string is: 'ReferenceError: "{U%}this" can not be used as the left-hand side of assignment' And jdk.nashorn.internal.runtime.Source#byteToCharArray: Detection for UTF-32LE does not work because it has the same prefix as UTF-16LE. --- Note: The following two bugs need some warm-up, I've tried to reduce the STR as much as possible. function tryItOut(c) { var f = tryCompiling(c); if (f !== null && c.indexOf('infloop') === -1) { tryRunning(f); } } function tryCompiling(c) { try { return Function(c); } catch(e) { return null; } } function tryRunning(f) { try { return f(); } catch (e) { if (e instanceof java.lang.Throwable) e.printStackTrace(); } } tryItOut("return;"); tryItOut("var x = [];"); tryItOut("var y = [];"); tryItOut("var z = [];"); tryItOut("return;"); tryItOut("Math.min"); tryItOut("Math.log"); tryItOut("Math.cos"); tryItOut("Math.max"); tryItOut("Math.sin"); tryItOut("Math.random"); tryItOut(""); tryItOut("return 1e81;"); tryItOut("{}"); tryItOut("((new Function(\"([,,]);\")).apply)(3.14);"); tryItOut("Math.tan"); tryItOut("Math.pow"); tryItOut("([,,]);"); java.lang.ClassCastException: jdk.nashorn.internal.runtime.Undefined cannot be cast to java.lang.Number at sun.invoke.util.ValueConversions.primitiveConversion(ValueConversions.java:199) at sun.invoke.util.ValueConversions.unboxDouble(ValueConversions.java:119) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:656) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387) at jdk.nashorn.internal.scripts.Script$Recompilation$10$213A$a.tryRunning(/tmp/a.js:14) at jdk.nashorn.internal.scripts.Script$Recompilation$7$a.tryItOut(/tmp/a.js:4) at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:636) at jdk.nashorn.internal.scripts.Script$Recompilation$1$a.:program(/tmp/a.js:37) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:636) ... --- function tryItOut(c) { var f = tryCompiling(c); if (f !== null && c.indexOf('infloop') === -1) { tryRunning(f); } } function tryCompiling(c) { try { return Function(c); } catch(e) { return null; } } function tryRunning(f) { try { return f(); } catch (e) { if (e instanceof java.lang.Throwable) e.printStackTrace(); } } tryItOut("x = 1e-81;"); tryItOut("y = x;"); tryItOut("for(x in (((new Function).call)(true))){}"); tryItOut("(x.constructor = new (new Function)(y));"); java.lang.IllegalArgumentException: target and combiner types must match: (Object,Object)Object != (boolean)Object at java.lang.invoke.MethodHandleStatics.newIllegalArgumentException(MethodHandleStatics.java:109) at java.lang.invoke.MethodHandles.misMatchedTypes(MethodHandles.java:2775) at java.lang.invoke.MethodHandles.foldArguments(MethodHandles.java:2714) at jdk.nashorn.internal.lookup.MethodHandleFactory$StandardMethodHandleFunctionality.foldArguments(MethodHandleFactory.java:430) at jdk.nashorn.internal.runtime.CompiledFunction.createConstructorFromInvoker(CompiledFunction.java:265) at jdk.nashorn.internal.runtime.CompiledFunction.getConstructor(CompiledFunction.java:224) at jdk.nashorn.internal.runtime.CompiledFunction.access$300(CompiledFunction.java:61) at jdk.nashorn.internal.runtime.CompiledFunction$3.get(CompiledFunction.java:680) at jdk.nashorn.internal.runtime.CompiledFunction$3.get(CompiledFunction.java:677) at jdk.nashorn.internal.runtime.CompiledFunction.getValidOptimisticInvocation(CompiledFunction.java:606) ... --- jjs> function f() { x3 = function x1(x3) { function (){} }; } f() Exception in thread "main" java.lang.AssertionError: x3 (slot=-1 ) 1090 at jdk.nashorn.internal.codegen.AssignSymbols.finalizeParameters(AssignSymbols.java:569) at jdk.nashorn.internal.codegen.AssignSymbols.leaveFunctionNode(AssignSymbols.java:849) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:384) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:47) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:59) at jdk.nashorn.internal.ir.BinaryNode.accept(BinaryNode.java:347) at jdk.nashorn.internal.ir.ExpressionStatement.accept(ExpressionStatement.java:64) at jdk.nashorn.internal.ir.Node.accept(Node.java:265) at jdk.nashorn.internal.ir.Block.accept(Block.java:178) ... jjs> Function("L: if(true) {x} if([].sort(function x (x){})) { if (eval(\"this\", 0)) {/a/gireturn;return; } else {/*infloop*/for\t(y; (0); 1 ? /x/ : 1) (this);({a:0});{} }}") :1 SyntaxError: :1:81 Unsupported RegExp flag: r jjs> Function("L: if(true) {x} if([].sort(function x (x){})) { if (eval(\"this\", 0)) {/a/gireturn;return; } else {/*infloop*/for\t(y; (0); 1 ? /x/ : 1) (this);({a:0});{} }}") Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.codegen.AssignSymbols.enterFunctionBody(AssignSymbols.java:494) at jdk.nashorn.internal.codegen.AssignSymbols.enterBlock(AssignSymbols.java:453) at jdk.nashorn.internal.ir.Block.accept(Block.java:177) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:425) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:384) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:47) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:59) at jdk.nashorn.internal.ir.Node.accept(Node.java:265) ... jjs> try{ x={}; (function(){ try { throw null; } catch(x) { with({}) return; } finally { eval("'a'.replace('a', Function.apply)"); }})() }catch(e){e.printStackTrace()} java.lang.ClassCastException: jdk.nashorn.internal.scripts.JO1P0 cannot be cast to jdk.nashorn.internal.runtime.WithObject at jdk.nashorn.internal.runtime.WithObject.withExpressionGuard(WithObject.java:363) at jdk.nashorn.internal.scripts.Script$Recompilation$15$\^shell\_#1\!84\^eval\_.:program(#1:84:1) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:636) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387) at jdk.nashorn.internal.runtime.Context.eval(Context.java:711) at jdk.nashorn.internal.objects.Global.directEval(Global.java:941) at jdk.nashorn.internal.scripts.Script$Recompilation$13$12$\^shell\_.L:1(:1) at jdk.nashorn.internal.scripts.Script$Recompilation$11$\^shell\_.:program(:1) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:636) ... jjs> try{ (function(){ if(false ? (-1) : '' ) {throw false;} else if (x = this) {var x = x; } })() } catch(e) { e.printStackTrace() } java.lang.NullPointerException at jdk.nashorn.internal.codegen.MethodEmitter.pushType(MethodEmitter.java:258) at jdk.nashorn.internal.codegen.MethodEmitter.loadUndefined(MethodEmitter.java:779) at jdk.nashorn.internal.codegen.MethodEmitter.emitLocalVariableConversion(MethodEmitter.java:2517) at jdk.nashorn.internal.codegen.MethodEmitter.beforeJoinPoint(MethodEmitter.java:2492) at jdk.nashorn.internal.codegen.CodeGenerator.leaveBlock(CodeGenerator.java:1126) at jdk.nashorn.internal.ir.Block.accept(Block.java:178) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:425) at jdk.nashorn.internal.codegen.CodeGenerator.enterIfNode(CodeGenerator.java:2025) at jdk.nashorn.internal.ir.IfNode.accept(IfNode.java:86) ... jjs> try { function f(){switch(0) { case 8: for (var x in {}) {x} case 8: }} f() } catch(e) { e.printStackTrace() } java.lang.NullPointerException at jdk.nashorn.internal.codegen.MethodEmitter.markDeadSlots(MethodEmitter.java:1154) at jdk.nashorn.internal.codegen.MethodEmitter.markDeadLocalVariable(MethodEmitter.java:1149) at jdk.nashorn.internal.codegen.MethodEmitter.beforeJoinPoint(MethodEmitter.java:2494) at jdk.nashorn.internal.codegen.CodeGenerator.enterSwitchNode(CodeGenerator.java:2932) at jdk.nashorn.internal.ir.SwitchNode.accept(SwitchNode.java:106) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextStatement.accept(LexicalContextStatement.java:55) at jdk.nashorn.internal.ir.SwitchNode.accept(SwitchNode.java:38) at jdk.nashorn.internal.ir.Node.accept(Node.java:265) at jdk.nashorn.internal.ir.Block.accept(Block.java:178) ... jjs> try{ (function(){ if(x, false) { return; var x; } else if (x = 0) { } else { x } })() }catch(e){e.printStackTrace()} java.lang.NullPointerException at jdk.nashorn.internal.codegen.MethodEmitter.markDeadSlots(MethodEmitter.java:1154) at jdk.nashorn.internal.codegen.MethodEmitter.markDeadLocalVariable(MethodEmitter.java:1149) at jdk.nashorn.internal.codegen.MethodEmitter.beforeJoinPoint(MethodEmitter.java:2494) at jdk.nashorn.internal.codegen.CodeGenerator.leaveBlock(CodeGenerator.java:1126) at jdk.nashorn.internal.ir.Block.accept(Block.java:178) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:425) at jdk.nashorn.internal.codegen.CodeGenerator.enterIfNode(CodeGenerator.java:2025) at jdk.nashorn.internal.ir.IfNode.accept(IfNode.java:86) at jdk.nashorn.internal.ir.Node.accept(Node.java:265) ... jjs> function f() { function(){}; function(){} } f() Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.ir.Symbol.getFirstSlot(Symbol.java:545) at jdk.nashorn.internal.codegen.MethodEmitter.markDeadLocalVariable(MethodEmitter.java:1149) at jdk.nashorn.internal.codegen.MethodEmitter.store(MethodEmitter.java:1202) at jdk.nashorn.internal.codegen.CodeGenerator.storeIdentWithCatchConversion(CodeGenerator.java:3201) at jdk.nashorn.internal.codegen.CodeGenerator.enterVarNode(CodeGenerator.java:3161) at jdk.nashorn.internal.ir.VarNode.accept(VarNode.java:171) at jdk.nashorn.internal.ir.Node.accept(Node.java:265) at jdk.nashorn.internal.ir.Block.accept(Block.java:178) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:425) ... jjs> try { false.constructor = 0 } catch(e) { e.printStackTrace() } java.lang.invoke.WrongMethodTypeException: Parameter counts differ: (Object)Object vs. (Object,int)Object at jdk.internal.dynalink.support.TypeConverterFactory.asType(TypeConverterFactory.java:236) at jdk.internal.dynalink.support.LinkerServicesImpl.asType(LinkerServicesImpl.java:126) at jdk.internal.dynalink.linker.LinkerServices$Implementation.asTypeLosslessReturn(LinkerServices.java:197) at jdk.internal.dynalink.support.LinkerServicesImpl.asTypeLosslessReturn(LinkerServicesImpl.java:131) at jdk.internal.dynalink.linker.GuardedInvocation.asTypeSafeReturn(GuardedInvocation.java:340) at jdk.nashorn.internal.runtime.linker.Bootstrap.asTypeSafeReturn(Bootstrap.java:429) at jdk.nashorn.internal.runtime.linker.NashornPrimitiveLinker.getGuardedInvocation(NashornPrimitiveLinker.java:70) at jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176) at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:149) ... jjs> function f() { var x; (x -= x = 0); } f() Exception in thread "main" java.lang.AssertionError: Attempted load of uninitialized slot 1 (as type int) at jdk.nashorn.internal.codegen.MethodEmitter.load(MethodEmitter.java:993) at jdk.nashorn.internal.codegen.MethodEmitter.load(MethodEmitter.java:955) at jdk.nashorn.internal.codegen.MethodEmitter.load(MethodEmitter.java:937) at jdk.nashorn.internal.codegen.CodeGenerator.loadIdent(CodeGenerator.java:318) at jdk.nashorn.internal.codegen.CodeGenerator.access$400(CodeGenerator.java:183) at jdk.nashorn.internal.codegen.CodeGenerator$1.enterIdentNode(CodeGenerator.java:725) at jdk.nashorn.internal.ir.IdentNode.accept(IdentNode.java:138) at jdk.nashorn.internal.codegen.CodeGenerator.loadExpression(CodeGenerator.java:722) at jdk.nashorn.internal.codegen.CodeGenerator.loadBinaryOperands(CodeGenerator.java:590) at jdk.nashorn.internal.codegen.CodeGenerator.access$6800(CodeGenerator.java:183) ... jjs> (function x(x){}) Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.codegen.AssignSymbols.enterFunctionBody(AssignSymbols.java:494) at jdk.nashorn.internal.codegen.AssignSymbols.enterBlock(AssignSymbols.java:453) at jdk.nashorn.internal.ir.Block.accept(Block.java:177) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:425) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:384) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:47) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:59) at jdk.nashorn.internal.ir.BinaryNode.accept(BinaryNode.java:347) ... jjs> function f() { x; throw null; (function (){ var x; }); } f() Exception in thread "main" java.lang.AssertionError: Couldn't find scope depth for symbol x in [object] function {U%}f() at jdk.nashorn.internal.codegen.CodeGenerator.loadFastScopeProto(CodeGenerator.java:516) at jdk.nashorn.internal.codegen.CodeGenerator.access$100(CodeGenerator.java:183) at jdk.nashorn.internal.codegen.CodeGenerator$LoadFastScopeVar.getProto(CodeGenerator.java:483) at jdk.nashorn.internal.codegen.CodeGenerator$LoadScopeVar.loadStack(CodeGenerator.java:456) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4407) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4392) at jdk.nashorn.internal.codegen.CodeGenerator.loadIdent(CodeGenerator.java:331) at jdk.nashorn.internal.codegen.CodeGenerator.access$400(CodeGenerator.java:183) at jdk.nashorn.internal.codegen.CodeGenerator$1.enterIdentNode(CodeGenerator.java:725) at jdk.nashorn.internal.ir.IdentNode.accept(IdentNode.java:138) ... jjs> function f() { void null + 0; } f() Exception in thread "main" java.lang.AssertionError: object at jdk.nashorn.internal.codegen.CodeGenerator$TypeBounds.(CodeGenerator.java:627) at jdk.nashorn.internal.codegen.CodeGenerator$TypeBounds.maybeNew(CodeGenerator.java:650) at jdk.nashorn.internal.codegen.CodeGenerator$TypeBounds.notNarrowerThan(CodeGenerator.java:635) at jdk.nashorn.internal.codegen.CodeGenerator.loadBinaryOperands(CodeGenerator.java:575) at jdk.nashorn.internal.codegen.CodeGenerator.access$6800(CodeGenerator.java:183) at jdk.nashorn.internal.codegen.CodeGenerator$14.loadStack(CodeGenerator.java:3575) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4407) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4392) at jdk.nashorn.internal.codegen.CodeGenerator.loadADD(CodeGenerator.java:3582) at jdk.nashorn.internal.codegen.CodeGenerator$1.enterADD(CodeGenerator.java:872) ... jjs> function f() { var x; x += void x; } f() Exception in thread "main" java.lang.AssertionError: object at jdk.nashorn.internal.codegen.CodeGenerator$TypeBounds.(CodeGenerator.java:627) at jdk.nashorn.internal.codegen.CodeGenerator$TypeBounds.maybeNew(CodeGenerator.java:650) at jdk.nashorn.internal.codegen.CodeGenerator$TypeBounds.notNarrowerThan(CodeGenerator.java:635) at jdk.nashorn.internal.codegen.CodeGenerator.loadBinaryOperands(CodeGenerator.java:575) at jdk.nashorn.internal.codegen.CodeGenerator.access$6800(CodeGenerator.java:183) at jdk.nashorn.internal.codegen.CodeGenerator$BinaryOptimisticSelfAssignment$1.loadStack(CodeGenerator.java:3700) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4407) at jdk.nashorn.internal.codegen.CodeGenerator$BinaryOptimisticSelfAssignment.evaluate(CodeGenerator.java:3706) at jdk.nashorn.internal.codegen.CodeGenerator$Store.store(CodeGenerator.java:4286) at jdk.nashorn.internal.codegen.CodeGenerator.loadASSIGN_ADD(CodeGenerator.java:3735) ... jjs> function f(){ var a = true + x, x; } f() Exception in thread "main" java.lang.AssertionError: object at jdk.nashorn.internal.codegen.CodeGenerator$TypeBounds.(CodeGenerator.java:627) at jdk.nashorn.internal.codegen.CodeGenerator$TypeBounds.maybeNew(CodeGenerator.java:650) at jdk.nashorn.internal.codegen.CodeGenerator$TypeBounds.notNarrowerThan(CodeGenerator.java:635) at jdk.nashorn.internal.codegen.CodeGenerator.loadBinaryOperands(CodeGenerator.java:575) at jdk.nashorn.internal.codegen.CodeGenerator.access$6800(CodeGenerator.java:183) at jdk.nashorn.internal.codegen.CodeGenerator$14.loadStack(CodeGenerator.java:3575) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4407) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4392) at jdk.nashorn.internal.codegen.CodeGenerator.loadADD(CodeGenerator.java:3582) at jdk.nashorn.internal.codegen.CodeGenerator$1.enterADD(CodeGenerator.java:872) ... jjs> function f(){ try { Object; } catch(x if x >>>=0) { throw x2; } finally { } } f() Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.ir.Symbol.getSlot(Symbol.java:563) at jdk.nashorn.internal.codegen.MethodEmitter.load(MethodEmitter.java:953) at jdk.nashorn.internal.codegen.MethodEmitter.emitLocalVariableConversion(MethodEmitter.java:2519) at jdk.nashorn.internal.codegen.MethodEmitter.beforeJoinPoint(MethodEmitter.java:2492) at jdk.nashorn.internal.codegen.CodeGenerator.enterThrowNode(CodeGenerator.java:2981) at jdk.nashorn.internal.ir.ThrowNode.accept(ThrowNode.java:80) at jdk.nashorn.internal.ir.Node.accept(Node.java:265) at jdk.nashorn.internal.ir.Block.accept(Block.java:178) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:425) ... jjs> function f(){ try { return; } catch(x) { return x ^= 0; } finally { throw 0; } } f() Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.ir.Symbol.getSlot(Symbol.java:555) at jdk.nashorn.internal.codegen.MethodEmitter.load(MethodEmitter.java:953) at jdk.nashorn.internal.codegen.MethodEmitter.emitLocalVariableConversion(MethodEmitter.java:2519) at jdk.nashorn.internal.codegen.MethodEmitter.beforeJoinPoint(MethodEmitter.java:2492) at jdk.nashorn.internal.codegen.CodeGenerator.enterThrowNode(CodeGenerator.java:2981) at jdk.nashorn.internal.ir.ThrowNode.accept(ThrowNode.java:80) at jdk.nashorn.internal.ir.Node.accept(Node.java:265) at jdk.nashorn.internal.ir.Block.accept(Block.java:178) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:425) ... jjs> function f(){ try { return; } catch(x) { return x ^= Object; } finally { throw Object; } } f() Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.ir.Symbol.getSlot(Symbol.java:558) at jdk.nashorn.internal.codegen.MethodEmitter.load(MethodEmitter.java:953) at jdk.nashorn.internal.codegen.MethodEmitter.emitLocalVariableConversion(MethodEmitter.java:2519) at jdk.nashorn.internal.codegen.MethodEmitter.beforeJoinPoint(MethodEmitter.java:2492) at jdk.nashorn.internal.codegen.CodeGenerator.enterThrowNode(CodeGenerator.java:2981) at jdk.nashorn.internal.ir.ThrowNode.accept(ThrowNode.java:80) at jdk.nashorn.internal.ir.Node.accept(Node.java:265) at jdk.nashorn.internal.ir.Block.accept(Block.java:178) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:425) ... jjs> function f() { try { undefined } catch(x1) { try { undefined } catch(x2) { x1 = 0; } } } f() Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.ir.Symbol.getSlot(Symbol.java:558) at jdk.nashorn.internal.codegen.MethodEmitter.load(MethodEmitter.java:953) at jdk.nashorn.internal.codegen.MethodEmitter.emitLocalVariableConversion(MethodEmitter.java:2519) at jdk.nashorn.internal.codegen.MethodEmitter.beforeJoinPoint(MethodEmitter.java:2492) at jdk.nashorn.internal.codegen.CodeGenerator.leaveBlock(CodeGenerator.java:1126) at jdk.nashorn.internal.ir.Block.accept(Block.java:178) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:425) at jdk.nashorn.internal.codegen.CodeGenerator.enterTryNode(CodeGenerator.java:3088) at jdk.nashorn.internal.ir.TryNode.accept(TryNode.java:110) ... jjs> function f() { try{ undefined } catch(e if 1) {} } f() Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.codegen.Label$Stack.defineBlockLocalVariable(Label.java:379) at jdk.nashorn.internal.codegen.MethodEmitter.defineBlockLocalVariable(MethodEmitter.java:1274) at jdk.nashorn.internal.codegen.CodeGeneratorLexicalContext.assignSlots(CodeGeneratorLexicalContext.java:242) at jdk.nashorn.internal.codegen.CodeGeneratorLexicalContext.onEnterBlock(CodeGeneratorLexicalContext.java:210) at jdk.nashorn.internal.codegen.CodeGenerator.initLocals(CodeGenerator.java:1671) at jdk.nashorn.internal.codegen.CodeGenerator.enterBlock(CodeGenerator.java:1113) at jdk.nashorn.internal.codegen.CodeGenerator.enterTryNode(CodeGenerator.java:3045) at jdk.nashorn.internal.ir.TryNode.accept(TryNode.java:110) at jdk.nashorn.internal.ir.Node.accept(Node.java:265) at jdk.nashorn.internal.ir.Block.accept(Block.java:178) ... jjs> function f() { try { undefined } catch(x1 if Object) { } catch(x2) { (function(){x2}) } } f() Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.codegen.CodeGenerator.enterBlock(CodeGenerator.java:1115) at jdk.nashorn.internal.codegen.CodeGenerator.enterTryNode(CodeGenerator.java:3045) at jdk.nashorn.internal.ir.TryNode.accept(TryNode.java:110) at jdk.nashorn.internal.ir.Node.accept(Node.java:265) at jdk.nashorn.internal.ir.Block.accept(Block.java:178) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:425) at jdk.nashorn.internal.codegen.CodeGenerator.enterBlockStatement(CodeGenerator.java:1583) at jdk.nashorn.internal.ir.BlockStatement.accept(BlockStatement.java:86) at jdk.nashorn.internal.ir.Node.accept(Node.java:265) ... jjs> function f() { try { undefined } catch(x4) { var x4; } finally { eval() } } f() Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.codegen.CodeGenerator.initLocals(CodeGenerator.java:1716) at jdk.nashorn.internal.codegen.CodeGenerator.enterBlock(CodeGenerator.java:1113) at jdk.nashorn.internal.ir.Block.accept(Block.java:177) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:425) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:384) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:47) at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:59) at jdk.nashorn.internal.codegen.CompilationPhase.transformFunction(CompilationPhase.java:732) ... jjs> Function("L:with(Object in Object)break L;\n{}")() Exception in thread "main" java.lang.ClassFormatError: Invalid pc in LineNumberTable in class file jdk/nashorn/internal/scripts/Script$Recompilation$6$1$\^function\_ at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:760) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at jdk.nashorn.internal.runtime.ScriptLoader.installClass(ScriptLoader.java:74) at jdk.nashorn.internal.runtime.Context$ContextCodeInstaller.install(Context.java:183) at jdk.nashorn.internal.codegen.CompilationPhase$14.transform(CompilationPhase.java:556) at jdk.nashorn.internal.codegen.CompilationPhase.apply(CompilationPhase.java:728) at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:620) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.compileTypeSpecialization(RecompilableScriptFunctionData.java:513) at jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.getBest(RecompilableScriptFunctionData.java:730) ... jjs> function f() { L: {this = x;break L}} f() Exception in thread "main" java.lang.VerifyError: StackMapTable error: bad offset Exception Details: Location: jdk/nashorn/internal/scripts/Script$Recompilation$4$1$\^shell\_.f(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; @0: aload_0 Reason: Invalid stackmap specification. Current Frame: bci: @21 flags: { } locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject' } stack: { } Bytecode: 0x0000000: 2ab6 0014 4d2b 2cba 0020 0000 1222 b800 0x0000010: 2857 a700 03 Stackmap Table: append_frame(@21,Object[#48]) jjs> function f(){ L:with(this--)break L; } f() Exception in thread "main" java.lang.VerifyError: StackMapTable error: bad offset Exception Details: Location: jdk/nashorn/internal/scripts/Script$Recompilation$4$\^shell\_.f(Ljava/lang/Object;)Ljava/lang/Object; @0: aload_0 Reason: Invalid stackmap specification. Current Frame: bci: @13 flags: { } locals: { 'java/lang/Object' } stack: { } Bytecode: 0x0000000: 2a01 1210 b800 16b8 001c a700 03 Stackmap Table: same_frame(@13) jjs> function f(){ L:with(Object in Object) break L; } f() Exception in thread "main" java.lang.VerifyError: StackMapTable error: bad offset Exception Details: Location: jdk/nashorn/internal/scripts/Script$Recompilation$4$\^shell\_.f(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; @0: aload_0 Reason: Invalid stackmap specification. Current Frame: bci: @42 flags: { } locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject' } stack: { } Bytecode: 0x0000000: 2ab6 0014 4d2c 2cba 0020 0000 2cba 0020 0x0000010: 0000 b800 26b8 002c b800 304d 2cb6 0035 0x0000020: 4da7 0009 2cb6 0035 4dbf Exception Handler Table: bci [28, 36] => handler: 36 Stackmap Table: full_frame(@36,{Object[#16],Object[#61],Object[#50]},{Object[#63]}) same_frame(@42) ---- Note: Only reproducible with jdk9-dev-nashorn. jjs> try { function f() { eval("get, a") } f() } catch (e) { e.printStackTrace() } jdk.nashorn.internal.runtime.ParserException: #1:21:1:3 Expected ident but found , get, a ^ at jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:292) at jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:277) at jdk.nashorn.internal.parser.AbstractParser.expectDontAdvance(AbstractParser.java:348) at jdk.nashorn.internal.parser.AbstractParser.expect(AbstractParser.java:335) at jdk.nashorn.internal.parser.AbstractParser.getIdentifierName(AbstractParser.java:486) at jdk.nashorn.internal.parser.Parser.propertyName(Parser.java:2228) at jdk.nashorn.internal.parser.Parser.propertyGetterFunction(Parser.java:2294) at jdk.nashorn.internal.parser.Parser.statement(Parser.java:966) at jdk.nashorn.internal.parser.Parser.sourceElements(Parser.java:787) at jdk.nashorn.internal.parser.Parser.program(Parser.java:712) ... jjs> function f(){ L: ({ set prop(){0 = null} }); } Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.parser.ParserContext.pop(ParserContext.java:91) at jdk.nashorn.internal.parser.Parser.functionExpression(Parser.java:2677) at jdk.nashorn.internal.parser.Parser.statement(Parser.java:887) at jdk.nashorn.internal.parser.Parser.sourceElements(Parser.java:787) at jdk.nashorn.internal.parser.Parser.program(Parser.java:712) at jdk.nashorn.internal.parser.Parser.parse(Parser.java:281) at jdk.nashorn.internal.parser.Parser.parse(Parser.java:247) at jdk.nashorn.internal.runtime.Context.compile(Context.java:1207) at jdk.nashorn.internal.runtime.Context.eval(Context.java:671) at jdk.nashorn.internal.runtime.Context.eval(Context.java:641) ... jjs> function f() { do ; while({ get x()1-- }); } Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.parser.ParserContext.pop(ParserContext.java:91) at jdk.nashorn.internal.parser.Parser.functionExpression(Parser.java:2677) at jdk.nashorn.internal.parser.Parser.statement(Parser.java:887) at jdk.nashorn.internal.parser.Parser.sourceElements(Parser.java:787) at jdk.nashorn.internal.parser.Parser.program(Parser.java:712) at jdk.nashorn.internal.parser.Parser.parse(Parser.java:281) at jdk.nashorn.internal.parser.Parser.parse(Parser.java:247) at jdk.nashorn.internal.runtime.Context.compile(Context.java:1207) at jdk.nashorn.internal.runtime.Context.eval(Context.java:671) at jdk.nashorn.internal.runtime.Context.eval(Context.java:641) ... jjs> function f() { (x+=void x); } f() Exception in thread "main" java.lang.AssertionError: object at jdk.nashorn.internal.codegen.CodeGenerator$TypeBounds.(CodeGenerator.java:627) at jdk.nashorn.internal.codegen.CodeGenerator$TypeBounds.maybeNew(CodeGenerator.java:650) at jdk.nashorn.internal.codegen.CodeGenerator$TypeBounds.notNarrowerThan(CodeGenerator.java:635) at jdk.nashorn.internal.codegen.CodeGenerator.loadBinaryOperands(CodeGenerator.java:575) at jdk.nashorn.internal.codegen.CodeGenerator.access$6800(CodeGenerator.java:183) at jdk.nashorn.internal.codegen.CodeGenerator$BinaryOptimisticSelfAssignment$1.loadStack(CodeGenerator.java:3700) at jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4407) at jdk.nashorn.internal.codegen.CodeGenerator$BinaryOptimisticSelfAssignment.evaluate(CodeGenerator.java:3706) at jdk.nashorn.internal.codegen.CodeGenerator$Store.store(CodeGenerator.java:4286) at jdk.nashorn.internal.codegen.CodeGenerator.loadASSIGN_ADD(CodeGenerator.java:3735) ... jjs> function f() { try { Object } catch(x) { (x=y); return; } finally { throw Object; } } f() Exception in thread "main" java.lang.AssertionError at jdk.nashorn.internal.ir.Symbol.getSlot(Symbol.java:558) at jdk.nashorn.internal.codegen.MethodEmitter.load(MethodEmitter.java:953) at jdk.nashorn.internal.codegen.MethodEmitter.emitLocalVariableConversion(MethodEmitter.java:2519) at jdk.nashorn.internal.codegen.MethodEmitter.beforeJoinPoint(MethodEmitter.java:2492) at jdk.nashorn.internal.codegen.CodeGenerator.enterThrowNode(CodeGenerator.java:2981) at jdk.nashorn.internal.ir.ThrowNode.accept(ThrowNode.java:80) at jdk.nashorn.internal.ir.Node.accept(Node.java:265) at jdk.nashorn.internal.ir.Block.accept(Block.java:178) at jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) at jdk.nashorn.internal.ir.Block.accept(Block.java:425) ... From mandy.chung at oracle.com Sat Nov 29 01:32:00 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 28 Nov 2014 17:32:00 -0800 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <54785160.3070501@oracle.com> References: <54785160.3070501@oracle.com> Message-ID: <54792210.70704@oracle.com> Hi Sundar, On 11/28/2014 2:41 AM, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8066146 Is jdk.nashorn.api.scripting a supported API? It looks like some classes are defined for JEP 202 [1] and is the entire package new in 8u40 and 9? @since is missing in the javadoc and I can't tell for sure. If supported, this should be declared in /modules.xml: jdk.scripting.nashorn java.base java.logging java.scripting jdk.nashorn.api.scripting JDK-8066146 is a build change. Probably best to file a new bug to follow up missing @since and modules.xml change? thanks Mandy [1] http://openjdk.java.net/jeps/202 From magnus.ihse.bursie at oracle.com Fri Nov 28 23:33:48 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 29 Nov 2014 00:33:48 +0100 Subject: RFR 8066146: jdk.nashorn.api.scripting package javadoc should be included in jdk docs In-Reply-To: <54785160.3070501@oracle.com> References: <54785160.3070501@oracle.com> Message-ID: <5479065C.2090302@oracle.com> On 2014-11-28 11:41, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8066146/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8066146 > > Thanks, > -Sundar Is it by intention that you do not add $(NASHORNAPI_PKGS) to NON_CORE_PKGS? /Magnus