From nilskp at gmail.com Sun Dec 3 17:02:10 2017 From: nilskp at gmail.com (Nils Kilden-Pedersen) Date: Sun, 3 Dec 2017 11:02:10 -0600 Subject: Changes in Java 9 Message-ID: I just switched to the Java 9.0.1 runtime, and Nashorn now fails to parse the Coffeescript compiler, which worked fine in Java 8_144. Coffeescript 2 compiler: http://coffeescript.org/v2/browser-compiler/coffeescript.js v1 also fails: http://coffeescript.org/v1/browser-compiler/coffee-script.js Exception is: javax.script.ScriptException: SyntaxError: unexpected in at line number 39 at column number 249736 at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:469) at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:425) at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.access$300(NashornScriptEngine.java:72) at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine$3.eval(NashornScriptEngine.java:513) at java.scripting/javax.script.CompiledScript.eval(CompiledScript.java:92) at scuff.js.CoffeeScriptCompiler.compile(CoffeeScriptCompiler.scala:115) at scuff.js.TestCoffeeScriptCompiler.cs2(TestCoffeeScriptCompiler.scala:114) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207) Caused by: :39:249736 SyntaxError: unexpected at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeError.initException(NativeError.java:135) at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyntaxError.(NativeSyntaxError.java:73) at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyntaxError.(NativeSyntaxError.java:77) at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyntaxError.constructor(NativeSyntaxError.java:98) at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2368$6956AA$\^eval\_.L:39-1#a#L:39-1#L:39#throwSyntaxError(:39) at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2364$253073AA$\^eval\_$cu1$restOf.L:39-1#a#L:39-8#L:39#parseError(:39) at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2359$\^eval\_$cu1$restOf.L:39-1#a#L:39-4#o#parse(:39) at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2343$\^eval\_$cu1$restOf.L:39-1#a#L:39-8#L:39#p(:39) at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2056$250675AA$\^eval\_.L:39-1#a#L:39-8#L:39#T#L:39(:39) at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$1572$\^eval\_.:program(:41) at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:652) at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513) at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:517) at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:420) ... 28 more ? From nilskp at gmail.com Sun Dec 3 19:39:10 2017 From: nilskp at gmail.com (Nils Kilden-Pedersen) Date: Sun, 3 Dec 2017 13:39:10 -0600 Subject: Changes in Java 9 In-Reply-To: References: Message-ID: Further testing with the un-minified code (cs2 , cs1 ) reveals the true problems in JDK 9.0.1 In cs2, it?s ES6 syntax (default args), which (unexpectedly for me at least), works in JDK 8: :46:45 Expected , but found = CoffeeScript.eval = function(code, options = {}) { ^ in at line number 46 at column number 45 And in cs1 it?s require that?s unresolved (also works in JDK 8): ReferenceError: "require" is not defined in at line number 7 ? On Sun, Dec 3, 2017 at 11:02 AM, Nils Kilden-Pedersen wrote: > I just switched to the Java 9.0.1 runtime, and Nashorn now fails to parse > the Coffeescript compiler, which worked fine in Java 8_144. > > Coffeescript 2 compiler: http://coffeescript.org/v2/ > browser-compiler/coffeescript.js > > v1 also fails: http://coffeescript.org/v1/browser-compiler/coffee- > script.js > > Exception is: > > javax.script.ScriptException: SyntaxError: unexpected in at line number 39 at column number 249736 > at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:469) > at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:425) > at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.access$300(NashornScriptEngine.java:72) > at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine$3.eval(NashornScriptEngine.java:513) > at java.scripting/javax.script.CompiledScript.eval(CompiledScript.java:92) > at scuff.js.CoffeeScriptCompiler.compile(CoffeeScriptCompiler.scala:115) > at scuff.js.TestCoffeeScriptCompiler.cs2(TestCoffeeScriptCompiler.scala:114) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207) > Caused by: :39:249736 SyntaxError: unexpected > at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeError.initException(NativeError.java:135) > at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyntaxError.(NativeSyntaxError.java:73) > at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyntaxError.(NativeSyntaxError.java:77) > at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyntaxError.constructor(NativeSyntaxError.java:98) > at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2368$6956AA$\^eval\_.L:39-1#a#L:39-1#L:39#throwSyntaxError(:39) > at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2364$253073AA$\^eval\_$cu1$restOf.L:39-1#a#L:39-8#L:39#parseError(:39) > at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2359$\^eval\_$cu1$restOf.L:39-1#a#L:39-4#o#parse(:39) > at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2343$\^eval\_$cu1$restOf.L:39-1#a#L:39-8#L:39#p(:39) > at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2056$250675AA$\^eval\_.L:39-1#a#L:39-8#L:39#T#L:39(:39) > at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$1572$\^eval\_.:program(:41) > at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:652) > at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513) > at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:517) > at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:420) > ... 28 more > > ? > From nilskp at gmail.com Sun Dec 3 20:08:24 2017 From: nilskp at gmail.com (Nils Kilden-Pedersen) Date: Sun, 3 Dec 2017 14:08:24 -0600 Subject: Changes in Java 9 In-Reply-To: References: Message-ID: Ok, the minified vs non-minified may not be identical. I cannot find the default parameters in the minified version, so perhaps those are removed. What does remain however, is that I can compile minified cs2 on JDK 8_144, but not on 9.0.1. On Sun, Dec 3, 2017 at 1:39 PM, Nils Kilden-Pedersen wrote: > Further testing with the un-minified code (cs2 > , cs1 > ) > reveals the true problems in JDK 9.0.1 > > In cs2, it?s ES6 syntax (default args), which (unexpectedly for me at > least), works in JDK 8: > > :46:45 Expected , but found = > CoffeeScript.eval = function(code, options = {}) { > ^ in at line number 46 at column number 45 > > And in cs1 it?s require that?s unresolved (also works in JDK 8): > > ReferenceError: "require" is not defined in at line number 7 > > ? > > On Sun, Dec 3, 2017 at 11:02 AM, Nils Kilden-Pedersen > wrote: > >> I just switched to the Java 9.0.1 runtime, and Nashorn now fails to parse >> the Coffeescript compiler, which worked fine in Java 8_144. >> >> Coffeescript 2 compiler: http://coffeescript.org/v2/bro >> wser-compiler/coffeescript.js >> >> v1 also fails: http://coffeescript.org/v1/bro >> wser-compiler/coffee-script.js >> >> Exception is: >> >> javax.script.ScriptException: SyntaxError: unexpected in at line number 39 at column number 249736 >> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:469) >> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:425) >> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.access$300(NashornScriptEngine.java:72) >> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine$3.eval(NashornScriptEngine.java:513) >> at java.scripting/javax.script.CompiledScript.eval(CompiledScript.java:92) >> at scuff.js.CoffeeScriptCompiler.compile(CoffeeScriptCompiler.scala:115) >> at scuff.js.TestCoffeeScriptCompiler.cs2(TestCoffeeScriptCompiler.scala:114) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) >> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) >> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) >> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) >> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539) >> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761) >> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461) >> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207) >> Caused by: :39:249736 SyntaxError: unexpected >> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeError.initException(NativeError.java:135) >> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyntaxError.(NativeSyntaxError.java:73) >> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyntaxError.(NativeSyntaxError.java:77) >> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyntaxError.constructor(NativeSyntaxError.java:98) >> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2368$6956AA$\^eval\_.L:39-1#a#L:39-1#L:39#throwSyntaxError(:39) >> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2364$253073AA$\^eval\_$cu1$restOf.L:39-1#a#L:39-8#L:39#parseError(:39) >> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2359$\^eval\_$cu1$restOf.L:39-1#a#L:39-4#o#parse(:39) >> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2343$\^eval\_$cu1$restOf.L:39-1#a#L:39-8#L:39#p(:39) >> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2056$250675AA$\^eval\_.L:39-1#a#L:39-8#L:39#T#L:39(:39) >> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$1572$\^eval\_.:program(:41) >> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:652) >> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513) >> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:517) >> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:420) >> ... 28 more >> >> ? >> > > From szegedia at gmail.com Mon Dec 4 12:40:41 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 4 Dec 2017 13:40:41 +0100 Subject: Review request for JDK-8192970: Element getters/setters with fixed key fail to link properly Message-ID: <12B32E5E-8D86-4C89-96BD-135B108B7A6B@gmail.com> Please review JDK-8192970 "Element getters/setters with fixed key fail to link properly" at for Note that this is unrelated to the previous refactoring (8191878), it is present even before that and also in JDK9, I?ll have to separately produce a backport fix for it. I discovered this while trying to expand the test coverage (and good thing that I did, too?) The gist of the problem is that convertArgToNumber as it was before will fail with IndexOutOfBoundsException invoking parameterType(1) on method type for fixed-key getters, as they only have one parameter at index 0. The fix is to move the logic into the Binder and use the methodType it manages, not the call site method type. This works because Binder always works with a method type as if the getter/setter were variable-key (it adds back the parameter type in its constructor if the operation is for a fixed key). Thanks, Attila. From hannes.wallnoefer at oracle.com Mon Dec 4 14:47:19 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 4 Dec 2017 15:47:19 +0100 Subject: Changes in Java 9 In-Reply-To: References: Message-ID: <97A626A8-3712-4C6D-B44C-82D76923AEFA@oracle.com> Hi Nils, Are you just evaluating the script files you linked in your first message, or trying to do some further processing? Using the jjs tool from JDK 9.0.1 I see no errors running both versions of CoffeeScript. Hannes > Am 03.12.2017 um 21:08 schrieb Nils Kilden-Pedersen : > > Ok, the minified vs non-minified may not be identical. I cannot find the > default parameters in the minified version, so perhaps those are removed. > > What does remain however, is that I can compile minified cs2 > on JDK 8_144, > but not on 9.0.1. > > > On Sun, Dec 3, 2017 at 1:39 PM, Nils Kilden-Pedersen > wrote: > >> Further testing with the un-minified code (cs2 >> , cs1 >> ) >> reveals the true problems in JDK 9.0.1 >> >> In cs2, it?s ES6 syntax (default args), which (unexpectedly for me at >> least), works in JDK 8: >> >> :46:45 Expected , but found = >> CoffeeScript.eval = function(code, options = {}) { >> ^ in at line number 46 at column number 45 >> >> And in cs1 it?s require that?s unresolved (also works in JDK 8): >> >> ReferenceError: "require" is not defined in at line number 7 >> >> ? >> >> On Sun, Dec 3, 2017 at 11:02 AM, Nils Kilden-Pedersen >> wrote: >> >>> I just switched to the Java 9.0.1 runtime, and Nashorn now fails to parse >>> the Coffeescript compiler, which worked fine in Java 8_144. >>> >>> Coffeescript 2 compiler: http://coffeescript.org/v2/bro >>> wser-compiler/coffeescript.js >>> >>> v1 also fails: http://coffeescript.org/v1/bro >>> wser-compiler/coffee-script.js >>> >>> Exception is: >>> >>> javax.script.ScriptException: SyntaxError: unexpected in at line number 39 at column number 249736 >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:469) >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:425) >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.access$300(NashornScriptEngine.java:72) >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine$3.eval(NashornScriptEngine.java:513) >>> at java.scripting/javax.script.CompiledScript.eval(CompiledScript.java:92) >>> at scuff.js.CoffeeScriptCompiler.compile(CoffeeScriptCompiler.scala:115) >>> at scuff.js.TestCoffeeScriptCompiler.cs2(TestCoffeeScriptCompiler.scala:114) >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >>> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) >>> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) >>> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) >>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >>> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) >>> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) >>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539) >>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761) >>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461) >>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207) >>> Caused by: :39:249736 SyntaxError: unexpected >>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeError.initException(NativeError.java:135) >>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyntaxError.(NativeSyntaxError.java:73) >>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyntaxError.(NativeSyntaxError.java:77) >>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyntaxError.constructor(NativeSyntaxError.java:98) >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2368$6956AA$\^eval\_.L:39-1#a#L:39-1#L:39#throwSyntaxError(:39) >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2364$253073AA$\^eval\_$cu1$restOf.L:39-1#a#L:39-8#L:39#parseError(:39) >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2359$\^eval\_$cu1$restOf.L:39-1#a#L:39-4#o#parse(:39) >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2343$\^eval\_$cu1$restOf.L:39-1#a#L:39-8#L:39#p(:39) >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$2056$250675AA$\^eval\_.L:39-1#a#L:39-8#L:39#T#L:39(:39) >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$1572$\^eval\_.:program(:41) >>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:652) >>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513) >>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:517) >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:420) >>> ... 28 more >>> >>> ? >>> >> >> From hannes.wallnoefer at oracle.com Mon Dec 4 15:36:43 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 4 Dec 2017 16:36:43 +0100 Subject: Review request for JDK-8192970: Element getters/setters with fixed key fail to link properly In-Reply-To: <12B32E5E-8D86-4C89-96BD-135B108B7A6B@gmail.com> References: <12B32E5E-8D86-4C89-96BD-135B108B7A6B@gmail.com> Message-ID: <3FCD6615-2D4F-4F4E-9AAD-D9A50520170C@oracle.com> Took me some time to spot the difference in behaviour (adaptation of method type in Binder)! +1 Hannes > Am 04.12.2017 um 13:40 schrieb Attila Szegedi : > > Please review JDK-8192970 "Element getters/setters with fixed key fail to link properly" at for > > Note that this is unrelated to the previous refactoring (8191878), it is present even before that and also in JDK9, I?ll have to separately produce a backport fix for it. I discovered this while trying to expand the test coverage (and good thing that I did, too?) > > The gist of the problem is that convertArgToNumber as it was before will fail with IndexOutOfBoundsException invoking parameterType(1) on method type for fixed-key getters, as they only have one parameter at index 0. > > The fix is to move the logic into the Binder and use the methodType it manages, not the call site method type. This works because Binder always works with a method type as if the getter/setter were variable-key (it adds back the parameter type in its constructor if the operation is for a fixed key). > > Thanks, > Attila. From nilskp at gmail.com Mon Dec 4 15:56:45 2017 From: nilskp at gmail.com (Nils Kilden-Pedersen) Date: Mon, 4 Dec 2017 09:56:45 -0600 Subject: Changes in Java 9 In-Reply-To: <97A626A8-3712-4C6D-B44C-82D76923AEFA@oracle.com> References: <97A626A8-3712-4C6D-B44C-82D76923AEFA@oracle.com> Message-ID: Thanks for bringing this up. It made me realize that my post was incomplete. These are the steps I take: 1. Initial step: Call engine.compile with the CS compiler source + CoffeeScript.compile(coffeeCode, {runtime: 'none'}); which returns CompiledScript that is retained and re-used. This works fine, also on JDK 9.0.1. 2. For subsequent Coffeescript -> Javascript transpilation, I then call engine.createBindings() 3. Then bindings.put("coffeeCode", csCode) to associate the CS code with the JS variable coffeeCode mentioned in initial step 4. Call CompiledScript.eval(bindings). This is the step that fails in 9.0.1. I?m open to better ways to achieve this, if it?s inefficient or plain wrong. ? On Mon, Dec 4, 2017 at 8:47 AM, Hannes Walln?fer < hannes.wallnoefer at oracle.com> wrote: > Hi Nils, > > Are you just evaluating the script files you linked in your first message, > or trying to do some further processing? > > Using the jjs tool from JDK 9.0.1 I see no errors running both versions of > CoffeeScript. > > Hannes > > > Am 03.12.2017 um 21:08 schrieb Nils Kilden-Pedersen : > > > > Ok, the minified vs non-minified may not be identical. I cannot find the > > default parameters in the minified version, so perhaps those are removed. > > > > What does remain however, is that I can compile minified cs2 > > on JDK > 8_144, > > but not on 9.0.1. > > > > > > On Sun, Dec 3, 2017 at 1:39 PM, Nils Kilden-Pedersen > > wrote: > > > >> Further testing with the un-minified code (cs2 > >> , cs1 > >> ) > >> reveals the true problems in JDK 9.0.1 > >> > >> In cs2, it?s ES6 syntax (default args), which (unexpectedly for me at > >> least), works in JDK 8: > >> > >> :46:45 Expected , but found = > >> CoffeeScript.eval = function(code, options = {}) { > >> ^ in at line number > 46 at column number 45 > >> > >> And in cs1 it?s require that?s unresolved (also works in JDK 8): > >> > >> ReferenceError: "require" is not defined in at line number 7 > >> > >> ? > >> > >> On Sun, Dec 3, 2017 at 11:02 AM, Nils Kilden-Pedersen > > >> wrote: > >> > >>> I just switched to the Java 9.0.1 runtime, and Nashorn now fails to > parse > >>> the Coffeescript compiler, which worked fine in Java 8_144. > >>> > >>> Coffeescript 2 compiler: http://coffeescript.org/v2/bro > >>> wser-compiler/coffeescript.js > >>> > >>> v1 also fails: http://coffeescript.org/v1/bro > >>> wser-compiler/coffee-script.js > >>> > >>> Exception is: > >>> > >>> javax.script.ScriptException: SyntaxError: unexpected in at > line number 39 at column number 249736 > >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting. > NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:469) > >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting. > NashornScriptEngine.evalImpl(NashornScriptEngine.java:425) > >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting. > NashornScriptEngine.access$300(NashornScriptEngine.java:72) > >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting. > NashornScriptEngine$3.eval(NashornScriptEngine.java:513) > >>> at java.scripting/javax.script.CompiledScript.eval( > CompiledScript.java:92) > >>> at scuff.js.CoffeeScriptCompiler.compile(CoffeeScriptCompiler. > scala:115) > >>> at scuff.js.TestCoffeeScriptCompiler.cs2(TestCoffeeScriptCompiler. > scala:114) > >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:62) > >>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. > invoke(DelegatingMethodAccessorImpl.java:43) > >>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) > >>> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall( > FrameworkMethod.java:50) > >>> at org.junit.internal.runners.model.ReflectiveCallable.run( > ReflectiveCallable.java:12) > >>> at org.junit.runners.model.FrameworkMethod.invokeExplosively( > FrameworkMethod.java:47) > >>> at org.junit.internal.runners.statements.InvokeMethod. > evaluate(InvokeMethod.java:17) > >>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild( > BlockJUnit4ClassRunner.java:78) > >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild( > BlockJUnit4ClassRunner.java:57) > >>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > >>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > >>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > >>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > >>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > >>> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run( > JUnit4TestReference.java:86) > >>> at org.eclipse.jdt.internal.junit.runner.TestExecution. > run(TestExecution.java:38) > >>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > runTests(RemoteTestRunner.java:539) > >>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > runTests(RemoteTestRunner.java:761) > >>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > run(RemoteTestRunner.java:461) > >>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner. > main(RemoteTestRunner.java:207) > >>> Caused by: :39:249736 SyntaxError: unexpected > >>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects. > NativeError.initException(NativeError.java:135) > >>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects. > NativeSyntaxError.(NativeSyntaxError.java:73) > >>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects. > NativeSyntaxError.(NativeSyntaxError.java:77) > >>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects. > NativeSyntaxError.constructor(NativeSyntaxError.java:98) > >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts. > Script$Recompilation$2368$6956AA$\^eval\_.L:39-1#a#L:39- > 1#L:39#throwSyntaxError(:39) > >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts. > Script$Recompilation$2364$253073AA$\^eval\_$cu1$restOf. > L:39-1#a#L:39-8#L:39#parseError(:39) > >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts. > Script$Recompilation$2359$\^eval\_$cu1$restOf.L:39-1#a#L: > 39-4#o#parse(:39) > >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts. > Script$Recompilation$2343$\^eval\_$cu1$restOf.L:39-1#a#L: > 39-8#L:39#p(:39) > >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts. > Script$Recompilation$2056$250675AA$\^eval\_.L:39-1#a#L: > 39-8#L:39#T#L:39(:39) > >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts. > Script$Recompilation$1572$\^eval\_.:program(:41) > >>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime. > ScriptFunctionData.invoke(ScriptFunctionData.java:652) > >>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime. > ScriptFunction.invoke(ScriptFunction.java:513) > >>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime. > ScriptRuntime.apply(ScriptRuntime.java:517) > >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting. > NashornScriptEngine.evalImpl(NashornScriptEngine.java:420) > >>> ... 28 more > >>> > >>> ? > >>> > >> > >> > > From szegedia at gmail.com Mon Dec 4 16:05:16 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 4 Dec 2017 17:05:16 +0100 Subject: Review request for JDK-8192970: Element getters/setters with fixed key fail to link properly In-Reply-To: <3FCD6615-2D4F-4F4E-9AAD-D9A50520170C@oracle.com> References: <12B32E5E-8D86-4C89-96BD-135B108B7A6B@gmail.com> <3FCD6615-2D4F-4F4E-9AAD-D9A50520170C@oracle.com> Message-ID: <20DA1C26-DC67-4565-A800-15E0FA844F7C@gmail.com> I know, it?s subtle; that?s why I decided to describe it in detail :-) > On 2017. Dec 4., at 16:36, Hannes Walln?fer wrote: > > Took me some time to spot the difference in behaviour (adaptation of method type in Binder)! > > +1 > > Hannes > >> Am 04.12.2017 um 13:40 schrieb Attila Szegedi : >> >> Please review JDK-8192970 "Element getters/setters with fixed key fail to link properly" at for >> >> Note that this is unrelated to the previous refactoring (8191878), it is present even before that and also in JDK9, I?ll have to separately produce a backport fix for it. I discovered this while trying to expand the test coverage (and good thing that I did, too?) >> >> The gist of the problem is that convertArgToNumber as it was before will fail with IndexOutOfBoundsException invoking parameterType(1) on method type for fixed-key getters, as they only have one parameter at index 0. >> >> The fix is to move the logic into the Binder and use the methodType it manages, not the call site method type. This works because Binder always works with a method type as if the getter/setter were variable-key (it adds back the parameter type in its constructor if the operation is for a fixed key). >> >> Thanks, >> Attila. > From hannes.wallnoefer at oracle.com Mon Dec 4 16:09:12 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Mon, 4 Dec 2017 17:09:12 +0100 Subject: Review request for JDK-8192970: Element getters/setters with fixed key fail to link properly In-Reply-To: <20DA1C26-DC67-4565-A800-15E0FA844F7C@gmail.com> References: <12B32E5E-8D86-4C89-96BD-135B108B7A6B@gmail.com> <3FCD6615-2D4F-4F4E-9AAD-D9A50520170C@oracle.com> <20DA1C26-DC67-4565-A800-15E0FA844F7C@gmail.com> Message-ID: <17900E04-8A48-478E-B34C-B7D8C58740DD@oracle.com> D'oh! I blindly clicked on that links of course :) > Am 04.12.2017 um 17:05 schrieb Attila Szegedi : > > I know, it?s subtle; that?s why I decided to describe it in detail :-) > >> On 2017. Dec 4., at 16:36, Hannes Walln?fer wrote: >> >> Took me some time to spot the difference in behaviour (adaptation of method type in Binder)! >> >> +1 >> >> Hannes >> >>> Am 04.12.2017 um 13:40 schrieb Attila Szegedi : >>> >>> Please review JDK-8192970 "Element getters/setters with fixed key fail to link properly" at for >>> >>> Note that this is unrelated to the previous refactoring (8191878), it is present even before that and also in JDK9, I?ll have to separately produce a backport fix for it. I discovered this while trying to expand the test coverage (and good thing that I did, too?) >>> >>> The gist of the problem is that convertArgToNumber as it was before will fail with IndexOutOfBoundsException invoking parameterType(1) on method type for fixed-key getters, as they only have one parameter at index 0. >>> >>> The fix is to move the logic into the Binder and use the methodType it manages, not the call site method type. This works because Binder always works with a method type as if the getter/setter were variable-key (it adds back the parameter type in its constructor if the operation is for a fixed key). >>> >>> Thanks, >>> Attila. >> > From priya.lakshmi.muthuswamy at oracle.com Tue Dec 5 06:13:56 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Tue, 5 Dec 2017 11:43:56 +0530 Subject: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements Message-ID: <03416610-734e-7207-7fde-caa1b64ec670@oracle.com> Hi, please review JDK-8191301 : JavaImporter fails to resolve imported elements within functions, that contain too many statements JBS : https://bugs.openjdk.java.net/browse/JDK-8191301 webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.00/ Thanks, Priya From szegedia at gmail.com Tue Dec 5 06:42:36 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 5 Dec 2017 07:42:36 +0100 Subject: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements In-Reply-To: <03416610-734e-7207-7fde-caa1b64ec670@oracle.com> References: <03416610-734e-7207-7fde-caa1b64ec670@oracle.com> Message-ID: <2CC9D6AB-B145-4409-80FD-8D68BDE5DDCE@gmail.com> Hm? this seems to be an issue with shared scope calls; that?s why it?s sensitive to the number of similar statements. That said, here?s some thoughts: 1. Instead of if (self instanceof ScriptObject && ((ScriptObject)self).hasWithScope()) { you should be able to just use if (self instanceof ScriptObject) { As then you?ll evaluate getWithScopeObject and test it for being null anyway. This way, you avoid walking the prototype chain twice. 2. That said, I guess hasWithScope could be reimplemented simply as public boolean hasWithScope() { return getWithScopeObject() != null; } as both have very similar code, so it?d reduce to it nicely. (I understand that you haven?t changed that, but since you were in the vicinity of that code, you might as wel do it? It?s also fine if you leave it alone as it is.) 3. One of the statements in the test is indented differently than the others. 4. What happens if there?s _two_ with scopes, and the JavaImporter is in the outer one? Does this fix still work? E.g.: var imports = new JavaImporter(java.lang); var dummy = { x: 42, y: 13 } with (imports) { with (dummy) { function func() { System.out.println('a'); System.out.println('a'); System.out.println('a'); System.out.println('a'); System.out.println('a'); System.out.println('a'); System.out.println('a'); }; func(); } } Attila. > On Dec 5, 2017, at 7:13 AM, Priya Lakshmi Muthuswamy wrote: > > Hi, > > please review JDK-8191301 : JavaImporter fails to resolve imported elements within functions, that contain too many statements > > JBS : https://bugs.openjdk.java.net/browse/JDK-8191301 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.00/ > > Thanks, > Priya > > From priya.lakshmi.muthuswamy at oracle.com Tue Dec 5 07:24:57 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Tue, 5 Dec 2017 12:54:57 +0530 Subject: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements In-Reply-To: <2CC9D6AB-B145-4409-80FD-8D68BDE5DDCE@gmail.com> References: <03416610-734e-7207-7fde-caa1b64ec670@oracle.com> <2CC9D6AB-B145-4409-80FD-8D68BDE5DDCE@gmail.com> Message-ID: <6c8580db-1d6c-7fe2-b333-d8ffb1193d1d@oracle.com> Hi Attila, Thanks for review. Yes when I checked with two with scopes as suggested(JavaImporter as outer), current fix doesn't work. I will work on that. Thanks, Priya On 12/5/2017 12:12 PM, Attila Szegedi wrote: > Hm? this seems to be an issue with shared scope calls; that?s why it?s sensitive to the number of similar statements. > > That said, here?s some thoughts: > > 1. Instead of > > if (self instanceof ScriptObject && ((ScriptObject)self).hasWithScope()) { > > you should be able to just use > > if (self instanceof ScriptObject) { > > As then you?ll evaluate getWithScopeObject and test it for being null anyway. This way, you avoid walking the prototype chain twice. > > 2. That said, I guess hasWithScope could be reimplemented simply as > > public boolean hasWithScope() { > return getWithScopeObject() != null; > } > > as both have very similar code, so it?d reduce to it nicely. (I understand that you haven?t changed that, but since you were in the vicinity of that code, you might as wel do it? It?s also fine if you leave it alone as it is.) > > 3. One of the statements in the test is indented differently than the others. > > 4. What happens if there?s _two_ with scopes, and the JavaImporter is in the outer one? Does this fix still work? E.g.: > > var imports = new JavaImporter(java.lang); > var dummy = { x: 42, y: 13 } > with (imports) { > with (dummy) { > function func() { > System.out.println('a'); > System.out.println('a'); > System.out.println('a'); > System.out.println('a'); > System.out.println('a'); > System.out.println('a'); > System.out.println('a'); > }; > func(); > } > } > > Attila. > >> On Dec 5, 2017, at 7:13 AM, Priya Lakshmi Muthuswamy wrote: >> >> Hi, >> >> please review JDK-8191301 : JavaImporter fails to resolve imported elements within functions, that contain too many statements >> >> JBS : https://bugs.openjdk.java.net/browse/JDK-8191301 >> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.00/ >> >> Thanks, >> Priya >> >> From nilskp at gmail.com Wed Dec 6 15:15:15 2017 From: nilskp at gmail.com (Nils Kilden-Pedersen) Date: Wed, 6 Dec 2017 09:15:15 -0600 Subject: Changes in Java 9 In-Reply-To: References: <97A626A8-3712-4C6D-B44C-82D76923AEFA@oracle.com> Message-ID: What's the right place to file a bug? On Mon, Dec 4, 2017 at 9:56 AM, Nils Kilden-Pedersen wrote: > Thanks for bringing this up. It made me realize that my post was > incomplete. > > These are the steps I take: > > 1. Initial step: Call engine.compile with the CS compiler source + > CoffeeScript.compile(coffeeCode, {runtime: 'none'}); which returns > CompiledScript that is retained and re-used. This works fine, also on > JDK 9.0.1. > 2. For subsequent Coffeescript -> Javascript transpilation, I then > call engine.createBindings() > 3. Then bindings.put("coffeeCode", csCode) to associate the CS code > with the JS variable coffeeCode mentioned in initial step > 4. Call CompiledScript.eval(bindings). This is the step that fails in > 9.0.1. > > I?m open to better ways to achieve this, if it?s inefficient or plain > wrong. > ? > > On Mon, Dec 4, 2017 at 8:47 AM, Hannes Walln?fer < > hannes.wallnoefer at oracle.com> wrote: > >> Hi Nils, >> >> Are you just evaluating the script files you linked in your first >> message, or trying to do some further processing? >> >> Using the jjs tool from JDK 9.0.1 I see no errors running both versions >> of CoffeeScript. >> >> Hannes >> >> > Am 03.12.2017 um 21:08 schrieb Nils Kilden-Pedersen : >> > >> > Ok, the minified vs non-minified may not be identical. I cannot find the >> > default parameters in the minified version, so perhaps those are >> removed. >> > >> > What does remain however, is that I can compile minified cs2 >> > on JDK >> 8_144, >> > but not on 9.0.1. >> > >> > >> > On Sun, Dec 3, 2017 at 1:39 PM, Nils Kilden-Pedersen >> > wrote: >> > >> >> Further testing with the un-minified code (cs2 >> >> , >> cs1 >> >> ) >> >> reveals the true problems in JDK 9.0.1 >> >> >> >> In cs2, it?s ES6 syntax (default args), which (unexpectedly for me at >> >> least), works in JDK 8: >> >> >> >> :46:45 Expected , but found = >> >> CoffeeScript.eval = function(code, options = {}) { >> >> ^ in at line number >> 46 at column number 45 >> >> >> >> And in cs1 it?s require that?s unresolved (also works in JDK 8): >> >> >> >> ReferenceError: "require" is not defined in at line number 7 >> >> >> >> ? >> >> >> >> On Sun, Dec 3, 2017 at 11:02 AM, Nils Kilden-Pedersen < >> nilskp at gmail.com> >> >> wrote: >> >> >> >>> I just switched to the Java 9.0.1 runtime, and Nashorn now fails to >> parse >> >>> the Coffeescript compiler, which worked fine in Java 8_144. >> >>> >> >>> Coffeescript 2 compiler: http://coffeescript.org/v2/bro >> >>> wser-compiler/coffeescript.js >> >>> >> >>> v1 also fails: http://coffeescript.org/v1/bro >> >>> wser-compiler/coffee-script.js >> >>> >> >>> Exception is: >> >>> >> >>> javax.script.ScriptException: SyntaxError: unexpected in at >> line number 39 at column number 249736 >> >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >> tEngine.throwAsScriptException(NashornScriptEngine.java:469) >> >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >> tEngine.evalImpl(NashornScriptEngine.java:425) >> >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >> tEngine.access$300(NashornScriptEngine.java:72) >> >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >> tEngine$3.eval(NashornScriptEngine.java:513) >> >>> at java.scripting/javax.script.CompiledScript.eval(CompiledScri >> pt.java:92) >> >>> at scuff.js.CoffeeScriptCompiler.compile(CoffeeScriptCompiler.s >> cala:115) >> >>> at scuff.js.TestCoffeeScriptCompiler.cs2(TestCoffeeScriptCompil >> er.scala:114) >> >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >> ke(NativeMethodAccessorImpl.java:62) >> >>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. >> invoke(DelegatingMethodAccessorImpl.java:43) >> >>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> >>> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall( >> FrameworkMethod.java:50) >> >>> at org.junit.internal.runners.model.ReflectiveCallable.run(Refl >> ectiveCallable.java:12) >> >>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr >> ameworkMethod.java:47) >> >>> at org.junit.internal.runners.statements.InvokeMethod.evaluate( >> InvokeMethod.java:17) >> >>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >> >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit >> 4ClassRunner.java:78) >> >>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit >> 4ClassRunner.java:57) >> >>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >> >>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >> >>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >> >>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >> >>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >> >>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >> >>> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference. >> run(JUnit4TestReference.java:86) >> >>> at org.eclipse.jdt.internal.junit.runner.TestExecution.run( >> TestExecution.java:38) >> >>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe >> sts(RemoteTestRunner.java:539) >> >>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe >> sts(RemoteTestRunner.java:761) >> >>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run( >> RemoteTestRunner.java:461) >> >>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( >> RemoteTestRunner.java:207) >> >>> Caused by: :39:249736 SyntaxError: unexpected >> >>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeErr >> or.initException(NativeError.java:135) >> >>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn >> taxError.(NativeSyntaxError.java:73) >> >>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn >> taxError.(NativeSyntaxError.java:77) >> >>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn >> taxError.constructor(NativeSyntaxError.java:98) >> >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >> cript$Recompilation$2368$6956AA$\^eval\_.L:39-1#a#L:39-1#L: >> 39#throwSyntaxError(:39) >> >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >> cript$Recompilation$2364$253073AA$\^eval\_$cu1$restOf.L:39- >> 1#a#L:39-8#L:39#parseError(:39) >> >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >> cript$Recompilation$2359$\^eval\_$cu1$restOf.L:39-1#a#L:39- >> 4#o#parse(:39) >> >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >> cript$Recompilation$2343$\^eval\_$cu1$restOf.L:39-1#a#L:39- >> 8#L:39#p(:39) >> >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >> cript$Recompilation$2056$250675AA$\^eval\_.L:39-1#a#L:39-8# >> L:39#T#L:39(:39) >> >>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >> cript$Recompilation$1572$\^eval\_.:program(:41) >> >>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFun >> ctionData.invoke(ScriptFunctionData.java:652) >> >>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFun >> ction.invoke(ScriptFunction.java:513) >> >>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRun >> time.apply(ScriptRuntime.java:517) >> >>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >> tEngine.evalImpl(NashornScriptEngine.java:420) >> >>> ... 28 more >> >>> >> >>> ? >> >>> >> >> >> >> >> >> > From srinivas.dama at oracle.com Wed Dec 6 15:47:46 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Wed, 6 Dec 2017 07:47:46 -0800 (PST) Subject: RFR: 8134516(Move getInvokeByName and getDynamicInvoker methods from Global to Context) Message-ID: Hi, Please review http://cr.openjdk.java.net/~sdama/8134516/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8134516 Regards, Srinivas From hannes.wallnoefer at oracle.com Wed Dec 6 17:43:57 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 6 Dec 2017 18:43:57 +0100 Subject: RFR: 8069338: Implement sharedScopeCall for optimistic types Message-ID: <04FA86C9-0CCA-4903-9EA0-8B197B12BA6A@oracle.com> Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8069338 Webrev: http://cr.openjdk.java.net/~hannesw/8069338/webrev.00/ This implements shared scope calls for optimistic vars/calls. I followed Attila?s blueprint in the bug description to the last detail - thanks for figuring it all out. Some adjustments and cleanups I did along the way: - Originally shared scope calls were designed to support slow scope vars (with/eval). However, that feature was disabled later on. I refactored the code to make it clear that we only do shared scope calls for fast scope operations. - I unified the threshold for all shared scope operations to 5. I don?t think there is a reason for different thresholds for different operations. I did some testing, using 5 as threshold appeared to be a sensible value. Running all of the octane benchmark I see a decrease in created callsites (200 000 to 178 000) and a slight decrease in callsite invalidations. Hannes From szegedia at gmail.com Wed Dec 6 19:52:16 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 6 Dec 2017 20:52:16 +0100 Subject: Review request for JDK-8192970: Element getters/setters with fixed key fail to link properly In-Reply-To: <3FCD6615-2D4F-4F4E-9AAD-D9A50520170C@oracle.com> References: <12B32E5E-8D86-4C89-96BD-135B108B7A6B@gmail.com> <3FCD6615-2D4F-4F4E-9AAD-D9A50520170C@oracle.com> Message-ID: <5EFE92C6-EF27-4EFD-862B-A4FBAD4CF65B@gmail.com> Is it okay to commit this with one +1 or should I wait for another approval? Thanks, Attila. > On 2017. Dec 4., at 16:36, Hannes Walln?fer wrote: > > Took me some time to spot the difference in behaviour (adaptation of method type in Binder)! > > +1 > > Hannes > >> Am 04.12.2017 um 13:40 schrieb Attila Szegedi : >> >> Please review JDK-8192970 "Element getters/setters with fixed key fail to link properly" at for >> >> Note that this is unrelated to the previous refactoring (8191878), it is present even before that and also in JDK9, I?ll have to separately produce a backport fix for it. I discovered this while trying to expand the test coverage (and good thing that I did, too?) >> >> The gist of the problem is that convertArgToNumber as it was before will fail with IndexOutOfBoundsException invoking parameterType(1) on method type for fixed-key getters, as they only have one parameter at index 0. >> >> The fix is to move the logic into the Binder and use the methodType it manages, not the call site method type. This works because Binder always works with a method type as if the getter/setter were variable-key (it adds back the parameter type in its constructor if the operation is for a fixed key). >> >> Thanks, >> Attila. > From james.laskey at oracle.com Wed Dec 6 20:15:56 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 6 Dec 2017 16:15:56 -0400 Subject: Review request for JDK-8192970: Element getters/setters with fixed key fail to link properly In-Reply-To: <5EFE92C6-EF27-4EFD-862B-A4FBAD4CF65B@gmail.com> References: <12B32E5E-8D86-4C89-96BD-135B108B7A6B@gmail.com> <3FCD6615-2D4F-4F4E-9AAD-D9A50520170C@oracle.com> <5EFE92C6-EF27-4EFD-862B-A4FBAD4CF65B@gmail.com> Message-ID: <9E195EE8-D69E-48A2-A2E2-1F9968E4E491@oracle.com> Please wait for Sundar > On Dec 6, 2017, at 3:52 PM, Attila Szegedi wrote: > > Is it okay to commit this with one +1 or should I wait for another approval? > > Thanks, > Attila. > >> On 2017. Dec 4., at 16:36, Hannes Walln?fer wrote: >> >> Took me some time to spot the difference in behaviour (adaptation of method type in Binder)! >> >> +1 >> >> Hannes >> >>> Am 04.12.2017 um 13:40 schrieb Attila Szegedi : >>> >>> Please review JDK-8192970 "Element getters/setters with fixed key fail to link properly" at for >>> >>> Note that this is unrelated to the previous refactoring (8191878), it is present even before that and also in JDK9, I?ll have to separately produce a backport fix for it. I discovered this while trying to expand the test coverage (and good thing that I did, too?) >>> >>> The gist of the problem is that convertArgToNumber as it was before will fail with IndexOutOfBoundsException invoking parameterType(1) on method type for fixed-key getters, as they only have one parameter at index 0. >>> >>> The fix is to move the logic into the Binder and use the methodType it manages, not the call site method type. This works because Binder always works with a method type as if the getter/setter were variable-key (it adds back the parameter type in its constructor if the operation is for a fixed key). >>> >>> Thanks, >>> Attila. >> > From hannes.wallnoefer at oracle.com Wed Dec 6 20:19:51 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 6 Dec 2017 21:19:51 +0100 Subject: Changes in Java 9 In-Reply-To: References: <97A626A8-3712-4C6D-B44C-82D76923AEFA@oracle.com> Message-ID: <95CF8D7E-48D2-4736-AE99-36C519BE8CC3@oracle.com> That would be https://bugs.openjdk.java.net/ but you need an OpenJDK account to file a bug. Alternatively, if you can send me something reproduce the bug (could be a small snippet of code) I can file it for you. Hannes > Am 06.12.2017 um 16:15 schrieb Nils Kilden-Pedersen : > > What's the right place to file a bug? > > On Mon, Dec 4, 2017 at 9:56 AM, Nils Kilden-Pedersen > wrote: > >> Thanks for bringing this up. It made me realize that my post was >> incomplete. >> >> These are the steps I take: >> >> 1. Initial step: Call engine.compile with the CS compiler source + >> CoffeeScript.compile(coffeeCode, {runtime: 'none'}); which returns >> CompiledScript that is retained and re-used. This works fine, also on >> JDK 9.0.1. >> 2. For subsequent Coffeescript -> Javascript transpilation, I then >> call engine.createBindings() >> 3. Then bindings.put("coffeeCode", csCode) to associate the CS code >> with the JS variable coffeeCode mentioned in initial step >> 4. Call CompiledScript.eval(bindings). This is the step that fails in >> 9.0.1. >> >> I?m open to better ways to achieve this, if it?s inefficient or plain >> wrong. >> ? >> >> On Mon, Dec 4, 2017 at 8:47 AM, Hannes Walln?fer < >> hannes.wallnoefer at oracle.com> wrote: >> >>> Hi Nils, >>> >>> Are you just evaluating the script files you linked in your first >>> message, or trying to do some further processing? >>> >>> Using the jjs tool from JDK 9.0.1 I see no errors running both versions >>> of CoffeeScript. >>> >>> Hannes >>> >>>> Am 03.12.2017 um 21:08 schrieb Nils Kilden-Pedersen : >>>> >>>> Ok, the minified vs non-minified may not be identical. I cannot find the >>>> default parameters in the minified version, so perhaps those are >>> removed. >>>> >>>> What does remain however, is that I can compile minified cs2 >>>> on JDK >>> 8_144, >>>> but not on 9.0.1. >>>> >>>> >>>> On Sun, Dec 3, 2017 at 1:39 PM, Nils Kilden-Pedersen >>>> wrote: >>>> >>>>> Further testing with the un-minified code (cs2 >>>>> , >>> cs1 >>>>> ) >>>>> reveals the true problems in JDK 9.0.1 >>>>> >>>>> In cs2, it?s ES6 syntax (default args), which (unexpectedly for me at >>>>> least), works in JDK 8: >>>>> >>>>> :46:45 Expected , but found = >>>>> CoffeeScript.eval = function(code, options = {}) { >>>>> ^ in at line number >>> 46 at column number 45 >>>>> >>>>> And in cs1 it?s require that?s unresolved (also works in JDK 8): >>>>> >>>>> ReferenceError: "require" is not defined in at line number 7 >>>>> >>>>> ? >>>>> >>>>> On Sun, Dec 3, 2017 at 11:02 AM, Nils Kilden-Pedersen < >>> nilskp at gmail.com> >>>>> wrote: >>>>> >>>>>> I just switched to the Java 9.0.1 runtime, and Nashorn now fails to >>> parse >>>>>> the Coffeescript compiler, which worked fine in Java 8_144. >>>>>> >>>>>> Coffeescript 2 compiler: http://coffeescript.org/v2/bro >>>>>> wser-compiler/coffeescript.js >>>>>> >>>>>> v1 also fails: http://coffeescript.org/v1/bro >>>>>> wser-compiler/coffee-script.js >>>>>> >>>>>> Exception is: >>>>>> >>>>>> javax.script.ScriptException: SyntaxError: unexpected in at >>> line number 39 at column number 249736 >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>> tEngine.throwAsScriptException(NashornScriptEngine.java:469) >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>> tEngine.evalImpl(NashornScriptEngine.java:425) >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>> tEngine.access$300(NashornScriptEngine.java:72) >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>> tEngine$3.eval(NashornScriptEngine.java:513) >>>>>> at java.scripting/javax.script.CompiledScript.eval(CompiledScri >>> pt.java:92) >>>>>> at scuff.js.CoffeeScriptCompiler.compile(CoffeeScriptCompiler.s >>> cala:115) >>>>>> at scuff.js.TestCoffeeScriptCompiler.cs2(TestCoffeeScriptCompil >>> er.scala:114) >>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >>> ke(NativeMethodAccessorImpl.java:62) >>>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. >>> invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >>>>>> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall( >>> FrameworkMethod.java:50) >>>>>> at org.junit.internal.runners.model.ReflectiveCallable.run(Refl >>> ectiveCallable.java:12) >>>>>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr >>> ameworkMethod.java:47) >>>>>> at org.junit.internal.runners.statements.InvokeMethod.evaluate( >>> InvokeMethod.java:17) >>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >>>>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit >>> 4ClassRunner.java:78) >>>>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit >>> 4ClassRunner.java:57) >>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >>>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >>>>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >>>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >>>>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >>>>>> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference. >>> run(JUnit4TestReference.java:86) >>>>>> at org.eclipse.jdt.internal.junit.runner.TestExecution.run( >>> TestExecution.java:38) >>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe >>> sts(RemoteTestRunner.java:539) >>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe >>> sts(RemoteTestRunner.java:761) >>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run( >>> RemoteTestRunner.java:461) >>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( >>> RemoteTestRunner.java:207) >>>>>> Caused by: :39:249736 SyntaxError: unexpected >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeErr >>> or.initException(NativeError.java:135) >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn >>> taxError.(NativeSyntaxError.java:73) >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn >>> taxError.(NativeSyntaxError.java:77) >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn >>> taxError.constructor(NativeSyntaxError.java:98) >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>> cript$Recompilation$2368$6956AA$\^eval\_.L:39-1#a#L:39-1#L: >>> 39#throwSyntaxError(:39) >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>> cript$Recompilation$2364$253073AA$\^eval\_$cu1$restOf.L:39- >>> 1#a#L:39-8#L:39#parseError(:39) >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>> cript$Recompilation$2359$\^eval\_$cu1$restOf.L:39-1#a#L:39- >>> 4#o#parse(:39) >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>> cript$Recompilation$2343$\^eval\_$cu1$restOf.L:39-1#a#L:39- >>> 8#L:39#p(:39) >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>> cript$Recompilation$2056$250675AA$\^eval\_.L:39-1#a#L:39-8# >>> L:39#T#L:39(:39) >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>> cript$Recompilation$1572$\^eval\_.:program(:41) >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFun >>> ctionData.invoke(ScriptFunctionData.java:652) >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFun >>> ction.invoke(ScriptFunction.java:513) >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRun >>> time.apply(ScriptRuntime.java:517) >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>> tEngine.evalImpl(NashornScriptEngine.java:420) >>>>>> ... 28 more >>>>>> >>>>>> ? >>>>>> >>>>> >>>>> >>> >>> >> From nilskp at gmail.com Wed Dec 6 21:30:16 2017 From: nilskp at gmail.com (Nils Kilden-Pedersen) Date: Wed, 6 Dec 2017 15:30:16 -0600 Subject: Changes in Java 9 In-Reply-To: <95CF8D7E-48D2-4736-AE99-36C519BE8CC3@oracle.com> References: <97A626A8-3712-4C6D-B44C-82D76923AEFA@oracle.com> <95CF8D7E-48D2-4736-AE99-36C519BE8CC3@oracle.com> Message-ID: Hannes, I've sent an email with zip file attachment. Just letting you know in a separate email, in case it ends up being blocked. Nils On Wed, Dec 6, 2017 at 2:19 PM, Hannes Walln?fer < hannes.wallnoefer at oracle.com> wrote: > That would be https://bugs.openjdk.java.net/ but you need an OpenJDK > account to file a bug. > > Alternatively, if you can send me something reproduce the bug (could be a > small snippet of code) I can file it for you. > > Hannes > > > > Am 06.12.2017 um 16:15 schrieb Nils Kilden-Pedersen : > > > > What's the right place to file a bug? > > > > On Mon, Dec 4, 2017 at 9:56 AM, Nils Kilden-Pedersen > > wrote: > > > >> Thanks for bringing this up. It made me realize that my post was > >> incomplete. > >> > >> These are the steps I take: > >> > >> 1. Initial step: Call engine.compile with the CS compiler source + > >> CoffeeScript.compile(coffeeCode, {runtime: 'none'}); which returns > >> CompiledScript that is retained and re-used. This works fine, also on > >> JDK 9.0.1. > >> 2. For subsequent Coffeescript -> Javascript transpilation, I then > >> call engine.createBindings() > >> 3. Then bindings.put("coffeeCode", csCode) to associate the CS code > >> with the JS variable coffeeCode mentioned in initial step > >> 4. Call CompiledScript.eval(bindings). This is the step that fails in > >> 9.0.1. > >> > >> I?m open to better ways to achieve this, if it?s inefficient or plain > >> wrong. > >> ? > >> > >> On Mon, Dec 4, 2017 at 8:47 AM, Hannes Walln?fer < > >> hannes.wallnoefer at oracle.com> wrote: > >> > >>> Hi Nils, > >>> > >>> Are you just evaluating the script files you linked in your first > >>> message, or trying to do some further processing? > >>> > >>> Using the jjs tool from JDK 9.0.1 I see no errors running both versions > >>> of CoffeeScript. > >>> > >>> Hannes > >>> > >>>> Am 03.12.2017 um 21:08 schrieb Nils Kilden-Pedersen >: > >>>> > >>>> Ok, the minified vs non-minified may not be identical. I cannot find > the > >>>> default parameters in the minified version, so perhaps those are > >>> removed. > >>>> > >>>> What does remain however, is that I can compile minified cs2 > >>>> on JDK > >>> 8_144, > >>>> but not on 9.0.1. > >>>> > >>>> > >>>> On Sun, Dec 3, 2017 at 1:39 PM, Nils Kilden-Pedersen < > nilskp at gmail.com> > >>>> wrote: > >>>> > >>>>> Further testing with the un-minified code (cs2 > >>>>> , > >>> cs1 > >>>>> >) > >>>>> reveals the true problems in JDK 9.0.1 > >>>>> > >>>>> In cs2, it?s ES6 syntax (default args), which (unexpectedly for me at > >>>>> least), works in JDK 8: > >>>>> > >>>>> :46:45 Expected , but found = > >>>>> CoffeeScript.eval = function(code, options = {}) { > >>>>> ^ in at line number > >>> 46 at column number 45 > >>>>> > >>>>> And in cs1 it?s require that?s unresolved (also works in JDK 8): > >>>>> > >>>>> ReferenceError: "require" is not defined in at line number 7 > >>>>> > >>>>> ? > >>>>> > >>>>> On Sun, Dec 3, 2017 at 11:02 AM, Nils Kilden-Pedersen < > >>> nilskp at gmail.com> > >>>>> wrote: > >>>>> > >>>>>> I just switched to the Java 9.0.1 runtime, and Nashorn now fails to > >>> parse > >>>>>> the Coffeescript compiler, which worked fine in Java 8_144. > >>>>>> > >>>>>> Coffeescript 2 compiler: http://coffeescript.org/v2/bro > >>>>>> wser-compiler/coffeescript.js > >>>>>> > >>>>>> v1 also fails: http://coffeescript.org/v1/bro > >>>>>> wser-compiler/coffee-script.js > >>>>>> > >>>>>> Exception is: > >>>>>> > >>>>>> javax.script.ScriptException: SyntaxError: unexpected in at > >>> line number 39 at column number 249736 > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip > >>> tEngine.throwAsScriptException(NashornScriptEngine.java:469) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip > >>> tEngine.evalImpl(NashornScriptEngine.java:425) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip > >>> tEngine.access$300(NashornScriptEngine.java:72) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip > >>> tEngine$3.eval(NashornScriptEngine.java:513) > >>>>>> at java.scripting/javax.script.CompiledScript.eval(CompiledScri > >>> pt.java:92) > >>>>>> at scuff.js.CoffeeScriptCompiler.compile(CoffeeScriptCompiler.s > >>> cala:115) > >>>>>> at scuff.js.TestCoffeeScriptCompiler.cs2(TestCoffeeScriptCompil > >>> er.scala:114) > >>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl. > invoke0(Native > >>> Method) > >>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo > >>> ke(NativeMethodAccessorImpl.java:62) > >>>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. > >>> invoke(DelegatingMethodAccessorImpl.java:43) > >>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) > >>>>>> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall( > >>> FrameworkMethod.java:50) > >>>>>> at org.junit.internal.runners.model.ReflectiveCallable.run(Refl > >>> ectiveCallable.java:12) > >>>>>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr > >>> ameworkMethod.java:47) > >>>>>> at org.junit.internal.runners.statements.InvokeMethod.evaluate( > >>> InvokeMethod.java:17) > >>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > >>>>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit > >>> 4ClassRunner.java:78) > >>>>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit > >>> 4ClassRunner.java:57) > >>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > >>>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > >>>>>> at org.junit.runners.ParentRunner.runChildren( > ParentRunner.java:288) > >>>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > >>>>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > >>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > >>>>>> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference. > >>> run(JUnit4TestReference.java:86) > >>>>>> at org.eclipse.jdt.internal.junit.runner.TestExecution.run( > >>> TestExecution.java:38) > >>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe > >>> sts(RemoteTestRunner.java:539) > >>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe > >>> sts(RemoteTestRunner.java:761) > >>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run( > >>> RemoteTestRunner.java:461) > >>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( > >>> RemoteTestRunner.java:207) > >>>>>> Caused by: :39:249736 SyntaxError: unexpected > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeErr > >>> or.initException(NativeError.java:135) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn > >>> taxError.(NativeSyntaxError.java:73) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn > >>> taxError.(NativeSyntaxError.java:77) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn > >>> taxError.constructor(NativeSyntaxError.java:98) > >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S > >>> cript$Recompilation$2368$6956AA$\^eval\_.L:39-1#a#L:39-1#L: > >>> 39#throwSyntaxError(:39) > >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S > >>> cript$Recompilation$2364$253073AA$\^eval\_$cu1$restOf.L:39- > >>> 1#a#L:39-8#L:39#parseError(:39) > >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S > >>> cript$Recompilation$2359$\^eval\_$cu1$restOf.L:39-1#a#L:39- > >>> 4#o#parse(:39) > >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S > >>> cript$Recompilation$2343$\^eval\_$cu1$restOf.L:39-1#a#L:39- > >>> 8#L:39#p(:39) > >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S > >>> cript$Recompilation$2056$250675AA$\^eval\_.L:39-1#a#L:39-8# > >>> L:39#T#L:39(:39) > >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S > >>> cript$Recompilation$1572$\^eval\_.:program(:41) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFun > >>> ctionData.invoke(ScriptFunctionData.java:652) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFun > >>> ction.invoke(ScriptFunction.java:513) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRun > >>> time.apply(ScriptRuntime.java:517) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip > >>> tEngine.evalImpl(NashornScriptEngine.java:420) > >>>>>> ... 28 more > >>>>>> > >>>>>> ? > >>>>>> > >>>>> > >>>>> > >>> > >>> > >> > > From sundararajan.athijegannathan at oracle.com Thu Dec 7 03:36:43 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 07 Dec 2017 09:06:43 +0530 Subject: Review request for JDK-8192970: Element getters/setters with fixed key fail to link properly In-Reply-To: <12B32E5E-8D86-4C89-96BD-135B108B7A6B@gmail.com> References: <12B32E5E-8D86-4C89-96BD-135B108B7A6B@gmail.com> Message-ID: <5A28B74B.3070903@oracle.com> Looks good. PS. Sorry for the delayed response. -Sundar On 04/12/17, 6:10 PM, Attila Szegedi wrote: > Please review JDK-8192970 "Element getters/setters with fixed key fail to link properly" at for > > Note that this is unrelated to the previous refactoring (8191878), it is present even before that and also in JDK9, I?ll have to separately produce a backport fix for it. I discovered this while trying to expand the test coverage (and good thing that I did, too?) > > The gist of the problem is that convertArgToNumber as it was before will fail with IndexOutOfBoundsException invoking parameterType(1) on method type for fixed-key getters, as they only have one parameter at index 0. > > The fix is to move the logic into the Binder and use the methodType it manages, not the call site method type. This works because Binder always works with a method type as if the getter/setter were variable-key (it adds back the parameter type in its constructor if the operation is for a fixed key). > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Thu Dec 7 16:28:54 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 7 Dec 2017 17:28:54 +0100 Subject: RFR: 8134516(Move getInvokeByName and getDynamicInvoker methods from Global to Context) In-Reply-To: References: Message-ID: <1EA29F66-C18D-43CF-A71F-51A86C2ADEF0@oracle.com> I have some doubts about whether this is worth it. The idea was to be able to use these internal callsites between various globals without relinking. But since built-in prototypes in different globals have different property maps that doesn?t really happen. That matches your observation that fewer callsites are created with your patch, but more callsites are invalidated. I think if we want to do this, we also have to make sure builtins in different globals use the same property map. Otherwise it?s probably better not to make this change. Hannes > Am 06.12.2017 um 16:47 schrieb Srinivas Dama : > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8134516/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8134516 > > Regards, > Srinivas From priya.lakshmi.muthuswamy at oracle.com Fri Dec 8 08:39:36 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Fri, 8 Dec 2017 14:09:36 +0530 Subject: RFR:JDK-8193137:Nashorn crashes when given an empty script file Message-ID: Hi, Please review JDK-8193137 : Nashorn crashes when given an empty script file JBS : https://bugs.openjdk.java.net/browse/JDK-8193137 webrev : http://cr.openjdk.java.net/~pmuthuswamy/8193137/webrev.00/ Thanks, Priya From sundararajan.athijegannathan at oracle.com Fri Dec 8 09:10:55 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 08 Dec 2017 14:40:55 +0530 Subject: RFR:JDK-8193137:Nashorn crashes when given an empty script file In-Reply-To: References: Message-ID: <5A2A571F.9010709@oracle.com> Looks good. The test uses $EXEC("rm..."). Better to avoid that [what about Windows?] - use Java API to delete file instead./ / -Sundar On 08/12/17, 2:09 PM, Priya Lakshmi Muthuswamy wrote: > Hi, > > Please review JDK-8193137 : Nashorn crashes when given an empty script > file > > JBS : https://bugs.openjdk.java.net/browse/JDK-8193137 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8193137/webrev.00/ > > Thanks, > Priya From priya.lakshmi.muthuswamy at oracle.com Fri Dec 8 09:26:48 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Fri, 8 Dec 2017 14:56:48 +0530 Subject: RFR:JDK-8193137:Nashorn crashes when given an empty script file In-Reply-To: <5A2A571F.9010709@oracle.com> References: <5A2A571F.9010709@oracle.com> Message-ID: <7eb83838-d82c-64db-4e13-c35e8fe85970@oracle.com> Thanks Sundar. I have modified the test. updated webrev : http://cr.openjdk.java.net/~pmuthuswamy/8193137/webrev.01/ Thanks, Priya On 12/8/2017 2:40 PM, Sundararajan Athijegannathan wrote: > Looks good. The test uses $EXEC("rm..."). Better to avoid that [what > about Windows?] - use Java API to delete file instead./ > / > -Sundar > > On 08/12/17, 2:09 PM, Priya Lakshmi Muthuswamy wrote: >> Hi, >> >> Please review JDK-8193137 : Nashorn crashes when given an empty >> script file >> >> JBS : https://bugs.openjdk.java.net/browse/JDK-8193137 >> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8193137/webrev.00/ >> >> Thanks, >> Priya From hannes.wallnoefer at oracle.com Fri Dec 8 09:32:00 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 8 Dec 2017 10:32:00 +0100 Subject: RFR:JDK-8193137:Nashorn crashes when given an empty script file In-Reply-To: <7eb83838-d82c-64db-4e13-c35e8fe85970@oracle.com> References: <5A2A571F.9010709@oracle.com> <7eb83838-d82c-64db-4e13-c35e8fe85970@oracle.com> Message-ID: <1DA1AA99-E4D3-46AA-8D45-FE7CB053D8C4@oracle.com> +1 Hannes > Am 08.12.2017 um 10:26 schrieb Priya Lakshmi Muthuswamy : > > Thanks Sundar. I have modified the test. > > updated webrev : http://cr.openjdk.java.net/~pmuthuswamy/8193137/webrev.01/ > > Thanks, > Priya > On 12/8/2017 2:40 PM, Sundararajan Athijegannathan wrote: >> Looks good. The test uses $EXEC("rm..."). Better to avoid that [what about Windows?] - use Java API to delete file instead./ >> / >> -Sundar >> >> On 08/12/17, 2:09 PM, Priya Lakshmi Muthuswamy wrote: >>> Hi, >>> >>> Please review JDK-8193137 : Nashorn crashes when given an empty script file >>> >>> JBS : https://bugs.openjdk.java.net/browse/JDK-8193137 >>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8193137/webrev.00/ >>> >>> Thanks, >>> Priya > From sundararajan.athijegannathan at oracle.com Fri Dec 8 09:58:20 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 08 Dec 2017 15:28:20 +0530 Subject: RFR:JDK-8193137:Nashorn crashes when given an empty script file In-Reply-To: <7eb83838-d82c-64db-4e13-c35e8fe85970@oracle.com> References: <5A2A571F.9010709@oracle.com> <7eb83838-d82c-64db-4e13-c35e8fe85970@oracle.com> Message-ID: <5A2A623C.1040206@oracle.com> +1 -Sundar On 08/12/17, 2:56 PM, Priya Lakshmi Muthuswamy wrote: > Thanks Sundar. I have modified the test. > > updated webrev : > http://cr.openjdk.java.net/~pmuthuswamy/8193137/webrev.01/ > > Thanks, > Priya > On 12/8/2017 2:40 PM, Sundararajan Athijegannathan wrote: >> Looks good. The test uses $EXEC("rm..."). Better to avoid that [what >> about Windows?] - use Java API to delete file instead./ >> / >> -Sundar >> >> On 08/12/17, 2:09 PM, Priya Lakshmi Muthuswamy wrote: >>> Hi, >>> >>> Please review JDK-8193137 : Nashorn crashes when given an empty >>> script file >>> >>> JBS : https://bugs.openjdk.java.net/browse/JDK-8193137 >>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8193137/webrev.00/ >>> >>> Thanks, >>> Priya > From szegedia at mykolab.com Fri Dec 8 11:13:09 2017 From: szegedia at mykolab.com (Attila Szegedi) Date: Fri, 8 Dec 2017 12:13:09 +0100 Subject: Review request for JDK-8191905: Add a REMOVE value to jdk.dynalink.StandardOperation Message-ID: <402C5C17-BDEC-421B-A52C-D0FAAE75E73B@mykolab.com> Please review JDK-8191905 "Add a REMOVE value to jdk.dynalink.StandardOperation" at for The public API changes have an approved CSR. Note that this adds a REMOVE operation to Dynalink and a default implementation for Lists and Maps to BeanLinker, but stops short of retrofitting Nashorn?s delete operator - that?s the next step I?m yet to implement. Thanks, Attila. From szegedia at gmail.com Sun Dec 10 16:22:56 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 10 Dec 2017 17:22:56 +0100 Subject: Review request for JDK-8193296: Parser should not eagerly transform delete expressions Message-ID: Please review JDK-8193296 "Parser should not eagerly transform delete expressions" at > for > Thanks, Attila. From szegedia at gmail.com Sun Dec 10 16:26:44 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 10 Dec 2017 17:26:44 +0100 Subject: Review request for JDK-8193298: Don't run javadoc with test.single Message-ID: Please review JDK-8193298 "Don't run javadoc with test.single" at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Mon Dec 11 06:27:19 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 11 Dec 2017 11:57:19 +0530 Subject: Review request for JDK-8191905: Add a REMOVE value to jdk.dynalink.StandardOperation Message-ID: <5A2E2547.9090400@oracle.com> +1 -Sundar PS. I deleted the original review request email. http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-December/007220.html From sundararajan.athijegannathan at oracle.com Mon Dec 11 07:18:41 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 11 Dec 2017 12:48:41 +0530 Subject: Review request for JDK-8193296: Parser should not eagerly transform delete expressions In-Reply-To: References: Message-ID: <5A2E3151.9090404@oracle.com> * Test misses copyright comment * you may want to add @bug and @summary line in jtreg comment section Other than that, +1 -Sundar On 10/12/17, 9:52 PM, Attila Szegedi wrote: > Please review JDK-8193296 "Parser should not eagerly transform delete expressions" at> for> > > Thanks, > Attila. > From sundararajan.athijegannathan at oracle.com Mon Dec 11 07:19:55 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 11 Dec 2017 12:49:55 +0530 Subject: Review request for JDK-8193298: Don't run javadoc with test.single In-Reply-To: References: Message-ID: <5A2E319B.3060409@oracle.com> +1 -Sundar On 10/12/17, 9:56 PM, Attila Szegedi wrote: > Please review JDK-8193298 "Don't run javadoc with test.single" at for > > Thanks, > Attila. From szegedia at gmail.com Mon Dec 11 10:55:55 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 11 Dec 2017 11:55:55 +0100 Subject: RFR: 8069338: Implement sharedScopeCall for optimistic types In-Reply-To: <04FA86C9-0CCA-4903-9EA0-8B197B12BA6A@oracle.com> References: <04FA86C9-0CCA-4903-9EA0-8B197B12BA6A@oracle.com> Message-ID: Reviewing this now, thanks for going ahead and implementing it! So what you are saying about slow scopes is that shared scopes were disabled anyway with them for some time, so you didn?t really take away functionality, just cleaned up the remains? So, some remarks: 1. I see the bytecode shape you wrote around invocation of ScriptObject.getProto(int), and I realized it?s weird it asserts n > 0 and it has the first getProto() unrolled before the loop. I?m pretty sure it can just look like this: public final ScriptObject getProto(final int n) { ScriptObject p = this; for (int i = n; i-- > 0;) { p = p.getProto(); } return p; } That assert was there because we knew that it?s only CodeGenerator that emits calls to it, and it will always emit invocations with n > 0, but now we?d have a justification for invoking it with n == 0, so I think it?s fine to do it and avoid the no_proto_call branch in shared scope call bytecode. It?s not a big deal even if you leave it as-is, though. To be entirely pedantic, that assert in getProto should?ve read ?n > 1? before because the CodeGenerator was guaranteed to emit invocations to it with n > 1, so a really pedantic implementation of it should?ve read: public final ScriptObject getProto(final int n) { assert n > 1; ScriptObject p = getProto().getProto(); for (int i = n - 1; --i > 0;) { p = p.getProto(); } return p; } (God, I really hope everyone reading this realizes I?m joking with this last one.) FWIW, we could also factor out the: if (depth > 1) { method.load(depth); method.invoke(ScriptObject.GET_PROTO_DEPTH); } else { method.invoke(ScriptObject.GET_PROTO); } pattern in CodeGenerator into its own little ?emitGetProto(int depth)? method, as it appears twice (and make sure it asserts on depth > 0 ;-) ) 2. For that invocation of UnwarrantedOptimismException.withProgramPoint - I?d create a Call objects using CompilerConstants.virtualCallNoLookup and stash it in a static final field either in SharedScopeCall or UnwarrantedOptimismException; it?s more typesafe than writing type descriptors as strings. 3. So, UOE.hasPrimitiveReturnValue was unused, I take it? 3. In getStaticSignature you have another occurrence of number 3 that you can replace with FIXED_PARAM_COUNT :-) But these are all minor points? overall, this looks really good. Attila. > On Dec 6, 2017, at 6:43 PM, Hannes Walln?fer wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8069338 > Webrev: http://cr.openjdk.java.net/~hannesw/8069338/webrev.00/ > > This implements shared scope calls for optimistic vars/calls. I followed Attila?s blueprint in the bug description to the last detail - thanks for figuring it all out. > > Some adjustments and cleanups I did along the way: > > - Originally shared scope calls were designed to support slow scope vars (with/eval). However, that feature was disabled later on. I refactored the code to make it clear that we only do shared scope calls for fast scope operations. > - I unified the threshold for all shared scope operations to 5. I don?t think there is a reason for different thresholds for different operations. I did some testing, using 5 as threshold appeared to be a sensible value. > > Running all of the octane benchmark I see a decrease in created callsites (200 000 to 178 000) and a slight decrease in callsite invalidations. > > Hannes From szegedia at gmail.com Mon Dec 11 11:15:51 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 11 Dec 2017 12:15:51 +0100 Subject: RFR: 8134516(Move getInvokeByName and getDynamicInvoker methods from Global to Context) In-Reply-To: References: Message-ID: You shouldn't make Global.getContext() public. Context is a security-sensitive class, and the only public access to it is supposed to be through Context.getContext(), which includes a security check. I see you have also simply disabled that security check in your patch. I?m afraid that?s unacceptable. You could make the patch much smaller (and avoid security concerns altogether) if you kept Global.getInvokeByName and Global.getDynamicInvoker methods as they are and have them internally delegate to their new equivalents in Context, adding ?this? as the last argument as they do so. This is all in addition to Hannes? observation with regard to the performance implications in his previous e-mail. Attila. > On Dec 6, 2017, at 4:47 PM, Srinivas Dama wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8134516/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8134516 > > Regards, > Srinivas From szegedia at gmail.com Mon Dec 11 11:25:34 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 11 Dec 2017 12:25:34 +0100 Subject: Review request for JDK-8193296: Parser should not eagerly transform delete expressions In-Reply-To: <5A2E3151.9090404@oracle.com> References: <5A2E3151.9090404@oracle.com> Message-ID: Thanks! I admittedly cribbed the various @tags from the neighboring JDK_8188098_Test class :-). I take it ?@run testng ?? is meaningful and understood by jtreg then, so I can leave that as it is? I tried to find other examples and stumbled upon e.g. JDK_8184723_Test which specifies ?@run main/othervm? and also declares ?@modules? - is that something I should be doing as well, and can you advice what would be the correct values? Attila. > On Dec 11, 2017, at 8:18 AM, Sundararajan Athijegannathan wrote: > > * Test misses copyright comment > * you may want to add @bug and @summary line in jtreg comment section > > Other than that, +1 > > -Sundar > > On 10/12/17, 9:52 PM, Attila Szegedi wrote: >> Please review JDK-8193296 "Parser should not eagerly transform delete expressions" at> for> >> >> Thanks, >> Attila. >> From sundararajan.athijegannathan at oracle.com Mon Dec 11 17:26:09 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 11 Dec 2017 22:56:09 +0530 Subject: Review request for JDK-8193296: Parser should not eagerly transform delete expressions In-Reply-To: References: <5A2E3151.9090404@oracle.com> Message-ID: <5A2EBFB1.7020106@oracle.com> Hi, 1) @bug and @summary are for documentation purpose - explain what the test is all about (without having to look at JIRA...) 2) @modules is needed only if you want to add module exports for internal packages from other modules to your test (equivalent to --add-exports in java command line). That is not needed in this case (because you use only exported API packages from jdk.dynalink module). -Sundar On 11/12/17, 4:55 PM, Attila Szegedi wrote: > Thanks! > > I admittedly cribbed the various @tags from the neighboring JDK_8188098_Test class :-). I take it ?@run testng ?? is meaningful and understood by jtreg then, so I can leave that as it is? I tried to find other examples and stumbled upon e.g. JDK_8184723_Test which specifies ?@run main/othervm? and also declares ?@modules? - is that something I should be doing as well, and can you advice what would be the correct values? > > Attila. > > >> On Dec 11, 2017, at 8:18 AM, Sundararajan Athijegannathan wrote: >> >> * Test misses copyright comment >> * you may want to add @bug and @summary line in jtreg comment section >> >> Other than that, +1 >> >> -Sundar >> >> On 10/12/17, 9:52 PM, Attila Szegedi wrote: >>> Please review JDK-8193296 "Parser should not eagerly transform delete expressions" at> for> >>> >>> Thanks, >>> Attila. >>> From joaovarandas at inpaas.com Mon Dec 11 22:07:18 2017 From: joaovarandas at inpaas.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Varandas?=) Date: Mon, 11 Dec 2017 20:07:18 -0200 Subject: Any news from JDK-8151981 in Java8 ? Message-ID: Hi guys! We are also experiencing some odd issues here with setCallSiteTargetNormal. https://bugs.openjdk.java.net/browse/JDK-8151981 Our cenario is: - Web Application using Tomcat; - 8 HTTP Threads; - A single ScriptEngine for the whole application; When a request hits the server, that request may be processed by a Nashorn Script, this script is evaluated during runtime, run queries (Jdbc), and return results (Maps and/or Collections) that are serialized to JSON before being written to the response. The problem is... sometimes 7 or more threads are getting stuck in the setCallSiteTargetNormal and I have no clue why is that happening. Could you guys help me out troubleshooting this? - Or, if there's a bug, what are the recomended fixes I should do? By the way, those are not freshly created ScriptEngines (which differ from the normal issues related in the internet). -- "Esta mensagem, incluindo seus anexos, pode conter informacoes confidenciais e privilegiadas. Se voce a recebeu por engano, solicitamos que a apague e avise o remetente imediatamente. Opinioes ou informacoes aqui contidas nao refletem necessariamente a posicao oficial da Plusoft." "Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO AMBIENTE" From hannes.wallnoefer at oracle.com Tue Dec 12 12:21:12 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 12 Dec 2017 13:21:12 +0100 Subject: RFR: 8069338: Implement sharedScopeCall for optimistic types In-Reply-To: References: <04FA86C9-0CCA-4903-9EA0-8B197B12BA6A@oracle.com> Message-ID: <53FEFB83-06EE-449B-8288-13E10DE5B575@oracle.com> Thanks for the review, Attila. I?ve uploaded a new webrev with your suggested changes (including making ScriptObject.getProto(int) accept 0 argument and refactoring GET_PROTO code in CodeGenerator into a method). I have also done extensive performance testing over the last days and found that for some reason, shared methods for variable access has a very detrimental effect on performance for some reason. My theory is that we don?t save as much by making property access shared, and the flood of additional methods has some significant cost on codegen, runtime, JIT etc. Based on this I decided to increase the threshold for shared property access again to 100, which performs noticeably better than with the lower threshold in some benchmarks. New webrev is here: http://cr.openjdk.java.net/~hannesw/8069338/webrev.01/ Hannes > Am 11.12.2017 um 11:55 schrieb Attila Szegedi : > > Reviewing this now, thanks for going ahead and implementing it! > > So what you are saying about slow scopes is that shared scopes were disabled anyway with them for some time, so you didn?t really take away functionality, just cleaned up the remains? > > So, some remarks: > > 1. I see the bytecode shape you wrote around invocation of ScriptObject.getProto(int), and I realized it?s weird it asserts n > 0 and it has the first getProto() unrolled before the loop. I?m pretty sure it can just look like this: > > public final ScriptObject getProto(final int n) { > ScriptObject p = this; > for (int i = n; i-- > 0;) { > p = p.getProto(); > } > return p; > } > > That assert was there because we knew that it?s only CodeGenerator that emits calls to it, and it will always emit invocations with n > 0, but now we?d have a justification for invoking it with n == 0, so I think it?s fine to do it and avoid the no_proto_call branch in shared scope call bytecode. It?s not a big deal even if you leave it as-is, though. > > To be entirely pedantic, that assert in getProto should?ve read ?n > 1? before because the CodeGenerator was guaranteed to emit invocations to it with n > 1, so a really pedantic implementation of it should?ve read: > > public final ScriptObject getProto(final int n) { > assert n > 1; > ScriptObject p = getProto().getProto(); > for (int i = n - 1; --i > 0;) { > p = p.getProto(); > } > return p; > } > > (God, I really hope everyone reading this realizes I?m joking with this last one.) > > FWIW, we could also factor out the: > > if (depth > 1) { > method.load(depth); > method.invoke(ScriptObject.GET_PROTO_DEPTH); > } else { > method.invoke(ScriptObject.GET_PROTO); > } > > pattern in CodeGenerator into its own little ?emitGetProto(int depth)? method, as it appears twice (and make sure it asserts on depth > 0 ;-) ) > > 2. For that invocation of UnwarrantedOptimismException.withProgramPoint - I?d create a Call objects using CompilerConstants.virtualCallNoLookup and stash it in a static final field either in SharedScopeCall or UnwarrantedOptimismException; it?s more typesafe than writing type descriptors as strings. > > 3. So, UOE.hasPrimitiveReturnValue was unused, I take it? > > 3. In getStaticSignature you have another occurrence of number 3 that you can replace with FIXED_PARAM_COUNT :-) > > But these are all minor points? overall, this looks really good. > > Attila. > >> On Dec 6, 2017, at 6:43 PM, Hannes Walln?fer wrote: >> >> Please review: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8069338 >> Webrev: http://cr.openjdk.java.net/~hannesw/8069338/webrev.00/ >> >> This implements shared scope calls for optimistic vars/calls. I followed Attila?s blueprint in the bug description to the last detail - thanks for figuring it all out. >> >> Some adjustments and cleanups I did along the way: >> >> - Originally shared scope calls were designed to support slow scope vars (with/eval). However, that feature was disabled later on. I refactored the code to make it clear that we only do shared scope calls for fast scope operations. >> - I unified the threshold for all shared scope operations to 5. I don?t think there is a reason for different thresholds for different operations. I did some testing, using 5 as threshold appeared to be a sensible value. >> >> Running all of the octane benchmark I see a decrease in created callsites (200 000 to 178 000) and a slight decrease in callsite invalidations. >> >> Hannes > From szegedia at gmail.com Tue Dec 12 12:30:10 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 12 Dec 2017 13:30:10 +0100 Subject: RFR: 8069338: Implement sharedScopeCall for optimistic types In-Reply-To: <53FEFB83-06EE-449B-8288-13E10DE5B575@oracle.com> References: <04FA86C9-0CCA-4903-9EA0-8B197B12BA6A@oracle.com> <53FEFB83-06EE-449B-8288-13E10DE5B575@oracle.com> Message-ID: +1 > On Dec 12, 2017, at 1:21 PM, Hannes Walln?fer wrote: > > Thanks for the review, Attila. > > I?ve uploaded a new webrev with your suggested changes (including making ScriptObject.getProto(int) accept 0 argument and refactoring GET_PROTO code in CodeGenerator into a method). > > I have also done extensive performance testing over the last days and found that for some reason, shared methods for variable access has a very detrimental effect on performance for some reason. My theory is that we don?t save as much by making property access shared, and the flood of additional methods has some significant cost on codegen, runtime, JIT etc. Based on this I decided to increase the threshold for shared property access again to 100, which performs noticeably better than with the lower threshold in some benchmarks. > > New webrev is here: > > http://cr.openjdk.java.net/~hannesw/8069338/webrev.01/ > > Hannes > > >> Am 11.12.2017 um 11:55 schrieb Attila Szegedi : >> >> Reviewing this now, thanks for going ahead and implementing it! >> >> So what you are saying about slow scopes is that shared scopes were disabled anyway with them for some time, so you didn?t really take away functionality, just cleaned up the remains? >> >> So, some remarks: >> >> 1. I see the bytecode shape you wrote around invocation of ScriptObject.getProto(int), and I realized it?s weird it asserts n > 0 and it has the first getProto() unrolled before the loop. I?m pretty sure it can just look like this: >> >> public final ScriptObject getProto(final int n) { >> ScriptObject p = this; >> for (int i = n; i-- > 0;) { >> p = p.getProto(); >> } >> return p; >> } >> >> That assert was there because we knew that it?s only CodeGenerator that emits calls to it, and it will always emit invocations with n > 0, but now we?d have a justification for invoking it with n == 0, so I think it?s fine to do it and avoid the no_proto_call branch in shared scope call bytecode. It?s not a big deal even if you leave it as-is, though. >> >> To be entirely pedantic, that assert in getProto should?ve read ?n > 1? before because the CodeGenerator was guaranteed to emit invocations to it with n > 1, so a really pedantic implementation of it should?ve read: >> >> public final ScriptObject getProto(final int n) { >> assert n > 1; >> ScriptObject p = getProto().getProto(); >> for (int i = n - 1; --i > 0;) { >> p = p.getProto(); >> } >> return p; >> } >> >> (God, I really hope everyone reading this realizes I?m joking with this last one.) >> >> FWIW, we could also factor out the: >> >> if (depth > 1) { >> method.load(depth); >> method.invoke(ScriptObject.GET_PROTO_DEPTH); >> } else { >> method.invoke(ScriptObject.GET_PROTO); >> } >> >> pattern in CodeGenerator into its own little ?emitGetProto(int depth)? method, as it appears twice (and make sure it asserts on depth > 0 ;-) ) >> >> 2. For that invocation of UnwarrantedOptimismException.withProgramPoint - I?d create a Call objects using CompilerConstants.virtualCallNoLookup and stash it in a static final field either in SharedScopeCall or UnwarrantedOptimismException; it?s more typesafe than writing type descriptors as strings. >> >> 3. So, UOE.hasPrimitiveReturnValue was unused, I take it? >> >> 3. In getStaticSignature you have another occurrence of number 3 that you can replace with FIXED_PARAM_COUNT :-) >> >> But these are all minor points? overall, this looks really good. >> >> Attila. >> >>> On Dec 6, 2017, at 6:43 PM, Hannes Walln?fer wrote: >>> >>> Please review: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069338 >>> Webrev: http://cr.openjdk.java.net/~hannesw/8069338/webrev.00/ >>> >>> This implements shared scope calls for optimistic vars/calls. I followed Attila?s blueprint in the bug description to the last detail - thanks for figuring it all out. >>> >>> Some adjustments and cleanups I did along the way: >>> >>> - Originally shared scope calls were designed to support slow scope vars (with/eval). However, that feature was disabled later on. I refactored the code to make it clear that we only do shared scope calls for fast scope operations. >>> - I unified the threshold for all shared scope operations to 5. I don?t think there is a reason for different thresholds for different operations. I did some testing, using 5 as threshold appeared to be a sensible value. >>> >>> Running all of the octane benchmark I see a decrease in created callsites (200 000 to 178 000) and a slight decrease in callsite invalidations. >>> >>> Hannes >> > From hannes.wallnoefer at oracle.com Tue Dec 12 12:50:54 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 12 Dec 2017 13:50:54 +0100 Subject: Review request for JDK-8191905: Add a REMOVE value to jdk.dynalink.StandardOperation In-Reply-To: <402C5C17-BDEC-421B-A52C-D0FAAE75E73B@mykolab.com> References: <402C5C17-BDEC-421B-A52C-D0FAAE75E73B@mykolab.com> Message-ID: +1 Hannes > Am 08.12.2017 um 12:13 schrieb Attila Szegedi : > > Please review JDK-8191905 "Add a REMOVE value to jdk.dynalink.StandardOperation" at for > > The public API changes have an approved CSR. Note that this adds a REMOVE operation to Dynalink and a default implementation for Lists and Maps to BeanLinker, but stops short of retrofitting Nashorn?s delete operator - that?s the next step I?m yet to implement. > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Tue Dec 12 12:51:12 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 12 Dec 2017 13:51:12 +0100 Subject: Review request for JDK-8193298: Don't run javadoc with test.single In-Reply-To: References: Message-ID: +1 Hannes > Am 10.12.2017 um 17:26 schrieb Attila Szegedi : > > Please review JDK-8193298 "Don't run javadoc with test.single" at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Tue Dec 12 13:00:18 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 12 Dec 2017 18:30:18 +0530 Subject: RFR: 8069338: Implement sharedScopeCall for optimistic types In-Reply-To: <53FEFB83-06EE-449B-8288-13E10DE5B575@oracle.com> References: <04FA86C9-0CCA-4903-9EA0-8B197B12BA6A@oracle.com> <53FEFB83-06EE-449B-8288-13E10DE5B575@oracle.com> Message-ID: <5A2FD2E2.8000507@oracle.com> +1 PS. Not sure if it is worth making SHARED_GET_THRESHOLD configurable via System property? -Sundar On 12/12/17, 5:51 PM, Hannes Walln?fer wrote: > Thanks for the review, Attila. > > I?ve uploaded a new webrev with your suggested changes (including making ScriptObject.getProto(int) accept 0 argument and refactoring GET_PROTO code in CodeGenerator into a method). > > I have also done extensive performance testing over the last days and found that for some reason, shared methods for variable access has a very detrimental effect on performance for some reason. My theory is that we don?t save as much by making property access shared, and the flood of additional methods has some significant cost on codegen, runtime, JIT etc. Based on this I decided to increase the threshold for shared property access again to 100, which performs noticeably better than with the lower threshold in some benchmarks. > > New webrev is here: > > http://cr.openjdk.java.net/~hannesw/8069338/webrev.01/ > > Hannes > > >> Am 11.12.2017 um 11:55 schrieb Attila Szegedi: >> >> Reviewing this now, thanks for going ahead and implementing it! >> >> So what you are saying about slow scopes is that shared scopes were disabled anyway with them for some time, so you didn?t really take away functionality, just cleaned up the remains? >> >> So, some remarks: >> >> 1. I see the bytecode shape you wrote around invocation of ScriptObject.getProto(int), and I realized it?s weird it asserts n> 0 and it has the first getProto() unrolled before the loop. I?m pretty sure it can just look like this: >> >> public final ScriptObject getProto(final int n) { >> ScriptObject p = this; >> for (int i = n; i--> 0;) { >> p = p.getProto(); >> } >> return p; >> } >> >> That assert was there because we knew that it?s only CodeGenerator that emits calls to it, and it will always emit invocations with n> 0, but now we?d have a justification for invoking it with n == 0, so I think it?s fine to do it and avoid the no_proto_call branch in shared scope call bytecode. It?s not a big deal even if you leave it as-is, though. >> >> To be entirely pedantic, that assert in getProto should?ve read ?n> 1? before because the CodeGenerator was guaranteed to emit invocations to it with n> 1, so a really pedantic implementation of it should?ve read: >> >> public final ScriptObject getProto(final int n) { >> assert n> 1; >> ScriptObject p = getProto().getProto(); >> for (int i = n - 1; --i> 0;) { >> p = p.getProto(); >> } >> return p; >> } >> >> (God, I really hope everyone reading this realizes I?m joking with this last one.) >> >> FWIW, we could also factor out the: >> >> if (depth> 1) { >> method.load(depth); >> method.invoke(ScriptObject.GET_PROTO_DEPTH); >> } else { >> method.invoke(ScriptObject.GET_PROTO); >> } >> >> pattern in CodeGenerator into its own little ?emitGetProto(int depth)? method, as it appears twice (and make sure it asserts on depth> 0 ;-) ) >> >> 2. For that invocation of UnwarrantedOptimismException.withProgramPoint - I?d create a Call objects using CompilerConstants.virtualCallNoLookup and stash it in a static final field either in SharedScopeCall or UnwarrantedOptimismException; it?s more typesafe than writing type descriptors as strings. >> >> 3. So, UOE.hasPrimitiveReturnValue was unused, I take it? >> >> 3. In getStaticSignature you have another occurrence of number 3 that you can replace with FIXED_PARAM_COUNT :-) >> >> But these are all minor points? overall, this looks really good. >> >> Attila. >> >>> On Dec 6, 2017, at 6:43 PM, Hannes Walln?fer wrote: >>> >>> Please review: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069338 >>> Webrev: http://cr.openjdk.java.net/~hannesw/8069338/webrev.00/ >>> >>> This implements shared scope calls for optimistic vars/calls. I followed Attila?s blueprint in the bug description to the last detail - thanks for figuring it all out. >>> >>> Some adjustments and cleanups I did along the way: >>> >>> - Originally shared scope calls were designed to support slow scope vars (with/eval). However, that feature was disabled later on. I refactored the code to make it clear that we only do shared scope calls for fast scope operations. >>> - I unified the threshold for all shared scope operations to 5. I don?t think there is a reason for different thresholds for different operations. I did some testing, using 5 as threshold appeared to be a sensible value. >>> >>> Running all of the octane benchmark I see a decrease in created callsites (200 000 to 178 000) and a slight decrease in callsite invalidations. >>> >>> Hannes From priya.lakshmi.muthuswamy at oracle.com Tue Dec 12 12:32:36 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Tue, 12 Dec 2017 18:02:36 +0530 Subject: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements In-Reply-To: <6c8580db-1d6c-7fe2-b333-d8ffb1193d1d@oracle.com> References: <03416610-734e-7207-7fde-caa1b64ec670@oracle.com> <2CC9D6AB-B145-4409-80FD-8D68BDE5DDCE@gmail.com> <6c8580db-1d6c-7fe2-b333-d8ffb1193d1d@oracle.com> Message-ID: <60679184-91a3-bc91-09bd-8c06e283a82e@oracle.com> Hi, Kindly review. I have modified the fix to work with multiple with scopes. webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.01/ Thanks, Priya On 12/5/2017 12:54 PM, Priya Lakshmi Muthuswamy wrote: > Hi Attila, > > Thanks for review. > Yes when I checked with two with scopes as suggested(JavaImporter as > outer), current fix doesn't work. I will work on that. > > Thanks, > Priya > On 12/5/2017 12:12 PM, Attila Szegedi wrote: >> Hm? this seems to be an issue with shared scope calls; that?s why >> it?s sensitive to the number of similar statements. >> >> That said, here?s some thoughts: >> >> 1. Instead of >> >> ????if (self instanceof ScriptObject && >> ((ScriptObject)self).hasWithScope()) { >> >> you should be able to just use >> >> ????if (self instanceof ScriptObject) { >> >> As then you?ll evaluate getWithScopeObject and test it for being null >> anyway. This way, you avoid walking the prototype chain twice. >> >> 2. That said, I guess hasWithScope could be reimplemented simply as >> >> ????public boolean hasWithScope() { >> ??????? return getWithScopeObject() != null; >> ????} >> >> as both have very similar code, so it?d reduce to it nicely. (I >> understand that you haven?t changed that, but since you were in the >> vicinity of that code, you might as wel do it? It?s also fine if you >> leave it alone as it is.) >> >> 3. One of the statements in the test is indented differently than the >> others. >> >> 4. What happens if there?s _two_ with scopes, and the JavaImporter is >> in the outer one? Does this fix still work? E.g.: >> >> var imports = new JavaImporter(java.lang); >> var dummy = { x: 42, y: 13 } >> with (imports) { >> ???? with (dummy) { >> ???????? function func() { >> ???????????? System.out.println('a'); >> ??????????? System.out.println('a'); >> ??????? System.out.println('a'); >> ???????????? System.out.println('a'); >> ??????????? System.out.println('a'); >> ??????? System.out.println('a'); >> ??????????? System.out.println('a'); >> ???????? }; >> ???????? func(); >> ????} >> } >> >> Attila. >> >>> On Dec 5, 2017, at 7:13 AM, Priya Lakshmi Muthuswamy >>> wrote: >>> >>> Hi, >>> >>> please review JDK-8191301 : JavaImporter fails to resolve imported >>> elements within functions, that contain too many statements >>> >>> JBS : https://bugs.openjdk.java.net/browse/JDK-8191301 >>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.00/ >>> >>> Thanks, >>> Priya >>> >>> > From hannes.wallnoefer at oracle.com Tue Dec 12 13:11:49 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 12 Dec 2017 14:11:49 +0100 Subject: Any news from JDK-8151981 in Java8 ? In-Reply-To: References: Message-ID: <128E8DE6-4263-4806-B06E-17D3A7E9C065@oracle.com> Hi Jo?o, this functionality is part of java.lang.invoke package, not Nashorn, so we can?t help you here. The best place to ask about this would be the core-libs-dev mailing list. Regards, Hannes > Am 11.12.2017 um 23:07 schrieb Jo?o Paulo Varandas : > > Hi guys! > > We are also experiencing some odd issues here with setCallSiteTargetNormal. > https://bugs.openjdk.java.net/browse/JDK-8151981 > > Our cenario is: > > - Web Application using Tomcat; > - 8 HTTP Threads; > - A single ScriptEngine for the whole application; > > When a request hits the server, that request may be processed by a Nashorn > Script, this script is evaluated during runtime, run queries (Jdbc), and > return results (Maps and/or Collections) that are serialized to JSON before > being written to the response. > > The problem is... sometimes 7 or more threads are getting stuck in the > setCallSiteTargetNormal and I have no clue why is that happening. Could you > guys help me out troubleshooting this? - Or, if there's a bug, what are the > recomended fixes I should do? > > > By the way, those are not freshly created ScriptEngines (which differ from > the normal issues related in the internet). > > -- > "Esta mensagem, incluindo seus anexos, pode conter informacoes > confidenciais e privilegiadas. > Se voce a recebeu por engano, solicitamos que a apague e avise o remetente > imediatamente. > Opinioes ou informacoes aqui contidas nao refletem necessariamente a > posicao oficial da Plusoft." > > "Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO > AMBIENTE" > From hannes.wallnoefer at oracle.com Tue Dec 12 13:39:46 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 12 Dec 2017 14:39:46 +0100 Subject: RFR: 8069338: Implement sharedScopeCall for optimistic types In-Reply-To: <5A2FD2E2.8000507@oracle.com> References: <04FA86C9-0CCA-4903-9EA0-8B197B12BA6A@oracle.com> <53FEFB83-06EE-449B-8288-13E10DE5B575@oracle.com> <5A2FD2E2.8000507@oracle.com> Message-ID: <429DDC66-5165-44B3-BBD0-7092ADACC203@oracle.com> Thanks for the review, Sundar. I think making thresholds configurable is a good idea. I?ve uploaded a new webrev where SHARED_CALL_THRESHOLD and SHARED_GET_THRESHOLD are configurable via ?nashorn.shared.scope.call.threshold? and ?nashorn.shared.scope.get.threshold? system properties, respectively. http://cr.openjdk.java.net/~hannesw/8069338/webrev.02/ Hannes > Am 12.12.2017 um 14:00 schrieb Sundararajan Athijegannathan : > > +1 > > PS. Not sure if it is worth making SHARED_GET_THRESHOLD configurable via System property? > > -Sundar > > On 12/12/17, 5:51 PM, Hannes Walln?fer wrote: >> Thanks for the review, Attila. >> >> I?ve uploaded a new webrev with your suggested changes (including making ScriptObject.getProto(int) accept 0 argument and refactoring GET_PROTO code in CodeGenerator into a method). >> >> I have also done extensive performance testing over the last days and found that for some reason, shared methods for variable access has a very detrimental effect on performance for some reason. My theory is that we don?t save as much by making property access shared, and the flood of additional methods has some significant cost on codegen, runtime, JIT etc. Based on this I decided to increase the threshold for shared property access again to 100, which performs noticeably better than with the lower threshold in some benchmarks. >> >> New webrev is here: >> >> http://cr.openjdk.java.net/~hannesw/8069338/webrev.01/ >> >> Hannes >> >> >>> Am 11.12.2017 um 11:55 schrieb Attila Szegedi: >>> >>> Reviewing this now, thanks for going ahead and implementing it! >>> >>> So what you are saying about slow scopes is that shared scopes were disabled anyway with them for some time, so you didn?t really take away functionality, just cleaned up the remains? >>> >>> So, some remarks: >>> >>> 1. I see the bytecode shape you wrote around invocation of ScriptObject.getProto(int), and I realized it?s weird it asserts n> 0 and it has the first getProto() unrolled before the loop. I?m pretty sure it can just look like this: >>> >>> public final ScriptObject getProto(final int n) { >>> ScriptObject p = this; >>> for (int i = n; i--> 0;) { >>> p = p.getProto(); >>> } >>> return p; >>> } >>> >>> That assert was there because we knew that it?s only CodeGenerator that emits calls to it, and it will always emit invocations with n> 0, but now we?d have a justification for invoking it with n == 0, so I think it?s fine to do it and avoid the no_proto_call branch in shared scope call bytecode. It?s not a big deal even if you leave it as-is, though. >>> >>> To be entirely pedantic, that assert in getProto should?ve read ?n> 1? before because the CodeGenerator was guaranteed to emit invocations to it with n> 1, so a really pedantic implementation of it should?ve read: >>> >>> public final ScriptObject getProto(final int n) { >>> assert n> 1; >>> ScriptObject p = getProto().getProto(); >>> for (int i = n - 1; --i> 0;) { >>> p = p.getProto(); >>> } >>> return p; >>> } >>> >>> (God, I really hope everyone reading this realizes I?m joking with this last one.) >>> >>> FWIW, we could also factor out the: >>> >>> if (depth> 1) { >>> method.load(depth); >>> method.invoke(ScriptObject.GET_PROTO_DEPTH); >>> } else { >>> method.invoke(ScriptObject.GET_PROTO); >>> } >>> >>> pattern in CodeGenerator into its own little ?emitGetProto(int depth)? method, as it appears twice (and make sure it asserts on depth> 0 ;-) ) >>> >>> 2. For that invocation of UnwarrantedOptimismException.withProgramPoint - I?d create a Call objects using CompilerConstants.virtualCallNoLookup and stash it in a static final field either in SharedScopeCall or UnwarrantedOptimismException; it?s more typesafe than writing type descriptors as strings. >>> >>> 3. So, UOE.hasPrimitiveReturnValue was unused, I take it? >>> >>> 3. In getStaticSignature you have another occurrence of number 3 that you can replace with FIXED_PARAM_COUNT :-) >>> >>> But these are all minor points? overall, this looks really good. >>> >>> Attila. >>> >>>> On Dec 6, 2017, at 6:43 PM, Hannes Walln?fer wrote: >>>> >>>> Please review: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069338 >>>> Webrev: http://cr.openjdk.java.net/~hannesw/8069338/webrev.00/ >>>> >>>> This implements shared scope calls for optimistic vars/calls. I followed Attila?s blueprint in the bug description to the last detail - thanks for figuring it all out. >>>> >>>> Some adjustments and cleanups I did along the way: >>>> >>>> - Originally shared scope calls were designed to support slow scope vars (with/eval). However, that feature was disabled later on. I refactored the code to make it clear that we only do shared scope calls for fast scope operations. >>>> - I unified the threshold for all shared scope operations to 5. I don?t think there is a reason for different thresholds for different operations. I did some testing, using 5 as threshold appeared to be a sensible value. >>>> >>>> Running all of the octane benchmark I see a decrease in created callsites (200 000 to 178 000) and a slight decrease in callsite invalidations. >>>> >>>> Hannes From sundararajan.athijegannathan at oracle.com Tue Dec 12 13:56:41 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 12 Dec 2017 19:26:41 +0530 Subject: RFR: 8069338: Implement sharedScopeCall for optimistic types In-Reply-To: <429DDC66-5165-44B3-BBD0-7092ADACC203@oracle.com> References: <04FA86C9-0CCA-4903-9EA0-8B197B12BA6A@oracle.com> <53FEFB83-06EE-449B-8288-13E10DE5B575@oracle.com> <5A2FD2E2.8000507@oracle.com> <429DDC66-5165-44B3-BBD0-7092ADACC203@oracle.com> Message-ID: <5A2FE019.6070007@oracle.com> +1 -Sundar On 12/12/17, 7:09 PM, Hannes Walln?fer wrote: > Thanks for the review, Sundar. > > I think making thresholds configurable is a good idea. I?ve uploaded a new webrev where SHARED_CALL_THRESHOLD and SHARED_GET_THRESHOLD are configurable via ?nashorn.shared.scope.call.threshold? and ?nashorn.shared.scope.get.threshold? system properties, respectively. > > http://cr.openjdk.java.net/~hannesw/8069338/webrev.02/ > > Hannes > >> Am 12.12.2017 um 14:00 schrieb Sundararajan Athijegannathan: >> >> +1 >> >> PS. Not sure if it is worth making SHARED_GET_THRESHOLD configurable via System property? >> >> -Sundar >> >> On 12/12/17, 5:51 PM, Hannes Walln?fer wrote: >>> Thanks for the review, Attila. >>> >>> I?ve uploaded a new webrev with your suggested changes (including making ScriptObject.getProto(int) accept 0 argument and refactoring GET_PROTO code in CodeGenerator into a method). >>> >>> I have also done extensive performance testing over the last days and found that for some reason, shared methods for variable access has a very detrimental effect on performance for some reason. My theory is that we don?t save as much by making property access shared, and the flood of additional methods has some significant cost on codegen, runtime, JIT etc. Based on this I decided to increase the threshold for shared property access again to 100, which performs noticeably better than with the lower threshold in some benchmarks. >>> >>> New webrev is here: >>> >>> http://cr.openjdk.java.net/~hannesw/8069338/webrev.01/ >>> >>> Hannes >>> >>> >>>> Am 11.12.2017 um 11:55 schrieb Attila Szegedi: >>>> >>>> Reviewing this now, thanks for going ahead and implementing it! >>>> >>>> So what you are saying about slow scopes is that shared scopes were disabled anyway with them for some time, so you didn?t really take away functionality, just cleaned up the remains? >>>> >>>> So, some remarks: >>>> >>>> 1. I see the bytecode shape you wrote around invocation of ScriptObject.getProto(int), and I realized it?s weird it asserts n> 0 and it has the first getProto() unrolled before the loop. I?m pretty sure it can just look like this: >>>> >>>> public final ScriptObject getProto(final int n) { >>>> ScriptObject p = this; >>>> for (int i = n; i--> 0;) { >>>> p = p.getProto(); >>>> } >>>> return p; >>>> } >>>> >>>> That assert was there because we knew that it?s only CodeGenerator that emits calls to it, and it will always emit invocations with n> 0, but now we?d have a justification for invoking it with n == 0, so I think it?s fine to do it and avoid the no_proto_call branch in shared scope call bytecode. It?s not a big deal even if you leave it as-is, though. >>>> >>>> To be entirely pedantic, that assert in getProto should?ve read ?n> 1? before because the CodeGenerator was guaranteed to emit invocations to it with n> 1, so a really pedantic implementation of it should?ve read: >>>> >>>> public final ScriptObject getProto(final int n) { >>>> assert n> 1; >>>> ScriptObject p = getProto().getProto(); >>>> for (int i = n - 1; --i> 0;) { >>>> p = p.getProto(); >>>> } >>>> return p; >>>> } >>>> >>>> (God, I really hope everyone reading this realizes I?m joking with this last one.) >>>> >>>> FWIW, we could also factor out the: >>>> >>>> if (depth> 1) { >>>> method.load(depth); >>>> method.invoke(ScriptObject.GET_PROTO_DEPTH); >>>> } else { >>>> method.invoke(ScriptObject.GET_PROTO); >>>> } >>>> >>>> pattern in CodeGenerator into its own little ?emitGetProto(int depth)? method, as it appears twice (and make sure it asserts on depth> 0 ;-) ) >>>> >>>> 2. For that invocation of UnwarrantedOptimismException.withProgramPoint - I?d create a Call objects using CompilerConstants.virtualCallNoLookup and stash it in a static final field either in SharedScopeCall or UnwarrantedOptimismException; it?s more typesafe than writing type descriptors as strings. >>>> >>>> 3. So, UOE.hasPrimitiveReturnValue was unused, I take it? >>>> >>>> 3. In getStaticSignature you have another occurrence of number 3 that you can replace with FIXED_PARAM_COUNT :-) >>>> >>>> But these are all minor points? overall, this looks really good. >>>> >>>> Attila. >>>> >>>>> On Dec 6, 2017, at 6:43 PM, Hannes Walln?fer wrote: >>>>> >>>>> Please review: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069338 >>>>> Webrev: http://cr.openjdk.java.net/~hannesw/8069338/webrev.00/ >>>>> >>>>> This implements shared scope calls for optimistic vars/calls. I followed Attila?s blueprint in the bug description to the last detail - thanks for figuring it all out. >>>>> >>>>> Some adjustments and cleanups I did along the way: >>>>> >>>>> - Originally shared scope calls were designed to support slow scope vars (with/eval). However, that feature was disabled later on. I refactored the code to make it clear that we only do shared scope calls for fast scope operations. >>>>> - I unified the threshold for all shared scope operations to 5. I don?t think there is a reason for different thresholds for different operations. I did some testing, using 5 as threshold appeared to be a sensible value. >>>>> >>>>> Running all of the octane benchmark I see a decrease in created callsites (200 000 to 178 000) and a slight decrease in callsite invalidations. >>>>> >>>>> Hannes From forax at univ-mlv.fr Tue Dec 12 13:52:39 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 12 Dec 2017 14:52:39 +0100 (CET) Subject: Any news from JDK-8151981 in Java8 ? In-Reply-To: <128E8DE6-4263-4806-B06E-17D3A7E9C065@oracle.com> References: <128E8DE6-4263-4806-B06E-17D3A7E9C065@oracle.com> Message-ID: <568631132.775855.1513086759540.JavaMail.zimbra@u-pem.fr> Hi Hannes, it can also be Nashorn triggering too much deoptimizations creating a deoptimization storm. R?mi ----- Mail original ----- > De: "Hannes Walln?fer" > ?: "Jo?o Paulo Varandas" > Cc: nashorn-dev at openjdk.java.net > Envoy?: Mardi 12 D?cembre 2017 14:11:49 > Objet: Re: Any news from JDK-8151981 in Java8 ? > Hi Jo?o, > > this functionality is part of java.lang.invoke package, not Nashorn, so we can?t > help you here. > > The best place to ask about this would be the core-libs-dev mailing list. > > Regards, > Hannes > > >> Am 11.12.2017 um 23:07 schrieb Jo?o Paulo Varandas : >> >> Hi guys! >> >> We are also experiencing some odd issues here with setCallSiteTargetNormal. >> https://bugs.openjdk.java.net/browse/JDK-8151981 >> >> Our cenario is: >> >> - Web Application using Tomcat; >> - 8 HTTP Threads; >> - A single ScriptEngine for the whole application; >> >> When a request hits the server, that request may be processed by a Nashorn >> Script, this script is evaluated during runtime, run queries (Jdbc), and >> return results (Maps and/or Collections) that are serialized to JSON before >> being written to the response. >> >> The problem is... sometimes 7 or more threads are getting stuck in the >> setCallSiteTargetNormal and I have no clue why is that happening. Could you >> guys help me out troubleshooting this? - Or, if there's a bug, what are the >> recomended fixes I should do? >> >> >> By the way, those are not freshly created ScriptEngines (which differ from >> the normal issues related in the internet). >> >> -- >> "Esta mensagem, incluindo seus anexos, pode conter informacoes >> confidenciais e privilegiadas. >> Se voce a recebeu por engano, solicitamos que a apague e avise o remetente >> imediatamente. >> Opinioes ou informacoes aqui contidas nao refletem necessariamente a >> posicao oficial da Plusoft." >> >> "Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO >> AMBIENTE" From joaovarandas at inpaas.com Tue Dec 12 14:13:09 2017 From: joaovarandas at inpaas.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Varandas?=) Date: Tue, 12 Dec 2017 12:13:09 -0200 Subject: Any news from JDK-8151981 in Java8 ? In-Reply-To: <568631132.775855.1513086759540.JavaMail.zimbra@u-pem.fr> References: <128E8DE6-4263-4806-B06E-17D3A7E9C065@oracle.com> <568631132.775855.1513086759540.JavaMail.zimbra@u-pem.fr> Message-ID: I see... I'm sorry about that, I haven't noticed the subpackage/components in the bug report. 2017-12-12 11:52 GMT-02:00 Remi Forax : > Hi Hannes, > it can also be Nashorn triggering too much deoptimizations creating a > deoptimization storm. > > R?mi > > ----- Mail original ----- > > De: "Hannes Walln?fer" > > ?: "Jo?o Paulo Varandas" > > Cc: nashorn-dev at openjdk.java.net > > Envoy?: Mardi 12 D?cembre 2017 14:11:49 > > Objet: Re: Any news from JDK-8151981 in Java8 ? > > > Hi Jo?o, > > > > this functionality is part of java.lang.invoke package, not Nashorn, so > we can?t > > help you here. > > > > The best place to ask about this would be the core-libs-dev mailing list. > > > > Regards, > > Hannes > > > > > >> Am 11.12.2017 um 23:07 schrieb Jo?o Paulo Varandas < > joaovarandas at inpaas.com>: > >> > >> Hi guys! > >> > >> We are also experiencing some odd issues here with > setCallSiteTargetNormal. > >> https://bugs.openjdk.java.net/browse/JDK-8151981 > >> > >> Our cenario is: > >> > >> - Web Application using Tomcat; > >> - 8 HTTP Threads; > >> - A single ScriptEngine for the whole application; > >> > >> When a request hits the server, that request may be processed by a > Nashorn > >> Script, this script is evaluated during runtime, run queries (Jdbc), and > >> return results (Maps and/or Collections) that are serialized to JSON > before > >> being written to the response. > >> > >> The problem is... sometimes 7 or more threads are getting stuck in the > >> setCallSiteTargetNormal and I have no clue why is that happening. Could > you > >> guys help me out troubleshooting this? - Or, if there's a bug, what are > the > >> recomended fixes I should do? > >> > >> > >> By the way, those are not freshly created ScriptEngines (which differ > from > >> the normal issues related in the internet). > >> > >> -- > >> "Esta mensagem, incluindo seus anexos, pode conter informacoes > >> confidenciais e privilegiadas. > >> Se voce a recebeu por engano, solicitamos que a apague e avise o > remetente > >> imediatamente. > >> Opinioes ou informacoes aqui contidas nao refletem necessariamente a > >> posicao oficial da Plusoft." > >> > >> "Antes de imprimir, pense em sua responsabilidade e compromisso com o > MEIO > >> AMBIENTE" > -- "Esta mensagem, incluindo seus anexos, pode conter informacoes confidenciais e privilegiadas. Se voce a recebeu por engano, solicitamos que a apague e avise o remetente imediatamente. Opinioes ou informacoes aqui contidas nao refletem necessariamente a posicao oficial da Plusoft." "Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO AMBIENTE" From hannes.wallnoefer at oracle.com Tue Dec 12 14:35:02 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 12 Dec 2017 15:35:02 +0100 Subject: Any news from JDK-8151981 in Java8 ? In-Reply-To: <568631132.775855.1513086759540.JavaMail.zimbra@u-pem.fr> References: <128E8DE6-4263-4806-B06E-17D3A7E9C065@oracle.com> <568631132.775855.1513086759540.JavaMail.zimbra@u-pem.fr> Message-ID: Hi R?mi, Am 12.12.2017 um 14:52 schrieb Remi Forax : > > Hi Hannes, > it can also be Nashorn triggering too much deoptimizations creating a deoptimization storm. I agree. But given that the problem manifests itself in java.lang.invoke I think the first step is to understand what is going wrong there. Without a better understanding of the problem it is very hard to provide provide any help. Hannes > R?mi > > ----- Mail original ----- >> De: "Hannes Walln?fer" >> ?: "Jo?o Paulo Varandas" >> Cc: nashorn-dev at openjdk.java.net >> Envoy?: Mardi 12 D?cembre 2017 14:11:49 >> Objet: Re: Any news from JDK-8151981 in Java8 ? > >> Hi Jo?o, >> >> this functionality is part of java.lang.invoke package, not Nashorn, so we can?t >> help you here. >> >> The best place to ask about this would be the core-libs-dev mailing list. >> >> Regards, >> Hannes >> >> >>> Am 11.12.2017 um 23:07 schrieb Jo?o Paulo Varandas : >>> >>> Hi guys! >>> >>> We are also experiencing some odd issues here with setCallSiteTargetNormal. >>> https://bugs.openjdk.java.net/browse/JDK-8151981 >>> >>> Our cenario is: >>> >>> - Web Application using Tomcat; >>> - 8 HTTP Threads; >>> - A single ScriptEngine for the whole application; >>> >>> When a request hits the server, that request may be processed by a Nashorn >>> Script, this script is evaluated during runtime, run queries (Jdbc), and >>> return results (Maps and/or Collections) that are serialized to JSON before >>> being written to the response. >>> >>> The problem is... sometimes 7 or more threads are getting stuck in the >>> setCallSiteTargetNormal and I have no clue why is that happening. Could you >>> guys help me out troubleshooting this? - Or, if there's a bug, what are the >>> recomended fixes I should do? >>> >>> >>> By the way, those are not freshly created ScriptEngines (which differ from >>> the normal issues related in the internet). >>> >>> -- >>> "Esta mensagem, incluindo seus anexos, pode conter informacoes >>> confidenciais e privilegiadas. >>> Se voce a recebeu por engano, solicitamos que a apague e avise o remetente >>> imediatamente. >>> Opinioes ou informacoes aqui contidas nao refletem necessariamente a >>> posicao oficial da Plusoft." >>> >>> "Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO >>> AMBIENTE" From srinivas.dama at oracle.com Tue Dec 12 14:33:23 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Tue, 12 Dec 2017 06:33:23 -0800 (PST) Subject: RFR: 8134516(Move getInvokeByName and getDynamicInvoker methods from Global to Context) Message-ID: Hi Attila, Thank you for the comments. I have resolved the bug as "will-not-fix" and added appropriate comments in the bug. So I am taking back this RFR. Regards, Srinivas ----- Original Message ----- From: szegedia at gmail.com To: srinivas.dama at oracle.com Cc: nashorn-dev at openjdk.java.net Sent: Monday, December 11, 2017 4:45:56 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi Subject: Re: RFR: 8134516(Move getInvokeByName and getDynamicInvoker methods from Global to Context) You shouldn't make Global.getContext() public. Context is a security-sensitive class, and the only public access to it is supposed to be through Context.getContext(), which includes a security check. I see you have also simply disabled that security check in your patch. I?m afraid that?s unacceptable. You could make the patch much smaller (and avoid security concerns altogether) if you kept Global.getInvokeByName and Global.getDynamicInvoker methods as they are and have them internally delegate to their new equivalents in Context, adding ?this? as the last argument as they do so. This is all in addition to Hannes? observation with regard to the performance implications in his previous e-mail. Attila. > On Dec 6, 2017, at 4:47 PM, Srinivas Dama wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8134516/webrev.01/ for > https://bugs.openjdk.java.net/browse/JDK-8134516 > > Regards, > Srinivas From hannes.wallnoefer at oracle.com Tue Dec 12 14:54:24 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 12 Dec 2017 15:54:24 +0100 Subject: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements In-Reply-To: <60679184-91a3-bc91-09bd-8c06e283a82e@oracle.com> References: <03416610-734e-7207-7fde-caa1b64ec670@oracle.com> <2CC9D6AB-B145-4409-80FD-8D68BDE5DDCE@gmail.com> <6c8580db-1d6c-7fe2-b333-d8ffb1193d1d@oracle.com> <60679184-91a3-bc91-09bd-8c06e283a82e@oracle.com> Message-ID: +1, and I like the fact that the patch has become smaller. Hannes > Am 12.12.2017 um 13:32 schrieb Priya Lakshmi Muthuswamy : > > Hi, > > Kindly review. I have modified the fix to work with multiple with scopes. > > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.01/ > > Thanks, > Priya > On 12/5/2017 12:54 PM, Priya Lakshmi Muthuswamy wrote: >> Hi Attila, >> >> Thanks for review. >> Yes when I checked with two with scopes as suggested(JavaImporter as outer), current fix doesn't work. I will work on that. >> >> Thanks, >> Priya >> On 12/5/2017 12:12 PM, Attila Szegedi wrote: >>> Hm? this seems to be an issue with shared scope calls; that?s why it?s sensitive to the number of similar statements. >>> >>> That said, here?s some thoughts: >>> >>> 1. Instead of >>> >>> if (self instanceof ScriptObject && ((ScriptObject)self).hasWithScope()) { >>> >>> you should be able to just use >>> >>> if (self instanceof ScriptObject) { >>> >>> As then you?ll evaluate getWithScopeObject and test it for being null anyway. This way, you avoid walking the prototype chain twice. >>> >>> 2. That said, I guess hasWithScope could be reimplemented simply as >>> >>> public boolean hasWithScope() { >>> return getWithScopeObject() != null; >>> } >>> >>> as both have very similar code, so it?d reduce to it nicely. (I understand that you haven?t changed that, but since you were in the vicinity of that code, you might as wel do it? It?s also fine if you leave it alone as it is.) >>> >>> 3. One of the statements in the test is indented differently than the others. >>> >>> 4. What happens if there?s _two_ with scopes, and the JavaImporter is in the outer one? Does this fix still work? E.g.: >>> >>> var imports = new JavaImporter(java.lang); >>> var dummy = { x: 42, y: 13 } >>> with (imports) { >>> with (dummy) { >>> function func() { >>> System.out.println('a'); >>> System.out.println('a'); >>> System.out.println('a'); >>> System.out.println('a'); >>> System.out.println('a'); >>> System.out.println('a'); >>> System.out.println('a'); >>> }; >>> func(); >>> } >>> } >>> >>> Attila. >>> >>>> On Dec 5, 2017, at 7:13 AM, Priya Lakshmi Muthuswamy wrote: >>>> >>>> Hi, >>>> >>>> please review JDK-8191301 : JavaImporter fails to resolve imported elements within functions, that contain too many statements >>>> >>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8191301 >>>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.00/ >>>> >>>> Thanks, >>>> Priya >>>> >>>> >> > From szegedia at gmail.com Tue Dec 12 15:19:15 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 12 Dec 2017 16:19:15 +0100 Subject: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements In-Reply-To: <60679184-91a3-bc91-09bd-8c06e283a82e@oracle.com> References: <03416610-734e-7207-7fde-caa1b64ec670@oracle.com> <2CC9D6AB-B145-4409-80FD-8D68BDE5DDCE@gmail.com> <6c8580db-1d6c-7fe2-b333-d8ffb1193d1d@oracle.com> <60679184-91a3-bc91-09bd-8c06e283a82e@oracle.com> Message-ID: <9065E950-1061-42C6-B910-6A817C2921EB@gmail.com> Hi Priya, This indeed looks much better, although I do have some remarks with regard to the the style of the code. Specifically, repetitions of identical code, as well as assignments inside predicates. There are several cases of code that is repeating: First is: ((NativeJavaImporter)...).createProperty(JSType.toString(name)) Which occurs twice. You can avoid this by creating a ?private static NativeJavaImporter getJavaImporter(Object self)? method that either returns self or does the lookup in scope, finally throws the type error if it found nothing. Then __noSuchProperty__ can be simply written as: return getJavaImporter(self).createProperty(JSType.toString(name)); You have a similar duplication of ((WithObject)obj).getExpression() in getJavaImporterInScope that you should avoid with an assignment to a (final) local variable. Also note that this method could return NativeJavaImporter as it already tests the expression for being an instanceof NativeJavaImporter. Basically, push the (NativeJavaImporter) cast down into getJavaImporterInScope; it?ll look nicer from the point of view of types than if you have to cast its return value in the caller. Assignment in if: that?s discouraged because visually it?s easy to overlook or mistake for a comparison check at a glance. Instead of ScriptObject expression; if (self instanceof ScriptObject && (expression = getJavaImporterInScope((ScriptObject)self))!=null) { return ((NativeJavaImporter)expression).createProperty(JSType.toString(name)); } use if (self instanceof ScriptObject) { final NativeJavaExporter expression = getJavaImporterInScope((ScriptObject)self); If (expression != null) { return ... } } Attila. > On Dec 12, 2017, at 1:32 PM, Priya Lakshmi Muthuswamy wrote: > > Hi, > > Kindly review. I have modified the fix to work with multiple with scopes. > > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.01/ > > Thanks, > Priya > On 12/5/2017 12:54 PM, Priya Lakshmi Muthuswamy wrote: >> Hi Attila, >> >> Thanks for review. >> Yes when I checked with two with scopes as suggested(JavaImporter as outer), current fix doesn't work. I will work on that. >> >> Thanks, >> Priya >> On 12/5/2017 12:12 PM, Attila Szegedi wrote: >>> Hm? this seems to be an issue with shared scope calls; that?s why it?s sensitive to the number of similar statements. >>> >>> That said, here?s some thoughts: >>> >>> 1. Instead of >>> >>> if (self instanceof ScriptObject && ((ScriptObject)self).hasWithScope()) { >>> >>> you should be able to just use >>> >>> if (self instanceof ScriptObject) { >>> >>> As then you?ll evaluate getWithScopeObject and test it for being null anyway. This way, you avoid walking the prototype chain twice. >>> >>> 2. That said, I guess hasWithScope could be reimplemented simply as >>> >>> public boolean hasWithScope() { >>> return getWithScopeObject() != null; >>> } >>> >>> as both have very similar code, so it?d reduce to it nicely. (I understand that you haven?t changed that, but since you were in the vicinity of that code, you might as wel do it? It?s also fine if you leave it alone as it is.) >>> >>> 3. One of the statements in the test is indented differently than the others. >>> >>> 4. What happens if there?s _two_ with scopes, and the JavaImporter is in the outer one? Does this fix still work? E.g.: >>> >>> var imports = new JavaImporter(java.lang); >>> var dummy = { x: 42, y: 13 } >>> with (imports) { >>> with (dummy) { >>> function func() { >>> System.out.println('a'); >>> System.out.println('a'); >>> System.out.println('a'); >>> System.out.println('a'); >>> System.out.println('a'); >>> System.out.println('a'); >>> System.out.println('a'); >>> }; >>> func(); >>> } >>> } >>> >>> Attila. >>> >>>> On Dec 5, 2017, at 7:13 AM, Priya Lakshmi Muthuswamy wrote: >>>> >>>> Hi, >>>> >>>> please review JDK-8191301 : JavaImporter fails to resolve imported elements within functions, that contain too many statements >>>> >>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8191301 >>>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.00/ >>>> >>>> Thanks, >>>> Priya >>>> >>>> >> > From szegedia at gmail.com Tue Dec 12 15:20:52 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 12 Dec 2017 16:20:52 +0100 Subject: RFR: 8069338: Implement sharedScopeCall for optimistic types In-Reply-To: <429DDC66-5165-44B3-BBD0-7092ADACC203@oracle.com> References: <04FA86C9-0CCA-4903-9EA0-8B197B12BA6A@oracle.com> <53FEFB83-06EE-449B-8288-13E10DE5B575@oracle.com> <5A2FD2E2.8000507@oracle.com> <429DDC66-5165-44B3-BBD0-7092ADACC203@oracle.com> Message-ID: <7E9EE1F3-851C-46C7-9538-30935053EBB0@gmail.com> I personally don?t believe anybody will ever be fidgeting with these, but it doesn?t hurt having them configurable, so? +1 :-) > On Dec 12, 2017, at 2:39 PM, Hannes Walln?fer wrote: > > Thanks for the review, Sundar. > > I think making thresholds configurable is a good idea. I?ve uploaded a new webrev where SHARED_CALL_THRESHOLD and SHARED_GET_THRESHOLD are configurable via ?nashorn.shared.scope.call.threshold? and ?nashorn.shared.scope.get.threshold? system properties, respectively. > > http://cr.openjdk.java.net/~hannesw/8069338/webrev.02/ > > Hannes > >> Am 12.12.2017 um 14:00 schrieb Sundararajan Athijegannathan : >> >> +1 >> >> PS. Not sure if it is worth making SHARED_GET_THRESHOLD configurable via System property? >> >> -Sundar >> >> On 12/12/17, 5:51 PM, Hannes Walln?fer wrote: >>> Thanks for the review, Attila. >>> >>> I?ve uploaded a new webrev with your suggested changes (including making ScriptObject.getProto(int) accept 0 argument and refactoring GET_PROTO code in CodeGenerator into a method). >>> >>> I have also done extensive performance testing over the last days and found that for some reason, shared methods for variable access has a very detrimental effect on performance for some reason. My theory is that we don?t save as much by making property access shared, and the flood of additional methods has some significant cost on codegen, runtime, JIT etc. Based on this I decided to increase the threshold for shared property access again to 100, which performs noticeably better than with the lower threshold in some benchmarks. >>> >>> New webrev is here: >>> >>> http://cr.openjdk.java.net/~hannesw/8069338/webrev.01/ >>> >>> Hannes >>> >>> >>>> Am 11.12.2017 um 11:55 schrieb Attila Szegedi: >>>> >>>> Reviewing this now, thanks for going ahead and implementing it! >>>> >>>> So what you are saying about slow scopes is that shared scopes were disabled anyway with them for some time, so you didn?t really take away functionality, just cleaned up the remains? >>>> >>>> So, some remarks: >>>> >>>> 1. I see the bytecode shape you wrote around invocation of ScriptObject.getProto(int), and I realized it?s weird it asserts n> 0 and it has the first getProto() unrolled before the loop. I?m pretty sure it can just look like this: >>>> >>>> public final ScriptObject getProto(final int n) { >>>> ScriptObject p = this; >>>> for (int i = n; i--> 0;) { >>>> p = p.getProto(); >>>> } >>>> return p; >>>> } >>>> >>>> That assert was there because we knew that it?s only CodeGenerator that emits calls to it, and it will always emit invocations with n> 0, but now we?d have a justification for invoking it with n == 0, so I think it?s fine to do it and avoid the no_proto_call branch in shared scope call bytecode. It?s not a big deal even if you leave it as-is, though. >>>> >>>> To be entirely pedantic, that assert in getProto should?ve read ?n> 1? before because the CodeGenerator was guaranteed to emit invocations to it with n> 1, so a really pedantic implementation of it should?ve read: >>>> >>>> public final ScriptObject getProto(final int n) { >>>> assert n> 1; >>>> ScriptObject p = getProto().getProto(); >>>> for (int i = n - 1; --i> 0;) { >>>> p = p.getProto(); >>>> } >>>> return p; >>>> } >>>> >>>> (God, I really hope everyone reading this realizes I?m joking with this last one.) >>>> >>>> FWIW, we could also factor out the: >>>> >>>> if (depth> 1) { >>>> method.load(depth); >>>> method.invoke(ScriptObject.GET_PROTO_DEPTH); >>>> } else { >>>> method.invoke(ScriptObject.GET_PROTO); >>>> } >>>> >>>> pattern in CodeGenerator into its own little ?emitGetProto(int depth)? method, as it appears twice (and make sure it asserts on depth> 0 ;-) ) >>>> >>>> 2. For that invocation of UnwarrantedOptimismException.withProgramPoint - I?d create a Call objects using CompilerConstants.virtualCallNoLookup and stash it in a static final field either in SharedScopeCall or UnwarrantedOptimismException; it?s more typesafe than writing type descriptors as strings. >>>> >>>> 3. So, UOE.hasPrimitiveReturnValue was unused, I take it? >>>> >>>> 3. In getStaticSignature you have another occurrence of number 3 that you can replace with FIXED_PARAM_COUNT :-) >>>> >>>> But these are all minor points? overall, this looks really good. >>>> >>>> Attila. >>>> >>>>> On Dec 6, 2017, at 6:43 PM, Hannes Walln?fer wrote: >>>>> >>>>> Please review: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8069338 >>>>> Webrev: http://cr.openjdk.java.net/~hannesw/8069338/webrev.00/ >>>>> >>>>> This implements shared scope calls for optimistic vars/calls. I followed Attila?s blueprint in the bug description to the last detail - thanks for figuring it all out. >>>>> >>>>> Some adjustments and cleanups I did along the way: >>>>> >>>>> - Originally shared scope calls were designed to support slow scope vars (with/eval). However, that feature was disabled later on. I refactored the code to make it clear that we only do shared scope calls for fast scope operations. >>>>> - I unified the threshold for all shared scope operations to 5. I don?t think there is a reason for different thresholds for different operations. I did some testing, using 5 as threshold appeared to be a sensible value. >>>>> >>>>> Running all of the octane benchmark I see a decrease in created callsites (200 000 to 178 000) and a slight decrease in callsite invalidations. >>>>> >>>>> Hannes > From priya.lakshmi.muthuswamy at oracle.com Tue Dec 12 17:31:14 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Tue, 12 Dec 2017 23:01:14 +0530 Subject: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements In-Reply-To: <9065E950-1061-42C6-B910-6A817C2921EB@gmail.com> References: <03416610-734e-7207-7fde-caa1b64ec670@oracle.com> <2CC9D6AB-B145-4409-80FD-8D68BDE5DDCE@gmail.com> <6c8580db-1d6c-7fe2-b333-d8ffb1193d1d@oracle.com> <60679184-91a3-bc91-09bd-8c06e283a82e@oracle.com> <9065E950-1061-42C6-B910-6A817C2921EB@gmail.com> Message-ID: <939b194a-b3cc-e0dc-18d1-40436de9d6c8@oracle.com> Hi Attila, I have modified the patch with your suggestions. webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.02/ Thanks, Priya On 12/12/2017 8:49 PM, Attila Szegedi wrote: > Hi Priya, > > This indeed looks much better, although I do have some remarks with regard to the the style of the code. Specifically, repetitions of identical code, as well as assignments inside predicates. > > There are several cases of code that is repeating: > First is: > > ((NativeJavaImporter)...).createProperty(JSType.toString(name)) > > Which occurs twice. You can avoid this by creating a ?private static NativeJavaImporter getJavaImporter(Object self)? method that either returns self or does the lookup in scope, finally throws the type error if it found nothing. Then __noSuchProperty__ can be simply written as: > > return getJavaImporter(self).createProperty(JSType.toString(name)); > > You have a similar duplication of ((WithObject)obj).getExpression() in getJavaImporterInScope that you should avoid with an assignment to a (final) local variable. > > Also note that this method could return NativeJavaImporter as it already tests the expression for being an instanceof NativeJavaImporter. Basically, push the (NativeJavaImporter) cast down into getJavaImporterInScope; it?ll look nicer from the point of view of types than if you have to cast its return value in the caller. > > Assignment in if: that?s discouraged because visually it?s easy to overlook or mistake for a comparison check at a glance. Instead of > > ScriptObject expression; > if (self instanceof ScriptObject && (expression = getJavaImporterInScope((ScriptObject)self))!=null) { > return ((NativeJavaImporter)expression).createProperty(JSType.toString(name)); > } > > use > > if (self instanceof ScriptObject) { > final NativeJavaExporter expression = getJavaImporterInScope((ScriptObject)self); > If (expression != null) { > return ... > } > } > > Attila. > >> On Dec 12, 2017, at 1:32 PM, Priya Lakshmi Muthuswamy wrote: >> >> Hi, >> >> Kindly review. I have modified the fix to work with multiple with scopes. >> >> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.01/ >> >> Thanks, >> Priya >> On 12/5/2017 12:54 PM, Priya Lakshmi Muthuswamy wrote: >>> Hi Attila, >>> >>> Thanks for review. >>> Yes when I checked with two with scopes as suggested(JavaImporter as outer), current fix doesn't work. I will work on that. >>> >>> Thanks, >>> Priya >>> On 12/5/2017 12:12 PM, Attila Szegedi wrote: >>>> Hm? this seems to be an issue with shared scope calls; that?s why it?s sensitive to the number of similar statements. >>>> >>>> That said, here?s some thoughts: >>>> >>>> 1. Instead of >>>> >>>> if (self instanceof ScriptObject && ((ScriptObject)self).hasWithScope()) { >>>> >>>> you should be able to just use >>>> >>>> if (self instanceof ScriptObject) { >>>> >>>> As then you?ll evaluate getWithScopeObject and test it for being null anyway. This way, you avoid walking the prototype chain twice. >>>> >>>> 2. That said, I guess hasWithScope could be reimplemented simply as >>>> >>>> public boolean hasWithScope() { >>>> return getWithScopeObject() != null; >>>> } >>>> >>>> as both have very similar code, so it?d reduce to it nicely. (I understand that you haven?t changed that, but since you were in the vicinity of that code, you might as wel do it? It?s also fine if you leave it alone as it is.) >>>> >>>> 3. One of the statements in the test is indented differently than the others. >>>> >>>> 4. What happens if there?s _two_ with scopes, and the JavaImporter is in the outer one? Does this fix still work? E.g.: >>>> >>>> var imports = new JavaImporter(java.lang); >>>> var dummy = { x: 42, y: 13 } >>>> with (imports) { >>>> with (dummy) { >>>> function func() { >>>> System.out.println('a'); >>>> System.out.println('a'); >>>> System.out.println('a'); >>>> System.out.println('a'); >>>> System.out.println('a'); >>>> System.out.println('a'); >>>> System.out.println('a'); >>>> }; >>>> func(); >>>> } >>>> } >>>> >>>> Attila. >>>> >>>>> On Dec 5, 2017, at 7:13 AM, Priya Lakshmi Muthuswamy wrote: >>>>> >>>>> Hi, >>>>> >>>>> please review JDK-8191301 : JavaImporter fails to resolve imported elements within functions, that contain too many statements >>>>> >>>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8191301 >>>>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.00/ >>>>> >>>>> Thanks, >>>>> Priya >>>>> >>>>> From szegedia at gmail.com Tue Dec 12 19:27:56 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 12 Dec 2017 20:27:56 +0100 Subject: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements In-Reply-To: <939b194a-b3cc-e0dc-18d1-40436de9d6c8@oracle.com> References: <03416610-734e-7207-7fde-caa1b64ec670@oracle.com> <2CC9D6AB-B145-4409-80FD-8D68BDE5DDCE@gmail.com> <6c8580db-1d6c-7fe2-b333-d8ffb1193d1d@oracle.com> <60679184-91a3-bc91-09bd-8c06e283a82e@oracle.com> <9065E950-1061-42C6-B910-6A817C2921EB@gmail.com> <939b194a-b3cc-e0dc-18d1-40436de9d6c8@oracle.com> Message-ID: <4671E01C-D663-4FD3-BB4A-43C04F63ACBB@gmail.com> This is generally acceptable, and while I really don?t want to be a pain, I?ll point out few minor things still, because I really want this code to be the best it can be :-) - in Nashorn code (and OpenJDK in general), we format ?else? and ?else if? to be on the same line as the closing brace of the previous block, so : if (?) { ? } else if (?) { ? } else { ? } - in Nashorn, we declare all method parameters to be final. - We strongly prefer final local variables with single-assignment whenever possible, so instead of early-initializing ?expression" to null in getJavaImporter and then overwriting it, the preferred style would be: final NativeJavaImporter expression; if (self instanceof NativeJavaImporter) { expression = (NativeJavaImporter)self; } else if (self instanceof ScriptObject) { expression = getJavaImporterInScope((ScriptObject)self); } else { expression = null; } return expression; The compiler will prove that a final variable is assigned exactly once on each branch. This code is fairly simple so it might not matter much, but it?s good to adopt this style of coding as it lets the compiler help you ensure you didn?t forget to initialize the variable on any path. Sometimes the early-initialization value, in this case null, wouldn?t be valid in all cases and by providing it early, you paper over all the missing cases and the compiler can?t tell if you overlooked something. On the other hand, if you declare the variable as final, it?ll report a compilation error if the variable is not initialized on every possible path. Alternatively, you could even do away with expression completely, and just use early return statements like this: if (self instanceof NativeJavaImporter) { return (NativeJavaImporter)self; } if (self instanceof ScriptObject) { return getJavaImporterInScope((ScriptObject)self); } return null; but I don?t consider that to be more valid than the above version with "final NativeJavaImporter expression?; they?re pretty much equivalent, albeit this last one is slightly shorter. Attila. > On 2017. Dec 12., at 18:31, Priya Lakshmi Muthuswamy wrote: > > Hi Attila, > > I have modified the patch with your suggestions. > > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.02/ > > Thanks, > Priya > > On 12/12/2017 8:49 PM, Attila Szegedi wrote: >> Hi Priya, >> >> This indeed looks much better, although I do have some remarks with regard to the the style of the code. Specifically, repetitions of identical code, as well as assignments inside predicates. >> >> There are several cases of code that is repeating: >> First is: >> >> ((NativeJavaImporter)...).createProperty(JSType.toString(name)) >> >> Which occurs twice. You can avoid this by creating a ?private static NativeJavaImporter getJavaImporter(Object self)? method that either returns self or does the lookup in scope, finally throws the type error if it found nothing. Then __noSuchProperty__ can be simply written as: >> >> return getJavaImporter(self).createProperty(JSType.toString(name)); >> >> You have a similar duplication of ((WithObject)obj).getExpression() in getJavaImporterInScope that you should avoid with an assignment to a (final) local variable. >> >> Also note that this method could return NativeJavaImporter as it already tests the expression for being an instanceof NativeJavaImporter. Basically, push the (NativeJavaImporter) cast down into getJavaImporterInScope; it?ll look nicer from the point of view of types than if you have to cast its return value in the caller. >> >> Assignment in if: that?s discouraged because visually it?s easy to overlook or mistake for a comparison check at a glance. Instead of >> >> ScriptObject expression; >> if (self instanceof ScriptObject && (expression = getJavaImporterInScope((ScriptObject)self))!=null) { >> return ((NativeJavaImporter)expression).createProperty(JSType.toString(name)); >> } >> >> use >> >> if (self instanceof ScriptObject) { >> final NativeJavaExporter expression = getJavaImporterInScope((ScriptObject)self); >> If (expression != null) { >> return ... >> } >> } >> >> Attila. >> >>> On Dec 12, 2017, at 1:32 PM, Priya Lakshmi Muthuswamy wrote: >>> >>> Hi, >>> >>> Kindly review. I have modified the fix to work with multiple with scopes. >>> >>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.01/ >>> >>> Thanks, >>> Priya >>> On 12/5/2017 12:54 PM, Priya Lakshmi Muthuswamy wrote: >>>> Hi Attila, >>>> >>>> Thanks for review. >>>> Yes when I checked with two with scopes as suggested(JavaImporter as outer), current fix doesn't work. I will work on that. >>>> >>>> Thanks, >>>> Priya >>>> On 12/5/2017 12:12 PM, Attila Szegedi wrote: >>>>> Hm? this seems to be an issue with shared scope calls; that?s why it?s sensitive to the number of similar statements. >>>>> >>>>> That said, here?s some thoughts: >>>>> >>>>> 1. Instead of >>>>> >>>>> if (self instanceof ScriptObject && ((ScriptObject)self).hasWithScope()) { >>>>> >>>>> you should be able to just use >>>>> >>>>> if (self instanceof ScriptObject) { >>>>> >>>>> As then you?ll evaluate getWithScopeObject and test it for being null anyway. This way, you avoid walking the prototype chain twice. >>>>> >>>>> 2. That said, I guess hasWithScope could be reimplemented simply as >>>>> >>>>> public boolean hasWithScope() { >>>>> return getWithScopeObject() != null; >>>>> } >>>>> >>>>> as both have very similar code, so it?d reduce to it nicely. (I understand that you haven?t changed that, but since you were in the vicinity of that code, you might as wel do it? It?s also fine if you leave it alone as it is.) >>>>> >>>>> 3. One of the statements in the test is indented differently than the others. >>>>> >>>>> 4. What happens if there?s _two_ with scopes, and the JavaImporter is in the outer one? Does this fix still work? E.g.: >>>>> >>>>> var imports = new JavaImporter(java.lang); >>>>> var dummy = { x: 42, y: 13 } >>>>> with (imports) { >>>>> with (dummy) { >>>>> function func() { >>>>> System.out.println('a'); >>>>> System.out.println('a'); >>>>> System.out.println('a'); >>>>> System.out.println('a'); >>>>> System.out.println('a'); >>>>> System.out.println('a'); >>>>> System.out.println('a'); >>>>> }; >>>>> func(); >>>>> } >>>>> } >>>>> >>>>> Attila. >>>>> >>>>>> On Dec 5, 2017, at 7:13 AM, Priya Lakshmi Muthuswamy wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> please review JDK-8191301 : JavaImporter fails to resolve imported elements within functions, that contain too many statements >>>>>> >>>>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8191301 >>>>>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Priya >>>>>> >>>>>> > From forax at univ-mlv.fr Tue Dec 12 19:41:27 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 12 Dec 2017 20:41:27 +0100 (CET) Subject: Any news from JDK-8151981 in Java8 ? In-Reply-To: References: <128E8DE6-4263-4806-B06E-17D3A7E9C065@oracle.com> <568631132.775855.1513086759540.JavaMail.zimbra@u-pem.fr> Message-ID: <522522624.926755.1513107687993.JavaMail.zimbra@u-pem.fr> It's just that i've seen several times setCallSiteTargetNormal in the profile and each time it was my fault, creating a GWT with the two branches swaped, invalidating SwitchPoints too vigorously, etc. R?mi ----- Mail original ----- > De: "Hannes Walln?fer" > ?: "Remi Forax" > Cc: "Jo?o Paulo Varandas" , "nashorn-dev" > Envoy?: Mardi 12 D?cembre 2017 15:35:02 > Objet: Re: Any news from JDK-8151981 in Java8 ? > Hi R?mi, > > Am 12.12.2017 um 14:52 schrieb Remi Forax : >> >> Hi Hannes, >> it can also be Nashorn triggering too much deoptimizations creating a >> deoptimization storm. > > I agree. But given that the problem manifests itself in java.lang.invoke I think > the first step is to understand what is going wrong there. Without a better > understanding of the problem it is very hard to provide provide any help. > > Hannes > > >> R?mi >> >> ----- Mail original ----- >>> De: "Hannes Walln?fer" >>> ?: "Jo?o Paulo Varandas" >>> Cc: nashorn-dev at openjdk.java.net >>> Envoy?: Mardi 12 D?cembre 2017 14:11:49 >>> Objet: Re: Any news from JDK-8151981 in Java8 ? >> >>> Hi Jo?o, >>> >>> this functionality is part of java.lang.invoke package, not Nashorn, so we can?t >>> help you here. >>> >>> The best place to ask about this would be the core-libs-dev mailing list. >>> >>> Regards, >>> Hannes >>> >>> >>>> Am 11.12.2017 um 23:07 schrieb Jo?o Paulo Varandas : >>>> >>>> Hi guys! >>>> >>>> We are also experiencing some odd issues here with setCallSiteTargetNormal. >>>> https://bugs.openjdk.java.net/browse/JDK-8151981 >>>> >>>> Our cenario is: >>>> >>>> - Web Application using Tomcat; >>>> - 8 HTTP Threads; >>>> - A single ScriptEngine for the whole application; >>>> >>>> When a request hits the server, that request may be processed by a Nashorn >>>> Script, this script is evaluated during runtime, run queries (Jdbc), and >>>> return results (Maps and/or Collections) that are serialized to JSON before >>>> being written to the response. >>>> >>>> The problem is... sometimes 7 or more threads are getting stuck in the >>>> setCallSiteTargetNormal and I have no clue why is that happening. Could you >>>> guys help me out troubleshooting this? - Or, if there's a bug, what are the >>>> recomended fixes I should do? >>>> >>>> >>>> By the way, those are not freshly created ScriptEngines (which differ from >>>> the normal issues related in the internet). >>>> >>>> -- >>>> "Esta mensagem, incluindo seus anexos, pode conter informacoes >>>> confidenciais e privilegiadas. >>>> Se voce a recebeu por engano, solicitamos que a apague e avise o remetente >>>> imediatamente. >>>> Opinioes ou informacoes aqui contidas nao refletem necessariamente a >>>> posicao oficial da Plusoft." >>>> >>>> "Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO > >>> AMBIENTE" From priya.lakshmi.muthuswamy at oracle.com Wed Dec 13 03:42:08 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Wed, 13 Dec 2017 09:12:08 +0530 Subject: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements In-Reply-To: <4671E01C-D663-4FD3-BB4A-43C04F63ACBB@gmail.com> References: <03416610-734e-7207-7fde-caa1b64ec670@oracle.com> <2CC9D6AB-B145-4409-80FD-8D68BDE5DDCE@gmail.com> <6c8580db-1d6c-7fe2-b333-d8ffb1193d1d@oracle.com> <60679184-91a3-bc91-09bd-8c06e283a82e@oracle.com> <9065E950-1061-42C6-B910-6A817C2921EB@gmail.com> <939b194a-b3cc-e0dc-18d1-40436de9d6c8@oracle.com> <4671E01C-D663-4FD3-BB4A-43C04F63ACBB@gmail.com> Message-ID: Thanks Attila, I have modified the patch webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.03/ Thanks, Priya On 12/13/2017 12:57 AM, Attila Szegedi wrote: > This is generally acceptable, and while I really don?t want to be a > pain, I?ll point out few minor things still, because I really want > this code to be the best it can be :-) > > - in Nashorn code (and OpenJDK in general), we format ?else? and ?else > if? to be on the same line as the closing brace of the previous block, > so : > > if (?) { > ? > } else if (?) { > ? > } else { > ? > } > > > - in Nashorn, we declare all method parameters to be final. > > - We strongly prefer final local variables with single-assignment > whenever possible, so instead of early-initializing ?expression" to > null in getJavaImporter and then overwriting it, the preferred style > would be: > > final NativeJavaImporter expression; > if (self instanceof NativeJavaImporter) { > ? ? expression = (NativeJavaImporter)self; > }?else if (self instanceof ScriptObject) { > ? ? expression = getJavaImporterInScope((ScriptObject)self); > } else { > ? ? expression = null; > } > return expression; > > > The compiler will prove that a final variable is assigned exactly once > on each branch. This code is fairly simple so it might not matter > much, but it?s good to adopt this style of coding as it lets the > compiler help you ensure you didn?t forget to initialize the variable > on any path. Sometimes the early-initialization value, in this case > null, wouldn?t be valid in all cases and by providing it early, you > paper over all the missing cases and the compiler can?t tell if you > overlooked something. On the other hand, if you declare the variable > as final, it?ll report a compilation error if the variable is not > initialized on every possible path. > > Alternatively, you could even do away with expression completely, and > just use early return statements like this: > > if (self instanceof NativeJavaImporter) { > ? ? return (NativeJavaImporter)self; > } > if (self instanceof ScriptObject) { > ? ? return getJavaImporterInScope((ScriptObject)self); > } > return null; > > but I don?t consider that to be more valid than the above version with > "final NativeJavaImporter expression?; they?re pretty much equivalent, > albeit this last one is slightly shorter. > > Attila. > >> On 2017. Dec 12., at 18:31, Priya Lakshmi Muthuswamy >> > > wrote: >> >> Hi Attila, >> >> I have modified the patch with your suggestions. >> >> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.02/ >> >> >> Thanks, >> Priya >> >> On 12/12/2017 8:49 PM, Attila Szegedi wrote: >>> Hi Priya, >>> >>> This indeed looks much better, although I do have some remarks with >>> regard to the the style of the code. Specifically, repetitions of >>> identical code, as well as assignments inside predicates. >>> >>> There are several cases of code that is repeating: >>> First is: >>> >>> ((NativeJavaImporter)...).createProperty(JSType.toString(name)) >>> >>> Which occurs twice. You can avoid this by creating a ?private static >>> NativeJavaImporter getJavaImporter(Object self)? method that either >>> returns self or does the lookup in scope, finally throws the?type >>> error if it found nothing. Then __noSuchProperty__ can be simply >>> written as: >>> >>> return getJavaImporter(self).createProperty(JSType.toString(name)); >>> >>> You have a similar duplication of ((WithObject)obj).getExpression() >>> in getJavaImporterInScope that you should avoid with an assignment >>> to a (final) local variable. >>> >>> Also note that this method could return NativeJavaImporter as it >>> already tests the expression for being an instanceof >>> NativeJavaImporter. Basically, push the (NativeJavaImporter) cast >>> down into?getJavaImporterInScope; it?ll look nicer from the point of >>> view of types than if you have to cast its return value in the caller. >>> >>> Assignment in if: that?s discouraged because visually it?s easy to >>> overlook or mistake for a comparison check at a glance. Instead of >>> >>> ScriptObject expression; >>> if (self instanceof ScriptObject && (expression ?= >>> getJavaImporterInScope((ScriptObject)self))!=null) { >>> ? ? return >>> ((NativeJavaImporter)expression).createProperty(JSType.toString(name)); >>> } >>> >>> use >>> >>> if (self instanceof ScriptObject) { >>> ? ? final NativeJavaExporter expression = >>> getJavaImporterInScope((ScriptObject)self); >>> ? ? If (expression != null) { >>> ? ? ? ? return ... >>> ? ? } >>> } >>> >>> Attila. >>> >>>> On Dec 12, 2017, at 1:32 PM, Priya Lakshmi Muthuswamy >>>> >>> > wrote: >>>> >>>> Hi, >>>> >>>> Kindly review. I have modified the fix to work with multiple with >>>> scopes. >>>> >>>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.01/ >>>> >>>> >>>> Thanks, >>>> Priya >>>> On 12/5/2017 12:54 PM, Priya Lakshmi Muthuswamy wrote: >>>>> Hi Attila, >>>>> >>>>> Thanks for review. >>>>> Yes when I checked with two with scopes as suggested(JavaImporter >>>>> as outer), current fix doesn't work. I will work on that. >>>>> >>>>> Thanks, >>>>> Priya >>>>> On 12/5/2017 12:12 PM, Attila Szegedi wrote: >>>>>> Hm? this seems to be an issue with shared scope calls; that?s why >>>>>> it?s sensitive to the number of similar statements. >>>>>> >>>>>> That said, here?s some thoughts: >>>>>> >>>>>> 1. Instead of >>>>>> >>>>>> ? ? if (self instanceof ScriptObject && >>>>>> ((ScriptObject)self).hasWithScope()) { >>>>>> >>>>>> you should be able to just use >>>>>> >>>>>> ? ? if (self instanceof ScriptObject) { >>>>>> >>>>>> As then you?ll evaluate getWithScopeObject and test it for being >>>>>> null anyway. This way, you avoid walking the prototype chain twice. >>>>>> >>>>>> 2. That said, I guess hasWithScope could be reimplemented simply as >>>>>> >>>>>> ? ? public boolean hasWithScope() { >>>>>> ? ? ? ? return getWithScopeObject() != null; >>>>>> ? ? } >>>>>> >>>>>> as both have very similar code, so it?d reduce to it nicely. (I >>>>>> understand that you haven?t changed that, but since you were in >>>>>> the vicinity of that code, you might as wel do it? It?s also fine >>>>>> if?you leave it alone as it is.) >>>>>> >>>>>> 3. One of the statements in the test is indented differently than >>>>>> the others. >>>>>> >>>>>> 4. What happens if there?s _two_ with scopes, and the >>>>>> JavaImporter is in the outer one? Does this fix still work? E.g.: >>>>>> >>>>>> var imports = new JavaImporter(java.lang); >>>>>> var dummy = { x: 42, y: 13 } >>>>>> with (imports) { >>>>>> ? ? ?with (dummy) { >>>>>> ? ? ? ? ?function func() { >>>>>> ? ? ? ? ? ? ?System.out.println('a'); >>>>>> ? ? ? ? ? ? System.out.println('a'); >>>>>> ? ? ? ? System.out.println('a'); >>>>>> ? ? ? ? ? ? ?System.out.println('a'); >>>>>> ? ? ? ? ? ? System.out.println('a'); >>>>>> ? ? ? ? System.out.println('a'); >>>>>> ? ? ? ? ? ? System.out.println('a'); >>>>>> ? ? ? ? ?}; >>>>>> ? ? ? ? ?func(); >>>>>> ? ? } >>>>>> } >>>>>> >>>>>> Attila. >>>>>> >>>>>>> On Dec 5, 2017, at 7:13 AM, Priya Lakshmi Muthuswamy >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> please review JDK-8191301 : JavaImporter fails to resolve >>>>>>> imported elements within functions, that contain too many statements >>>>>>> >>>>>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8191301 >>>>>>> webrev : >>>>>>> http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Priya >>>>>>> >>>>>>> >> > From szegedia at gmail.com Wed Dec 13 08:35:34 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 13 Dec 2017 09:35:34 +0100 Subject: RFR:8191301:JavaImporter fails to resolve imported elements within functions, that contain too many statements In-Reply-To: References: <03416610-734e-7207-7fde-caa1b64ec670@oracle.com> <2CC9D6AB-B145-4409-80FD-8D68BDE5DDCE@gmail.com> <6c8580db-1d6c-7fe2-b333-d8ffb1193d1d@oracle.com> <60679184-91a3-bc91-09bd-8c06e283a82e@oracle.com> <9065E950-1061-42C6-B910-6A817C2921EB@gmail.com> <939b194a-b3cc-e0dc-18d1-40436de9d6c8@oracle.com> <4671E01C-D663-4FD3-BB4A-43C04F63ACBB@gmail.com> Message-ID: Excellent! +1 Attila. > On 2017. Dec 13., at 4:42, Priya Lakshmi Muthuswamy wrote: > > Thanks Attila, I have modified the patch > > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.03/ Thanks, > Priya > On 12/13/2017 12:57 AM, Attila Szegedi wrote: >> This is generally acceptable, and while I really don?t want to be a pain, I?ll point out few minor things still, because I really want this code to be the best it can be :-) >> >> - in Nashorn code (and OpenJDK in general), we format ?else? and ?else if? to be on the same line as the closing brace of the previous block, so : >> >> if (?) { >> ? >> } else if (?) { >> ? >> } else { >> ? >> } >> >> - in Nashorn, we declare all method parameters to be final. >> >> - We strongly prefer final local variables with single-assignment whenever possible, so instead of early-initializing ?expression" to null in getJavaImporter and then overwriting it, the preferred style would be: >> >> final NativeJavaImporter expression; >> if (self instanceof NativeJavaImporter) { >> expression = (NativeJavaImporter)self; >> } else if (self instanceof ScriptObject) { >> expression = getJavaImporterInScope((ScriptObject)self); >> } else { >> expression = null; >> } >> return expression; >> >> The compiler will prove that a final variable is assigned exactly once on each branch. This code is fairly simple so it might not matter much, but it?s good to adopt this style of coding as it lets the compiler help you ensure you didn?t forget to initialize the variable on any path. Sometimes the early-initialization value, in this case null, wouldn?t be valid in all cases and by providing it early, you paper over all the missing cases and the compiler can?t tell if you overlooked something. On the other hand, if you declare the variable as final, it?ll report a compilation error if the variable is not initialized on every possible path. >> >> Alternatively, you could even do away with expression completely, and just use early return statements like this: >> >> if (self instanceof NativeJavaImporter) { >> return (NativeJavaImporter)self; >> } >> if (self instanceof ScriptObject) { >> return getJavaImporterInScope((ScriptObject)self); >> } >> return null; >> >> but I don?t consider that to be more valid than the above version with "final NativeJavaImporter expression?; they?re pretty much equivalent, albeit this last one is slightly shorter. >> >> Attila. >> >>> On 2017. Dec 12., at 18:31, Priya Lakshmi Muthuswamy > wrote: >>> >>> Hi Attila, >>> >>> I have modified the patch with your suggestions. >>> >>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.02/ >>> >>> Thanks, >>> Priya >>> >>> On 12/12/2017 8:49 PM, Attila Szegedi wrote: >>>> Hi Priya, >>>> >>>> This indeed looks much better, although I do have some remarks with regard to the the style of the code. Specifically, repetitions of identical code, as well as assignments inside predicates. >>>> >>>> There are several cases of code that is repeating: >>>> First is: >>>> >>>> ((NativeJavaImporter)...).createProperty(JSType.toString(name)) >>>> >>>> Which occurs twice. You can avoid this by creating a ?private static NativeJavaImporter getJavaImporter(Object self)? method that either returns self or does the lookup in scope, finally throws the type error if it found nothing. Then __noSuchProperty__ can be simply written as: >>>> >>>> return getJavaImporter(self).createProperty(JSType.toString(name)); >>>> >>>> You have a similar duplication of ((WithObject)obj).getExpression() in getJavaImporterInScope that you should avoid with an assignment to a (final) local variable. >>>> >>>> Also note that this method could return NativeJavaImporter as it already tests the expression for being an instanceof NativeJavaImporter. Basically, push the (NativeJavaImporter) cast down into getJavaImporterInScope; it?ll look nicer from the point of view of types than if you have to cast its return value in the caller. >>>> >>>> Assignment in if: that?s discouraged because visually it?s easy to overlook or mistake for a comparison check at a glance. Instead of >>>> >>>> ScriptObject expression; >>>> if (self instanceof ScriptObject && (expression = getJavaImporterInScope((ScriptObject)self))!=null) { >>>> return ((NativeJavaImporter)expression).createProperty(JSType.toString(name)); >>>> } >>>> >>>> use >>>> >>>> if (self instanceof ScriptObject) { >>>> final NativeJavaExporter expression = getJavaImporterInScope((ScriptObject)self); >>>> If (expression != null) { >>>> return ... >>>> } >>>> } >>>> >>>> Attila. >>>> >>>>> On Dec 12, 2017, at 1:32 PM, Priya Lakshmi Muthuswamy > wrote: >>>>> >>>>> Hi, >>>>> >>>>> Kindly review. I have modified the fix to work with multiple with scopes. >>>>> >>>>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.01/ >>>>> >>>>> Thanks, >>>>> Priya >>>>> On 12/5/2017 12:54 PM, Priya Lakshmi Muthuswamy wrote: >>>>>> Hi Attila, >>>>>> >>>>>> Thanks for review. >>>>>> Yes when I checked with two with scopes as suggested(JavaImporter as outer), current fix doesn't work. I will work on that. >>>>>> >>>>>> Thanks, >>>>>> Priya >>>>>> On 12/5/2017 12:12 PM, Attila Szegedi wrote: >>>>>>> Hm? this seems to be an issue with shared scope calls; that?s why it?s sensitive to the number of similar statements. >>>>>>> >>>>>>> That said, here?s some thoughts: >>>>>>> >>>>>>> 1. Instead of >>>>>>> >>>>>>> if (self instanceof ScriptObject && ((ScriptObject)self).hasWithScope()) { >>>>>>> >>>>>>> you should be able to just use >>>>>>> >>>>>>> if (self instanceof ScriptObject) { >>>>>>> >>>>>>> As then you?ll evaluate getWithScopeObject and test it for being null anyway. This way, you avoid walking the prototype chain twice. >>>>>>> >>>>>>> 2. That said, I guess hasWithScope could be reimplemented simply as >>>>>>> >>>>>>> public boolean hasWithScope() { >>>>>>> return getWithScopeObject() != null; >>>>>>> } >>>>>>> >>>>>>> as both have very similar code, so it?d reduce to it nicely. (I understand that you haven?t changed that, but since you were in the vicinity of that code, you might as wel do it? It?s also fine if you leave it alone as it is.) >>>>>>> >>>>>>> 3. One of the statements in the test is indented differently than the others. >>>>>>> >>>>>>> 4. What happens if there?s _two_ with scopes, and the JavaImporter is in the outer one? Does this fix still work? E.g.: >>>>>>> >>>>>>> var imports = new JavaImporter(java.lang); >>>>>>> var dummy = { x: 42, y: 13 } >>>>>>> with (imports) { >>>>>>> with (dummy) { >>>>>>> function func() { >>>>>>> System.out.println('a'); >>>>>>> System.out.println('a'); >>>>>>> System.out.println('a'); >>>>>>> System.out.println('a'); >>>>>>> System.out.println('a'); >>>>>>> System.out.println('a'); >>>>>>> System.out.println('a'); >>>>>>> }; >>>>>>> func(); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> Attila. >>>>>>> >>>>>>>> On Dec 5, 2017, at 7:13 AM, Priya Lakshmi Muthuswamy > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review JDK-8191301 : JavaImporter fails to resolve imported elements within functions, that contain too many statements >>>>>>>> >>>>>>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8191301 >>>>>>>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8191301/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Priya >>>>>>>> >>>>>>>> >>> >> > From szegedia at gmail.com Wed Dec 13 20:19:10 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 13 Dec 2017 21:19:10 +0100 Subject: Review request for JDK-8193296: Parser should not eagerly transform delete expressions In-Reply-To: <5A2EBFB1.7020106@oracle.com> References: <5A2E3151.9090404@oracle.com> <5A2EBFB1.7020106@oracle.com> Message-ID: <61B02C3B-4D07-4F92-AFD5-613F66780FA3@gmail.com> I updated the webrev with @bug and @summary in the tests: Attila. > On Dec 11, 2017, at 6:26 PM, Sundararajan Athijegannathan wrote: > > Hi, > > 1) @bug and @summary are for documentation purpose - explain what the test is all about (without having to look at JIRA...) > > 2) @modules is needed only if you want to add module exports for internal packages from other modules to your test (equivalent to --add-exports in java command line). That is not needed in this case (because you use only exported API packages from jdk.dynalink module). > > -Sundar > > On 11/12/17, 4:55 PM, Attila Szegedi wrote: >> Thanks! >> >> I admittedly cribbed the various @tags from the neighboring JDK_8188098_Test class :-). I take it ?@run testng ?? is meaningful and understood by jtreg then, so I can leave that as it is? I tried to find other examples and stumbled upon e.g. JDK_8184723_Test which specifies ?@run main/othervm? and also declares ?@modules? - is that something I should be doing as well, and can you advice what would be the correct values? >> >> Attila. >> >> >>> On Dec 11, 2017, at 8:18 AM, Sundararajan Athijegannathan wrote: >>> >>> * Test misses copyright comment >>> * you may want to add @bug and @summary line in jtreg comment section >>> >>> Other than that, +1 >>> >>> -Sundar >>> >>> On 10/12/17, 9:52 PM, Attila Szegedi wrote: >>>> Please review JDK-8193296 "Parser should not eagerly transform delete expressions" at> for> >>>> >>>> Thanks, >>>> Attila. >>>> From sundararajan.athijegannathan at oracle.com Wed Dec 13 23:07:43 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 14 Dec 2017 04:37:43 +0530 Subject: Review request for JDK-8193296: Parser should not eagerly transform delete expressions In-Reply-To: <61B02C3B-4D07-4F92-AFD5-613F66780FA3@gmail.com> References: <5A2E3151.9090404@oracle.com> <5A2EBFB1.7020106@oracle.com> <61B02C3B-4D07-4F92-AFD5-613F66780FA3@gmail.com> Message-ID: <5A31B2BF.1060007@oracle.com> Looks good. -Sundar On 14/12/17, 1:49 AM, Attila Szegedi wrote: > I updated the webrev with @bug and @summary in the tests: > > Attila. > >> On Dec 11, 2017, at 6:26 PM, Sundararajan Athijegannathan wrote: >> >> Hi, >> >> 1) @bug and @summary are for documentation purpose - explain what the test is all about (without having to look at JIRA...) >> >> 2) @modules is needed only if you want to add module exports for internal packages from other modules to your test (equivalent to --add-exports in java command line). That is not needed in this case (because you use only exported API packages from jdk.dynalink module). >> >> -Sundar >> >> On 11/12/17, 4:55 PM, Attila Szegedi wrote: >>> Thanks! >>> >>> I admittedly cribbed the various @tags from the neighboring JDK_8188098_Test class :-). I take it ?@run testng ?? is meaningful and understood by jtreg then, so I can leave that as it is? I tried to find other examples and stumbled upon e.g. JDK_8184723_Test which specifies ?@run main/othervm? and also declares ?@modules? - is that something I should be doing as well, and can you advice what would be the correct values? >>> >>> Attila. >>> >>> >>>> On Dec 11, 2017, at 8:18 AM, Sundararajan Athijegannathan wrote: >>>> >>>> * Test misses copyright comment >>>> * you may want to add @bug and @summary line in jtreg comment section >>>> >>>> Other than that, +1 >>>> >>>> -Sundar >>>> >>>> On 10/12/17, 9:52 PM, Attila Szegedi wrote: >>>>> Please review JDK-8193296 "Parser should not eagerly transform delete expressions" at> for> >>>>> >>>>> Thanks, >>>>> Attila. >>>>> From szegedia at gmail.com Thu Dec 14 11:42:26 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 14 Dec 2017 12:42:26 +0100 Subject: Review request for JDK-8193371: Use Dynalink REMOVE operation in Nashorn Message-ID: <9D34DB4D-C0CA-4881-BEB8-ED372433A7B9@gmail.com> Please review JDK-8193371 "Use Dynalink REMOVE operation in Nashorn" at for It looks bigger than it is. let me quickly explain this change in detail: There are some things that could make sense even if we didn?t refit delete operator on Dynalink REMOVE. * Fist such thing is moving the evaluation logic for the delete operator from AssignSymbols into CodeGenerator. That way, we eliminated a need to carry information from AS to CG in a RuntimeNode, and we could retire all of DELETE, SLOW_DELETE, and FAIL_DELETE RuntimeNode enums. It also allowed us to have cleaner expression of the code generator, e.g strict flag is handled more elegantly when deleting an IdentNode, and also we can just emit invocation of ScriptObject.delete on the scope object for IdentNode removals. There?s overall stronger typing (e.g. slow delete implementation has a better signature). * By not erasing ?delete? UnaryNodes in AssignSymbols anymore, I had to take a bit of special care in LocalVariableTypesCalculator to not treat deletes of IdentNodes as uses. * The changes in control flow of AbstractJavaLinker and BeanLinker getGuardedInvocationComponent are actual bug fixes that became apparent to me when I realized while writing the tests that the code as it was was failing to link REMOVE:PROPERTY|ELEMENT; it was incorrectly not trying all the namespaces it should?ve. (The bug was more generic than just that one operation combination: it?d affect e.g. SET:METHOD|PROPERTY too and some other combinations). As for actual delete operator through Dynalink: * MethodEmitter gained methods for emitting dynamic call sites for removal. Those are very similar to existing ones for dynamic getters and setters, nothing special there. * The logic formerly in ScriptRuntime.DELETE has now been spread into relevant linkers: ScriptObject.lookup, JSObjectLinker, Undefined.lookup, and NashornBottomLinker. The case in ScriptRuntime.DELETE for ?if (JSType.isPrimitive(obj))? doesn?t even have to be handled separately, primitive linking that instantiates wrappers takes care nicely of it. * That said, ScriptRuntime.DELETE had a final ?return true? fallback for POJOs, and I decided to improve on it. For one thing, theres an automatic improvement because delete now works as expected on Java lists and maps just by virtue of Dynalink providing that functionality. Another improvement that I decided to introduce manually is found in the way NashornBottomLinker handles delete on POJOs, specifically the uses of isNonConfigurableProperty. I tried treating all properties and methods of POJOs as if they were non-configurable properties (we try to treat them like that elsewhere in the code as well), so attempts to delete them will return false (non-strict) or throw a TypeError (strict), in accordance with ES 8.12.7 [[Delete]]. The newly added test file tries to exercise all new behavior. * Finally, NashornCallSiteDescriptor now needs 4 bits for the operation as we went from 8 operations to 10 with ?delete obj.name? and ?delete obj[index]". This again halved the number of program points available to 131072, but that's fortunately still about 10x what is really needed, so we should be good. Thanks, Attila. From hannes.wallnoefer at oracle.com Thu Dec 14 12:09:46 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 14 Dec 2017 13:09:46 +0100 Subject: Review request for JDK-8193296: Parser should not eagerly transform delete expressions In-Reply-To: <61B02C3B-4D07-4F92-AFD5-613F66780FA3@gmail.com> References: <5A2E3151.9090404@oracle.com> <5A2EBFB1.7020106@oracle.com> <61B02C3B-4D07-4F92-AFD5-613F66780FA3@gmail.com> Message-ID: <135D3F51-18E3-4FC6-9CE8-1797D00D9B14@oracle.com> +1 Hannes > Am 13.12.2017 um 21:19 schrieb Attila Szegedi : > > I updated the webrev with @bug and @summary in the tests: > > Attila. > >> On Dec 11, 2017, at 6:26 PM, Sundararajan Athijegannathan wrote: >> >> Hi, >> >> 1) @bug and @summary are for documentation purpose - explain what the test is all about (without having to look at JIRA...) >> >> 2) @modules is needed only if you want to add module exports for internal packages from other modules to your test (equivalent to --add-exports in java command line). That is not needed in this case (because you use only exported API packages from jdk.dynalink module). >> >> -Sundar >> >> On 11/12/17, 4:55 PM, Attila Szegedi wrote: >>> Thanks! >>> >>> I admittedly cribbed the various @tags from the neighboring JDK_8188098_Test class :-). I take it ?@run testng ?? is meaningful and understood by jtreg then, so I can leave that as it is? I tried to find other examples and stumbled upon e.g. JDK_8184723_Test which specifies ?@run main/othervm? and also declares ?@modules? - is that something I should be doing as well, and can you advice what would be the correct values? >>> >>> Attila. >>> >>> >>>> On Dec 11, 2017, at 8:18 AM, Sundararajan Athijegannathan wrote: >>>> >>>> * Test misses copyright comment >>>> * you may want to add @bug and @summary line in jtreg comment section >>>> >>>> Other than that, +1 >>>> >>>> -Sundar >>>> >>>> On 10/12/17, 9:52 PM, Attila Szegedi wrote: >>>>> Please review JDK-8193296 "Parser should not eagerly transform delete expressions" at> for> >>>>> >>>>> Thanks, >>>>> Attila. >>>>> > From hannes.wallnoefer at oracle.com Thu Dec 14 17:38:32 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 14 Dec 2017 18:38:32 +0100 Subject: RFR: 8193508: Expressions in split literals must never be optimistic Message-ID: <2F770FFE-873E-49F6-A780-E04EDF54AAE1@oracle.com> Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8193508 Webrev: http://cr.openjdk.java.net/~hannesw/8193508/webrev.00/ The actual fix is quite simple: stop visiting when we encounter a split object or array literal in OptimisticTypesCalculator. There are a few non-essential changes: - rename methods and fields in CodeGeneratorLexicalContext from *SplitNode to *SplitLiteral as the former is misleading (no actual SplitNodes around) - make sure we don?t have optimistic operations unless we generate optimistic code to avoid the situation that enabled this bug - add logging for split array and object nodes in Splitter - add some @Ignore annotations to make nodes behave in IR printer Thanks, Hannes From info at fiRelord.rU Thu Dec 14 19:08:33 2017 From: info at fiRelord.rU (nashorn-dev) Date: Fri, 15 Dec 2017 01:08:33 +0600 Subject: =?utf-8?B?UmU6IFJFOiBDYXNlICM6IDg3OTgxNzQzMzM=?= Message-ID: <8DE7A158-9534-4BB1-8FD0-533084AE4741@fiRelord.rU> U.S. Department of Justice FBI Internet Crime Investigation Center/Cyber Division FBI - Minneapolis Suite 1273 144 Washington Avenue, East MN 55224 Telephone: (888) 348-1766 Fax: (888) 348-1766 November 14, 2017 Case: 8791174132 The IP registered on your name was referred to the FBI's ICC Center (IC3) several times as being a possible victim of cyber fraud. We believe that your IP address was used to commit multiple computer fraud and abuse crimes. This investigation covers the time period from September 4, 2017 to the present date. We appreciate your immediate attention to this matter. Contact us urgently , at phone number provided below. Sincerely, Jeff Davis Internet Crime Investigation Center FBI - Minneapolis Suite 2362 135 Washington Avenue, West MN 55744 Phone: (888) 348-1766 Fax: (888) 348-1766 - Votre usage d?une plus value ou mat?riel apr?s site est pleinement ? toutes vos risques et p?rils , pour quoi nous ne serons pas g?rants . Il vous incombe de vous certifier que tous les articles , services ou pr?cisions vendus sur ce site Web r?pondent ? toutes vos exigences pr?cis . ce site web y a de l'?quipement qui nous appartient ou qui nous est comptable sous autorisation . Ce mat?riel inclut , mais n'est pas limit? ? , la conception , la mise en page , l'apparence , la forme et les graphismes . From sundararajan.athijegannathan at oracle.com Fri Dec 15 12:37:20 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 15 Dec 2017 18:07:20 +0530 Subject: Review request for JDK-8193371: Use Dynalink REMOVE operation in Nashorn In-Reply-To: <9D34DB4D-C0CA-4881-BEB8-ED372433A7B9@gmail.com> References: <9D34DB4D-C0CA-4881-BEB8-ED372433A7B9@gmail.com> Message-ID: <5A33C200.9050203@oracle.com> +1 Nice work! -Sundar On 14/12/17, 5:12 PM, Attila Szegedi wrote: > Please review JDK-8193371 "Use Dynalink REMOVE operation in Nashorn" at for > > It looks bigger than it is. let me quickly explain this change in detail: > > There are some things that could make sense even if we didn?t refit delete operator on Dynalink REMOVE. > > * Fist such thing is moving the evaluation logic for the delete operator from AssignSymbols into CodeGenerator. That way, we eliminated a need to carry information from AS to CG in a RuntimeNode, and we could retire all of DELETE, SLOW_DELETE, and FAIL_DELETE RuntimeNode enums. It also allowed us to have cleaner expression of the code generator, e.g strict flag is handled more elegantly when deleting an IdentNode, and also we can just emit invocation of ScriptObject.delete on the scope object for IdentNode removals. There?s overall stronger typing (e.g. slow delete implementation has a better signature). > > * By not erasing ?delete? UnaryNodes in AssignSymbols anymore, I had to take a bit of special care in LocalVariableTypesCalculator to not treat deletes of IdentNodes as uses. > > * The changes in control flow of AbstractJavaLinker and BeanLinker getGuardedInvocationComponent are actual bug fixes that became apparent to me when I realized while writing the tests that the code as it was was failing to link REMOVE:PROPERTY|ELEMENT; it was incorrectly not trying all the namespaces it should?ve. (The bug was more generic than just that one operation combination: it?d affect e.g. SET:METHOD|PROPERTY too and some other combinations). > > As for actual delete operator through Dynalink: > > * MethodEmitter gained methods for emitting dynamic call sites for removal. Those are very similar to existing ones for dynamic getters and setters, nothing special there. > > * The logic formerly in ScriptRuntime.DELETE has now been spread into relevant linkers: ScriptObject.lookup, JSObjectLinker, Undefined.lookup, and NashornBottomLinker. The case in ScriptRuntime.DELETE for ?if (JSType.isPrimitive(obj))? doesn?t even have to be handled separately, primitive linking that instantiates wrappers takes care nicely of it. > > * That said, ScriptRuntime.DELETE had a final ?return true? fallback for POJOs, and I decided to improve on it. For one thing, theres an automatic improvement because delete now works as expected on Java lists and maps just by virtue of Dynalink providing that functionality. Another improvement that I decided to introduce manually is found in the way NashornBottomLinker handles delete on POJOs, specifically the uses of isNonConfigurableProperty. I tried treating all properties and methods of POJOs as if they were non-configurable properties (we try to treat them like that elsewhere in the code as well), so attempts to delete them will return false (non-strict) or throw a TypeError (strict), in accordance with ES 8.12.7 [[Delete]]. The newly added test file tries to exercise all new behavior. > > * Finally, NashornCallSiteDescriptor now needs 4 bits for the operation as we went from 8 operations to 10 with ?delete obj.name? and ?delete obj[index]". This again halved the number of program points available to 131072, but that's fortunately still about 10x what is really needed, so we should be good. > > Thanks, > Attila. > From hannes.wallnoefer at oracle.com Fri Dec 15 12:43:47 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 15 Dec 2017 13:43:47 +0100 Subject: Review request for JDK-8193371: Use Dynalink REMOVE operation in Nashorn In-Reply-To: <9D34DB4D-C0CA-4881-BEB8-ED372433A7B9@gmail.com> References: <9D34DB4D-C0CA-4881-BEB8-ED372433A7B9@gmail.com> Message-ID: Nice work indeed. +1 Hannes > Am 14.12.2017 um 12:42 schrieb Attila Szegedi : > > Please review JDK-8193371 "Use Dynalink REMOVE operation in Nashorn" at for > > It looks bigger than it is. let me quickly explain this change in detail: > > There are some things that could make sense even if we didn?t refit delete operator on Dynalink REMOVE. > > * Fist such thing is moving the evaluation logic for the delete operator from AssignSymbols into CodeGenerator. That way, we eliminated a need to carry information from AS to CG in a RuntimeNode, and we could retire all of DELETE, SLOW_DELETE, and FAIL_DELETE RuntimeNode enums. It also allowed us to have cleaner expression of the code generator, e.g strict flag is handled more elegantly when deleting an IdentNode, and also we can just emit invocation of ScriptObject.delete on the scope object for IdentNode removals. There?s overall stronger typing (e.g. slow delete implementation has a better signature). > > * By not erasing ?delete? UnaryNodes in AssignSymbols anymore, I had to take a bit of special care in LocalVariableTypesCalculator to not treat deletes of IdentNodes as uses. > > * The changes in control flow of AbstractJavaLinker and BeanLinker getGuardedInvocationComponent are actual bug fixes that became apparent to me when I realized while writing the tests that the code as it was was failing to link REMOVE:PROPERTY|ELEMENT; it was incorrectly not trying all the namespaces it should?ve. (The bug was more generic than just that one operation combination: it?d affect e.g. SET:METHOD|PROPERTY too and some other combinations). > > As for actual delete operator through Dynalink: > > * MethodEmitter gained methods for emitting dynamic call sites for removal. Those are very similar to existing ones for dynamic getters and setters, nothing special there. > > * The logic formerly in ScriptRuntime.DELETE has now been spread into relevant linkers: ScriptObject.lookup, JSObjectLinker, Undefined.lookup, and NashornBottomLinker. The case in ScriptRuntime.DELETE for ?if (JSType.isPrimitive(obj))? doesn?t even have to be handled separately, primitive linking that instantiates wrappers takes care nicely of it. > > * That said, ScriptRuntime.DELETE had a final ?return true? fallback for POJOs, and I decided to improve on it. For one thing, theres an automatic improvement because delete now works as expected on Java lists and maps just by virtue of Dynalink providing that functionality. Another improvement that I decided to introduce manually is found in the way NashornBottomLinker handles delete on POJOs, specifically the uses of isNonConfigurableProperty. I tried treating all properties and methods of POJOs as if they were non-configurable properties (we try to treat them like that elsewhere in the code as well), so attempts to delete them will return false (non-strict) or throw a TypeError (strict), in accordance with ES 8.12.7 [[Delete]]. The newly added test file tries to exercise all new behavior. > > * Finally, NashornCallSiteDescriptor now needs 4 bits for the operation as we went from 8 operations to 10 with ?delete obj.name? and ?delete obj[index]". This again halved the number of program points available to 131072, but that's fortunately still about 10x what is really needed, so we should be good. > > Thanks, > Attila. > From hannes.wallnoefer at oracle.com Fri Dec 15 12:40:04 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 15 Dec 2017 13:40:04 +0100 Subject: Changes in Java 9 In-Reply-To: References: <97A626A8-3712-4C6D-B44C-82D76923AEFA@oracle.com> <95CF8D7E-48D2-4736-AE99-36C519BE8CC3@oracle.com> Message-ID: <5C251281-D89E-419E-8AD4-573FA70D2273@oracle.com> Hi Nils, Thanks for the code. Unfortunately you hit a bug in optimistic types, which is enabled by default in JDK 9. I?ve filed an issue for it and have a fix for it. https://bugs.openjdk.java.net/browse/JDK-8193508 The good news is that it is quite easy to work around this bug by disabling optimistic types. The way to do this is to use the NashornScriptEngineFactory class to create the script engine: import jdk.nashorn.api.scripting.NashornScriptEngineFactory; ... ScriptEngine engine = new NashornScriptEngineFactory().getScriptEngine("-ot=false"); Hannes > Am 06.12.2017 um 22:30 schrieb Nils Kilden-Pedersen : > > Hannes, > > I've sent an email with zip file attachment. > > Just letting you know in a separate email, in case it ends up being blocked. > > Nils > > On Wed, Dec 6, 2017 at 2:19 PM, Hannes Walln?fer wrote: > That would be https://bugs.openjdk.java.net/ but you need an OpenJDK account to file a bug. > > Alternatively, if you can send me something reproduce the bug (could be a small snippet of code) I can file it for you. > > Hannes > > > > Am 06.12.2017 um 16:15 schrieb Nils Kilden-Pedersen : > > > > What's the right place to file a bug? > > > > On Mon, Dec 4, 2017 at 9:56 AM, Nils Kilden-Pedersen > > wrote: > > > >> Thanks for bringing this up. It made me realize that my post was > >> incomplete. > >> > >> These are the steps I take: > >> > >> 1. Initial step: Call engine.compile with the CS compiler source + > >> CoffeeScript.compile(coffeeCode, {runtime: 'none'}); which returns > >> CompiledScript that is retained and re-used. This works fine, also on > >> JDK 9.0.1. > >> 2. For subsequent Coffeescript -> Javascript transpilation, I then > >> call engine.createBindings() > >> 3. Then bindings.put("coffeeCode", csCode) to associate the CS code > >> with the JS variable coffeeCode mentioned in initial step > >> 4. Call CompiledScript.eval(bindings). This is the step that fails in > >> 9.0.1. > >> > >> I?m open to better ways to achieve this, if it?s inefficient or plain > >> wrong. > >> ? > >> > >> On Mon, Dec 4, 2017 at 8:47 AM, Hannes Walln?fer < > >> hannes.wallnoefer at oracle.com> wrote: > >> > >>> Hi Nils, > >>> > >>> Are you just evaluating the script files you linked in your first > >>> message, or trying to do some further processing? > >>> > >>> Using the jjs tool from JDK 9.0.1 I see no errors running both versions > >>> of CoffeeScript. > >>> > >>> Hannes > >>> > >>>> Am 03.12.2017 um 21:08 schrieb Nils Kilden-Pedersen : > >>>> > >>>> Ok, the minified vs non-minified may not be identical. I cannot find the > >>>> default parameters in the minified version, so perhaps those are > >>> removed. > >>>> > >>>> What does remain however, is that I can compile minified cs2 > >>>> on JDK > >>> 8_144, > >>>> but not on 9.0.1. > >>>> > >>>> > >>>> On Sun, Dec 3, 2017 at 1:39 PM, Nils Kilden-Pedersen > >>>> wrote: > >>>> > >>>>> Further testing with the un-minified code (cs2 > >>>>> , > >>> cs1 > >>>>> ) > >>>>> reveals the true problems in JDK 9.0.1 > >>>>> > >>>>> In cs2, it?s ES6 syntax (default args), which (unexpectedly for me at > >>>>> least), works in JDK 8: > >>>>> > >>>>> :46:45 Expected , but found = > >>>>> CoffeeScript.eval = function(code, options = {}) { > >>>>> ^ in at line number > >>> 46 at column number 45 > >>>>> > >>>>> And in cs1 it?s require that?s unresolved (also works in JDK 8): > >>>>> > >>>>> ReferenceError: "require" is not defined in at line number 7 > >>>>> > >>>>> ? > >>>>> > >>>>> On Sun, Dec 3, 2017 at 11:02 AM, Nils Kilden-Pedersen < > >>> nilskp at gmail.com> > >>>>> wrote: > >>>>> > >>>>>> I just switched to the Java 9.0.1 runtime, and Nashorn now fails to > >>> parse > >>>>>> the Coffeescript compiler, which worked fine in Java 8_144. > >>>>>> > >>>>>> Coffeescript 2 compiler: http://coffeescript.org/v2/bro > >>>>>> wser-compiler/coffeescript.js > >>>>>> > >>>>>> v1 also fails: http://coffeescript.org/v1/bro > >>>>>> wser-compiler/coffee-script.js > >>>>>> > >>>>>> Exception is: > >>>>>> > >>>>>> javax.script.ScriptException: SyntaxError: unexpected in at > >>> line number 39 at column number 249736 > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip > >>> tEngine.throwAsScriptException(NashornScriptEngine.java:469) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip > >>> tEngine.evalImpl(NashornScriptEngine.java:425) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip > >>> tEngine.access$300(NashornScriptEngine.java:72) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip > >>> tEngine$3.eval(NashornScriptEngine.java:513) > >>>>>> at java.scripting/javax.script.CompiledScript.eval(CompiledScri > >>> pt.java:92) > >>>>>> at scuff.js.CoffeeScriptCompiler.compile(CoffeeScriptCompiler.s > >>> cala:115) > >>>>>> at scuff.js.TestCoffeeScriptCompiler.cs2(TestCoffeeScriptCompil > >>> er.scala:114) > >>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >>> Method) > >>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo > >>> ke(NativeMethodAccessorImpl.java:62) > >>>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. > >>> invoke(DelegatingMethodAccessorImpl.java:43) > >>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) > >>>>>> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall( > >>> FrameworkMethod.java:50) > >>>>>> at org.junit.internal.runners.model.ReflectiveCallable.run(Refl > >>> ectiveCallable.java:12) > >>>>>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr > >>> ameworkMethod.java:47) > >>>>>> at org.junit.internal.runners.statements.InvokeMethod.evaluate( > >>> InvokeMethod.java:17) > >>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > >>>>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit > >>> 4ClassRunner.java:78) > >>>>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit > >>> 4ClassRunner.java:57) > >>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > >>>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > >>>>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > >>>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > >>>>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > >>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > >>>>>> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference. > >>> run(JUnit4TestReference.java:86) > >>>>>> at org.eclipse.jdt.internal.junit.runner.TestExecution.run( > >>> TestExecution.java:38) > >>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe > >>> sts(RemoteTestRunner.java:539) > >>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe > >>> sts(RemoteTestRunner.java:761) > >>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run( > >>> RemoteTestRunner.java:461) > >>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( > >>> RemoteTestRunner.java:207) > >>>>>> Caused by: :39:249736 SyntaxError: unexpected > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeErr > >>> or.initException(NativeError.java:135) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn > >>> taxError.(NativeSyntaxError.java:73) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn > >>> taxError.(NativeSyntaxError.java:77) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn > >>> taxError.constructor(NativeSyntaxError.java:98) > >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S > >>> cript$Recompilation$2368$6956AA$\^eval\_.L:39-1#a#L:39-1#L: > >>> 39#throwSyntaxError(:39) > >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S > >>> cript$Recompilation$2364$253073AA$\^eval\_$cu1$restOf.L:39- > >>> 1#a#L:39-8#L:39#parseError(:39) > >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S > >>> cript$Recompilation$2359$\^eval\_$cu1$restOf.L:39-1#a#L:39- > >>> 4#o#parse(:39) > >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S > >>> cript$Recompilation$2343$\^eval\_$cu1$restOf.L:39-1#a#L:39- > >>> 8#L:39#p(:39) > >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S > >>> cript$Recompilation$2056$250675AA$\^eval\_.L:39-1#a#L:39-8# > >>> L:39#T#L:39(:39) > >>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S > >>> cript$Recompilation$1572$\^eval\_.:program(:41) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFun > >>> ctionData.invoke(ScriptFunctionData.java:652) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFun > >>> ction.invoke(ScriptFunction.java:513) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRun > >>> time.apply(ScriptRuntime.java:517) > >>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip > >>> tEngine.evalImpl(NashornScriptEngine.java:420) > >>>>>> ... 28 more > >>>>>> > >>>>>> ? > >>>>>> > >>>>> > >>>>> > >>> > >>> > >> > > From sundararajan.athijegannathan at oracle.com Fri Dec 15 13:19:05 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 15 Dec 2017 18:49:05 +0530 Subject: Changes in Java 9 In-Reply-To: <5C251281-D89E-419E-8AD4-573FA70D2273@oracle.com> References: <97A626A8-3712-4C6D-B44C-82D76923AEFA@oracle.com> <95CF8D7E-48D2-4736-AE99-36C519BE8CC3@oracle.com> <5C251281-D89E-419E-8AD4-573FA70D2273@oracle.com> Message-ID: <5A33CBC9.4040502@oracle.com> Adding to what Hannes said. In case if you cannot modify existing code, you can also pass options to nashorn engine via System property "nashorn.args" - all nashorn engines created in the process will be initialized with those options. For example: java -Dnashorn.args="-ot=false" Main See also: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes -Sundar On 15/12/17, 6:10 PM, Hannes Walln?fer wrote: > Hi Nils, > > Thanks for the code. Unfortunately you hit a bug in optimistic types, which is enabled by default in JDK 9. I?ve filed an issue for it and have a fix for it. > > https://bugs.openjdk.java.net/browse/JDK-8193508 > > The good news is that it is quite easy to work around this bug by disabling optimistic types. The way to do this is to use the NashornScriptEngineFactory class to create the script engine: > > import jdk.nashorn.api.scripting.NashornScriptEngineFactory; > > ... > ScriptEngine engine = new NashornScriptEngineFactory().getScriptEngine("-ot=false"); > > Hannes > > >> Am 06.12.2017 um 22:30 schrieb Nils Kilden-Pedersen: >> >> Hannes, >> >> I've sent an email with zip file attachment. >> >> Just letting you know in a separate email, in case it ends up being blocked. >> >> Nils >> >> On Wed, Dec 6, 2017 at 2:19 PM, Hannes Walln?fer wrote: >> That would be https://bugs.openjdk.java.net/ but you need an OpenJDK account to file a bug. >> >> Alternatively, if you can send me something reproduce the bug (could be a small snippet of code) I can file it for you. >> >> Hannes >> >> >>> Am 06.12.2017 um 16:15 schrieb Nils Kilden-Pedersen: >>> >>> What's the right place to file a bug? >>> >>> On Mon, Dec 4, 2017 at 9:56 AM, Nils Kilden-Pedersen >>> wrote: >>> >>>> Thanks for bringing this up. It made me realize that my post was >>>> incomplete. >>>> >>>> These are the steps I take: >>>> >>>> 1. Initial step: Call engine.compile with the CS compiler source + >>>> CoffeeScript.compile(coffeeCode, {runtime: 'none'}); which returns >>>> CompiledScript that is retained and re-used. This works fine, also on >>>> JDK 9.0.1. >>>> 2. For subsequent Coffeescript -> Javascript transpilation, I then >>>> call engine.createBindings() >>>> 3. Then bindings.put("coffeeCode", csCode) to associate the CS code >>>> with the JS variable coffeeCode mentioned in initial step >>>> 4. Call CompiledScript.eval(bindings). This is the step that fails in >>>> 9.0.1. >>>> >>>> I?m open to better ways to achieve this, if it?s inefficient or plain >>>> wrong. >>>> ? >>>> >>>> On Mon, Dec 4, 2017 at 8:47 AM, Hannes Walln?fer< >>>> hannes.wallnoefer at oracle.com> wrote: >>>> >>>>> Hi Nils, >>>>> >>>>> Are you just evaluating the script files you linked in your first >>>>> message, or trying to do some further processing? >>>>> >>>>> Using the jjs tool from JDK 9.0.1 I see no errors running both versions >>>>> of CoffeeScript. >>>>> >>>>> Hannes >>>>> >>>>>> Am 03.12.2017 um 21:08 schrieb Nils Kilden-Pedersen: >>>>>> >>>>>> Ok, the minified vs non-minified may not be identical. I cannot find the >>>>>> default parameters in the minified version, so perhaps those are >>>>> removed. >>>>>> What does remain however, is that I can compile minified cs2 >>>>>> on JDK >>>>> 8_144, >>>>>> but not on 9.0.1. >>>>>> >>>>>> >>>>>> On Sun, Dec 3, 2017 at 1:39 PM, Nils Kilden-Pedersen >>>>>> wrote: >>>>>> >>>>>>> Further testing with the un-minified code (cs2 >>>>>>> , >>>>> cs1 >>>>>>> ) >>>>>>> reveals the true problems in JDK 9.0.1 >>>>>>> >>>>>>> In cs2, it?s ES6 syntax (default args), which (unexpectedly for me at >>>>>>> least), works in JDK 8: >>>>>>> >>>>>>> :46:45 Expected , but found = >>>>>>> CoffeeScript.eval = function(code, options = {}) { >>>>>>> ^ in at line number >>>>> 46 at column number 45 >>>>>>> And in cs1 it?s require that?s unresolved (also works in JDK 8): >>>>>>> >>>>>>> ReferenceError: "require" is not defined in at line number 7 >>>>>>> >>>>>>> ? >>>>>>> >>>>>>> On Sun, Dec 3, 2017 at 11:02 AM, Nils Kilden-Pedersen< >>>>> nilskp at gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I just switched to the Java 9.0.1 runtime, and Nashorn now fails to >>>>> parse >>>>>>>> the Coffeescript compiler, which worked fine in Java 8_144. >>>>>>>> >>>>>>>> Coffeescript 2 compiler: http://coffeescript.org/v2/bro >>>>>>>> wser-compiler/coffeescript.js >>>>>>>> >>>>>>>> v1 also fails: http://coffeescript.org/v1/bro >>>>>>>> wser-compiler/coffee-script.js >>>>>>>> >>>>>>>> Exception is: >>>>>>>> >>>>>>>> javax.script.ScriptException: SyntaxError: unexpected in at >>>>> line number 39 at column number 249736 >>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>>>> tEngine.throwAsScriptException(NashornScriptEngine.java:469) >>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>>>> tEngine.evalImpl(NashornScriptEngine.java:425) >>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>>>> tEngine.access$300(NashornScriptEngine.java:72) >>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>>>> tEngine$3.eval(NashornScriptEngine.java:513) >>>>>>>> at java.scripting/javax.script.CompiledScript.eval(CompiledScri >>>>> pt.java:92) >>>>>>>> at scuff.js.CoffeeScriptCompiler.compile(CoffeeScriptCompiler.s >>>>> cala:115) >>>>>>>> at scuff.js.TestCoffeeScriptCompiler.cs2(TestCoffeeScriptCompil >>>>> er.scala:114) >>>>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>> Method) >>>>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >>>>> ke(NativeMethodAccessorImpl.java:62) >>>>>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. >>>>> invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >>>>>>>> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall( >>>>> FrameworkMethod.java:50) >>>>>>>> at org.junit.internal.runners.model.ReflectiveCallable.run(Refl >>>>> ectiveCallable.java:12) >>>>>>>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr >>>>> ameworkMethod.java:47) >>>>>>>> at org.junit.internal.runners.statements.InvokeMethod.evaluate( >>>>> InvokeMethod.java:17) >>>>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >>>>>>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit >>>>> 4ClassRunner.java:78) >>>>>>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit >>>>> 4ClassRunner.java:57) >>>>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >>>>>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >>>>>>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >>>>>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >>>>>>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >>>>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >>>>>>>> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference. >>>>> run(JUnit4TestReference.java:86) >>>>>>>> at org.eclipse.jdt.internal.junit.runner.TestExecution.run( >>>>> TestExecution.java:38) >>>>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe >>>>> sts(RemoteTestRunner.java:539) >>>>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe >>>>> sts(RemoteTestRunner.java:761) >>>>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run( >>>>> RemoteTestRunner.java:461) >>>>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( >>>>> RemoteTestRunner.java:207) >>>>>>>> Caused by::39:249736 SyntaxError: unexpected >>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeErr >>>>> or.initException(NativeError.java:135) >>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn >>>>> taxError.(NativeSyntaxError.java:73) >>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn >>>>> taxError.(NativeSyntaxError.java:77) >>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn >>>>> taxError.constructor(NativeSyntaxError.java:98) >>>>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>>>> cript$Recompilation$2368$6956AA$\^eval\_.L:39-1#a#L:39-1#L: >>>>> 39#throwSyntaxError(:39) >>>>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>>>> cript$Recompilation$2364$253073AA$\^eval\_$cu1$restOf.L:39- >>>>> 1#a#L:39-8#L:39#parseError(:39) >>>>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>>>> cript$Recompilation$2359$\^eval\_$cu1$restOf.L:39-1#a#L:39- >>>>> 4#o#parse(:39) >>>>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>>>> cript$Recompilation$2343$\^eval\_$cu1$restOf.L:39-1#a#L:39- >>>>> 8#L:39#p(:39) >>>>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>>>> cript$Recompilation$2056$250675AA$\^eval\_.L:39-1#a#L:39-8# >>>>> L:39#T#L:39(:39) >>>>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>>>> cript$Recompilation$1572$\^eval\_.:program(:41) >>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFun >>>>> ctionData.invoke(ScriptFunctionData.java:652) >>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFun >>>>> ction.invoke(ScriptFunction.java:513) >>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRun >>>>> time.apply(ScriptRuntime.java:517) >>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>>>> tEngine.evalImpl(NashornScriptEngine.java:420) >>>>>>>> ... 28 more >>>>>>>> >>>>>>>> ? >>>>>>>> >>>>>>> >>>>> >> From nils at kilden-pedersen.net Fri Dec 15 22:38:08 2017 From: nils at kilden-pedersen.net (Nils Kilden-Pedersen) Date: Fri, 15 Dec 2017 16:38:08 -0600 Subject: Changes in Java 9 In-Reply-To: <5A33CBC9.4040502@oracle.com> References: <97A626A8-3712-4C6D-B44C-82D76923AEFA@oracle.com> <95CF8D7E-48D2-4736-AE99-36C519BE8CC3@oracle.com> <5C251281-D89E-419E-8AD4-573FA70D2273@oracle.com> <5A33CBC9.4040502@oracle.com> Message-ID: Excellent, that appears to work. Thanks both! On Fri, Dec 15, 2017 at 7:19 AM, Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Adding to what Hannes said. In case if you cannot modify existing code, > you can also pass options to nashorn engine via System property > "nashorn.args" - all nashorn engines created in the process will be > initialized with those options. > > For example: > > java -Dnashorn.args="-ot=false" Main > > See also: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223 > +engine+notes > > -Sundar > > > On 15/12/17, 6:10 PM, Hannes Walln?fer wrote: > >> Hi Nils, >> >> Thanks for the code. Unfortunately you hit a bug in optimistic types, >> which is enabled by default in JDK 9. I?ve filed an issue for it and have a >> fix for it. >> >> https://bugs.openjdk.java.net/browse/JDK-8193508 >> >> The good news is that it is quite easy to work around this bug by >> disabling optimistic types. The way to do this is to use the >> NashornScriptEngineFactory class to create the script engine: >> >> import jdk.nashorn.api.scripting.NashornScriptEngineFactory; >> >> ... >> ScriptEngine engine = new NashornScriptEngineFactory().g >> etScriptEngine("-ot=false"); >> >> Hannes >> >> >> Am 06.12.2017 um 22:30 schrieb Nils Kilden-Pedersen: >>> >>> Hannes, >>> >>> I've sent an email with zip file attachment. >>> >>> Just letting you know in a separate email, in case it ends up being >>> blocked. >>> >>> Nils >>> >>> On Wed, Dec 6, 2017 at 2:19 PM, Hannes Walln?fer>> acle.com> wrote: >>> That would be https://bugs.openjdk.java.net/ but you need an OpenJDK >>> account to file a bug. >>> >>> Alternatively, if you can send me something reproduce the bug (could be >>> a small snippet of code) I can file it for you. >>> >>> Hannes >>> >>> >>> Am 06.12.2017 um 16:15 schrieb Nils Kilden-Pedersen: >>>> >>>> What's the right place to file a bug? >>>> >>>> On Mon, Dec 4, 2017 at 9:56 AM, Nils Kilden-Pedersen >>>> wrote: >>>> >>>> Thanks for bringing this up. It made me realize that my post was >>>>> incomplete. >>>>> >>>>> These are the steps I take: >>>>> >>>>> 1. Initial step: Call engine.compile with the CS compiler source + >>>>> CoffeeScript.compile(coffeeCode, {runtime: 'none'}); which returns >>>>> CompiledScript that is retained and re-used. This works fine, also >>>>> on >>>>> JDK 9.0.1. >>>>> 2. For subsequent Coffeescript -> Javascript transpilation, I then >>>>> call engine.createBindings() >>>>> 3. Then bindings.put("coffeeCode", csCode) to associate the CS code >>>>> with the JS variable coffeeCode mentioned in initial step >>>>> 4. Call CompiledScript.eval(bindings). This is the step that fails >>>>> in >>>>> 9.0.1. >>>>> >>>>> I?m open to better ways to achieve this, if it?s inefficient or plain >>>>> wrong. >>>>> ? >>>>> >>>>> On Mon, Dec 4, 2017 at 8:47 AM, Hannes Walln?fer< >>>>> hannes.wallnoefer at oracle.com> wrote: >>>>> >>>>> Hi Nils, >>>>>> >>>>>> Are you just evaluating the script files you linked in your first >>>>>> message, or trying to do some further processing? >>>>>> >>>>>> Using the jjs tool from JDK 9.0.1 I see no errors running both >>>>>> versions >>>>>> of CoffeeScript. >>>>>> >>>>>> Hannes >>>>>> >>>>>> Am 03.12.2017 um 21:08 schrieb Nils Kilden-Pedersen>>>>>> >: >>>>>>> >>>>>>> Ok, the minified vs non-minified may not be identical. I cannot find >>>>>>> the >>>>>>> default parameters in the minified version, so perhaps those are >>>>>>> >>>>>> removed. >>>>>> >>>>>>> What does remain however, is that I can compile minified cs2 >>>>>>> on >>>>>>> JDK >>>>>>> >>>>>> 8_144, >>>>>> >>>>>>> but not on 9.0.1. >>>>>>> >>>>>>> >>>>>>> On Sun, Dec 3, 2017 at 1:39 PM, Nils Kilden-Pedersen>>>>>> om> >>>>>>> wrote: >>>>>>> >>>>>>> Further testing with the un-minified code (cs2 >>>>>>>> , >>>>>>>> >>>>>>> cs1 >>>>>> >>>>>>> >>>>>>> >) >>>>>>>> reveals the true problems in JDK 9.0.1 >>>>>>>> >>>>>>>> In cs2, it?s ES6 syntax (default args), which (unexpectedly for me >>>>>>>> at >>>>>>>> least), works in JDK 8: >>>>>>>> >>>>>>>> :46:45 Expected , but found = >>>>>>>> CoffeeScript.eval = function(code, options = {}) { >>>>>>>> ^ in at line >>>>>>>> number >>>>>>>> >>>>>>> 46 at column number 45 >>>>>> >>>>>>> And in cs1 it?s require that?s unresolved (also works in JDK 8): >>>>>>>> >>>>>>>> ReferenceError: "require" is not defined in at line number 7 >>>>>>>> >>>>>>>> ? >>>>>>>> >>>>>>>> On Sun, Dec 3, 2017 at 11:02 AM, Nils Kilden-Pedersen< >>>>>>>> >>>>>>> nilskp at gmail.com> >>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> I just switched to the Java 9.0.1 runtime, and Nashorn now fails to >>>>>>>>> >>>>>>>> parse >>>>>> >>>>>>> the Coffeescript compiler, which worked fine in Java 8_144. >>>>>>>>> >>>>>>>>> Coffeescript 2 compiler: http://coffeescript.org/v2/bro >>>>>>>>> wser-compiler/coffeescript.js >>>>>>>>> >>>>>>>>> v1 also fails: http://coffeescript.org/v1/bro >>>>>>>>> wser-compiler/coffee-script.js >>>>>>>>> >>>>>>>>> Exception is: >>>>>>>>> >>>>>>>>> javax.script.ScriptException: SyntaxError: unexpected in at >>>>>>>>> >>>>>>>> line number 39 at column number 249736 >>>>>> >>>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>>>>>>>> >>>>>>>> tEngine.throwAsScriptException(NashornScriptEngine.java:469) >>>>>> >>>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>>>>>>>> >>>>>>>> tEngine.evalImpl(NashornScriptEngine.java:425) >>>>>> >>>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>>>>>>>> >>>>>>>> tEngine.access$300(NashornScriptEngine.java:72) >>>>>> >>>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>>>>>>>> >>>>>>>> tEngine$3.eval(NashornScriptEngine.java:513) >>>>>> >>>>>>> at java.scripting/javax.script.CompiledScript.eval(CompiledScri >>>>>>>>> >>>>>>>> pt.java:92) >>>>>> >>>>>>> at scuff.js.CoffeeScriptCompiler.compile(CoffeeScriptCompiler.s >>>>>>>>> >>>>>>>> cala:115) >>>>>> >>>>>>> at scuff.js.TestCoffeeScriptCompiler.cs2(TestCoffeeScriptCompil >>>>>>>>> >>>>>>>> er.scala:114) >>>>>> >>>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >>>>>>>>> ke0(Native >>>>>>>>> >>>>>>>> Method) >>>>>> >>>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invo >>>>>>>>> >>>>>>>> ke(NativeMethodAccessorImpl.java:62) >>>>>> >>>>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl. >>>>>>>>> >>>>>>>> invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> >>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >>>>>>>>> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall( >>>>>>>>> >>>>>>>> FrameworkMethod.java:50) >>>>>> >>>>>>> at org.junit.internal.runners.model.ReflectiveCallable.run(Refl >>>>>>>>> >>>>>>>> ectiveCallable.java:12) >>>>>> >>>>>>> at org.junit.runners.model.FrameworkMethod.invokeExplosively(Fr >>>>>>>>> >>>>>>>> ameworkMethod.java:47) >>>>>> >>>>>>> at org.junit.internal.runners.statements.InvokeMethod.evaluate( >>>>>>>>> >>>>>>>> InvokeMethod.java:17) >>>>>> >>>>>>> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >>>>>>>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit >>>>>>>>> >>>>>>>> 4ClassRunner.java:78) >>>>>> >>>>>>> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit >>>>>>>>> >>>>>>>> 4ClassRunner.java:57) >>>>>> >>>>>>> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >>>>>>>>> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >>>>>>>>> at org.junit.runners.ParentRunner.runChildren(ParentRunner. >>>>>>>>> java:288) >>>>>>>>> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >>>>>>>>> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java: >>>>>>>>> 268) >>>>>>>>> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >>>>>>>>> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference. >>>>>>>>> >>>>>>>> run(JUnit4TestReference.java:86) >>>>>> >>>>>>> at org.eclipse.jdt.internal.junit.runner.TestExecution.run( >>>>>>>>> >>>>>>>> TestExecution.java:38) >>>>>> >>>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe >>>>>>>>> >>>>>>>> sts(RemoteTestRunner.java:539) >>>>>> >>>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe >>>>>>>>> >>>>>>>> sts(RemoteTestRunner.java:761) >>>>>> >>>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run( >>>>>>>>> >>>>>>>> RemoteTestRunner.java:461) >>>>>> >>>>>>> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main( >>>>>>>>> >>>>>>>> RemoteTestRunner.java:207) >>>>>> >>>>>>> Caused by::39:249736 SyntaxError: unexpected >>>>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeErr >>>>>>>>> >>>>>>>> or.initException(NativeError.java:135) >>>>>> >>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn >>>>>>>>> >>>>>>>> taxError.(NativeSyntaxError.java:73) >>>>>> >>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn >>>>>>>>> >>>>>>>> taxError.(NativeSyntaxError.java:77) >>>>>> >>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.objects.NativeSyn >>>>>>>>> >>>>>>>> taxError.constructor(NativeSyntaxError.java:98) >>>>>> >>>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>>>>>>>> >>>>>>>> cript$Recompilation$2368$6956AA$\^eval\_.L:39-1#a#L:39-1#L: >>>>>> 39#throwSyntaxError(:39) >>>>>> >>>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>>>>>>>> >>>>>>>> cript$Recompilation$2364$253073AA$\^eval\_$cu1$restOf.L:39- >>>>>> 1#a#L:39-8#L:39#parseError(:39) >>>>>> >>>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>>>>>>>> >>>>>>>> cript$Recompilation$2359$\^eval\_$cu1$restOf.L:39-1#a#L:39- >>>>>> 4#o#parse(:39) >>>>>> >>>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>>>>>>>> >>>>>>>> cript$Recompilation$2343$\^eval\_$cu1$restOf.L:39-1#a#L:39- >>>>>> 8#L:39#p(:39) >>>>>> >>>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>>>>>>>> >>>>>>>> cript$Recompilation$2056$250675AA$\^eval\_.L:39-1#a#L:39-8# >>>>>> L:39#T#L:39(:39) >>>>>> >>>>>>> at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.S >>>>>>>>> >>>>>>>> cript$Recompilation$1572$\^eval\_.:program(:41) >>>>>> >>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFun >>>>>>>>> >>>>>>>> ctionData.invoke(ScriptFunctionData.java:652) >>>>>> >>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFun >>>>>>>>> >>>>>>>> ction.invoke(ScriptFunction.java:513) >>>>>> >>>>>>> at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRun >>>>>>>>> >>>>>>>> time.apply(ScriptRuntime.java:517) >>>>>> >>>>>>> at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScrip >>>>>>>>> >>>>>>>> tEngine.evalImpl(NashornScriptEngine.java:420) >>>>>> >>>>>>> ... 28 more >>>>>>>>> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>> From jesse at dreamtsoft.com Mon Dec 18 19:36:18 2017 From: jesse at dreamtsoft.com (Jesse Schulman) Date: Mon, 18 Dec 2017 19:36:18 +0000 Subject: ClassCastException when running Compromise.js Message-ID: I have been trying to get the Compromise.js library working in nashorn, I have tried it on both 8 and 9.0.1 without success. I have tried to workaround the issue by modifying the js file but have not been able to get past the issue, any help or suggested workarounds are appreciated. The issue is from line 5377 of Compromise.js, which is: ts.match('#Hyphenated #Hyphenated').match('#NumericValue #NumericValue').tag('NumberRange'); This throws: java.lang.ClassCastException: Cannot cast jdk.nashorn.internal.scripts.JD4 to jdk.nashorn.internal.runtime.ScriptFunction In trying to debug in our application I passed the ts variable to a JSObject that I had available in the context, where I was able to set a java breakpoint and see if I could reproduce the ClassCastException by calling the same match().match().tag() functions via the ScriptObjectMirror APIs. I was not able to reproduce the issue this way, there were a few times when I was debugging this way in our application that I was able to get the script to run successfully (it should print "dinosaurs"), I however have not been able to consistently make the script succeed or reproduce that success in the repo I'm sharing. I have a simple reproducing case here https://github.com/jesseschulman/nashorn_compromise where you can see the functions being called without exception from java if you uncomment line 5376 of the js file. In stepping through the code and looking at the variables in the stack when the ClassCastException is thrown, it looks like the ScriptFunction is a param in the guardWithCatch method, but when that calls reinvoke it is passing JD4 (param_2) instead of ScriptFunction (param_1). Thanks! Jesse From sundararajan.athijegannathan at oracle.com Tue Dec 19 10:38:06 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 19 Dec 2017 16:08:06 +0530 Subject: RFR 8193779: Fix copyright header in nashorn builtin scripts Message-ID: <5A38EC0E.20407@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8193799 Webrev: http://cr.openjdk.java.net/~sundar/8193799/webrev.00/ Thanks, -Sundar From Alan.Bateman at oracle.com Tue Dec 19 10:30:27 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Dec 2017 10:30:27 +0000 Subject: RFR 8193779: Fix copyright header in nashorn builtin scripts In-Reply-To: <5A38EC0E.20407@oracle.com> References: <5A38EC0E.20407@oracle.com> Message-ID: <407b9f8f-3caa-aa83-8ca0-c024d19183aa@oracle.com> On 19/12/2017 10:38, Sundararajan Athijegannathan wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193799 > Webrev: http://cr.openjdk.java.net/~sundar/8193799/webrev.00/ Looks fine. Will you push this to jdk/jdk10? -Alan From sundararajan.athijegannathan at oracle.com Tue Dec 19 10:42:36 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 19 Dec 2017 16:12:36 +0530 Subject: RFR 8193779: Fix copyright header in nashorn builtin scripts In-Reply-To: <407b9f8f-3caa-aa83-8ca0-c024d19183aa@oracle.com> References: <5A38EC0E.20407@oracle.com> <407b9f8f-3caa-aa83-8ca0-c024d19183aa@oracle.com> Message-ID: <5A38ED1C.505@oracle.com> Yes, I'll. -Sundar On 19/12/17, 4:00 PM, Alan Bateman wrote: > On 19/12/2017 10:38, Sundararajan Athijegannathan wrote: >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8193799 >> Webrev: http://cr.openjdk.java.net/~sundar/8193799/webrev.00/ > Looks fine. Will you push this to jdk/jdk10? > > -Alan From hannes.wallnoefer at oracle.com Tue Dec 19 10:42:04 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 19 Dec 2017 11:42:04 +0100 Subject: RFR 8193779: Fix copyright header in nashorn builtin scripts In-Reply-To: <5A38EC0E.20407@oracle.com> References: <5A38EC0E.20407@oracle.com> Message-ID: <7E346784-F29C-4A14-BADB-33906AF15682@oracle.com> +1 Hannes > Am 19.12.2017 um 11:38 schrieb Sundararajan Athijegannathan : > > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193799 > Webrev: http://cr.openjdk.java.net/~sundar/8193799/webrev.00/ > > Thanks, > -Sundar > From priya.lakshmi.muthuswamy at oracle.com Wed Dec 20 06:11:11 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Wed, 20 Dec 2017 11:41:11 +0530 Subject: RFR:8193491:JavaImporter fails to resolve method elements within functions, that contain too many statements Message-ID: <07d68d13-edf5-681c-16b0-329eeb216848@oracle.com> Hi, Please review JDK-8193491 : JavaImporter fails to resolve method elements within functions, that contain too many statements JBS: https://bugs.openjdk.java.net/browse/JDK-8193491 webrev: http://cr.openjdk.java.net/~pmuthuswamy/8193491/webrev.00/ This issue address both method and property lookup in JavaImporter when the function is split . Thanks, Priya From priya.lakshmi.muthuswamy at oracle.com Wed Dec 20 14:01:34 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Wed, 20 Dec 2017 19:31:34 +0530 Subject: RFR:8193491:JavaImporter fails to resolve method elements within functions, that contain too many statements In-Reply-To: <07d68d13-edf5-681c-16b0-329eeb216848@oracle.com> References: <07d68d13-edf5-681c-16b0-329eeb216848@oracle.com> Message-ID: ?Removed __noSuchProperty__ methods in NativeJavaImporter ?updated webrev : http://cr.openjdk.java.net/~pmuthuswamy/8193491/webrev.01/ Thanks, Priya On 12/20/2017 11:41 AM, Priya Lakshmi Muthuswamy wrote: > Hi, > > Please review JDK-8193491 : JavaImporter fails to resolve method > elements within functions, that contain too many statements > > JBS: https://bugs.openjdk.java.net/browse/JDK-8193491 > webrev: http://cr.openjdk.java.net/~pmuthuswamy/8193491/webrev.00/ > > This issue address both method and property lookup in JavaImporter > when the function is split . > > Thanks, > Priya From james.laskey at oracle.com Wed Dec 20 14:10:46 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 20 Dec 2017 10:10:46 -0400 Subject: RFR:8193491:JavaImporter fails to resolve method elements within functions, that contain too many statements In-Reply-To: References: <07d68d13-edf5-681c-16b0-329eeb216848@oracle.com> Message-ID: <6F5713CD-02AB-4CAB-BC38-6CE6ED4F7C6A@oracle.com> +1 > On Dec 20, 2017, at 10:01 AM, Priya Lakshmi Muthuswamy wrote: > > Removed __noSuchProperty__ methods in NativeJavaImporter > > updated webrev : http://cr.openjdk.java.net/~pmuthuswamy/8193491/webrev.01/ > > Thanks, > Priya > On 12/20/2017 11:41 AM, Priya Lakshmi Muthuswamy wrote: >> Hi, >> >> Please review JDK-8193491 : JavaImporter fails to resolve method elements within functions, that contain too many statements >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8193491 >> webrev: http://cr.openjdk.java.net/~pmuthuswamy/8193491/webrev.00/ >> >> This issue address both method and property lookup in JavaImporter when the function is split . >> >> Thanks, >> Priya > From hannes.wallnoefer at oracle.com Wed Dec 20 14:48:48 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 20 Dec 2017 15:48:48 +0100 Subject: RFR:8193491:JavaImporter fails to resolve method elements within functions, that contain too many statements In-Reply-To: References: <07d68d13-edf5-681c-16b0-329eeb216848@oracle.com> Message-ID: +1 Hannes > Am 20.12.2017 um 15:01 schrieb Priya Lakshmi Muthuswamy : > > Removed __noSuchProperty__ methods in NativeJavaImporter > > updated webrev : http://cr.openjdk.java.net/~pmuthuswamy/8193491/webrev.01/ > > Thanks, > Priya > On 12/20/2017 11:41 AM, Priya Lakshmi Muthuswamy wrote: >> Hi, >> >> Please review JDK-8193491 : JavaImporter fails to resolve method elements within functions, that contain too many statements >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8193491 >> webrev: http://cr.openjdk.java.net/~pmuthuswamy/8193491/webrev.00/ >> >> This issue address both method and property lookup in JavaImporter when the function is split . >> >> Thanks, >> Priya > From james.laskey at oracle.com Wed Dec 20 16:13:08 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 20 Dec 2017 12:13:08 -0400 Subject: RFR: 8193508: Expressions in split literals must never be optimistic In-Reply-To: <2F770FFE-873E-49F6-A780-E04EDF54AAE1@oracle.com> References: <2F770FFE-873E-49F6-A780-E04EDF54AAE1@oracle.com> Message-ID: <8D6B5F70-0285-44DC-829B-477BE813FE88@oracle.com> +1 > On Dec 14, 2017, at 1:38 PM, Hannes Walln?fer wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193508 > Webrev: http://cr.openjdk.java.net/~hannesw/8193508/webrev.00/ > > The actual fix is quite simple: stop visiting when we encounter a split object or array literal in OptimisticTypesCalculator. > > There are a few non-essential changes: > - rename methods and fields in CodeGeneratorLexicalContext from *SplitNode to *SplitLiteral as the former is misleading (no actual SplitNodes around) > - make sure we don?t have optimistic operations unless we generate optimistic code to avoid the situation that enabled this bug > - add logging for split array and object nodes in Splitter > - add some @Ignore annotations to make nodes behave in IR printer > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Wed Dec 20 16:39:13 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 20 Dec 2017 22:09:13 +0530 Subject: RFR: 8193508: Expressions in split literals must never be optimistic In-Reply-To: <2F770FFE-873E-49F6-A780-E04EDF54AAE1@oracle.com> References: <2F770FFE-873E-49F6-A780-E04EDF54AAE1@oracle.com> Message-ID: <5A3A9231.1060304@oracle.com> +1 -Sundar On 14/12/17, 11:08 PM, Hannes Walln?fer wrote: > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193508 > Webrev: http://cr.openjdk.java.net/~hannesw/8193508/webrev.00/ > > The actual fix is quite simple: stop visiting when we encounter a split object or array literal in OptimisticTypesCalculator. > > There are a few non-essential changes: > - rename methods and fields in CodeGeneratorLexicalContext from *SplitNode to *SplitLiteral as the former is misleading (no actual SplitNodes around) > - make sure we don?t have optimistic operations unless we generate optimistic code to avoid the situation that enabled this bug > - add logging for split array and object nodes in Splitter > - add some @Ignore annotations to make nodes behave in IR printer > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Thu Dec 21 15:36:52 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 21 Dec 2017 16:36:52 +0100 Subject: RFR: 8193567: Conversion of comparison nodes affects local slots in optimistic continuation Message-ID: <2A602DA1-A5E0-4292-81E0-92476101EC96@oracle.com> Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8193567 Webrev: http://cr.openjdk.java.net/~hannesw/8193567/webrev.00/ I?ve tried finding a smaller fix like just tagging the child nodes of all comparisons as non-optimistic, but that didn't fix the problem as those nodes could still have optimistic children. Hannes From szegedia at gmail.com Thu Dec 21 18:20:25 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 21 Dec 2017 19:20:25 +0100 Subject: Review request for JDK-8193295: Remove no longer used COMMALEFT Message-ID: <202BF530-2C4A-4EEC-9EC3-E1900CB6DC06@gmail.com> Please review JDK-8193295 "Remove no longer used COMMALEFT" at for I love deleting code :-) COMMALEFT was an odd duck, as there?s not really anything in the ES specification that?d require it, and we really don?t even use it for anything. I had a memory that we used to use it for some behavior around object literals, but I can?t find any traces of that? I run: hg log --template "{ifcontains('COMMALEFT', diff(), '{node} {desc}\n', '')}? and trawled through the diffs for all changesets it brought up, but I haven?t found a single use of COMMALEFT ever. Thanks, Attila. From szegedia at gmail.com Thu Dec 21 20:59:01 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 21 Dec 2017 21:59:01 +0100 Subject: Dynalink and delete In-Reply-To: References: Message-ID: <03F27FF8-4C3C-4563-BCE2-7772EDA39E81@gmail.com> Hi Marc, So? this took about a year and a half to happen, but I?m happy to announce that there?s now a REMOVE operation in Dynalink. The latest EA of JDK10 contains it: >. Hopefully you can still find a use for it :-) What the latest EA doesn?t contain _yet_ is Nashorn using it to implement its delete operator, so even if you link REMOVE in your language runtime, Nashorn won?t be able to delete your object?s properties, and your language won?t be able to delete Nashorn JS objects? properties yet. The good news is that this functionality is also implemented and committed, but I just committed it now, so it will only ship with the next EA build. Alternatively, if you build your own jdk10 from the tip of the jdk/jdk10 repository, or your own jdk11 from the tip of jdk/jdk, you should have it. Best Regards, Attila. > On May 24, 2016, at 12:11 AM, Marc Downie wrote: > > Dear all, > > First of all, many thanks for this year's JEP-276 / jdk.dynalink > refactoring. We've been enjoying all of the benefits of installing a custom > Linker without having to maintain a fork of Nashorn just to get it > installed. We can massage and customize the face that Java objects present > to JavaScript almost completely. > > The one thing that remains that I can't manipulate is the behavior of Java > objects with respect to *delete*. In short we have elaborately customizable > *dyn:setProp*, *setElem*, *getProp*, *getElem* that we can bridge to other > languages and runtimes, but no *dyn:deleteX. *Is this by omission or by > design? > > best, > > Marc From hannes.wallnoefer at oracle.com Thu Dec 21 20:37:45 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 21 Dec 2017 21:37:45 +0100 Subject: Review request for JDK-8193295: Remove no longer used COMMALEFT In-Reply-To: <202BF530-2C4A-4EEC-9EC3-E1900CB6DC06@gmail.com> References: <202BF530-2C4A-4EEC-9EC3-E1900CB6DC06@gmail.com> Message-ID: <4E6B3DD0-A3FF-4DD2-B18C-725F99FDE37C@oracle.com> Interesting. I bet the answer is in the commits from before we went open source. +1 I assume this is for JDK 11? Hannes > Am 21.12.2017 um 19:20 schrieb Attila Szegedi : > > Please review JDK-8193295 "Remove no longer used COMMALEFT" at for > > I love deleting code :-) > > COMMALEFT was an odd duck, as there?s not really anything in the ES specification that?d require it, and we really don?t even use it for anything. I had a memory that we used to use it for some behavior around object literals, but I can?t find any traces of that? I run: > > hg log --template "{ifcontains('COMMALEFT', diff(), '{node} {desc}\n', '')}? > > and trawled through the diffs for all changesets it brought up, but I haven?t found a single use of COMMALEFT ever. > > Thanks, > Attila. From marc at openendedgroup.com Thu Dec 21 23:16:15 2017 From: marc at openendedgroup.com (Marc Downie) Date: Thu, 21 Dec 2017 17:16:15 -0600 Subject: Dynalink and delete In-Reply-To: <03F27FF8-4C3C-4563-BCE2-7772EDA39E81@gmail.com> References: <03F27FF8-4C3C-4563-BCE2-7772EDA39E81@gmail.com> Message-ID: Attila, Followed the reviews and commits with anticipation, pulling the changes and building this evening. Assuming it all goes well, I'll have it in front of students writing code in two weeks time. Many thanks! Marc. On Thu, Dec 21, 2017 at 2:59 PM, Attila Szegedi wrote: > Hi Marc, > > So? this took about a year and a half to happen, but I?m happy to announce > that there?s now a REMOVE operation in Dynalink. The latest EA of JDK10 > contains it: dynalink/StandardOperation.html#REMOVE>. Hopefully you can still find a > use for it :-) > > What the latest EA doesn?t contain _yet_ is Nashorn using it to implement > its delete operator, so even if you link REMOVE in your language runtime, > Nashorn won?t be able to delete your object?s properties, and your language > won?t be able to delete Nashorn JS objects? properties yet. The good news > is that this functionality is also implemented and committed, but I just > committed it now, so it will only ship with the next EA build. > Alternatively, if you build your own jdk10 from the tip of the jdk/jdk10 > repository, or your own jdk11 from the tip of jdk/jdk, you should have it. > > Best Regards, > Attila. > > On May 24, 2016, at 12:11 AM, Marc Downie wrote: > > Dear all, > > First of all, many thanks for this year's JEP-276 / jdk.dynalink > refactoring. We've been enjoying all of the benefits of installing a custom > Linker without having to maintain a fork of Nashorn just to get it > installed. We can massage and customize the face that Java objects present > to JavaScript almost completely. > > The one thing that remains that I can't manipulate is the behavior of Java > objects with respect to *delete*. In short we have elaborately customizable > *dyn:setProp*, *setElem*, *getProp*, *getElem* that we can bridge to other > languages and runtimes, but no *dyn:deleteX. *Is this by omission or by > design? > > best, > > Marc > > > From james.laskey at oracle.com Fri Dec 22 00:42:11 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 21 Dec 2017 20:42:11 -0400 Subject: RFR: 8193567: Conversion of comparison nodes affects local slots in optimistic continuation In-Reply-To: <2A602DA1-A5E0-4292-81E0-92476101EC96@oracle.com> References: <2A602DA1-A5E0-4292-81E0-92476101EC96@oracle.com> Message-ID: +1 > On Dec 21, 2017, at 11:36 AM, Hannes Walln?fer wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193567 > Webrev: http://cr.openjdk.java.net/~hannesw/8193567/webrev.00/ > > I?ve tried finding a smaller fix like just tagging the child nodes of all comparisons as non-optimistic, but that didn't fix the problem as those nodes could still have optimistic children. > > Hannes From szegedia at gmail.com Mon Dec 25 09:59:05 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 25 Dec 2017 10:59:05 +0100 Subject: Review request for JDK-8193295: Remove no longer used COMMALEFT In-Reply-To: <4E6B3DD0-A3FF-4DD2-B18C-725F99FDE37C@oracle.com> References: <202BF530-2C4A-4EEC-9EC3-E1900CB6DC06@gmail.com> <4E6B3DD0-A3FF-4DD2-B18C-725F99FDE37C@oracle.com> Message-ID: Yeah, JDK 11. There?s no visible changes, so it doesn?t really make sense pushing it into JDK 10. > On Dec 21, 2017, at 9:37 PM, Hannes Walln?fer wrote: > > Interesting. I bet the answer is in the commits from before we went open source. > > +1 > > I assume this is for JDK 11? > > Hannes > >> Am 21.12.2017 um 19:20 schrieb Attila Szegedi : >> >> Please review JDK-8193295 "Remove no longer used COMMALEFT" at for >> >> I love deleting code :-) >> >> COMMALEFT was an odd duck, as there?s not really anything in the ES specification that?d require it, and we really don?t even use it for anything. I had a memory that we used to use it for some behavior around object literals, but I can?t find any traces of that? I run: >> >> hg log --template "{ifcontains('COMMALEFT', diff(), '{node} {desc}\n', '')}? >> >> and trawled through the diffs for all changesets it brought up, but I haven?t found a single use of COMMALEFT ever. >> >> Thanks, >> Attila. > From szegedia at gmail.com Mon Dec 25 16:27:23 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Mon, 25 Dec 2017 17:27:23 +0100 Subject: RFR: 8193567: Conversion of comparison nodes affects local slots in optimistic continuation In-Reply-To: <2A602DA1-A5E0-4292-81E0-92476101EC96@oracle.com> References: <2A602DA1-A5E0-4292-81E0-92476101EC96@oracle.com> Message-ID: <415D866D-73DF-4A2F-90F1-52EBC34D3759@gmail.com> A sad +1. I too wish this were easier to solve. Can you point me to the code parts that cause differences in local slot assignment? I guess I could try to figure it out myself from that terrible expression in the test, but if you have a quick explanation? Thanks, Attila. > On Dec 21, 2017, at 4:36 PM, Hannes Walln?fer wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193567 > Webrev: http://cr.openjdk.java.net/~hannesw/8193567/webrev.00/ > > I?ve tried finding a smaller fix like just tagging the child nodes of all comparisons as non-optimistic, but that didn't fix the problem as those nodes could still have optimistic children. > > Hannes From anders.rundgren.net at gmail.com Thu Dec 28 11:02:46 2017 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Thu, 28 Dec 2017 12:02:46 +0100 Subject: Number Serialization Bug/Feature Message-ID: Hi All, A number of JS tools including Node.js, Chrome, Firefox, and Safari nowadays support the more advanced version of "Number" serialization defined by ECMA in section 7.1.12.1 including NOTE 2 in https://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf Nashorn as featured in OpenJDK version "1.8.0_151" does not appear following this specification leading to subtle interoperability problems: jjs> JSON.parse('{"v":5e-324}').v 4.9e-324 Chrome: JSON.parse('{"v":5e-324}').v 5e-324 Why would that ever lead to an interoperability problem you might [rightfully] wonder? Well, there a tentative IETF effort establishing a digital signature standard for JSON objects that works with clear text messages.? This among many things requires that data types have a "normalized" form.?? ECMA has essentially done that which together with creation ordering of properties (modulo properties with names expressed as integers) makes the rest pretty simple. Related: https://bugs.openjdk.java.net/browse/JDK-8149075 Cheers, Anders Rundgren https://cyberphone.github.io/doc/security/jose-jcs.html#Normalization_and_Signature_Validation From szegedia at gmail.com Thu Dec 28 18:39:16 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Thu, 28 Dec 2017 19:39:16 +0100 Subject: Dynalink and delete In-Reply-To: References: <03F27FF8-4C3C-4563-BCE2-7772EDA39E81@gmail.com> Message-ID: I?d love to learn more about how you are using Nashorn and Dynalink for teaching, if you can spare a time for a short write-up. Thanks, Attila. > On 2017. Dec 22., at 0:16, Marc Downie wrote: > > > Attila, > > Followed the reviews and commits with anticipation, pulling the changes and building this evening. Assuming it all goes well, I'll have it in front of students writing code in two weeks time. > > Many thanks! > > Marc. > > On Thu, Dec 21, 2017 at 2:59 PM, Attila Szegedi > wrote: > Hi Marc, > > So? this took about a year and a half to happen, but I?m happy to announce that there?s now a REMOVE operation in Dynalink. The latest EA of JDK10 contains it: >. Hopefully you can still find a use for it :-) > > What the latest EA doesn?t contain _yet_ is Nashorn using it to implement its delete operator, so even if you link REMOVE in your language runtime, Nashorn won?t be able to delete your object?s properties, and your language won?t be able to delete Nashorn JS objects? properties yet. The good news is that this functionality is also implemented and committed, but I just committed it now, so it will only ship with the next EA build. Alternatively, if you build your own jdk10 from the tip of the jdk/jdk10 repository, or your own jdk11 from the tip of jdk/jdk, you should have it. > > Best Regards, > Attila. > >> On May 24, 2016, at 12:11 AM, Marc Downie > wrote: >> >> Dear all, >> >> First of all, many thanks for this year's JEP-276 / jdk.dynalink >> refactoring. We've been enjoying all of the benefits of installing a custom >> Linker without having to maintain a fork of Nashorn just to get it >> installed. We can massage and customize the face that Java objects present >> to JavaScript almost completely. >> >> The one thing that remains that I can't manipulate is the behavior of Java >> objects with respect to *delete*. In short we have elaborately customizable >> *dyn:setProp*, *setElem*, *getProp*, *getElem* that we can bridge to other >> languages and runtimes, but no *dyn:deleteX. *Is this by omission or by >> design? >> >> best, >> >> Marc > >