From issaria at gmail.com Tue Aug 1 11:43:44 2017 From: issaria at gmail.com (Isaiah Peng) Date: Tue, 01 Aug 2017 11:43:44 +0000 Subject: Invalidate callsite Message-ID: Hi guys, My name is Isaiah, I'm currently trying to implement invokedynamic for my Python 3 implementation. Everything went quite well until I encountered a `ClassCastException` which I don't know how to fix. Here is my theory: there are two method calls that has the same arity, with signatures of: `(LPyObject;LThreadState;[LPyObject;LString;)LPyObject` and `(LPyObject;LThreadState;LPyObject;LPyObject)LPyObject` The former is for methods that take vararg and keyword arguments, the later is for methods that take two arguments. The stacktrace is as following: java.lang.ClassCastException: Cannot cast [Ljava.lang.String; to org.python.core.PyObject at java.base/java.lang.Class.cast(Class.java:3578) at contextlib_jython_36.__init__$12(contextlib:67) at org.python.core.Py.runCode(Py.java:1663) at org.python.core.PyTableCode.call(PyTableCode.java:404) at org.python.core.PyTableCode.call(PyTableCode.java:382) at org.python.core.PyFunction.__call__(PyFunction.java:442) at org.python.core.PyMethod.instancemethod___call__(PyMethod.java:237) at org.python.core.PyMethod.__call__(PyMethod.java:228) at org.python.core.PyMethod.__call__(PyMethod.java:223) at org.python.core.Deriveds.dispatch__init__(Deriveds.java:19) at org.python.core.PyObjectDerived.dispatch__init__(PyObjectDerived.java:940) at org.python.core.PyType.type___call__(PyType.java:1675) at org.python.core.PyType$type___call___exposer.__call__(Unknown Source) at org.python.core.PyTypeDerived.__call__(PyTypeDerived.java:831) at org.python.core.PyObject.__call__(PyObject.java:506) at org.python.core.PyObject.__call__(PyObject.java:510) at contextlib_jython_36.helper$17(contextlib:159) The GuardedInvocation returned from the linker is like: `return new GuardedInvocation(mh, null, new SwitchPoint[0], ClassCastException.class);` It seems to be able to catch the class cast exception for the receiver but not for arguments. I create a similar call path and the function works fine, so I thought the cause could be the callsite is not invalidated. My question is: Is my guess correct? if so why does it reuse the callsite when the signatures are different? and how to create a guard for such case? The source code can be found here: https://bitbucket.org/jylang/jylang/src/e0c64d17b21db7784c75892424cae09f9faa07d3/src/org/python/core/PyFunction.java?at=indy&fileviewer=file-view-default#PyFunction.java-513 Thanks in advance, Isaiah Peng From szegedia at gmail.com Tue Aug 1 12:37:44 2017 From: szegedia at gmail.com (Attila Szegedi) Date: Tue, 1 Aug 2017 14:37:44 +0200 Subject: Invalidate callsite In-Reply-To: References: Message-ID: I?d suggest that when findCallMethod is invoked so that in the LinkRequest arguments, there?s a string argument, you produce a GuardedInvocation with the first method and a guard that checks if the relevant argument is a string, and when invoked with a PyObject, then produce a GuardedInvocation with the second method and a guard that checks if argument 3 is a PyObject. Attila. > On 01 Aug 2017, at 13:43, Isaiah Peng wrote: > > Hi guys, > > My name is Isaiah, I'm currently trying to implement invokedynamic for my > Python 3 implementation. Everything went quite well until I encountered a > `ClassCastException` which I don't know how to fix. > > Here is my theory: there are two method calls that has the same arity, with > signatures of: > > `(LPyObject;LThreadState;[LPyObject;LString;)LPyObject` > and > `(LPyObject;LThreadState;LPyObject;LPyObject)LPyObject` > > The former is for methods that take vararg and keyword arguments, the later > is for methods that take two arguments. The stacktrace is as following: > > java.lang.ClassCastException: Cannot cast [Ljava.lang.String; to > org.python.core.PyObject > > at java.base/java.lang.Class.cast(Class.java:3578) > at contextlib_jython_36.__init__$12(contextlib:67) > at org.python.core.Py.runCode(Py.java:1663) > at org.python.core.PyTableCode.call(PyTableCode.java:404) > at org.python.core.PyTableCode.call(PyTableCode.java:382) > at org.python.core.PyFunction.__call__(PyFunction.java:442) > at > org.python.core.PyMethod.instancemethod___call__(PyMethod.java:237) > at org.python.core.PyMethod.__call__(PyMethod.java:228) > at org.python.core.PyMethod.__call__(PyMethod.java:223) > at org.python.core.Deriveds.dispatch__init__(Deriveds.java:19) > at > org.python.core.PyObjectDerived.dispatch__init__(PyObjectDerived.java:940) > at org.python.core.PyType.type___call__(PyType.java:1675) > at org.python.core.PyType$type___call___exposer.__call__(Unknown > Source) > at org.python.core.PyTypeDerived.__call__(PyTypeDerived.java:831) > at org.python.core.PyObject.__call__(PyObject.java:506) > at org.python.core.PyObject.__call__(PyObject.java:510) > at contextlib_jython_36.helper$17(contextlib:159) > > The GuardedInvocation returned from the linker is like: > > `return new GuardedInvocation(mh, null, new SwitchPoint[0], > ClassCastException.class);` > > It seems to be able to catch the class cast exception for the receiver but > not for arguments. I create a similar call path and the function works > fine, so I thought the cause could be the callsite is not invalidated. > > My question is: Is my guess correct? if so why does it reuse the callsite > when the signatures are different? and how to create a guard for such case? > > The source code can be found here: > > https://bitbucket.org/jylang/jylang/src/e0c64d17b21db7784c75892424cae09f9faa07d3/src/org/python/core/PyFunction.java?at=indy&fileviewer=file-view-default#PyFunction.java-513 > > Thanks in advance, > Isaiah Peng From issaria at gmail.com Tue Aug 1 14:48:35 2017 From: issaria at gmail.com (Isaiah Peng) Date: Tue, 01 Aug 2017 14:48:35 +0000 Subject: Invalidate callsite In-Reply-To: References: Message-ID: @szegedia I tried your suggestion, but the guards are not triggered, turns out the problem is with the generators, for which support for "wide call" invocations is not yet implemented. :( Thanks for your help. Isaiah On Tue, 1 Aug 2017 at 14:38 Attila Szegedi wrote: > I?d suggest that when findCallMethod is invoked so that in the LinkRequest > arguments, there?s a string argument, you produce a GuardedInvocation with > the first method and a guard that checks if the relevant argument is a > string, and when invoked with a PyObject, then produce a GuardedInvocation > with the second method and a guard that checks if argument 3 is a PyObject. > > Attila. > > > On 01 Aug 2017, at 13:43, Isaiah Peng wrote: > > > > Hi guys, > > > > My name is Isaiah, I'm currently trying to implement invokedynamic for my > > Python 3 implementation. Everything went quite well until I encountered a > > `ClassCastException` which I don't know how to fix. > > > > Here is my theory: there are two method calls that has the same arity, > with > > signatures of: > > > > `(LPyObject;LThreadState;[LPyObject;LString;)LPyObject` > > and > > `(LPyObject;LThreadState;LPyObject;LPyObject)LPyObject` > > > > The former is for methods that take vararg and keyword arguments, the > later > > is for methods that take two arguments. The stacktrace is as following: > > > > java.lang.ClassCastException: Cannot cast [Ljava.lang.String; to > > org.python.core.PyObject > > > > at java.base/java.lang.Class.cast(Class.java:3578) > > at contextlib_jython_36.__init__$12(contextlib:67) > > at org.python.core.Py.runCode(Py.java:1663) > > at org.python.core.PyTableCode.call(PyTableCode.java:404) > > at org.python.core.PyTableCode.call(PyTableCode.java:382) > > at org.python.core.PyFunction.__call__(PyFunction.java:442) > > at > > org.python.core.PyMethod.instancemethod___call__(PyMethod.java:237) > > at org.python.core.PyMethod.__call__(PyMethod.java:228) > > at org.python.core.PyMethod.__call__(PyMethod.java:223) > > at org.python.core.Deriveds.dispatch__init__(Deriveds.java:19) > > at > > > org.python.core.PyObjectDerived.dispatch__init__(PyObjectDerived.java:940) > > at org.python.core.PyType.type___call__(PyType.java:1675) > > at org.python.core.PyType$type___call___exposer.__call__(Unknown > > Source) > > at org.python.core.PyTypeDerived.__call__(PyTypeDerived.java:831) > > at org.python.core.PyObject.__call__(PyObject.java:506) > > at org.python.core.PyObject.__call__(PyObject.java:510) > > at contextlib_jython_36.helper$17(contextlib:159) > > > > The GuardedInvocation returned from the linker is like: > > > > `return new GuardedInvocation(mh, null, new SwitchPoint[0], > > ClassCastException.class);` > > > > It seems to be able to catch the class cast exception for the receiver > but > > not for arguments. I create a similar call path and the function works > > fine, so I thought the cause could be the callsite is not invalidated. > > > > My question is: Is my guess correct? if so why does it reuse the callsite > > when the signatures are different? and how to create a guard for such > case? > > > > The source code can be found here: > > > > > https://bitbucket.org/jylang/jylang/src/e0c64d17b21db7784c75892424cae09f9faa07d3/src/org/python/core/PyFunction.java?at=indy&fileviewer=file-view-default#PyFunction.java-513 > > > > Thanks in advance, > > Isaiah Peng > > From priya.lakshmi.muthuswamy at oracle.com Thu Aug 10 04:00:56 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Thu, 10 Aug 2017 09:30:56 +0530 Subject: RFR:8185252:Unary minus and plus use wrong node Kind Message-ID: Hi, Please review 8185252: Unary minus and plus use wrong node Kind Bug : https://bugs.openjdk.java.net/browse/JDK-8185252 webrev : http://cr.openjdk.java.net/~pmuthuswamy/8185252/webrev.01/ Thanks, Priya From sundararajan.athijegannathan at oracle.com Thu Aug 10 04:53:55 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 10 Aug 2017 10:23:55 +0530 Subject: RFR:8185252:Unary minus and plus use wrong node Kind In-Reply-To: References: Message-ID: <598BE6E3.7080303@oracle.com> +1 Nice work! -Sundar On 10/08/17, 9:30 AM, Priya Lakshmi Muthuswamy wrote: > Hi, > > Please review 8185252: Unary minus and plus use wrong node Kind > Bug : https://bugs.openjdk.java.net/browse/JDK-8185252 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8185252/webrev.01/ > > Thanks, > Priya > > From hannes.wallnoefer at oracle.com Thu Aug 10 08:41:44 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 10 Aug 2017 10:41:44 +0200 Subject: RFR:8185252:Unary minus and plus use wrong node Kind In-Reply-To: References: Message-ID: Hi Priya, +1 Great to see you got acquainted and productive so quickly with nashorn code! Hannes > Am 10.08.2017 um 06:00 schrieb Priya Lakshmi Muthuswamy : > > Hi, > > Please review 8185252: Unary minus and plus use wrong node Kind > Bug : https://bugs.openjdk.java.net/browse/JDK-8185252 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8185252/webrev.01/ > > Thanks, > Priya > > From priya.lakshmi.muthuswamy at oracle.com Fri Aug 18 05:36:32 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Fri, 18 Aug 2017 11:06:32 +0530 Subject: RFR: StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc') Message-ID: <83c47171-fdac-dad2-ee61-fec708a1f9cf@oracle.com> Hi, Please review JDK-8175362 : StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc') JBS : https://bugs.openjdk.java.net/browse/JDK-8175362 webrev : http://cr.openjdk.java.net/~pmuthuswamy/8175362/webrev.00/ Thanks, Priya From hannes.wallnoefer at oracle.com Fri Aug 18 08:48:15 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 18 Aug 2017 10:48:15 +0200 Subject: RFR: StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc') In-Reply-To: <83c47171-fdac-dad2-ee61-fec708a1f9cf@oracle.com> References: <83c47171-fdac-dad2-ee61-fec708a1f9cf@oracle.com> Message-ID: +1 I can provide some background information for this patch, whithout which it is probably hard to understand. The Joni matcher has different implementations of the stack pop operations that just discard stack entries or reset group boundaries and/or repeat counts, depending on the regular expression being executed. Because of the delayed compilation introduced in JDK-8011884 (Regexp literals are compiled twice) Joni was using the wrong implementation of stack pop in this case, causing the repeat count to be too high. Now since we actually added a LRU cache for compiled regular expressions in JDK-8066407 (Function with same body not reparsed after SyntaxError) the safest way to fix this is to revert back to the original regex instantiation/compilation order, which is what this patch does. Hannes > Am 18.08.2017 um 07:36 schrieb Priya Lakshmi Muthuswamy : > > Hi, > > Please review JDK-8175362 : StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc') > JBS : https://bugs.openjdk.java.net/browse/JDK-8175362 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8175362/webrev.00/ > > Thanks, > Priya From jesse at dreamtsoft.com Mon Aug 21 22:13:14 2017 From: jesse at dreamtsoft.com (Jesse Schulman) Date: Mon, 21 Aug 2017 22:13:14 +0000 Subject: ScriptFunction being passed to JSObject, expected ScriptObjectMirror Message-ID: This does not happen on the first run of the code but is consistently happening on the 17th run after a restart and from that point forward is broken until we restart. Attached is a broken and working call stack. I have tried to replicate what we are doing in a basic java reproducer but have not been able to do so, given that I can consistently reproduce this locally I am happy to take any suggested steps to gather more information or to workaround/resolve the issue. Environment: Java version 1.8.144 Engine created with "--no-java", "-strict", "--no-syntax-extensions", "--language=es6", "--optimistic-types=true" (also tried with optimistic-types=false) All evaluation done on the same engine via engine.eval(String, Bindings) using a Bindings that was returned from engine.createBindings, each of the "runs" described above took place in a different Bindings instance Thanks! Jesse -------------- next part -------------- BROKEN: at MY_JS_OBJECT.call(MY_CLASS.java:133) at jdk.nashorn.internal.objects.NativeFunction.apply(NativeFunction.java:106) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.986924955.invokeExact_MT(LambdaForm$MH:-1) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:661) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393) at jdk.nashorn.internal.objects.NativeFunction.apply(NativeFunction.java:104) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.239759455.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.712609105.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1022433442.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.546710868.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1149$46152A$\^function\_.L:1#clearStack#getClearStack#clearStack(:1647) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1948334320.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.1529060733.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1721057216.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.843329350.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1053$109486AI$\^function\_.L:1#QueueRunner#run(:3892) at java.lang.invoke.LambdaForm$DMH.1092004553.invokeStatic_L3I_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.1893269747.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1403062879.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1551589705.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1403062879.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1551589705.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.657389592.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1050$109209$\^function\_.L:1#QueueRunner#execute(:3873) at java.lang.invoke.LambdaForm$DMH.1577592551.invokeStatic_L_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1560940633.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.1484171695.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1420232606.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.713992047.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1047$23871A$\^function\_.L:1#Env#Env#queueRunnerFactory(:817) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1948334320.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.1529060733.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1721057216.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.843329350.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1090$14617AA$\^function\_.L:1#Spec#execute(:478) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.239759455.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.712609105.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1022433442.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.546710868.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1075$141218A$\^function\_.L:1#TreeProcessor#TreeProcessor#executeNode#fn-1(:4976) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1225929144.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.712609105.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1022433442.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.546710868.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1057$110204A$\^function\_.L:1#QueueRunner#run#attemptAsync(:3946) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.1869412025.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1529060733.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1721057216.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1529060733.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1721057216.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.843329350.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1053$109486AI$\^function\_.L:1#QueueRunner#run(:3885) at java.lang.invoke.LambdaForm$DMH.1092004553.invokeStatic_L3I_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.1893269747.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1403062879.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1551589705.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1403062879.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1551589705.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.657389592.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1050$109209$\^function\_.L:1#QueueRunner#execute(:3873) at java.lang.invoke.LambdaForm$DMH.1577592551.invokeStatic_L_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1560940633.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.1484171695.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1420232606.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.713992047.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1047$23871A$\^function\_.L:1#Env#Env#queueRunnerFactory(:817) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1948334320.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.1529060733.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1721057216.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.843329350.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1073$140690A$\^function\_.L:1#TreeProcessor#TreeProcessor#executeNode#fn(:4967) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.576431459.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.712609105.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1022433442.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.712609105.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1022433442.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.712609105.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1022433442.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.546710868.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1057$110204A$\^function\_.L:1#QueueRunner#run#attemptAsync(:3946) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.1869412025.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1529060733.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1721057216.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1529060733.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1721057216.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.843329350.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1053$109486AI$\^function\_.L:1#QueueRunner#run(:3885) at java.lang.invoke.LambdaForm$DMH.1092004553.invokeStatic_L3I_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.1893269747.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1403062879.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1551589705.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1403062879.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1551589705.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.657389592.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1050$109209$\^function\_.L:1#QueueRunner#execute(:3873) at java.lang.invoke.LambdaForm$DMH.1577592551.invokeStatic_L_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1560940633.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.1484171695.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1420232606.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.713992047.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1047$23871A$\^function\_.L:1#Env#Env#queueRunnerFactory(:817) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1948334320.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.1529060733.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1721057216.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.843329350.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$1046$136602A$\^function\_.L:1#TreeProcessor#TreeProcessor#execute(:4825) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1948334320.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.1529060733.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1721057216.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.843329350.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$969$24628A$\^function\_.L:1#Env#Env#execute(:884) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.1855762390.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1529060733.delegate(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1721057216.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1801048602.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.986924955.invokeExact_MT(LambdaForm$MH:-1) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:639) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393) at jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199) -------------- next part -------------- WORKING: at MY_JS_OBJECT.call(MY_CLASS.java:133) at java.lang.invoke.LambdaForm$DMH.298430307.invokeInterface_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.16115318.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.666823995.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.2006331902.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$559$46152A$\^function\_.L:1#clearStack#getClearStack#clearStack(:1647) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1557307464.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.666999885.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.537888354.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$463$109486AI$\^function\_.L:1#QueueRunner#run(:3892) at java.lang.invoke.LambdaForm$DMH.1092004553.invokeStatic_L3I_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.580973161.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$reinvoker.1252531992.dontInline(LambdaForm$reinvoker:-1) at java.lang.invoke.LambdaForm$MH.1989313827.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$reinvoker.1252531992.dontInline(LambdaForm$reinvoker:-1) at java.lang.invoke.LambdaForm$MH.1989313827.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1524475331.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$460$109209$\^function\_.L:1#QueueRunner#execute(:3873) at java.lang.invoke.LambdaForm$DMH.1577592551.invokeStatic_L_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1560940633.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$reinvoker.1627396964.dontInline(LambdaForm$reinvoker:-1) at java.lang.invoke.LambdaForm$MH.1420232606.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1875650138.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$457$23871A$\^function\_.L:1#Env#Env#queueRunnerFactory(:817) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1557307464.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.666999885.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.537888354.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$500$14617AA$\^function\_$cu1$restOf.L:1#Spec#execute(:478) at java.lang.invoke.LambdaForm$DMH.1577592551.invokeStatic_L_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.1123406363.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.460331690.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1123406363.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.460331690.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1123406363.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.460331690.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.2040688354.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.199004826.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.666823995.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.2006331902.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$485$141218A$\^function\_$cu1$restOf.L:1#TreeProcessor#TreeProcessor#executeNode#fn-1(:4976) at java.lang.invoke.LambdaForm$DMH.1577592551.invokeStatic_L_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.2040688354.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.2094548807.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.666823995.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.2006331902.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$467$110204A$\^function\_.L:1#QueueRunner#run#attemptAsync(:3946) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.228445507.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.666999885.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.537888354.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$463$109486AI$\^function\_.L:1#QueueRunner#run(:3885) at java.lang.invoke.LambdaForm$DMH.1092004553.invokeStatic_L3I_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.580973161.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.945039329.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1524475331.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$460$109209$\^function\_.L:1#QueueRunner#execute(:3873) at java.lang.invoke.LambdaForm$DMH.1577592551.invokeStatic_L_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1560940633.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.212683148.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.212683148.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$reinvoker.1627396964.dontInline(LambdaForm$reinvoker:-1) at java.lang.invoke.LambdaForm$MH.1420232606.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1875650138.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$457$23871A$\^function\_.L:1#Env#Env#queueRunnerFactory(:817) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1557307464.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.666999885.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.537888354.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$483$140690A$\^function\_$cu1$restOf.L:1#TreeProcessor#TreeProcessor#executeNode#fn(:4967) at java.lang.invoke.LambdaForm$DMH.1577592551.invokeStatic_L_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.460331690.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1123406363.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.460331690.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.2040688354.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.2094548807.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.666823995.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.2006331902.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$467$110204A$\^function\_$cu1$restOf.L:1#QueueRunner#run#attemptAsync(:3946) at java.lang.invoke.LambdaForm$DMH.1577592551.invokeStatic_L_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.460331690.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1123406363.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.460331690.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.2040688354.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.228445507.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.666999885.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.537888354.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$463$109486AI$\^function\_$cu1$restOf.L:1#QueueRunner#run(:3885) at java.lang.invoke.LambdaForm$DMH.1577592551.invokeStatic_L_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.460331690.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1336817934.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.580973161.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.945039329.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1524475331.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$460$109209$\^function\_$cu1$restOf.L:1#QueueRunner#execute(:3873) at java.lang.invoke.LambdaForm$DMH.1577592551.invokeStatic_L_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.1123406363.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.987290930.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.212683148.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1875650138.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$457$23871A$\^function\_.L:1#Env#Env#queueRunnerFactory(:817) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$BMH.1557307464.reinvoke(LambdaForm$BMH:-1) at java.lang.invoke.LambdaForm$MH.666999885.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.537888354.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$456$136602A$\^function\_$cu1$restOf.L:1#TreeProcessor#TreeProcessor#execute(:4825) at java.lang.invoke.LambdaForm$DMH.1577592551.invokeStatic_L_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.1123406363.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.460331690.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.2040688354.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.228445507.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.666999885.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.537888354.linkToCallSite(LambdaForm$MH:-1) at jdk.nashorn.internal.scripts.Script$Recompilation$379$24628A$\^function\_.L:1#Env#Env#execute(:884) at java.lang.invoke.LambdaForm$DMH.1904253191.invokeStatic_L3_L(LambdaForm$DMH:-1) at java.lang.invoke.LambdaForm$MH.744216072.guardWithCatch(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$reinvoker.1058457595.dontInline(LambdaForm$reinvoker:-1) at java.lang.invoke.LambdaForm$MH.995133100.guard(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1345348356.exactInvoker(LambdaForm$MH:-1) at java.lang.invoke.LambdaForm$MH.1058123332.invokeExact_MT(LambdaForm$MH:-1) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:639) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:494) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393) at jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199) From srinivas.dama at oracle.com Wed Aug 23 04:38:24 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Tue, 22 Aug 2017 21:38:24 -0700 (PDT) Subject: RFR: 8184720(Nashorn engine in strict mode throws a java.lang.ClassCastException when calling apply() and passing the arguments object) Message-ID: <91c1597c-2c00-4756-adb1-4041b0d55c05@default> Hi, Please review http://cr.openjdk.java.net/~sdama/8184720/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8184720 Regards, Srinivas From hannes.wallnoefer at oracle.com Wed Aug 23 06:44:30 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 23 Aug 2017 08:44:30 +0200 Subject: RFR: 8184720(Nashorn engine in strict mode throws a java.lang.ClassCastException when calling apply() and passing the arguments object) In-Reply-To: <91c1597c-2c00-4756-adb1-4041b0d55c05@default> References: <91c1597c-2c00-4756-adb1-4041b0d55c05@default> Message-ID: Hi Srini, I don?t think the -scripting option is needed in the test, and you could just call the function without try-catch and printing messages. Otherwise +1 Hannes > Am 23.08.2017 um 06:38 schrieb Srinivas Dama : > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8184720/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8184720 > > Regards, > Srinivas From sundararajan.athijegannathan at oracle.com Thu Aug 24 02:13:16 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 24 Aug 2017 07:43:16 +0530 Subject: ScriptFunction being passed to JSObject, expected ScriptObjectMirror In-Reply-To: References: Message-ID: <599E363C.5000303@oracle.com> Hi, Sorry for the delayed response. We need more info to debug this - in particular, what is the exception (if any) thrown etc. I wonder if this is related to this recent apply-related fix -> http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-August/006998.html -Sundar On 22/08/17, 3:43 AM, Jesse Schulman wrote: > This does not happen on the first run of the code but is consistently > happening on the 17th run after a restart and from that point forward is > broken until we restart. > > Attached is a broken and working call stack. > > I have tried to replicate what we are doing in a basic java reproducer but > have not been able to do so, given that I can consistently reproduce this > locally I am happy to take any suggested steps to gather more information > or to workaround/resolve the issue. > > Environment: > Java version 1.8.144 > Engine created with "--no-java", "-strict", "--no-syntax-extensions", > "--language=es6", "--optimistic-types=true" (also tried with > optimistic-types=false) > All evaluation done on the same engine via engine.eval(String, Bindings) > using a Bindings that was returned from engine.createBindings, each of the > "runs" described above took place in a different Bindings instance > > Thanks! > Jesse From jesse at dreamtsoft.com Thu Aug 24 03:44:01 2017 From: jesse at dreamtsoft.com (Jesse Schulman) Date: Thu, 24 Aug 2017 03:44:01 +0000 Subject: ScriptFunction being passed to JSObject, expected ScriptObjectMirror In-Reply-To: <599E363C.5000303@oracle.com> References: <599E363C.5000303@oracle.com> Message-ID: I did try running with -Dnashorn.apply2call=false when I saw the email for that fix but it did not resolve the issue. There is no exception thrown, but our JSObject.call method basically is no-op as a result of not getting a ScriptObjectMirror, it effectively looks like this: @Override public Object call(Object thiz, Object ... args) { if (args.length < 2 || !(args[0] instanceof ScriptObjectMirror) || !((ScriptObjectMirror) args[0]).isFunction() || !(args[1] instanceof Integer)) return gScriptEnvironment.getUndefined(); // safely cast and call ScriptObjectMirror... } I am continuing to work on reproducing it outside our application in a simple way. In the mean time if there's any other information I can share besides a reproducing example, or suggestions on workarounds to try let me know. Thanks! Jesse On Wed, Aug 23, 2017 at 7:10 PM Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Hi, > > Sorry for the delayed response. We need more info to debug this - in > particular, what is the exception (if any) thrown etc. > > I wonder if this is related to this recent apply-related fix -> > > http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-August/006998.html > > -Sundar > > On 22/08/17, 3:43 AM, Jesse Schulman wrote: > > This does not happen on the first run of the code but is consistently > > happening on the 17th run after a restart and from that point forward is > > broken until we restart. > > > > Attached is a broken and working call stack. > > > > I have tried to replicate what we are doing in a basic java reproducer > but > > have not been able to do so, given that I can consistently reproduce this > > locally I am happy to take any suggested steps to gather more information > > or to workaround/resolve the issue. > > > > Environment: > > Java version 1.8.144 > > Engine created with "--no-java", "-strict", "--no-syntax-extensions", > > "--language=es6", "--optimistic-types=true" (also tried with > > optimistic-types=false) > > All evaluation done on the same engine via engine.eval(String, Bindings) > > using a Bindings that was returned from engine.createBindings, each of > the > > "runs" described above took place in a different Bindings instance > > > > Thanks! > > Jesse > From sundararajan.athijegannathan at oracle.com Thu Aug 24 08:07:37 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 24 Aug 2017 13:37:37 +0530 Subject: ScriptFunction being passed to JSObject, expected ScriptObjectMirror In-Reply-To: References: <599E363C.5000303@oracle.com> Message-ID: <599E8949.7000600@oracle.com> what is the type of args[0]? Can you print args[0].getClass() to check it? Thanks, -Sundar On 24/08/17, 9:14 AM, Jesse Schulman wrote: > I did try running with -Dnashorn.apply2call=false when I saw the email > for that fix but it did not resolve the issue. > > There is no exception thrown, but our JSObject.call method basically > is no-op as a result of not getting a ScriptObjectMirror, it > effectively looks like this: > > @Override > public Object call(Object thiz, Object ... args) { > if (args.length < 2 || !(args[0] instanceof > ScriptObjectMirror) || !((ScriptObjectMirror) args[0]).isFunction() || > !(args[1] instanceof Integer)) > return gScriptEnvironment.getUndefined(); > > // safely cast and call ScriptObjectMirror... > } > > > I am continuing to work on reproducing it outside our application in a > simple way. In the mean time if there's any other information I can > share besides a reproducing example, or suggestions on workarounds to > try let me know. > > Thanks! > Jesse > > On Wed, Aug 23, 2017 at 7:10 PM Sundararajan Athijegannathan > > wrote: > > Hi, > > Sorry for the delayed response. We need more info to debug this - in > particular, what is the exception (if any) thrown etc. > > I wonder if this is related to this recent apply-related fix -> > > http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-August/006998.html > > -Sundar > > On 22/08/17, 3:43 AM, Jesse Schulman wrote: > > This does not happen on the first run of the code but is > consistently > > happening on the 17th run after a restart and from that point > forward is > > broken until we restart. > > > > Attached is a broken and working call stack. > > > > I have tried to replicate what we are doing in a basic java > reproducer but > > have not been able to do so, given that I can consistently > reproduce this > > locally I am happy to take any suggested steps to gather more > information > > or to workaround/resolve the issue. > > > > Environment: > > Java version 1.8.144 > > Engine created with "--no-java", "-strict", > "--no-syntax-extensions", > > "--language=es6", "--optimistic-types=true" (also tried with > > optimistic-types=false) > > All evaluation done on the same engine via engine.eval(String, > Bindings) > > using a Bindings that was returned from engine.createBindings, > each of the > > "runs" described above took place in a different Bindings instance > > > > Thanks! > > Jesse > From jesse at dreamtsoft.com Thu Aug 24 17:41:33 2017 From: jesse at dreamtsoft.com (Jesse Schulman) Date: Thu, 24 Aug 2017 17:41:33 +0000 Subject: ScriptFunction being passed to JSObject, expected ScriptObjectMirror In-Reply-To: <599E8949.7000600@oracle.com> References: <599E363C.5000303@oracle.com> <599E8949.7000600@oracle.com> Message-ID: The type is ScriptFunction, I've created a simple reproducer that I've pushed to https://github.com/jesseschulman/JSObject_gets_ScriptFunction Thanks! Jesse On Thu, Aug 24, 2017 at 1:05 AM Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > what is the type of args[0]? Can you print args[0].getClass() to check it? > > Thanks, > -Sundar > > > On 24/08/17, 9:14 AM, Jesse Schulman wrote: > > I did try running with -Dnashorn.apply2call=false when I saw the email for > that fix but it did not resolve the issue. > > There is no exception thrown, but our JSObject.call method basically is > no-op as a result of not getting a ScriptObjectMirror, it effectively looks > like this: > > @Override > public Object call(Object thiz, Object ... args) { > if (args.length < 2 || !(args[0] instanceof > ScriptObjectMirror) || !((ScriptObjectMirror) args[0]).isFunction() || > !(args[1] instanceof Integer)) > return gScriptEnvironment.getUndefined(); > > // safely cast and call ScriptObjectMirror... > } > > > I am continuing to work on reproducing it outside our application in a > simple way. In the mean time if there's any other information I can share > besides a reproducing example, or suggestions on workarounds to try let me > know. > > Thanks! > Jesse > > On Wed, Aug 23, 2017 at 7:10 PM Sundararajan Athijegannathan < > sundararajan.athijegannathan at oracle.com> wrote: > >> Hi, >> >> Sorry for the delayed response. We need more info to debug this - in >> particular, what is the exception (if any) thrown etc. >> >> I wonder if this is related to this recent apply-related fix -> >> >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-August/006998.html >> >> -Sundar >> >> On 22/08/17, 3:43 AM, Jesse Schulman wrote: >> > This does not happen on the first run of the code but is consistently >> > happening on the 17th run after a restart and from that point forward is >> > broken until we restart. >> > >> > Attached is a broken and working call stack. >> > >> > I have tried to replicate what we are doing in a basic java reproducer >> but >> > have not been able to do so, given that I can consistently reproduce >> this >> > locally I am happy to take any suggested steps to gather more >> information >> > or to workaround/resolve the issue. >> > >> > Environment: >> > Java version 1.8.144 >> > Engine created with "--no-java", "-strict", "--no-syntax-extensions", >> > "--language=es6", "--optimistic-types=true" (also tried with >> > optimistic-types=false) >> > All evaluation done on the same engine via engine.eval(String, Bindings) >> > using a Bindings that was returned from engine.createBindings, each of >> the >> > "runs" described above took place in a different Bindings instance >> > >> > Thanks! >> > Jesse >> > From srinivas.dama at oracle.com Fri Aug 25 07:22:38 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Fri, 25 Aug 2017 00:22:38 -0700 (PDT) Subject: RFR: 8184720(Nashorn engine in strict mode throws a java.lang.ClassCastException when calling apply() and passing the arguments object) In-Reply-To: References: <91c1597c-2c00-4756-adb1-4041b0d55c05@default> Message-ID: Thank you Hannes for the comments. Here is the revised patch at http://cr.openjdk.java.net/~sdama/8184720/webrev.01/ . Note: This includes additional fix from Hannes on top of existing fix to resolve assertion error while running tests from 'ant' test runner without 'scripting' option. Regards, Srinivas -----Original Message----- From: Hannes Walln?fer Sent: Wednesday, August 23, 2017 12:15 PM To: Srinivas Dama Cc: Nashorn-Dev Subject: Re: RFR: 8184720(Nashorn engine in strict mode throws a java.lang.ClassCastException when calling apply() and passing the arguments object) Hi Srini, I don?t think the -scripting option is needed in the test, and you could just call the function without try-catch and printing messages. Otherwise +1 Hannes > Am 23.08.2017 um 06:38 schrieb Srinivas Dama : > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8184720/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8184720 > > Regards, > Srinivas From hannes.wallnoefer at oracle.com Fri Aug 25 09:02:36 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Fri, 25 Aug 2017 11:02:36 +0200 Subject: RFR: 8184720(Nashorn engine in strict mode throws a java.lang.ClassCastException when calling apply() and passing the arguments object) In-Reply-To: References: <91c1597c-2c00-4756-adb1-4041b0d55c05@default> Message-ID: <6F11F945-DEEC-4EA4-8FFE-722A050AD5D2@oracle.com> Looks good! Hannes > Am 25.08.2017 um 09:22 schrieb Srinivas Dama : > > Thank you Hannes for the comments. > > Here is the revised patch at http://cr.openjdk.java.net/~sdama/8184720/webrev.01/ . > > Note: This includes additional fix from Hannes on top of existing fix to resolve assertion error while > running tests from 'ant' test runner without 'scripting' option. > > Regards, > Srinivas > > -----Original Message----- > From: Hannes Walln?fer > Sent: Wednesday, August 23, 2017 12:15 PM > To: Srinivas Dama > Cc: Nashorn-Dev > Subject: Re: RFR: 8184720(Nashorn engine in strict mode throws a java.lang.ClassCastException when calling apply() and passing the arguments object) > > Hi Srini, > > I don?t think the -scripting option is needed in the test, and you could just call the function without try-catch and printing messages. > > Otherwise +1 > > Hannes > > >> Am 23.08.2017 um 06:38 schrieb Srinivas Dama : >> >> Hi, >> >> Please review http://cr.openjdk.java.net/~sdama/8184720/webrev.00/ for >> https://bugs.openjdk.java.net/browse/JDK-8184720 >> >> Regards, >> Srinivas > From sundararajan.athijegannathan at oracle.com Mon Aug 28 05:02:11 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 28 Aug 2017 10:32:11 +0530 Subject: ScriptFunction being passed to JSObject, expected ScriptObjectMirror In-Reply-To: References: <599E363C.5000303@oracle.com> <599E8949.7000600@oracle.com> Message-ID: <59A3A3D3.7030604@oracle.com> Hi, Thanks for the standalone test case! I reproduced the issue and filed a bug -> https://bugs.openjdk.java.net/browse/JDK-8186807 Thanks, -Sundar On 24/08/17, 11:11 PM, Jesse Schulman wrote: > The type is ScriptFunction, I've created a simple reproducer that I've > pushed to > https://github.com/jesseschulman/JSObject_gets_ScriptFunction > > > Thanks! > Jesse > > On Thu, Aug 24, 2017 at 1:05 AM Sundararajan Athijegannathan > > wrote: > > what is the type of args[0]? Can you print args[0].getClass() to > check it? > > Thanks, > -Sundar > > > On 24/08/17, 9:14 AM, Jesse Schulman wrote: >> I did try running with -Dnashorn.apply2call=false when I saw the >> email for that fix but it did not resolve the issue. >> >> There is no exception thrown, but our JSObject.call method >> basically is no-op as a result of not getting a >> ScriptObjectMirror, it effectively looks like this: >> >> @Override >> public Object call(Object thiz, Object ... args) { >> if (args.length < 2 || !(args[0] instanceof >> ScriptObjectMirror) || !((ScriptObjectMirror) >> args[0]).isFunction() || !(args[1] instanceof Integer)) >> return gScriptEnvironment.getUndefined(); >> >> // safely cast and call ScriptObjectMirror... >> } >> >> >> I am continuing to work on reproducing it outside our application >> in a simple way. In the mean time if there's any other >> information I can share besides a reproducing example, or >> suggestions on workarounds to try let me know. >> >> Thanks! >> Jesse >> >> On Wed, Aug 23, 2017 at 7:10 PM Sundararajan Athijegannathan >> > > wrote: >> >> Hi, >> >> Sorry for the delayed response. We need more info to debug >> this - in >> particular, what is the exception (if any) thrown etc. >> >> I wonder if this is related to this recent apply-related fix -> >> >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-August/006998.html >> >> -Sundar >> >> On 22/08/17, 3:43 AM, Jesse Schulman wrote: >> > This does not happen on the first run of the code but is >> consistently >> > happening on the 17th run after a restart and from that >> point forward is >> > broken until we restart. >> > >> > Attached is a broken and working call stack. >> > >> > I have tried to replicate what we are doing in a basic java >> reproducer but >> > have not been able to do so, given that I can consistently >> reproduce this >> > locally I am happy to take any suggested steps to gather >> more information >> > or to workaround/resolve the issue. >> > >> > Environment: >> > Java version 1.8.144 >> > Engine created with "--no-java", "-strict", >> "--no-syntax-extensions", >> > "--language=es6", "--optimistic-types=true" (also tried with >> > optimistic-types=false) >> > All evaluation done on the same engine via >> engine.eval(String, Bindings) >> > using a Bindings that was returned from >> engine.createBindings, each of the >> > "runs" described above took place in a different Bindings >> instance >> > >> > Thanks! >> > Jesse >> From jesse at dreamtsoft.com Mon Aug 28 16:33:44 2017 From: jesse at dreamtsoft.com (Jesse Schulman) Date: Mon, 28 Aug 2017 16:33:44 +0000 Subject: ScriptFunction being passed to JSObject, expected ScriptObjectMirror In-Reply-To: <59A3A3D3.7030604@oracle.com> References: <599E363C.5000303@oracle.com> <599E8949.7000600@oracle.com> <59A3A3D3.7030604@oracle.com> Message-ID: Awesome, thanks for the quick response! On a somewhat related note, what is the proper way of returning 'undefined' from a JSObject implementation? I have seen it work various ways but when I have tested our application on the jdk9 beta releases I have had to take a different approach than Undefined.getUndefined() or ScriptRuntime.UNDEFINED since as you mention in that bug report the internal package cannot be accessed. Thanks again, Jesse On Sun, Aug 27, 2017 at 9:59 PM Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > Hi, > > Thanks for the standalone test case! I reproduced the issue and filed a > bug -> https://bugs.openjdk.java.net/browse/JDK-8186807 > > Thanks, > -Sundar > > > On 24/08/17, 11:11 PM, Jesse Schulman wrote: > > The type is ScriptFunction, I've created a simple reproducer that I've > pushed to https://github.com/jesseschulman/JSObject_gets_ScriptFunction > > > Thanks! > Jesse > > On Thu, Aug 24, 2017 at 1:05 AM Sundararajan Athijegannathan < > sundararajan.athijegannathan at oracle.com> wrote: > >> what is the type of args[0]? Can you print args[0].getClass() to check it? >> >> Thanks, >> -Sundar >> >> >> On 24/08/17, 9:14 AM, Jesse Schulman wrote: >> >> I did try running with -Dnashorn.apply2call=false when I saw the email >> for that fix but it did not resolve the issue. >> >> There is no exception thrown, but our JSObject.call method basically is >> no-op as a result of not getting a ScriptObjectMirror, it effectively looks >> like this: >> >> @Override >> public Object call(Object thiz, Object ... args) { >> if (args.length < 2 || !(args[0] instanceof >> ScriptObjectMirror) || !((ScriptObjectMirror) args[0]).isFunction() || >> !(args[1] instanceof Integer)) >> return gScriptEnvironment.getUndefined(); >> >> // safely cast and call ScriptObjectMirror... >> } >> >> >> I am continuing to work on reproducing it outside our application in a >> simple way. In the mean time if there's any other information I can share >> besides a reproducing example, or suggestions on workarounds to try let me >> know. >> >> Thanks! >> Jesse >> >> On Wed, Aug 23, 2017 at 7:10 PM Sundararajan Athijegannathan < >> sundararajan.athijegannathan at oracle.com> wrote: >> >>> Hi, >>> >>> Sorry for the delayed response. We need more info to debug this - in >>> particular, what is the exception (if any) thrown etc. >>> >>> I wonder if this is related to this recent apply-related fix -> >>> >>> >>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-August/006998.html >>> >>> -Sundar >>> >>> On 22/08/17, 3:43 AM, Jesse Schulman wrote: >>> > This does not happen on the first run of the code but is consistently >>> > happening on the 17th run after a restart and from that point forward >>> is >>> > broken until we restart. >>> > >>> > Attached is a broken and working call stack. >>> > >>> > I have tried to replicate what we are doing in a basic java reproducer >>> but >>> > have not been able to do so, given that I can consistently reproduce >>> this >>> > locally I am happy to take any suggested steps to gather more >>> information >>> > or to workaround/resolve the issue. >>> > >>> > Environment: >>> > Java version 1.8.144 >>> > Engine created with "--no-java", "-strict", "--no-syntax-extensions", >>> > "--language=es6", "--optimistic-types=true" (also tried with >>> > optimistic-types=false) >>> > All evaluation done on the same engine via engine.eval(String, >>> Bindings) >>> > using a Bindings that was returned from engine.createBindings, each of >>> the >>> > "runs" described above took place in a different Bindings instance >>> > >>> > Thanks! >>> > Jesse >>> >> From sundararajan.athijegannathan at oracle.com Mon Aug 28 16:41:22 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 28 Aug 2017 22:11:22 +0530 Subject: ScriptFunction being passed to JSObject, expected ScriptObjectMirror In-Reply-To: References: <599E363C.5000303@oracle.com> <599E8949.7000600@oracle.com> <59A3A3D3.7030604@oracle.com> Message-ID: <59A447B2.10208@oracle.com> I think you can do something like this: import javax.script.*; import jdk.nashorn.api.scripting.JSObject; public class Main { public static void main(String[] args) throws Exception { ScriptEngineManager m = new ScriptEngineManager(); ScriptEngine e = m.getEngineByName("nashorn"); JSObject global = (JSObject) e.eval("this"); Object undefined = global.getMember("undefined"); System.out.println(undefined); } } Thanks, -Sundar On 28/08/17, 10:03 PM, Jesse Schulman wrote: > Awesome, thanks for the quick response! > > On a somewhat related note, what is the proper way of returning > 'undefined' from a JSObject implementation? I have seen it work > various ways but when I have tested our application on the jdk9 beta > releases I have had to take a different approach than > Undefined.getUndefined() or ScriptRuntime.UNDEFINED since as you > mention in that bug report the internal package cannot be accessed. > > Thanks again, > Jesse > > On Sun, Aug 27, 2017 at 9:59 PM Sundararajan Athijegannathan > > wrote: > > Hi, > > Thanks for the standalone test case! I reproduced the issue and > filed a bug -> https://bugs.openjdk.java.net/browse/JDK-8186807 > > Thanks, > -Sundar > > > On 24/08/17, 11:11 PM, Jesse Schulman wrote: >> The type is ScriptFunction, I've created a simple reproducer that >> I've pushed to >> https://github.com/jesseschulman/JSObject_gets_ScriptFunction >> >> >> Thanks! >> Jesse >> >> On Thu, Aug 24, 2017 at 1:05 AM Sundararajan Athijegannathan >> > > wrote: >> >> what is the type of args[0]? Can you print args[0].getClass() >> to check it? >> >> Thanks, >> -Sundar >> >> >> On 24/08/17, 9:14 AM, Jesse Schulman wrote: >>> I did try running with -Dnashorn.apply2call=false when I saw >>> the email for that fix but it did not resolve the issue. >>> >>> There is no exception thrown, but our JSObject.call method >>> basically is no-op as a result of not getting a >>> ScriptObjectMirror, it effectively looks like this: >>> >>> @Override >>> public Object call(Object thiz, Object ... args) { >>> if (args.length < 2 || !(args[0] instanceof >>> ScriptObjectMirror) || !((ScriptObjectMirror) >>> args[0]).isFunction() || !(args[1] instanceof Integer)) >>> return gScriptEnvironment.getUndefined(); >>> >>> // safely cast and call ScriptObjectMirror... >>> } >>> >>> >>> I am continuing to work on reproducing it outside our >>> application in a simple way. In the mean time if there's >>> any other information I can share besides a reproducing >>> example, or suggestions on workarounds to try let me know. >>> >>> Thanks! >>> Jesse >>> >>> On Wed, Aug 23, 2017 at 7:10 PM Sundararajan Athijegannathan >>> >> > wrote: >>> >>> Hi, >>> >>> Sorry for the delayed response. We need more info to >>> debug this - in >>> particular, what is the exception (if any) thrown etc. >>> >>> I wonder if this is related to this recent apply-related >>> fix -> >>> >>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-August/006998.html >>> >>> -Sundar >>> >>> On 22/08/17, 3:43 AM, Jesse Schulman wrote: >>> > This does not happen on the first run of the code but >>> is consistently >>> > happening on the 17th run after a restart and from >>> that point forward is >>> > broken until we restart. >>> > >>> > Attached is a broken and working call stack. >>> > >>> > I have tried to replicate what we are doing in a basic >>> java reproducer but >>> > have not been able to do so, given that I can >>> consistently reproduce this >>> > locally I am happy to take any suggested steps to >>> gather more information >>> > or to workaround/resolve the issue. >>> > >>> > Environment: >>> > Java version 1.8.144 >>> > Engine created with "--no-java", "-strict", >>> "--no-syntax-extensions", >>> > "--language=es6", "--optimistic-types=true" (also >>> tried with >>> > optimistic-types=false) >>> > All evaluation done on the same engine via >>> engine.eval(String, Bindings) >>> > using a Bindings that was returned from >>> engine.createBindings, each of the >>> > "runs" described above took place in a different >>> Bindings instance >>> > >>> > Thanks! >>> > Jesse >>> From priya.lakshmi.muthuswamy at oracle.com Tue Aug 29 03:18:25 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Tue, 29 Aug 2017 08:48:25 +0530 Subject: RFR:8184723: jdk.nashorn.internal.runtime.linker.JSObjectLinker.callToApply erroneously asserts given arguments Message-ID: Hi, Please review JDK-8184723: jdk.nashorn.internal.runtime.linker.JSObjectLinker.callToApply erroneously asserts given arguments JBS: https://bugs.openjdk.java.net/browse/JDK-8184723 webrev: http://cr.openjdk.java.net/~pmuthuswamy/8184723/webrev.00/ Thanks, Priya From sundararajan.athijegannathan at oracle.com Tue Aug 29 03:29:41 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 29 Aug 2017 08:59:41 +0530 Subject: RFR:8184723: jdk.nashorn.internal.runtime.linker.JSObjectLinker.callToApply erroneously asserts given arguments In-Reply-To: References: Message-ID: <59A4DFA5.40502@oracle.com> Line 41 of the test: new jdk.nashorn.api.scripting.NashornScriptEngineFactory * could use an import statement and unqualified name and that line is very long too. +1 otherwise. -Sundar On 29/08/17, 8:48 AM, Priya Lakshmi Muthuswamy wrote: > Hi, > > Please review JDK-8184723: > jdk.nashorn.internal.runtime.linker.JSObjectLinker.callToApply > erroneously asserts given arguments > > JBS: https://bugs.openjdk.java.net/browse/JDK-8184723 > webrev: http://cr.openjdk.java.net/~pmuthuswamy/8184723/webrev.00/ > > Thanks, > Priya From priya.lakshmi.muthuswamy at oracle.com Tue Aug 29 03:54:09 2017 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Tue, 29 Aug 2017 09:24:09 +0530 Subject: RFR:8184723: jdk.nashorn.internal.runtime.linker.JSObjectLinker.callToApply erroneously asserts given arguments In-Reply-To: <59A4DFA5.40502@oracle.com> References: <59A4DFA5.40502@oracle.com> Message-ID: Thanks Sundar for the comments. Modified the test. Revised patch: http://cr.openjdk.java.net/~pmuthuswamy/8184723/webrev.01/ Thanks, Priya On 8/29/2017 8:59 AM, Sundararajan Athijegannathan wrote: > Line 41 of the test: > > new jdk.nashorn.api.scripting.NashornScriptEngineFactory > > * could use an import statement and unqualified name and that line is > very long too. > > +1 otherwise. > > -Sundar > > On 29/08/17, 8:48 AM, Priya Lakshmi Muthuswamy wrote: >> Hi, >> >> Please review JDK-8184723: >> jdk.nashorn.internal.runtime.linker.JSObjectLinker.callToApply >> erroneously asserts given arguments >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8184723 >> webrev: http://cr.openjdk.java.net/~pmuthuswamy/8184723/webrev.00/ >> >> Thanks, >> Priya From sundararajan.athijegannathan at oracle.com Tue Aug 29 06:01:47 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 29 Aug 2017 11:31:47 +0530 Subject: RFR:8184723: jdk.nashorn.internal.runtime.linker.JSObjectLinker.callToApply erroneously asserts given arguments In-Reply-To: References: <59A4DFA5.40502@oracle.com> Message-ID: <59A5034B.9080804@oracle.com> +1 -Sundar On 29/08/17, 9:24 AM, Priya Lakshmi Muthuswamy wrote: > Thanks Sundar for the comments. > Modified the test. > Revised patch: http://cr.openjdk.java.net/~pmuthuswamy/8184723/webrev.01/ > > Thanks, > Priya > > On 8/29/2017 8:59 AM, Sundararajan Athijegannathan wrote: >> Line 41 of the test: >> >> new jdk.nashorn.api.scripting.NashornScriptEngineFactory >> >> * could use an import statement and unqualified name and that line is >> very long too. >> >> +1 otherwise. >> >> -Sundar >> >> On 29/08/17, 8:48 AM, Priya Lakshmi Muthuswamy wrote: >>> Hi, >>> >>> Please review JDK-8184723: >>> jdk.nashorn.internal.runtime.linker.JSObjectLinker.callToApply >>> erroneously asserts given arguments >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8184723 >>> webrev: http://cr.openjdk.java.net/~pmuthuswamy/8184723/webrev.00/ >>> >>> Thanks, >>> Priya > From srinivas.dama at oracle.com Tue Aug 29 13:55:28 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Tue, 29 Aug 2017 06:55:28 -0700 (PDT) Subject: RFR:8177691:Labeled break in catch and finally works wrongly, when invoked through nashorn Message-ID: Hi, Please review http://cr.openjdk.java.net/~sdama/8177691/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8177691 Regards, Srinivas From hannes.wallnoefer at oracle.com Tue Aug 29 14:46:49 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Tue, 29 Aug 2017 16:46:49 +0200 Subject: RFR:8184723: jdk.nashorn.internal.runtime.linker.JSObjectLinker.callToApply erroneously asserts given arguments In-Reply-To: References: <59A4DFA5.40502@oracle.com> Message-ID: <9DDA9846-2E97-4C05-B05A-AB693C8CC89D@oracle.com> +1 Hannes > Am 29.08.2017 um 05:54 schrieb Priya Lakshmi Muthuswamy : > > Thanks Sundar for the comments. > Modified the test. > Revised patch: http://cr.openjdk.java.net/~pmuthuswamy/8184723/webrev.01/ > > Thanks, > Priya > > On 8/29/2017 8:59 AM, Sundararajan Athijegannathan wrote: >> Line 41 of the test: >> >> new jdk.nashorn.api.scripting.NashornScriptEngineFactory >> >> * could use an import statement and unqualified name and that line is very long too. >> >> +1 otherwise. >> >> -Sundar >> >> On 29/08/17, 8:48 AM, Priya Lakshmi Muthuswamy wrote: >>> Hi, >>> >>> Please review JDK-8184723: jdk.nashorn.internal.runtime.linker.JSObjectLinker.callToApply erroneously asserts given arguments >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8184723 >>> webrev: http://cr.openjdk.java.net/~pmuthuswamy/8184723/webrev.00/ >>> >>> Thanks, >>> Priya > From jesse at dreamtsoft.com Wed Aug 30 21:24:32 2017 From: jesse at dreamtsoft.com (Jesse Schulman) Date: Wed, 30 Aug 2017 21:24:32 +0000 Subject: ScriptFunction being passed to JSObject, expected ScriptObjectMirror In-Reply-To: <59A447B2.10208@oracle.com> References: <599E363C.5000303@oracle.com> <599E8949.7000600@oracle.com> <59A3A3D3.7030604@oracle.com> <59A447B2.10208@oracle.com> Message-ID: Thanks for advising on how to best get undefined. For the bug you opened I have worked around it for now by calling ScriptUtil.wrap() when we get a ScriptFunction to turn it into a ScriptObjectMirror. I will track the issue at the URL you shared and remove the ScriptUtil.wrap call once it's fixed. Thanks again! Jesse On Mon, Aug 28, 2017 at 9:38 AM Sundararajan Athijegannathan < sundararajan.athijegannathan at oracle.com> wrote: > I think you can do something like this: > > import javax.script.*; > import jdk.nashorn.api.scripting.JSObject; > > public class Main { > public static void main(String[] args) throws Exception { > ScriptEngineManager m = new ScriptEngineManager(); > ScriptEngine e = m.getEngineByName("nashorn"); > JSObject global = (JSObject) e.eval("this"); > Object undefined = global.getMember("undefined"); > System.out.println(undefined); > } > } > > Thanks, > -Sundar > > > On 28/08/17, 10:03 PM, Jesse Schulman wrote: > > Awesome, thanks for the quick response! > > On a somewhat related note, what is the proper way of returning > 'undefined' from a JSObject implementation? I have seen it work various > ways but when I have tested our application on the jdk9 beta releases I > have had to take a different approach than Undefined.getUndefined() or > ScriptRuntime.UNDEFINED since as you mention in that bug report the > internal package cannot be accessed. > > Thanks again, > Jesse > > On Sun, Aug 27, 2017 at 9:59 PM Sundararajan Athijegannathan < > sundararajan.athijegannathan at oracle.com> wrote: > >> Hi, >> >> Thanks for the standalone test case! I reproduced the issue and filed a >> bug -> https://bugs.openjdk.java.net/browse/JDK-8186807 >> >> Thanks, >> -Sundar >> >> >> On 24/08/17, 11:11 PM, Jesse Schulman wrote: >> >> The type is ScriptFunction, I've created a simple reproducer that I've >> pushed to https://github.com/jesseschulman/JSObject_gets_ScriptFunction >> >> >> Thanks! >> Jesse >> >> On Thu, Aug 24, 2017 at 1:05 AM Sundararajan Athijegannathan < >> sundararajan.athijegannathan at oracle.com> wrote: >> >>> what is the type of args[0]? Can you print args[0].getClass() to check >>> it? >>> >>> Thanks, >>> -Sundar >>> >>> >>> On 24/08/17, 9:14 AM, Jesse Schulman wrote: >>> >>> I did try running with -Dnashorn.apply2call=false when I saw the email >>> for that fix but it did not resolve the issue. >>> >>> There is no exception thrown, but our JSObject.call method basically is >>> no-op as a result of not getting a ScriptObjectMirror, it effectively looks >>> like this: >>> >>> @Override >>> public Object call(Object thiz, Object ... args) { >>> if (args.length < 2 || !(args[0] instanceof >>> ScriptObjectMirror) || !((ScriptObjectMirror) args[0]).isFunction() || >>> !(args[1] instanceof Integer)) >>> return gScriptEnvironment.getUndefined(); >>> >>> // safely cast and call ScriptObjectMirror... >>> } >>> >>> >>> I am continuing to work on reproducing it outside our application in a >>> simple way. In the mean time if there's any other information I can share >>> besides a reproducing example, or suggestions on workarounds to try let me >>> know. >>> >>> Thanks! >>> Jesse >>> >>> On Wed, Aug 23, 2017 at 7:10 PM Sundararajan Athijegannathan < >>> sundararajan.athijegannathan at oracle.com> wrote: >>> >>>> Hi, >>>> >>>> Sorry for the delayed response. We need more info to debug this - in >>>> particular, what is the exception (if any) thrown etc. >>>> >>>> I wonder if this is related to this recent apply-related fix -> >>>> >>>> >>>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-August/006998.html >>>> >>>> -Sundar >>>> >>>> On 22/08/17, 3:43 AM, Jesse Schulman wrote: >>>> > This does not happen on the first run of the code but is consistently >>>> > happening on the 17th run after a restart and from that point forward >>>> is >>>> > broken until we restart. >>>> > >>>> > Attached is a broken and working call stack. >>>> > >>>> > I have tried to replicate what we are doing in a basic java >>>> reproducer but >>>> > have not been able to do so, given that I can consistently reproduce >>>> this >>>> > locally I am happy to take any suggested steps to gather more >>>> information >>>> > or to workaround/resolve the issue. >>>> > >>>> > Environment: >>>> > Java version 1.8.144 >>>> > Engine created with "--no-java", "-strict", "--no-syntax-extensions", >>>> > "--language=es6", "--optimistic-types=true" (also tried with >>>> > optimistic-types=false) >>>> > All evaluation done on the same engine via engine.eval(String, >>>> Bindings) >>>> > using a Bindings that was returned from engine.createBindings, each >>>> of the >>>> > "runs" described above took place in a different Bindings instance >>>> > >>>> > Thanks! >>>> > Jesse >>>> >>> From srinivas.dama at oracle.com Thu Aug 31 08:51:01 2017 From: srinivas.dama at oracle.com (Srinivas Dama) Date: Thu, 31 Aug 2017 01:51:01 -0700 (PDT) Subject: RFR:8073640:Nashorn scripting: here document with only whitespace gives error Message-ID: <39feeb10-8290-4b21-ad67-2d994a9e84b5@default> Hi, Please review http://cr.openjdk.java.net/~sdama/8073640/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8073640 Regards, srinivas From hannes.wallnoefer at oracle.com Thu Aug 31 11:01:55 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 31 Aug 2017 13:01:55 +0200 Subject: RFR:8073640:Nashorn scripting: here document with only whitespace gives error In-Reply-To: <39feeb10-8290-4b21-ad67-2d994a9e84b5@default> References: <39feeb10-8290-4b21-ad67-2d994a9e84b5@default> Message-ID: <6A378A3B-4BE1-4797-9526-DF750DA7DD6F@oracle.com> +1 Does this change behaviour for non-empty strings? Hannes > Am 31.08.2017 um 10:51 schrieb Srinivas Dama : > > Hi, > > Please review http://cr.openjdk.java.net/~sdama/8073640/webrev.00/ > for https://bugs.openjdk.java.net/browse/JDK-8073640 > > Regards, > srinivas From james.laskey at oracle.com Thu Aug 31 11:53:01 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 31 Aug 2017 08:53:01 -0300 Subject: RFR:8073640:Nashorn scripting: here document with only whitespace gives error In-Reply-To: <6A378A3B-4BE1-4797-9526-DF750DA7DD6F@oracle.com> References: <39feeb10-8290-4b21-ad67-2d994a9e84b5@default> <6A378A3B-4BE1-4797-9526-DF750DA7DD6F@oracle.com> Message-ID: +1 > On Aug 31, 2017, at 8:01 AM, Hannes Walln?fer wrote: > > +1 > > Does this change behaviour for non-empty strings? > > Hannes > >> Am 31.08.2017 um 10:51 schrieb Srinivas Dama : >> >> Hi, >> >> Please review http://cr.openjdk.java.net/~sdama/8073640/webrev.00/ >> for https://bugs.openjdk.java.net/browse/JDK-8073640 >> >> Regards, >> srinivas > From james.laskey at oracle.com Thu Aug 31 12:03:52 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 31 Aug 2017 09:03:52 -0300 Subject: RFR:8177691:Labeled break in catch and finally works wrongly, when invoked through nashorn In-Reply-To: References: Message-ID: <8094C494-E219-4A47-820F-B308CA06C943@oracle.com> +1 > On Aug 29, 2017, at 10:55 AM, Srinivas Dama wrote: > > Hi, > > > > Please review http://cr.openjdk.java.net/~sdama/8177691/webrev.00/ > > for https://bugs.openjdk.java.net/browse/JDK-8177691 > > > > Regards, > > Srinivas From hannes.wallnoefer at oracle.com Thu Aug 31 14:51:50 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 31 Aug 2017 16:51:50 +0200 Subject: RFR:8177691:Labeled break in catch and finally works wrongly, when invoked through nashorn In-Reply-To: References: Message-ID: <894F4C4B-8B53-4E9C-ABDB-70C6116B7AA9@oracle.com> +1 > Am 29.08.2017 um 15:55 schrieb Srinivas Dama : > > Hi, > > > > Please review http://cr.openjdk.java.net/~sdama/8177691/webrev.00/ > > for https://bugs.openjdk.java.net/browse/JDK-8177691 > > > > Regards, > > Srinivas