From erik.joelsson at oracle.com Thu Oct 2 08:34:13 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 02 Oct 2014 10:34:13 +0200 Subject: RFR: JDK-8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? Message-ID: <542D0E05.7000809@oracle.com> Hello, Please review this small patch fixing the bootstrap problem of building nasgen. To make sure no other nashorn is picked up, force the bootclasspath to be only the rt.jar of the boot jdk and the newly compiled nashorn classes. This webrev also contains the anti delta of the workaround for this that was introduced in [1]. Bug: https://bugs.openjdk.java.net/browse/JDK-8059135 Webrev: http://cr.openjdk.java.net/~erikj/8059135/webrev.nashorn.01/ /Erik [1] https://bugs.openjdk.java.net/browse/JDK-8059132 From attila.szegedi at oracle.com Thu Oct 2 09:12:33 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 2 Oct 2014 11:12:33 +0200 Subject: RFR: JDK-8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? In-Reply-To: <542D0E05.7000809@oracle.com> References: <542D0E05.7000809@oracle.com> Message-ID: <58D1485F-6512-4DD3-8EC1-F27657819466@oracle.com> +1 On Oct 2, 2014, at 10:34 AM, Erik Joelsson wrote: > Hello, > > Please review this small patch fixing the bootstrap problem of building nasgen. To make sure no other nashorn is picked up, force the bootclasspath to be only the rt.jar of the boot jdk and the newly compiled nashorn classes. This webrev also contains the anti delta of the workaround for this that was introduced in [1]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059135 > Webrev: http://cr.openjdk.java.net/~erikj/8059135/webrev.nashorn.01/ > > /Erik > > [1] https://bugs.openjdk.java.net/browse/JDK-8059132 > From attila.szegedi at oracle.com Thu Oct 2 11:21:38 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 2 Oct 2014 13:21:38 +0200 Subject: Review request for JDK-8059346 Message-ID: <5A4E6CCA-AD97-466A-B4AE-6E93EBEAA89F@oracle.com> Please review JDK-8059346 at for This patch allows classes representing obsolete code (overly optimistic code that got deoptimized) to get unloaded from memory. Example: with this patch box2d unloads 617 classes it didn't unload before. Thanks, Attila. From hannes.wallnoefer at oracle.com Thu Oct 2 11:42:01 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 02 Oct 2014 13:42:01 +0200 Subject: Review request for JDK-8059346 In-Reply-To: <5A4E6CCA-AD97-466A-B4AE-6E93EBEAA89F@oracle.com> References: <5A4E6CCA-AD97-466A-B4AE-6E93EBEAA89F@oracle.com> Message-ID: <542D3A09.8010008@oracle.com> +1 Am 2014-10-02 um 13:21 schrieb Attila Szegedi: > Please review JDK-8059346 at for > > This patch allows classes representing obsolete code (overly optimistic code that got deoptimized) to get unloaded from memory. Example: with this patch box2d unloads 617 classes it didn't unload before. > > Thanks, > Attila. > From marcus.lagergren at oracle.com Thu Oct 2 14:17:58 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 2 Oct 2014 07:17:58 -0700 Subject: RFR: JDK-8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? In-Reply-To: <542D0E05.7000809@oracle.com> References: <542D0E05.7000809@oracle.com> Message-ID: <288B65C1-9B47-49B5-A132-E1531017B514@oracle.com> +1 On 02 Oct 2014, at 01:34, Erik Joelsson wrote: > Hello, > > Please review this small patch fixing the bootstrap problem of building nasgen. To make sure no other nashorn is picked up, force the bootclasspath to be only the rt.jar of the boot jdk and the newly compiled nashorn classes. This webrev also contains the anti delta of the workaround for this that was introduced in [1]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059135 > Webrev: http://cr.openjdk.java.net/~erikj/8059135/webrev.nashorn.01/ > > /Erik > > [1] https://bugs.openjdk.java.net/browse/JDK-8059132 > From marcus.lagergren at oracle.com Thu Oct 2 14:19:06 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 2 Oct 2014 07:19:06 -0700 Subject: Review request for JDK-8059346 In-Reply-To: <5A4E6CCA-AD97-466A-B4AE-6E93EBEAA89F@oracle.com> References: <5A4E6CCA-AD97-466A-B4AE-6E93EBEAA89F@oracle.com> Message-ID: <64CDC31D-0EB8-441D-BCCC-FF9AAB58B136@oracle.com> +1 On 02 Oct 2014, at 04:21, Attila Szegedi wrote: > Please review JDK-8059346 at for > > This patch allows classes representing obsolete code (overly optimistic code that got deoptimized) to get unloaded from memory. Example: with this patch box2d unloads 617 classes it didn't unload before. > > Thanks, > Attila. > From attila.szegedi at oracle.com Thu Oct 2 14:29:04 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 2 Oct 2014 16:29:04 +0200 Subject: eval in DebuggerSupport.java fails. In-Reply-To: References: Message-ID: Not all locals live in the scope object. If you look at the code Nashorn emits[*] you will see that Nashorn strives to use JVM bytecode local variables whenever it can. Only function local variables that need to be visible in a nested lexical context (e.g. nested function) will be pushed into the scope object. Attila. -- [*] Use the --print-code command line switch to jjs. Programmatically, use "-Dnashorn.args=--print-code" or use NashornScriptEngineFactory explicitly and invoke its getScriptEngine(String...) method to pass command line arguments. On Sep 30, 2014, at 10:36 AM, Kuperman Sergey wrote: > Kuperman Sergey writes: > >> >> Hello ! I am not sure it is the right place to ask but i will try anyway ) >> My team is trying to develop a JS debugger poc running Nashorn , and we >> encountered an issue when trying to implement evaluation in function context: >> We run some JS function with: >> ScriptEngineManager sem = new ScriptEngineManager(); >> ScriptEngine engine = sem.getEngineByName("nashorn"); >> engine.eval("load (\"src/com/sap/rdl/runjs/file.js\");"); >> in another app we set a breakpoint in a function, and try to invoke eval() >> function from DebuggerSupport.java , while passing to it :scope variable we >> received from the relevant frame's visibleVariables (JDI). >> eval succeeds when global or upper scope defined variables are involved, but >> if i use an expression with local function variable, i receive ECMAException >> no such variable defined.. it seems to me that eval needs local vars to be >> defined within the scope but they are not .. >> Is there anything i could do to make it work ? >> >> Thanks in advance >> >> Sergey >> SAP RDL development team >> >> > > A little further investigation shows, that nashorn :scope loads variables > lazily - only when needed or if eval function is used inside js. > Is there a way to force :scope to contain all vars regardless of use ? I > mean except using dummy eval statement that would be an ugly workaround.. > thanks in advance > Sergey > > From tim.bell at oracle.com Thu Oct 2 14:29:23 2014 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 02 Oct 2014 07:29:23 -0700 Subject: RFR: JDK-8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? In-Reply-To: <542D0E05.7000809@oracle.com> References: <542D0E05.7000809@oracle.com> Message-ID: <542D6143.2010102@oracle.com> Hi Erik: > Please review this small patch fixing the bootstrap problem of > building nasgen. To make sure no other nashorn is picked up, force the > bootclasspath to be only the rt.jar of the boot jdk and the newly > compiled nashorn classes. This webrev also contains the anti delta of > the workaround for this that was introduced in [1]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059135 > Webrev: http://cr.openjdk.java.net/~erikj/8059135/webrev.nashorn.01/ > > /Erik > > [1] https://bugs.openjdk.java.net/browse/JDK-8059132 Looks good to me. Tim From attila.szegedi at oracle.com Thu Oct 2 14:39:07 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 2 Oct 2014 16:39:07 +0200 Subject: Nashorn and JVMTI In-Reply-To: References: Message-ID: <2695ADB3-5D95-485E-9D7F-0090256079AE@oracle.com> No, we don't do anything to conceal Nashorn's internals. Granted, most of it lives in jdk.internal and jdk.nashorn.internal that are designated as restricted packages, but that shouldn't stop a debugger from looking into them. We often use jvisualvm ourselves to investigate Nashorn performance. I often tell people that one of the benefits of running anything (including JavaScript) on the JVM is monitoring and management, so I'd definitely be against obscured visibility into the runtime. I'll try to make NetBeans and JVMTI people aware of this. Attila. On Sep 25, 2014, at 11:13 PM, David P. Caldwell wrote: > Team, > > When I attempt to connect the NetBeans profiler (which I understand to > be essentially the same as jvisualvm) to a Nashorn embedding, I get an > error (JVMTI error 62) for essentially every class that relates to > scripting, including the dynalink stuff and Nashorn itself, as well as > generated classes named NashornJavaAdapter. > > If I persist through all of this (or filter them out of being > profiled, or turn on -Xverify:none), I end up with profiling data that > doesn't involve the JavaScript code at all; it basically treats the > call to eval() as atomic. > > Do you guys do this stuff? My customers are constantly objecting to > the "fact" that running Java on the JVM is going to be a terrible > idea, performance-wise -- especially compared to Node, which they > believe is lightning fast -- and I am having difficulty generating > data on this point. > > More generally, of course, profiling is a normal and necessary > development activity. I wrote a Java agent for Rhino that mangled the > classes using Javassist to wrap all JavaScript function invocations in > instrumented methods, but I'm not clear on (a) whether that's > necessary, or (b) how it would work given the Nashorn implementation > is probably using constructs I don't yet understand. But if that's the > route, let me know and give me a pointer or two and I'll be on my way. > > -- David P. Caldwell > http://www.davidpcaldwell.com/ From attila.szegedi at oracle.com Thu Oct 2 14:44:38 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 2 Oct 2014 16:44:38 +0200 Subject: Is this a bug? Inconsistent Java type for modulo operator In-Reply-To: <5421A87A.6020208@oracle.com> References: <5421A87A.6020208@oracle.com> Message-ID: <698164D2-86CC-49B0-AFA4-3B0E880FF19B@oracle.com> What Sundar said. It's admittedly weird, however for 8u40 Nashorn has seriously revamped internals, including a fairly decent[*] type inference engine, so looks like that took care of this issue too. Attila. -- [*] IMHO, but I'm biased being the one who wrote it. On Sep 23, 2014, at 7:06 PM, A. Sundararajan wrote: > Hi, > > The latest 8u-dev code @ http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn prints this: > > eval = 0 > eval2 = 1 > eval.getClass() = class java.lang.Integer > eval2.getClass() = class java.lang.Integer > > That said it is better to avoid depending on Java side value to be a specific subtype of Number (like Integer, Double, Long). It is better to expect and handle Numbar and call intValue(), doubleValue() on it. That gives maximum freedom for Nashorn implementation. Nashorn tries to represent int/long/double as appropriate for the specific cases. > > -Sundar > > On Tuesday 23 September 2014 06:47 PM, David P. Caldwell wrote: >> Asked by a StackOverflow user; I've produced a clearer reproduction case below. >> >> Original question is >> http://stackoverflow.com/questions/25989642/why-does-java-8-nashorn-javascript-modulo-returns-0-0-double-instead-of-0-i/25991982 >> >> It confused the asker and I confess it makes no sense to me: >> >> public class Tester { >> public static void main( String[] args ) throws Exception { >> javax.script.ScriptEngine se = new >> javax.script.ScriptEngineManager().getEngineByName( "nashorn" ); >> >> Object eval = se.eval( "5%5" ); >> Object eval2 = se.eval( "5%2" ); >> >> System.out.println( "eval = " + eval ); >> System.out.println( "eval2 = " + eval2 ); >> System.out.println( "eval.getClass() = " + eval.getClass() ); >> System.out.println( "eval2.getClass() = " + eval2.getClass() ); >> } >> } >> >> Result: >> >> $ java -version && javac Tester.java && java Tester >> java version "1.8.0_20" >> Java(TM) SE Runtime Environment (build 1.8.0_20-b26) >> Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode) >> eval = 0.0 >> eval2 = 1 >> eval.getClass() = class java.lang.Double >> eval2.getClass() = class java.lang.Integer > From attila.szegedi at oracle.com Thu Oct 2 17:05:02 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 2 Oct 2014 19:05:02 +0200 Subject: Nashorn and JVMTI In-Reply-To: References: Message-ID: <61F01D9C-DDC2-41DE-96EC-41E1BAC49887@oracle.com> David, I was told this is a bug in the JDK that has since been fixed and will be released with 8u25 on October 14. Relevant issue descriptions are at and . The discussion at the first link seems to have also mentioned -Xverify:none as a temporary workaround. I have reviewed these and there's no talk about this fix being relevant to the visibility into Nashorn classes too. To determine that, you can download Java 8u40 Early Access release from and see if it fixes the entirety of your issue ? the current 8u40 EA build is 07, and I can see that the fix for this issue has made it already into build 03. Hope that helps, Attila. On Sep 25, 2014, at 11:13 PM, David P. Caldwell wrote: > Team, > > When I attempt to connect the NetBeans profiler (which I understand to > be essentially the same as jvisualvm) to a Nashorn embedding, I get an > error (JVMTI error 62) for essentially every class that relates to > scripting, including the dynalink stuff and Nashorn itself, as well as > generated classes named NashornJavaAdapter. > > If I persist through all of this (or filter them out of being > profiled, or turn on -Xverify:none), I end up with profiling data that > doesn't involve the JavaScript code at all; it basically treats the > call to eval() as atomic. > > Do you guys do this stuff? My customers are constantly objecting to > the "fact" that running Java on the JVM is going to be a terrible > idea, performance-wise -- especially compared to Node, which they > believe is lightning fast -- and I am having difficulty generating > data on this point. > > More generally, of course, profiling is a normal and necessary > development activity. I wrote a Java agent for Rhino that mangled the > classes using Javassist to wrap all JavaScript function invocations in > instrumented methods, but I'm not clear on (a) whether that's > necessary, or (b) how it would work given the Nashorn implementation > is probably using constructs I don't yet understand. But if that's the > route, let me know and give me a pointer or two and I'll be on my way. > > -- David P. Caldwell > http://www.davidpcaldwell.com/ From ecki at zusammenkunft.net Thu Oct 2 18:21:27 2014 From: ecki at zusammenkunft.net (Bernd) Date: Thu, 2 Oct 2014 20:21:27 +0200 Subject: Nashorn and JVMTI In-Reply-To: References: Message-ID: Hello David, Do you want to optimize the JVM settings before challenging V8 or do you hope to get absolute measurements with the profiler to show off? Because I would advice against using profilers for anything besides optimizations, finding hotspots and doing before/after comparision or trends. For the shootout an externally driven metric (req/s, 99%th service times) is a guess better. And particular on bigger machines (which I would expect to be the NodeJS bottleneck - not sure if Avatar.JS does this better). Gruss Bernd Am 25.09.2014 23:24 schrieb "David P. Caldwell" < david at code.davidpcaldwell.com>: > Team, > > When I attempt to connect the NetBeans profiler (which I understand to > be essentially the same as jvisualvm) to a Nashorn embedding, I get an > error (JVMTI error 62) for essentially every class that relates to > scripting, including the dynalink stuff and Nashorn itself, as well as > generated classes named NashornJavaAdapter. > > If I persist through all of this (or filter them out of being > profiled, or turn on -Xverify:none), I end up with profiling data that > doesn't involve the JavaScript code at all; it basically treats the > call to eval() as atomic. > > Do you guys do this stuff? My customers are constantly objecting to > the "fact" that running Java on the JVM is going to be a terrible > idea, performance-wise -- especially compared to Node, which they > believe is lightning fast -- and I am having difficulty generating > data on this point. > > More generally, of course, profiling is a normal and necessary > development activity. I wrote a Java agent for Rhino that mangled the > classes using Javassist to wrap all JavaScript function invocations in > instrumented methods, but I'm not clear on (a) whether that's > necessary, or (b) how it would work given the Nashorn implementation > is probably using constructs I don't yet understand. But if that's the > route, let me know and give me a pointer or two and I'll be on my way. > > -- David P. Caldwell > http://www.davidpcaldwell.com/ > From david at code.davidpcaldwell.com Thu Oct 2 18:56:43 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Thu, 2 Oct 2014 14:56:43 -0400 Subject: Nashorn and JVMTI In-Reply-To: References: Message-ID: Bernd, Thanks for your advice on this. I do not enjoy benchmarking; I enjoy simplicity, and a customer with a Java-based stack, lots of JavaScript programmers working on the client, and a desire to migrate toward scripting languages should use Nashorn, because it's by far the simplest path forward. But the objection I got was "there are performance concerns," with no evidence presented. So I'd want to (a) create a minimal amount of evidence, (b) use profiling exactly like you're suggesting to do a bit of bottleneck elimination of proof-of-concept code before presenting it. Because the first evaluation customer would do would be to load test it, and I'd want to be prepared. I anticipate bottlenecks would have nothing to do with Nashorn (there are no DBAs, so the database is not exactly optimized), but I'd like to have some metrics to demonstrate that. I agree that I would not use the profiler to do performance benchmarking, given that the profiler adds overhead in the first place. :) -- David. On Thu, Oct 2, 2014 at 2:21 PM, Bernd wrote: > Hello David, > > Do you want to optimize the JVM settings before challenging V8 or do you > hope to get absolute measurements with the profiler to show off? > > Because I would advice against using profilers for anything besides > optimizations, finding hotspots and doing before/after comparision or > trends. > > For the shootout an externally driven metric (req/s, 99%th service times) > is a guess better. And particular on bigger machines (which I would expect > to be the NodeJS bottleneck - not sure if Avatar.JS does this better). > > Gruss > Bernd > Am 25.09.2014 23:24 schrieb "David P. Caldwell" < > david at code.davidpcaldwell.com>: > >> Team, >> >> When I attempt to connect the NetBeans profiler (which I understand to >> be essentially the same as jvisualvm) to a Nashorn embedding, I get an >> error (JVMTI error 62) for essentially every class that relates to >> scripting, including the dynalink stuff and Nashorn itself, as well as >> generated classes named NashornJavaAdapter. >> >> If I persist through all of this (or filter them out of being >> profiled, or turn on -Xverify:none), I end up with profiling data that >> doesn't involve the JavaScript code at all; it basically treats the >> call to eval() as atomic. >> >> Do you guys do this stuff? My customers are constantly objecting to >> the "fact" that running Java on the JVM is going to be a terrible >> idea, performance-wise -- especially compared to Node, which they >> believe is lightning fast -- and I am having difficulty generating >> data on this point. >> >> More generally, of course, profiling is a normal and necessary >> development activity. I wrote a Java agent for Rhino that mangled the >> classes using Javassist to wrap all JavaScript function invocations in >> instrumented methods, but I'm not clear on (a) whether that's >> necessary, or (b) how it would work given the Nashorn implementation >> is probably using constructs I don't yet understand. But if that's the >> route, let me know and give me a pointer or two and I'll be on my way. >> >> -- David P. Caldwell >> http://www.davidpcaldwell.com/ >> From david at code.davidpcaldwell.com Fri Oct 3 16:15:43 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Fri, 3 Oct 2014 12:15:43 -0400 Subject: Problem (?) with Nashorn management of Error prototype Message-ID: So I have a big library of Rhino-compatible (and browser-compatible) code and have recently been working through the processes (debugger, profiler) and code changes necessary to get it working with Nashorn. A bit of background: the project probably differs from the typical early Nashorn use case in that it heavily manipulates scopes and targeting (i.e., 'this') in order to achieve its modularization goals. Much of this is abstracted into a "loader" layer whose innermost Nashorn invocation is the following code: this.compile = function(name,code,scope,target) { var compiled = Context.getContext().compileScript(toSource(name,code),scope); return Packages.jdk.nashorn.internal.runtime.ScriptRuntime.apply(compiled,target); }; Yes, internal interfaces, I've been warned, moving on ... :) The name "compile" is deceptive; it's actually the name of the strategy. (I had tried several, and they are still in the code, and selected at runtime via an environment variable. "compile" is the default. Feel free to comment.) The function would, if it were standalone, probably be called something like "run" or "load." toSource() calls the Source constructor or factory method, depending which is present (looks like that changed in early 1.8.0 JDKs). Here's the full source file: https://bitbucket.org/davidpcaldwell/slime/src/d04bd814156d4e4cc520492e65876cf1235a55e8/loader/rhino/nashorn.js For a while, this barely worked with Nashorn (requiring workarounds) because somehow with complicated scope chains Nashorn would get confused and variables from outer scopes would be missing inside inner scopes, particularly when Nashorn had been re-entered (i.e., the apply() call from which the inner scope was being executed was different from the apply() call in which the outer scope was executed). I vaguely wrote to the list about this but I was never able to reproduce the problem in a way that I could present or was small, and then it was somehow fixed by the u20 release of JDK 1.8, and suddenly everything worked. Except objects that have Error in the prototype chain. They still have strange behavior, and I've been poking at it for some time, and have a few guesses about it. The good news is, I have an easy way to reproduce it (instructions at end of this message). The bad news is, it involves my whole JavaScript shell because when I tried a minimal wrapper everything worked. The good news is, I'm confident it's not a bug in my code, because: 1. The loader layer abstracts the differences between the four major browsers, Rhino, and Nashorn, and everything except errors works the same in all six, and errors work the same in the first five. 2. When I replace the Error global object with my own, the code works. So it's something having to do with "your" Error object, or (my guess) some conditional code you have somewhere inside Nashorn that checks for it. My guess is that there is some optimization somewhere that walks the prototype chain and checks for Error. I think this because I tried a number of strategies for working around this: * Using Object.create * Using an intermediary function ErrorType that had new Error() as its prototype, and using new ErrorType() as the prototype for my function ... and they all had the same result if Error was anywhere in the prototype chain of my error. But using a different prototype (basically, writing my own Error) worked, also in several different configurations. Here's the code that fails (ignore the loader scaffolding): $exports.Error.Type = function(name) { var rv = function(message,properties) { if (this instanceof arguments.callee) { this.name = name; this.message = message; for (var x in properties) { this[x] = properties[x]; } } else { return new arguments.callee(message); } }; rv.prototype = new Error(); return rv; }; Here's some test code that exercises it: var Unimplemented = jsh.js.Error.Type("Unimplemented"); try { throw new Unimplemented("Not implemented."); } catch (e) { jsh.shell.echo("toString: " + e.toString()); jsh.shell.echo("Error?: " + Boolean(e instanceof Error)); jsh.shell.echo("Unimplemented?: " + Boolean(e instanceof Unimplemented)); jsh.shell.echo("name: " + e.name); jsh.shell.echo("message: " + e.message); jsh.shell.echo("stack: " + e.stack); } Here's the output if I use my own global Error object. That object is implemented at the top of nashorn.js (same file as above): https://bitbucket.org/davidpcaldwell/slime/src/d04bd814156d4e4cc520492e65876cf1235a55e8/loader/rhino/nashorn.js toString: Unimplemented: Not implemented. Error?: true Unimplemented?: true name: Unimplemented message: Not implemented. stack: at rhino/nashorn.js:35 at /Users/dcaldwell/tmp/nashorn.error/jsh/src/jsh/test/manual/errortype.jsh.js:11 at rhino/nashorn.js:131 at rhino/nashorn.js:173 at rhino/nashorn.js:203 at rhino/literal.js:65 at rhino/literal.js#36:9@6:132 at rhino/literal.js#36:9@6:217 at /Users/dcaldwell/tmp/nashorn.error/jsh/script/jsh/jsh.js#111:14@10:91 at /Users/dcaldwell/tmp/nashorn.error/jsh/script/jsh/jsh.js:252 That is what is intended. The output is roughly the same as that for all four major browsers and for Rhino. Here's the output if I don't replace the global Error object: toString: Error Error?: true Unimplemented?: false name: Error message: stack: So that's where I am at the moment. Basically, it looks like I'm getting the error subtype's prototype as my error, no matter what I do. A few comments: * My workaround *mostly* works. The main problems are, a.) I need to enumerate all my own error subtypes like TypeError or else TypeError objects are not instanceof Error. On the other hand, if I do that, b.) TypeErrors (presumably other errors, also) thrown from Nashorn itself are not instanceof TypeError or Error. So it's a little messy. * I haven't looked at the Nashorn source code surrounding any of this; I've been debugging it as a black box. (Obviously the fact that I am using ScriptRuntime, Context and Source means I've been in there a little bit, though. I have not built it myself.) * This may be a red herring, but developing with NetBeans, if I step through the $exports.Error.Type code (using a patched copy; NetBeans Nashorn support also isn't good enough yet to run my shell, though it becomes minimally usable with a little bit of patching; see https://netbeans.org/bugzilla/show_bug.cgi?id=247441), it is *very* confused. Inside the error subtype constructor (called "rv" above), the debugger (but not the code!) thinks that the global object is "this" (even when executing via new). But when the code executes, it does *not* treat the global object as "this." So don't know what the problem is here, but the whole thing smells funny. * My test environment is JDK 1.8.0u20. OS X Mavericks, though I can't imagine that matters. * Possibly unrelated, but another strange hard-coding symptom I seemed to have with Error is that if I assign properties to *my* replacement Error constructor -- not to Error objects, but to the constructor (I tried to use Error.nashorn to act as a conditional flag) -- those properties are invisible; not enumerable or accessible. But I haven't investigated this as thoroughly and it might be something dumb I'm doing; just reporting in case it rings a bell. Possibly the Error property of the global scope is used *by name* somewhere and handled specially, because that one symptom still seemed to impact my Error object even when I replaced yours. Anyway, I know this was long but I wanted to do my due diligence and communicate all of it. Here's how to reproduce, starting in an empty directory: 1. Build the shell to a subdirectory called "jsh": jrunscript -e "load('https://bitbucket.org/davidpcaldwell/slime/raw/d04bd81/jsh/etc/jrunscript.js?relative=./install.jrunscript.js')" jsh 2. To run the test case with my workaround enabled: java -jar jsh/jsh.jar jsh/src/jsh/test/manual/errortype.jsh.js 3. To run the test case with my workaround disabled, exposing the error (on a UNIX-like system; translate for Windows as necessary): env DISABLE_NASHORN_ERROR_HACK=true java -jar jsh/jsh.jar jsh/src/jsh/test/manual/errortype.jsh.js Hopefully it's something simple. :) -- David P. Caldwell http://www.davidpcaldwell.com/ From david at code.davidpcaldwell.com Fri Oct 3 16:20:21 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Fri, 3 Oct 2014 12:20:21 -0400 Subject: Problem (?) with Nashorn management of Error prototype In-Reply-To: References: Message-ID: P.S. on re-reading it occurs to me that it's possible I am crossing Nashorn-internal code that calls Object.freeze on the Error property of the global object, or something like that -- this is also consistent with my symptom of not being able to add properties to my replacement Error. On Fri, Oct 3, 2014 at 12:15 PM, David P. Caldwell wrote: > So I have a big library of Rhino-compatible (and browser-compatible) > code and have recently been working through the processes (debugger, > profiler) and code changes necessary to get it working with Nashorn. > > A bit of background: the project probably differs from the typical > early Nashorn use case in that it heavily manipulates scopes and > targeting (i.e., 'this') in order to achieve its modularization goals. > Much of this is abstracted into a "loader" layer whose innermost > Nashorn invocation is the following code: > > this.compile = function(name,code,scope,target) { > var compiled = > Context.getContext().compileScript(toSource(name,code),scope); > return Packages.jdk.nashorn.internal.runtime.ScriptRuntime.apply(compiled,target); > }; > > Yes, internal interfaces, I've been warned, moving on ... :) > > The name "compile" is deceptive; it's actually the name of the > strategy. (I had tried several, and they are still in the code, and > selected at runtime via an environment variable. "compile" is the > default. Feel free to comment.) The function would, if it were > standalone, probably be called something like "run" or "load." > toSource() calls the Source constructor or factory method, depending > which is present (looks like that changed in early 1.8.0 JDKs). > > Here's the full source file: > https://bitbucket.org/davidpcaldwell/slime/src/d04bd814156d4e4cc520492e65876cf1235a55e8/loader/rhino/nashorn.js > > For a while, this barely worked with Nashorn (requiring workarounds) > because somehow with complicated scope chains Nashorn would get > confused and variables from outer scopes would be missing inside inner > scopes, particularly when Nashorn had been re-entered (i.e., the > apply() call from which the inner scope was being executed was > different from the apply() call in which the outer scope was > executed). > > I vaguely wrote to the list about this but I was never able to > reproduce the problem in a way that I could present or was small, and > then it was somehow fixed by the u20 release of JDK 1.8, and suddenly > everything worked. > > Except objects that have Error in the prototype chain. They still have > strange behavior, and I've been poking at it for some time, and have a > few guesses about it. > > The good news is, I have an easy way to reproduce it (instructions at > end of this message). The bad news is, it involves my whole JavaScript > shell because when I tried a minimal wrapper everything worked. The > good news is, I'm confident it's not a bug in my code, because: > > 1. The loader layer abstracts the differences between the four major > browsers, Rhino, and Nashorn, and everything except errors works the > same in all six, and errors work the same in the first five. > > 2. When I replace the Error global object with my own, the code works. > So it's something having to do with "your" Error object, or (my guess) > some conditional code you have somewhere inside Nashorn that checks > for it. > > My guess is that there is some optimization somewhere that walks the > prototype chain and checks for Error. I think this because I tried a > number of strategies for working around this: > > * Using Object.create > * Using an intermediary function ErrorType that had new Error() as its > prototype, and using new ErrorType() as the prototype for my function > > ... and they all had the same result if Error was anywhere in the > prototype chain of my error. But using a different prototype > (basically, writing my own Error) worked, also in several different > configurations. > > Here's the code that fails (ignore the loader scaffolding): > > $exports.Error.Type = function(name) { > var rv = function(message,properties) { > if (this instanceof arguments.callee) { > this.name = name; > this.message = message; > for (var x in properties) { > this[x] = properties[x]; > } > } else { > return new arguments.callee(message); > } > }; > rv.prototype = new Error(); > return rv; > }; > > Here's some test code that exercises it: > > var Unimplemented = jsh.js.Error.Type("Unimplemented"); > > try { > throw new Unimplemented("Not implemented."); > } catch (e) { > jsh.shell.echo("toString: " + e.toString()); > jsh.shell.echo("Error?: " + Boolean(e instanceof Error)); > jsh.shell.echo("Unimplemented?: " + Boolean(e instanceof Unimplemented)); > jsh.shell.echo("name: " + e.name); > jsh.shell.echo("message: " + e.message); > jsh.shell.echo("stack: " + e.stack); > } > > Here's the output if I use my own global Error object. That object is > implemented at the top of nashorn.js (same file as above): > https://bitbucket.org/davidpcaldwell/slime/src/d04bd814156d4e4cc520492e65876cf1235a55e8/loader/rhino/nashorn.js > > toString: Unimplemented: Not implemented. > Error?: true > Unimplemented?: true > name: Unimplemented > message: Not implemented. > stack: at rhino/nashorn.js:35 > at /Users/dcaldwell/tmp/nashorn.error/jsh/src/jsh/test/manual/errortype.jsh.js:11 > at rhino/nashorn.js:131 > at rhino/nashorn.js:173 > at rhino/nashorn.js:203 > at rhino/literal.js:65 > at rhino/literal.js#36:9@6:132 > at rhino/literal.js#36:9@6:217 > at /Users/dcaldwell/tmp/nashorn.error/jsh/script/jsh/jsh.js#111:14@10:91 > at /Users/dcaldwell/tmp/nashorn.error/jsh/script/jsh/jsh.js:252 > > That is what is intended. The output is roughly the same as that for > all four major browsers and for Rhino. > > Here's the output if I don't replace the global Error object: > > toString: Error > Error?: true > Unimplemented?: false > name: Error > message: > stack: > > So that's where I am at the moment. Basically, it looks like I'm > getting the error subtype's prototype as my error, no matter what I > do. > > A few comments: > > * My workaround *mostly* works. The main problems are, a.) I need to > enumerate all my own error subtypes like TypeError or else TypeError > objects are not instanceof Error. On the other hand, if I do that, b.) > TypeErrors (presumably other errors, also) thrown from Nashorn itself > are not instanceof TypeError or Error. So it's a little messy. > > * I haven't looked at the Nashorn source code surrounding any of this; > I've been debugging it as a black box. (Obviously the fact that I am > using ScriptRuntime, Context and Source means I've been in there a > little bit, though. I have not built it myself.) > > * This may be a red herring, but developing with NetBeans, if I step > through the $exports.Error.Type code (using a patched copy; NetBeans > Nashorn support also isn't good enough yet to run my shell, though it > becomes minimally usable with a little bit of patching; see > https://netbeans.org/bugzilla/show_bug.cgi?id=247441), it is *very* > confused. Inside the error subtype constructor (called "rv" above), > the debugger (but not the code!) thinks that the global object is > "this" (even when executing via new). But when the code executes, it > does *not* treat the global object as "this." So don't know what the > problem is here, but the whole thing smells funny. > > * My test environment is JDK 1.8.0u20. OS X Mavericks, though I can't > imagine that matters. > > * Possibly unrelated, but another strange hard-coding symptom I seemed > to have with Error is that if I assign properties to *my* replacement > Error constructor -- not to Error objects, but to the constructor (I > tried to use Error.nashorn to act as a conditional flag) -- those > properties are invisible; not enumerable or accessible. But I haven't > investigated this as thoroughly and it might be something dumb I'm > doing; just reporting in case it rings a bell. Possibly the Error > property of the global scope is used *by name* somewhere and handled > specially, because that one symptom still seemed to impact my Error > object even when I replaced yours. > > Anyway, I know this was long but I wanted to do my due diligence and > communicate all of it. Here's how to reproduce, starting in an empty > directory: > > 1. Build the shell to a subdirectory called "jsh": > jrunscript -e "load('https://bitbucket.org/davidpcaldwell/slime/raw/d04bd81/jsh/etc/jrunscript.js?relative=./install.jrunscript.js')" > jsh > > 2. To run the test case with my workaround enabled: > java -jar jsh/jsh.jar jsh/src/jsh/test/manual/errortype.jsh.js > > 3. To run the test case with my workaround disabled, exposing the > error (on a UNIX-like system; translate for Windows as necessary): > env DISABLE_NASHORN_ERROR_HACK=true java -jar jsh/jsh.jar > jsh/src/jsh/test/manual/errortype.jsh.js > > Hopefully it's something simple. :) > > -- David P. Caldwell > http://www.davidpcaldwell.com/ From james.laskey at oracle.com Fri Oct 3 16:32:28 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 3 Oct 2014 09:32:28 -0700 Subject: Problem (?) with Nashorn management of Error prototype In-Reply-To: References: Message-ID: <6D31AC85-D70F-446D-8E32-EAEBBFA1779D@oracle.com> Just responding quickly to let you know we will look into this but the 5 of us are all away till Monday with JavaOne and much needed breaks. Cheers -- Jim Sent from Jim's iPhone > On Oct 3, 2014, at 9:20 AM, David P. Caldwell wrote: > > P.S. on re-reading it occurs to me that it's possible I am crossing > Nashorn-internal code that calls Object.freeze on the Error property > of the global object, or something like that -- this is also > consistent with my symptom of not being able to add properties to my > replacement Error. > > On Fri, Oct 3, 2014 at 12:15 PM, David P. Caldwell > wrote: >> So I have a big library of Rhino-compatible (and browser-compatible) >> code and have recently been working through the processes (debugger, >> profiler) and code changes necessary to get it working with Nashorn. >> >> A bit of background: the project probably differs from the typical >> early Nashorn use case in that it heavily manipulates scopes and >> targeting (i.e., 'this') in order to achieve its modularization goals. >> Much of this is abstracted into a "loader" layer whose innermost >> Nashorn invocation is the following code: >> >> this.compile = function(name,code,scope,target) { >> var compiled = >> Context.getContext().compileScript(toSource(name,code),scope); >> return Packages.jdk.nashorn.internal.runtime.ScriptRuntime.apply(compiled,target); >> }; >> >> Yes, internal interfaces, I've been warned, moving on ... :) >> >> The name "compile" is deceptive; it's actually the name of the >> strategy. (I had tried several, and they are still in the code, and >> selected at runtime via an environment variable. "compile" is the >> default. Feel free to comment.) The function would, if it were >> standalone, probably be called something like "run" or "load." >> toSource() calls the Source constructor or factory method, depending >> which is present (looks like that changed in early 1.8.0 JDKs). >> >> Here's the full source file: >> https://bitbucket.org/davidpcaldwell/slime/src/d04bd814156d4e4cc520492e65876cf1235a55e8/loader/rhino/nashorn.js >> >> For a while, this barely worked with Nashorn (requiring workarounds) >> because somehow with complicated scope chains Nashorn would get >> confused and variables from outer scopes would be missing inside inner >> scopes, particularly when Nashorn had been re-entered (i.e., the >> apply() call from which the inner scope was being executed was >> different from the apply() call in which the outer scope was >> executed). >> >> I vaguely wrote to the list about this but I was never able to >> reproduce the problem in a way that I could present or was small, and >> then it was somehow fixed by the u20 release of JDK 1.8, and suddenly >> everything worked. >> >> Except objects that have Error in the prototype chain. They still have >> strange behavior, and I've been poking at it for some time, and have a >> few guesses about it. >> >> The good news is, I have an easy way to reproduce it (instructions at >> end of this message). The bad news is, it involves my whole JavaScript >> shell because when I tried a minimal wrapper everything worked. The >> good news is, I'm confident it's not a bug in my code, because: >> >> 1. The loader layer abstracts the differences between the four major >> browsers, Rhino, and Nashorn, and everything except errors works the >> same in all six, and errors work the same in the first five. >> >> 2. When I replace the Error global object with my own, the code works. >> So it's something having to do with "your" Error object, or (my guess) >> some conditional code you have somewhere inside Nashorn that checks >> for it. >> >> My guess is that there is some optimization somewhere that walks the >> prototype chain and checks for Error. I think this because I tried a >> number of strategies for working around this: >> >> * Using Object.create >> * Using an intermediary function ErrorType that had new Error() as its >> prototype, and using new ErrorType() as the prototype for my function >> >> ... and they all had the same result if Error was anywhere in the >> prototype chain of my error. But using a different prototype >> (basically, writing my own Error) worked, also in several different >> configurations. >> >> Here's the code that fails (ignore the loader scaffolding): >> >> $exports.Error.Type = function(name) { >> var rv = function(message,properties) { >> if (this instanceof arguments.callee) { >> this.name = name; >> this.message = message; >> for (var x in properties) { >> this[x] = properties[x]; >> } >> } else { >> return new arguments.callee(message); >> } >> }; >> rv.prototype = new Error(); >> return rv; >> }; >> >> Here's some test code that exercises it: >> >> var Unimplemented = jsh.js.Error.Type("Unimplemented"); >> >> try { >> throw new Unimplemented("Not implemented."); >> } catch (e) { >> jsh.shell.echo("toString: " + e.toString()); >> jsh.shell.echo("Error?: " + Boolean(e instanceof Error)); >> jsh.shell.echo("Unimplemented?: " + Boolean(e instanceof Unimplemented)); >> jsh.shell.echo("name: " + e.name); >> jsh.shell.echo("message: " + e.message); >> jsh.shell.echo("stack: " + e.stack); >> } >> >> Here's the output if I use my own global Error object. That object is >> implemented at the top of nashorn.js (same file as above): >> https://bitbucket.org/davidpcaldwell/slime/src/d04bd814156d4e4cc520492e65876cf1235a55e8/loader/rhino/nashorn.js >> >> toString: Unimplemented: Not implemented. >> Error?: true >> Unimplemented?: true >> name: Unimplemented >> message: Not implemented. >> stack: at rhino/nashorn.js:35 >> at /Users/dcaldwell/tmp/nashorn.error/jsh/src/jsh/test/manual/errortype.jsh.js:11 >> at rhino/nashorn.js:131 >> at rhino/nashorn.js:173 >> at rhino/nashorn.js:203 >> at rhino/literal.js:65 >> at rhino/literal.js#36:9@6:132 >> at rhino/literal.js#36:9@6:217 >> at /Users/dcaldwell/tmp/nashorn.error/jsh/script/jsh/jsh.js#111:14@10:91 >> at /Users/dcaldwell/tmp/nashorn.error/jsh/script/jsh/jsh.js:252 >> >> That is what is intended. The output is roughly the same as that for >> all four major browsers and for Rhino. >> >> Here's the output if I don't replace the global Error object: >> >> toString: Error >> Error?: true >> Unimplemented?: false >> name: Error >> message: >> stack: >> >> So that's where I am at the moment. Basically, it looks like I'm >> getting the error subtype's prototype as my error, no matter what I >> do. >> >> A few comments: >> >> * My workaround *mostly* works. The main problems are, a.) I need to >> enumerate all my own error subtypes like TypeError or else TypeError >> objects are not instanceof Error. On the other hand, if I do that, b.) >> TypeErrors (presumably other errors, also) thrown from Nashorn itself >> are not instanceof TypeError or Error. So it's a little messy. >> >> * I haven't looked at the Nashorn source code surrounding any of this; >> I've been debugging it as a black box. (Obviously the fact that I am >> using ScriptRuntime, Context and Source means I've been in there a >> little bit, though. I have not built it myself.) >> >> * This may be a red herring, but developing with NetBeans, if I step >> through the $exports.Error.Type code (using a patched copy; NetBeans >> Nashorn support also isn't good enough yet to run my shell, though it >> becomes minimally usable with a little bit of patching; see >> https://netbeans.org/bugzilla/show_bug.cgi?id=247441), it is *very* >> confused. Inside the error subtype constructor (called "rv" above), >> the debugger (but not the code!) thinks that the global object is >> "this" (even when executing via new). But when the code executes, it >> does *not* treat the global object as "this." So don't know what the >> problem is here, but the whole thing smells funny. >> >> * My test environment is JDK 1.8.0u20. OS X Mavericks, though I can't >> imagine that matters. >> >> * Possibly unrelated, but another strange hard-coding symptom I seemed >> to have with Error is that if I assign properties to *my* replacement >> Error constructor -- not to Error objects, but to the constructor (I >> tried to use Error.nashorn to act as a conditional flag) -- those >> properties are invisible; not enumerable or accessible. But I haven't >> investigated this as thoroughly and it might be something dumb I'm >> doing; just reporting in case it rings a bell. Possibly the Error >> property of the global scope is used *by name* somewhere and handled >> specially, because that one symptom still seemed to impact my Error >> object even when I replaced yours. >> >> Anyway, I know this was long but I wanted to do my due diligence and >> communicate all of it. Here's how to reproduce, starting in an empty >> directory: >> >> 1. Build the shell to a subdirectory called "jsh": >> jrunscript -e "load('https://bitbucket.org/davidpcaldwell/slime/raw/d04bd81/jsh/etc/jrunscript.js?relative=./install.jrunscript.js')" >> jsh >> >> 2. To run the test case with my workaround enabled: >> java -jar jsh/jsh.jar jsh/src/jsh/test/manual/errortype.jsh.js >> >> 3. To run the test case with my workaround disabled, exposing the >> error (on a UNIX-like system; translate for Windows as necessary): >> env DISABLE_NASHORN_ERROR_HACK=true java -jar jsh/jsh.jar >> jsh/src/jsh/test/manual/errortype.jsh.js >> >> Hopefully it's something simple. :) >> >> -- David P. Caldwell >> http://www.davidpcaldwell.com/ From marcus.lagergren at oracle.com Fri Oct 3 17:42:50 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 3 Oct 2014 10:42:50 -0700 Subject: RFR: JDK-8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? In-Reply-To: <542D6143.2010102@oracle.com> References: <542D0E05.7000809@oracle.com> <542D6143.2010102@oracle.com> Message-ID: Thanks Erik, Are you pusing this forward to jdk9 as well? Regards Marcus On 02 Oct 2014, at 07:29, Tim Bell wrote: > Hi Erik: > >> Please review this small patch fixing the bootstrap problem of building nasgen. To make sure no other nashorn is picked up, force the bootclasspath to be only the rt.jar of the boot jdk and the newly compiled nashorn classes. This webrev also contains the anti delta of the workaround for this that was introduced in [1]. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059135 >> Webrev: http://cr.openjdk.java.net/~erikj/8059135/webrev.nashorn.01/ >> >> /Erik >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8059132 > > Looks good to me. > > Tim > > From marcus.lagergren at oracle.com Fri Oct 3 17:47:12 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 3 Oct 2014 10:47:12 -0700 Subject: RFR: JDK-8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? In-Reply-To: References: <542D0E05.7000809@oracle.com> <542D6143.2010102@oracle.com> Message-ID: <123C5961-9DA6-490F-B459-EF408CF714A7@oracle.com> Oh - you already did. My bad. Thanks so much for the quick resolution. /M On 03 Oct 2014, at 10:42, Marcus Lagergren wrote: > Thanks Erik, > > Are you pusing this forward to jdk9 as well? > > Regards > Marcus > > On 02 Oct 2014, at 07:29, Tim Bell wrote: > >> Hi Erik: >> >>> Please review this small patch fixing the bootstrap problem of building nasgen. To make sure no other nashorn is picked up, force the bootclasspath to be only the rt.jar of the boot jdk and the newly compiled nashorn classes. This webrev also contains the anti delta of the workaround for this that was introduced in [1]. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059135 >>> Webrev: http://cr.openjdk.java.net/~erikj/8059135/webrev.nashorn.01/ >>> >>> /Erik >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8059132 >> >> Looks good to me. >> >> Tim >> >> > From marcus.lagergren at oracle.com Fri Oct 3 18:24:18 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 3 Oct 2014 11:24:18 -0700 Subject: Please review JDK-8059231 Message-ID: <0065C3A3-FC77-486A-B1B4-84B276C2B251@oracle.com> There was a temporary regression which is now fixed and not reproducible either in 8u-dev or 9. Octane raytrace and pdfjs couldn?t run with optimistic types disabled. I have verified that this is no longer a problem and ensured that optimistic types really were disabled/enabled in the different configurations. When doing so, I noticed that the logging that should tell us if this is the case is missing, and there were also some other cosmetic problems with the compiler log. I fixed that, and also added the short name ?-ot? for optimistic typing. Webrev is at: http://cr.openjdk.java.net/~lagergren/8059231/webrev/ Please review. Regards Marcus From hannes.wallnoefer at oracle.com Fri Oct 3 18:28:30 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 03 Oct 2014 20:28:30 +0200 Subject: Please review JDK-8059231 In-Reply-To: <0065C3A3-FC77-486A-B1B4-84B276C2B251@oracle.com> References: <0065C3A3-FC77-486A-B1B4-84B276C2B251@oracle.com> Message-ID: <542EEACE.7030803@oracle.com> +1 Am 2014-10-03 um 20:24 schrieb Marcus Lagergren: > There was a temporary regression which is now fixed and not reproducible either in 8u-dev or 9. Octane raytrace and pdfjs couldn?t run with optimistic types disabled. > > I have verified that this is no longer a problem and ensured that optimistic types really were disabled/enabled in the different configurations. When doing so, I noticed that the logging that should tell us if this is the case is missing, and there were also some other cosmetic problems with the compiler log. I fixed that, and also added the short name ?-ot? for optimistic typing. > > Webrev is at: http://cr.openjdk.java.net/~lagergren/8059231/webrev/ > > Please review. > > Regards > Marcus > > > From sundararajan.athijegannathan at oracle.com Mon Oct 6 03:13:56 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 06 Oct 2014 08:43:56 +0530 Subject: RFR: JDK-8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? In-Reply-To: <542D0E05.7000809@oracle.com> References: <542D0E05.7000809@oracle.com> Message-ID: <543208F4.4010204@oracle.com> 1) Perhaps javac's extdirs option has to be used? 2) Also override whatever is in boot JDK with whatever is being built? (rather than prepend/append extension or bootstrap) Thanks -Sundar On Thursday 02 October 2014 02:04 PM, Erik Joelsson wrote: > Hello, > > Please review this small patch fixing the bootstrap problem of > building nasgen. To make sure no other nashorn is picked up, force the > bootclasspath to be only the rt.jar of the boot jdk and the newly > compiled nashorn classes. This webrev also contains the anti delta of > the workaround for this that was introduced in [1]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059135 > Webrev: http://cr.openjdk.java.net/~erikj/8059135/webrev.nashorn.01/ > > /Erik > > [1] https://bugs.openjdk.java.net/browse/JDK-8059132 > From sundararajan.athijegannathan at oracle.com Mon Oct 6 07:18:22 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 06 Oct 2014 12:48:22 +0530 Subject: Please review JDK-8059231 In-Reply-To: <542EEACE.7030803@oracle.com> References: <0065C3A3-FC77-486A-B1B4-84B276C2B251@oracle.com> <542EEACE.7030803@oracle.com> Message-ID: <5432423E.3050508@oracle.com> +1 On Friday 03 October 2014 11:58 PM, Hannes Wallnoefer wrote: > +1 > > Am 2014-10-03 um 20:24 schrieb Marcus Lagergren: >> There was a temporary regression which is now fixed and not >> reproducible either in 8u-dev or 9. Octane raytrace and pdfjs >> couldn?t run with optimistic types disabled. >> >> I have verified that this is no longer a problem and ensured that >> optimistic types really were disabled/enabled in the different >> configurations. When doing so, I noticed that the logging that should >> tell us if this is the case is missing, and there were also some >> other cosmetic problems with the compiler log. I fixed that, and also >> added the short name ?-ot? for optimistic typing. >> >> Webrev is at: http://cr.openjdk.java.net/~lagergren/8059231/webrev/ >> >> Please review. >> >> Regards >> Marcus >> >> >> > From erik.joelsson at oracle.com Tue Oct 7 08:33:20 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 07 Oct 2014 10:33:20 +0200 Subject: [8u40] Request for approval and review: JDK-8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? Message-ID: <5433A550.6020708@oracle.com> Hello, Please review and approve this backport from jdk9 to jdk8u40. The patch does not apply cleanly, but with a slight reduction it works just as well. The Bug: https://bugs.openjdk.java.net/browse/JDK-8059135 The jdk9 review: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003568.html The jdk8u-dev webrev: http://cr.openjdk.java.net/~erikj/8059135/webrev.nashorn.01.jdk8u/ /Erik From sean.coffey at oracle.com Tue Oct 7 11:14:41 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Tue, 07 Oct 2014 12:14:41 +0100 Subject: [8u40] Request for approval and review: JDK-8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? In-Reply-To: <5433A550.6020708@oracle.com> References: <5433A550.6020708@oracle.com> Message-ID: <5433CB21.80900@oracle.com> Approved but subject to a code review. Please add a noreg- label to the bug report also. regards, Sean. On 07/10/2014 09:33, Erik Joelsson wrote: > Hello, > > Please review and approve this backport from jdk9 to jdk8u40. The > patch does not apply cleanly, but with a slight reduction it works > just as well. > > The Bug: https://bugs.openjdk.java.net/browse/JDK-8059135 > The jdk9 review: > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003568.html > The jdk8u-dev webrev: > http://cr.openjdk.java.net/~erikj/8059135/webrev.nashorn.01.jdk8u/ > > /Erik From attila.szegedi at oracle.com Tue Oct 7 11:23:32 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 7 Oct 2014 13:23:32 +0200 Subject: Review request for JDK-8059842 Message-ID: <6FADB43C-F122-4FE6-852C-3844622FCB71@oracle.com> Please review JDK-8059842 at for Thanks, Attila. From attila.szegedi at oracle.com Tue Oct 7 11:29:48 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 7 Oct 2014 13:29:48 +0200 Subject: Review request for JDK-8059843 Message-ID: <7DFAFAF9-2147-4BD0-B210-5EFA93FCF76D@oracle.com> Please review JDK-8059843 at for Thanks, Attila. From marcus.lagergren at oracle.com Tue Oct 7 11:41:37 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 7 Oct 2014 13:41:37 +0200 Subject: Review request for JDK-8059842 In-Reply-To: <6FADB43C-F122-4FE6-852C-3844622FCB71@oracle.com> References: <6FADB43C-F122-4FE6-852C-3844622FCB71@oracle.com> Message-ID: +1 /M On 07 Oct 2014, at 13:23, Attila Szegedi wrote: > Please review JDK-8059842 at for > > Thanks, > Attila. From attila.szegedi at oracle.com Tue Oct 7 11:52:07 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 7 Oct 2014 13:52:07 +0200 Subject: Review request for JDK-8059844 Message-ID: <040FF823-8635-45AF-95AB-92BDAC8C679B@oracle.com> Please review JDK-8059844 at for Thanks, Attila. From marcus.lagergren at oracle.com Tue Oct 7 12:04:04 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 7 Oct 2014 14:04:04 +0200 Subject: Review request for JDK-8059843 In-Reply-To: <7DFAFAF9-2147-4BD0-B210-5EFA93FCF76D@oracle.com> References: <7DFAFAF9-2147-4BD0-B210-5EFA93FCF76D@oracle.com> Message-ID: <827E640E-051C-4F9F-812D-F9EB0B75D439@oracle.com> +1 On 07 Oct 2014, at 13:29, Attila Szegedi wrote: > Please review JDK-8059843 at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Tue Oct 7 12:19:29 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 07 Oct 2014 17:49:29 +0530 Subject: Problem (?) with Nashorn management of Error prototype Message-ID: <5433DA51.3070703@oracle.com> This is w.r.t this email: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003582.html Hi, did you manage a simpler test case? Internal runtime errors like TypeError on function-call-on-undefined etc. are created using Global.newTypeError, newURIError etc. - which actually create objects of specific impl. classes like NativeTypeError, NativeURIError and so on. This is as per the spec AFAIK - i.e., runtime can use "original" definitions of these constructors rather than the value fetched from current global's properties of same name ("Error", "TypeError" properties of global object). I don't recall any other place where there is specific prototype/constructor assumed/hard coded in nashorn. Thanks, -Sundar From hannes.wallnoefer at oracle.com Tue Oct 7 12:55:20 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 07 Oct 2014 14:55:20 +0200 Subject: Review request for JDK-8059842 In-Reply-To: <6FADB43C-F122-4FE6-852C-3844622FCB71@oracle.com> References: <6FADB43C-F122-4FE6-852C-3844622FCB71@oracle.com> Message-ID: <5433E2B8.20308@oracle.com> +1 Am 2014-10-07 um 13:23 schrieb Attila Szegedi: > Please review JDK-8059842 at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Tue Oct 7 12:56:05 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 07 Oct 2014 14:56:05 +0200 Subject: Review request for JDK-8059843 In-Reply-To: <7DFAFAF9-2147-4BD0-B210-5EFA93FCF76D@oracle.com> References: <7DFAFAF9-2147-4BD0-B210-5EFA93FCF76D@oracle.com> Message-ID: <5433E2E5.1010604@oracle.com> +1 Am 2014-10-07 um 13:29 schrieb Attila Szegedi: > Please review JDK-8059843 at for > > Thanks, > Attila. From david at code.davidpcaldwell.com Tue Oct 7 13:10:32 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Tue, 7 Oct 2014 09:10:32 -0400 Subject: Problem (?) with Nashorn management of Error prototype In-Reply-To: <5433DA51.3070703@oracle.com> References: <5433DA51.3070703@oracle.com> Message-ID: No, I haven't been able to get any of the layers peeled off. I figured since I was able to reduce it to running just a couple of commands that would be sufficient for you to catch it in action and see what's going on. I'm not sure what part of the surrounding stack is essential yet. > 1. Build the shell to a subdirectory called "jsh": > jrunscript -e "load('https://bitbucket.org/davidpcaldwell/slime/raw/d04bd81/jsh/etc/jrunscript.js?relative=./install.jrunscript.js')" > jsh > > 2. To run the test case with my workaround enabled: > java -jar jsh/jsh.jar jsh/src/jsh/test/manual/errortype.jsh.js > > 3. To run the test case with my workaround disabled, exposing the > error (on a UNIX-like system; translate for Windows as necessary): > env DISABLE_NASHORN_ERROR_HACK=true java -jar jsh/jsh.jar > jsh/src/jsh/test/manual/errortype.jsh.js -- David P. Caldwell http://www.davidpcaldwell.com/ On Tue, Oct 7, 2014 at 8:19 AM, A. Sundararajan wrote: > This is w.r.t this email: > > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003582.html > > Hi, > > did you manage a simpler test case? Internal runtime errors like TypeError > on function-call-on-undefined etc. are created using Global.newTypeError, > newURIError etc. - which actually create objects of specific impl. classes > like NativeTypeError, NativeURIError and so on. This is as per the spec > AFAIK - i.e., runtime can use "original" definitions of these constructors > rather than the value fetched from current global's properties of same name > ("Error", "TypeError" properties of global object). I don't recall any other > place where there is specific prototype/constructor assumed/hard coded in > nashorn. > > Thanks, > -Sundar From tim.bell at oracle.com Tue Oct 7 13:37:18 2014 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 07 Oct 2014 06:37:18 -0700 Subject: [8u40] Request for approval and review: JDK-8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? In-Reply-To: <5433CB21.80900@oracle.com> References: <5433A550.6020708@oracle.com> <5433CB21.80900@oracle.com> Message-ID: <5433EC8E.9050105@oracle.com> Erik: Code review looks good to me. Tim On 10/07/14 04:14, Se?n Coffey wrote: > Approved but subject to a code review. Please add a noreg- label to > the bug report also. > > regards, > Sean. > > On 07/10/2014 09:33, Erik Joelsson wrote: >> Hello, >> >> Please review and approve this backport from jdk9 to jdk8u40. The >> patch does not apply cleanly, but with a slight reduction it works >> just as well. >> >> The Bug: https://bugs.openjdk.java.net/browse/JDK-8059135 >> The jdk9 review: >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003568.html >> The jdk8u-dev webrev: >> http://cr.openjdk.java.net/~erikj/8059135/webrev.nashorn.01.jdk8u From andreas.gabrielsson at oracle.com Wed Oct 8 09:13:12 2014 From: andreas.gabrielsson at oracle.com (Andreas Gabrielsson) Date: Wed, 08 Oct 2014 11:13:12 +0200 Subject: Please review JDK-8012518 In-Reply-To: <541843D9.8050708@oracle.com> References: <5416FF44.4070804@oracle.com> <30117576-1E53-4D27-800D-ADF2A965DB3C@oracle.com> <541843D9.8050708@oracle.com> Message-ID: <54350028.30002@oracle.com> Now all of Attila's comments should be fixed. I have also removed some public setters that were not needed anymore. Me and Marcus run a few performance tests and they passed, there were basically no difference. New webrev is at: http://cr.openjdk.java.net/~lagergren/8012518.5/ Andreas On 2014-09-16 16:06, Andreas Gabrielsson wrote: > I have fixed the thing you list below, thank you. > New webrev uploaded at: http://cr.openjdk.java.net/~lagergren/8012518.3/ > On 2014-09-16 10:50, Attila Szegedi wrote: >> .hgignore: >> -what's OpenJDK policy for these? I see we have .idea/* in there; how >> about we put .externalToolBuilders/* and .settings/* there instead? >> >> Block.java: >> - I don't like variables named "tmp" anything. "terminalFlags"? >> - New public constructors are entirely undocumented. Not that the old >> one had quality documentation, but still? >> - private constructor no longer sets finish. Why is it still in the >> parameter list? >> >> ForNode.java: >> - undocumented public constructor >> >> LoopNode.java: >> - undocumented protected constructor parameters >> >> WhileNode.java >> - undocumented public constructor parameters >> >> In all the new classes for parser context implementation: >> - add empty line between package declaration and imports >> - the import ordering doesn't follow our source code policy of >> "strict alphabetical, no grouping separator lines" >> - do these classes need to be public? >> >> Parser.java: >> - many local variables and method parameters could be declared final. >> - I generally dislike assigning an expression only used once to a >> local variable, e.g. >> List statements = newBlock.getStatements(); >> return new Block(blockToken, finish, newBlock.getFlags(), >> statements); >> or >> FunctionNode scriptFunction = createFunctionNode(script, >> functionToken, ident, new ArrayList(), >> FunctionNode.Kind.SCRIPT, functionLine, programBody); >> return scriptFunction; >> and there are more. >> >> BaseParserContextNode.java: >> - several cases of missing space before opening curly brace >> - missing "final"s on function parameters >> - missing documentation >> >> ParserContext.java >> - getLastStatement(): consider extracting common subexpression >> stack[sp - 1].getStatements() into a local variable >> - if you made push() generic as public >> T push(final T node) then you wouldn't need casting its return values >> in Parser. >> >> ParserContextFunctionNode.java >> - consider extracting the (flags & FunctionNode.SOME_FLAG) != 0 >> pattern into a boolean getFlag(final int flag) function >> >> Most of these remarks are related to stylistic issues: we try to >> ensure everything has a JavaDoc, we're strict about using the "final" >> keyword everywhere possible (you can have an Eclipse save action that >> adds them), we have a set policy for organizing imports so that >> different people's IDE settings don't cause unnecessary noise in >> diffs, etc. You'll get the hang of it as you go. Nice work overall! >> >> Attila. >> >> On Sep 15, 2014, at 5:01 PM, Andreas Gabrielsson >> wrote: >> >>> Webrev: http://cr.openjdk.java.net/~lagergren/8012518.2/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8012518 > From marcus.lagergren at oracle.com Wed Oct 8 09:17:57 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 8 Oct 2014 11:17:57 +0200 Subject: [8u40] Request for approval and review: JDK-8059135: New Nasgen dependencies to Nashorn breaks the JDK 9 build - bootstrapping problem? In-Reply-To: <5433A550.6020708@oracle.com> References: <5433A550.6020708@oracle.com> Message-ID: <95BE5A49-826F-4355-A75D-EAE316F3817F@oracle.com> Looks good! /M On 07 Oct 2014, at 10:33, Erik Joelsson wrote: > Hello, > > Please review and approve this backport from jdk9 to jdk8u40. The patch does not apply cleanly, but with a slight reduction it works just as well. > > The Bug: https://bugs.openjdk.java.net/browse/JDK-8059135 > The jdk9 review: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003568.html > The jdk8u-dev webrev: http://cr.openjdk.java.net/~erikj/8059135/webrev.nashorn.01.jdk8u/ > > /Erik From hannes.wallnoefer at oracle.com Wed Oct 8 13:44:35 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 08 Oct 2014 15:44:35 +0200 Subject: Review request for JDK-8059236: Memory leak when executing octane pdfjs with optimistic typing Message-ID: <54353FC3.2000809@oracle.com> Please review JDK-8059236: Memory leak when executing octane pdfjs with optimistic typing: http://cr.openjdk.java.net/~hannesw/8059236/ Most of it is reformatting of run-octane.js which had strange indentation. The actual fix is to add a callback to reset the canvas_logs array after each iteration of pdfjs. Thanks, Hannes From james.laskey at oracle.com Wed Oct 8 13:46:46 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 8 Oct 2014 10:46:46 -0300 Subject: Review request for JDK-8059236: Memory leak when executing octane pdfjs with optimistic typing In-Reply-To: <54353FC3.2000809@oracle.com> References: <54353FC3.2000809@oracle.com> Message-ID: <3D1A3EE8-8258-44B7-9870-C4EFB58FA59B@oracle.com> +1 On Oct 8, 2014, at 10:44 AM, Hannes Wallnoefer wrote: > Please review JDK-8059236: Memory leak when executing octane pdfjs with optimistic typing: > > http://cr.openjdk.java.net/~hannesw/8059236/ > > Most of it is reformatting of run-octane.js which had strange indentation. The actual fix is to add a callback to reset the canvas_logs array after each iteration of pdfjs. > > Thanks, > Hannes From attila.szegedi at oracle.com Wed Oct 8 13:47:38 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 8 Oct 2014 15:47:38 +0200 Subject: Review request for JDK-8059236: Memory leak when executing octane pdfjs with optimistic typing In-Reply-To: <54353FC3.2000809@oracle.com> References: <54353FC3.2000809@oracle.com> Message-ID: +1. Nice fix. On Oct 8, 2014, at 3:44 PM, Hannes Wallnoefer wrote: > Please review JDK-8059236: Memory leak when executing octane pdfjs with optimistic typing: > > http://cr.openjdk.java.net/~hannesw/8059236/ > > Most of it is reformatting of run-octane.js which had strange indentation. The actual fix is to add a callback to reset the canvas_logs array after each iteration of pdfjs. > > Thanks, > Hannes From marcus.lagergren at oracle.com Wed Oct 8 14:40:58 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 8 Oct 2014 16:40:58 +0200 Subject: Review request for JDK-8059844 In-Reply-To: <040FF823-8635-45AF-95AB-92BDAC8C679B@oracle.com> References: <040FF823-8635-45AF-95AB-92BDAC8C679B@oracle.com> Message-ID: <20D6BF42-3663-402F-9E93-0ECF448DC6B7@oracle.com> Happy with this and your explanations after you?ve applied my suggestions offline. Also excellent wiki page on the inner workings of the splitter. /M On 07 Oct 2014, at 13:52, Attila Szegedi wrote: > Please review JDK-8059844 at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Wed Oct 8 14:42:09 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 08 Oct 2014 16:42:09 +0200 Subject: Review request for JDK-8059938: NPE restoring cached script with optimistic types disabled Message-ID: <54354D41.4050406@oracle.com> Please review JDK-8059938: NPE restoring cached script with optimistic types disabled: http://cr.openjdk.java.net/~hannesw/8059938/ Thanks, Hannes From kajmagnus79 at gmail.com Wed Oct 8 05:16:45 2014 From: kajmagnus79 at gmail.com (Kaj Magnus Lindberg) Date: Wed, 8 Oct 2014 07:16:45 +0200 Subject: Nashorn bug in Java 8 u20? For trivial TypeScript code Message-ID: Hi dear Nashorn developers, The example below throws an ArrayIndexOutOfBoundsException. I'm thinking there's a Nashorn bug that you might want to fix? I'm getting the impression that currently it's not possible to run TypeScript compiled code in Nashorn, because of this bug. The snippet below is a compiled trivial TypeScript module. File test.js: var test;(function (test) { (function (renderer) { var posts = { 0: null, 1: null, 2: null, 3: null // comment out this line --> no exception thrown }; })(test.renderer = {}); // comment out 'test.renderer = ' --> no exception thrown})(test = {}); Then run the script like so: /usr/lib/jvm/java-8-oracle/bin/jjs test.js Operating system: Linux Mint 17, 64 bit. Java version: $ java -version java version "1.8.0_20"Java(TM) SE Runtime Environment (build 1.8.0_20-b26)Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode) (There's also a StackOverflow question about this: http://stackoverflow.com/questions/26189940/java-8-nashorn-arrayindexoutofboundsexception ) Best regards, KajMagnus From james.laskey at oracle.com Wed Oct 8 15:02:39 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 8 Oct 2014 12:02:39 -0300 Subject: JJS tool In-Reply-To: References: Message-ID: <521AA188-65F3-4E32-A0FD-DD7B7897895D@oracle.com> You can find details in http://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn You can add a soft link to the command to simplify access (see http://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/shell.html ), but otherwise you add $JAVE_HOME/bin to your path or use $JAVE_HOME/bin/jjs . It compiles on the fly. Cheers, -- Jim On Sep 30, 2014, at 8:08 AM, Mitia Alexandrov wrote: > Hello, > I'm new here, so sorry for the stupid questions I may post. > I'm very exited about the Nashorn project and i want to dive deeper in the > details. As the first thing i want to know is about jjs tool. Actually, I > couldn't find it in the sources. > I really want to understand how it works ? does it compile on the fly or it > just interprets? > > Thank you for any info and guidance. > > Best regards, > > Mitia From mitiaalexandrov at gmail.com Wed Oct 8 15:08:48 2014 From: mitiaalexandrov at gmail.com (Mitia Alexandrov) Date: Wed, 08 Oct 2014 18:08:48 +0300 Subject: JJS tool In-Reply-To: <521AA188-65F3-4E32-A0FD-DD7B7897895D@oracle.com> References: <521AA188-65F3-4E32-A0FD-DD7B7897895D@oracle.com> Message-ID: Hello Jim, Thank you for your attention and support! I?ve still downloaded the sources and seen this myself! Now I?m diving even deeper into the code. Thank you anyway! Regards, Mitia On 08.10.14, 18:02, "Jim Laskey (Oracle)" wrote: >You can find details in >http://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn > >You can add a soft link to the command to simplify access (see >http://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/sh >ell.html ), but otherwise you add $JAVE_HOME/bin to your path or use >$JAVE_HOME/bin/jjs . > >It compiles on the fly. > >Cheers, > >-- Jim > > > > > >On Sep 30, 2014, at 8:08 AM, Mitia Alexandrov >wrote: > >> Hello, >> I'm new here, so sorry for the stupid questions I may post. >> I'm very exited about the Nashorn project and i want to dive deeper in >>the >> details. As the first thing i want to know is about jjs tool. Actually, >>I >> couldn't find it in the sources. >> I really want to understand how it works ? does it compile on the fly >>or it >> just interprets? >> >> Thank you for any info and guidance. >> >> Best regards, >> >> Mitia > From hannes.wallnoefer at oracle.com Wed Oct 8 15:18:30 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 08 Oct 2014 17:18:30 +0200 Subject: Nashorn bug in Java 8 u20? For trivial TypeScript code In-Reply-To: References: Message-ID: <543555C6.2030904@oracle.com> Hi Kaj Magnus, I can reproduce the problem with 8u20, however it seems to be fixed in JDK 9 and JDK8u40. You can download a preview release of 8u40 here: https://jdk8.java.net/download.html Please let us know if still run into problems using 8u40. Hannes Am 2014-10-08 um 07:16 schrieb Kaj Magnus Lindberg: > Hi dear Nashorn developers, > > The example below throws an ArrayIndexOutOfBoundsException. I'm thinking > there's a Nashorn bug that you might want to fix? > > I'm getting the impression that currently it's not possible to run > TypeScript compiled code in Nashorn, because of this bug. The snippet below > is a compiled trivial TypeScript module. > > File test.js: > > var test;(function (test) { > (function (renderer) { > var posts = { > 0: null, > 1: null, > 2: null, > 3: null // comment out this line --> no exception thrown > }; > })(test.renderer = {}); // comment out 'test.renderer = ' --> no > exception thrown})(test = {}); > > Then run the script like so: > /usr/lib/jvm/java-8-oracle/bin/jjs test.js > > > Operating system: Linux Mint 17, 64 bit. Java version: > > $ java -version > java version "1.8.0_20"Java(TM) SE Runtime Environment (build > 1.8.0_20-b26)Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed > mode) > > > (There's also a StackOverflow question about this: > http://stackoverflow.com/questions/26189940/java-8-nashorn-arrayindexoutofboundsexception > ) > > Best regards, KajMagnus From james.laskey at oracle.com Wed Oct 8 15:20:41 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 8 Oct 2014 12:20:41 -0300 Subject: JJS tool In-Reply-To: <521AA188-65F3-4E32-A0FD-DD7B7897895D@oracle.com> References: <521AA188-65F3-4E32-A0FD-DD7B7897895D@oracle.com> Message-ID: <1FB06BD0-E3CD-4799-BA71-D639B7B4C69E@oracle.com> That should be $JAVA_HOME, still jet-lagged from JavaOne. On Oct 8, 2014, at 12:02 PM, Jim Laskey (Oracle) wrote: > You can find details in http://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn > > You can add a soft link to the command to simplify access (see http://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/shell.html ), but otherwise you add $JAVE_HOME/bin to your path or use $JAVE_HOME/bin/jjs . > > It compiles on the fly. > > Cheers, > > -- Jim > > > > > > On Sep 30, 2014, at 8:08 AM, Mitia Alexandrov wrote: > >> Hello, >> I'm new here, so sorry for the stupid questions I may post. >> I'm very exited about the Nashorn project and i want to dive deeper in the >> details. As the first thing i want to know is about jjs tool. Actually, I >> couldn't find it in the sources. >> I really want to understand how it works ? does it compile on the fly or it >> just interprets? >> >> Thank you for any info and guidance. >> >> Best regards, >> >> Mitia > From sundararajan.athijegannathan at oracle.com Wed Oct 8 15:23:08 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 08 Oct 2014 20:53:08 +0530 Subject: Review request for JDK-8059938: NPE restoring cached script with optimistic types disabled In-Reply-To: <54354D41.4050406@oracle.com> References: <54354D41.4050406@oracle.com> Message-ID: <543556DC.103@oracle.com> +1 On Wednesday 08 October 2014 08:12 PM, Hannes Wallnoefer wrote: > Please review JDK-8059938: NPE restoring cached script with optimistic > types disabled: > > http://cr.openjdk.java.net/~hannesw/8059938/ > > Thanks, > Hannes From marcus.lagergren at oracle.com Wed Oct 8 16:16:07 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 8 Oct 2014 18:16:07 +0200 Subject: Please review JDK-8059811 Message-ID: This is 1) Optimistic types moving to a documented option in jjs -help 2) Optimistic types being default off for 8u40 (it is still left on in this that goes into 9 - will flip the flag at backport) 3) Support for testing in both optimistic and non optimistic mode for all the unit tests with ?ant test?. This will be live in both 8u40 and 9 (but with different defaults - same tests though) to avoid bit rot of the non-optimistic functionality as long as it exists. Please give me reviews. Ant test passes with both configurations after Hannes fixing JDK-8059938 The webrev is here: http://cr.openjdk.java.net/~lagergren/8059811.3/ /M From attila.szegedi at oracle.com Wed Oct 8 16:33:22 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 8 Oct 2014 18:33:22 +0200 Subject: Is there any way to implement equals and hashCode using Nashorn javascript? In-Reply-To: References: Message-ID: <81A51F69-ED6C-4A18-9996-32345A6FC745@oracle.com> Hi Arseniy, short answer: it isn't possible. The issue here is that your equals() methods aren't receiving the JavaScript objects that provide the state; rather, they're receiving "jdk.nashorn.javaadapters.java.lang.Object" adapter instances, which are encapsulating the JavaScript object and exposing its public interface (which, in this case, is java.lang.Object) You would need to access the JS object behind the "other" adapter, but there is currently no facility for that. Attila. On Aug 20, 2014, at 5:17 PM, Arseniy Kovalchuk wrote: > var HashMap = java.util.HashMap;var JInteger = java.lang.Integer;var > JObject = Java.extend(java.lang.Object); > var createVertex = (function() { > var > _equals = function(other) { > print(this + ' vs ' + other); > return this._from === other.from; > }; > _hashCode = function() { > var hashCode = JInteger.hashCode(this._from); > print(hashCode); > return hashCode; > }; > return function(from, cost) { > return new JObject() { > _from : from, > _cost : cost, > equals : _equals, > hashCode : _hashCode, > } > }})(); > var JSVertex = function(from, cost) { > return new JObject() { > _from : from, > _cost : cost, > equals : function(other) { > print(this + ' vs ' + other); > return this._from === other._from; > }, > hashCode : function() { > var hashCode = JInteger.hashCode(this._from); > print(hashCode); > return hashCode; > } > }} > var v1 = JSVertex(1, 10);var v2 = JSVertex(1, 20);//var v1 = > createVertex(1, 10);//var v2 = createVertex(1, 20);var v3 = > createVertex(1, 20); > print(v1.class === v2.class); // returns true > print(v2.class === v3.class); // returns truevar hm = new HashMap(); > hm.put(v1, 10); > hm.put(v2, 21); > print("HashMap size: " + hm.size()); // Prints 2, but I'd like to see 1 > print("HashMap contains: " + hm.containsKey(v3)); // Prints false From attila.szegedi at oracle.com Wed Oct 8 16:33:47 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 8 Oct 2014 18:33:47 +0200 Subject: Review request for JDK-8059938: NPE restoring cached script with optimistic types disabled In-Reply-To: <54354D41.4050406@oracle.com> References: <54354D41.4050406@oracle.com> Message-ID: +1 On Oct 8, 2014, at 4:42 PM, Hannes Wallnoefer wrote: > Please review JDK-8059938: NPE restoring cached script with optimistic types disabled: > > http://cr.openjdk.java.net/~hannesw/8059938/ > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Thu Oct 9 08:18:04 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 09 Oct 2014 10:18:04 +0200 Subject: Please review JDK-8059811 In-Reply-To: References: Message-ID: <543644BC.3060601@oracle.com> There are various indentation errors in the test classes. And since this is for JDK9, help text for --optimstic-types should not say "Optimistic typing is currently disabled by default". Apart from that +1. Hannes Am 2014-10-08 um 18:16 schrieb Marcus Lagergren: > This is > > 1) Optimistic types moving to a documented option in jjs -help > 2) Optimistic types being default off for 8u40 (it is still left on in this that goes into 9 - will flip the flag at backport) > 3) Support for testing in both optimistic and non optimistic mode for all the unit tests with ?ant test?. This will be live in both 8u40 and 9 (but with different defaults - same tests though) to avoid bit rot of the non-optimistic functionality as long as it exists. > > Please give me reviews. Ant test passes with both configurations after Hannes fixing JDK-8059938 > > The webrev is here: http://cr.openjdk.java.net/~lagergren/8059811.3/ > > /M > From attila.szegedi at oracle.com Thu Oct 9 09:30:37 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 9 Oct 2014 11:30:37 +0200 Subject: Please review JDK-8059811 In-Reply-To: References: Message-ID: <0D02353B-F27F-4814-B5AA-3A7B89128531@oracle.com> +1 On Oct 8, 2014, at 6:16 PM, Marcus Lagergren wrote: > This is > > 1) Optimistic types moving to a documented option in jjs -help > 2) Optimistic types being default off for 8u40 (it is still left on in this that goes into 9 - will flip the flag at backport) > 3) Support for testing in both optimistic and non optimistic mode for all the unit tests with ?ant test?. This will be live in both 8u40 and 9 (but with different defaults - same tests though) to avoid bit rot of the non-optimistic functionality as long as it exists. > > Please give me reviews. Ant test passes with both configurations after Hannes fixing JDK-8059938 > > The webrev is here: http://cr.openjdk.java.net/~lagergren/8059811.3/ > > /M > From marcus.lagergren at oracle.com Thu Oct 9 09:42:22 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 9 Oct 2014 11:42:22 +0200 Subject: Backport request for approval for Message-ID: Please review JDK-8059811, "turn off optimistic types for 8u40 by default." This is the CR: https://bugs.openjdk.java.net/browse/JDK-8059811 This is the webrev: http://cr.openjdk.java.net/~lagergren/8059811.3/ This is the thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003617.html When it goes back to 8u40, I will change the default from ?true? to ?false? in Options.properties and from ?true? to ?false? in TestFinder.java. Both configurations have been tested. Regards Marcus From sean.coffey at oracle.com Thu Oct 9 10:01:33 2014 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Thu, 09 Oct 2014 11:01:33 +0100 Subject: Backport request for approval for In-Reply-To: References: Message-ID: <54365CFD.3090706@oracle.com> Approved. If the change differs from JDK 9 around default settings, please get a peer review before pushing. regards, Sean. On 09/10/2014 10:42, Marcus Lagergren wrote: > Please review JDK-8059811, "turn off optimistic types for 8u40 by default." > > This is the CR: https://bugs.openjdk.java.net/browse/JDK-8059811 > This is the webrev: http://cr.openjdk.java.net/~lagergren/8059811.3/ > This is the thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003617.html > > When it goes back to 8u40, I will change the default from ?true? to ?false? in Options.properties and from ?true? to ?false? in TestFinder.java. Both configurations have been tested. > > Regards > Marcus > From hannes.wallnoefer at oracle.com Thu Oct 9 16:25:43 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 09 Oct 2014 18:25:43 +0200 Subject: Please review JDK-8012518 In-Reply-To: <54350028.30002@oracle.com> References: <5416FF44.4070804@oracle.com> <30117576-1E53-4D27-800D-ADF2A965DB3C@oracle.com> <541843D9.8050708@oracle.com> <54350028.30002@oracle.com> Message-ID: <5436B707.20306@oracle.com> Hi Andreas, This looks good. Some minor javadoc nitpicks: - First and last @param for ParserContextFunctionNode constructor do not exist - Your @param tags often miss a description - I think the proper way to link to an enum value is #VALUE, e.g. {@link CompilationState#PARSED} in FunctionNode Apart from these minor issues the patch looks good. Out of curiosity, what scripts did you use for performance testing? Mandreel might be interesting. Hannes Am 2014-10-08 um 11:13 schrieb Andreas Gabrielsson: > Now all of Attila's comments should be fixed. I have also removed some > public setters that were not needed anymore. > > Me and Marcus run a few performance tests and they passed, there were > basically no difference. > > New webrev is at: http://cr.openjdk.java.net/~lagergren/8012518.5/ > > Andreas > > On 2014-09-16 16:06, Andreas Gabrielsson wrote: >> I have fixed the thing you list below, thank you. >> New webrev uploaded at: http://cr.openjdk.java.net/~lagergren/8012518.3/ >> On 2014-09-16 10:50, Attila Szegedi wrote: >>> .hgignore: >>> -what's OpenJDK policy for these? I see we have .idea/* in there; >>> how about we put .externalToolBuilders/* and .settings/* there instead? >>> >>> Block.java: >>> - I don't like variables named "tmp" anything. "terminalFlags"? >>> - New public constructors are entirely undocumented. Not that the >>> old one had quality documentation, but still? >>> - private constructor no longer sets finish. Why is it still in the >>> parameter list? >>> >>> ForNode.java: >>> - undocumented public constructor >>> >>> LoopNode.java: >>> - undocumented protected constructor parameters >>> >>> WhileNode.java >>> - undocumented public constructor parameters >>> >>> In all the new classes for parser context implementation: >>> - add empty line between package declaration and imports >>> - the import ordering doesn't follow our source code policy of >>> "strict alphabetical, no grouping separator lines" >>> - do these classes need to be public? >>> >>> Parser.java: >>> - many local variables and method parameters could be declared final. >>> - I generally dislike assigning an expression only used once to a >>> local variable, e.g. >>> List statements = newBlock.getStatements(); >>> return new Block(blockToken, finish, newBlock.getFlags(), >>> statements); >>> or >>> FunctionNode scriptFunction = createFunctionNode(script, >>> functionToken, ident, new ArrayList(), >>> FunctionNode.Kind.SCRIPT, functionLine, programBody); >>> return scriptFunction; >>> and there are more. >>> >>> BaseParserContextNode.java: >>> - several cases of missing space before opening curly brace >>> - missing "final"s on function parameters >>> - missing documentation >>> >>> ParserContext.java >>> - getLastStatement(): consider extracting common subexpression >>> stack[sp - 1].getStatements() into a local variable >>> - if you made push() generic as public >> ParserContextNode> T push(final T node) then you wouldn't need >>> casting its return values in Parser. >>> >>> ParserContextFunctionNode.java >>> - consider extracting the (flags & FunctionNode.SOME_FLAG) != 0 >>> pattern into a boolean getFlag(final int flag) function >>> >>> Most of these remarks are related to stylistic issues: we try to >>> ensure everything has a JavaDoc, we're strict about using the >>> "final" keyword everywhere possible (you can have an Eclipse save >>> action that adds them), we have a set policy for organizing imports >>> so that different people's IDE settings don't cause unnecessary >>> noise in diffs, etc. You'll get the hang of it as you go. Nice work >>> overall! >>> >>> Attila. >>> >>> On Sep 15, 2014, at 5:01 PM, Andreas Gabrielsson >>> wrote: >>> >>>> Webrev: http://cr.openjdk.java.net/~lagergren/8012518.2/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8012518 >> > From marcus.lagergren at oracle.com Thu Oct 9 17:41:57 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 9 Oct 2014 19:41:57 +0200 Subject: Please review JDK-8012518 In-Reply-To: <5436B707.20306@oracle.com> References: <5416FF44.4070804@oracle.com> <30117576-1E53-4D27-800D-ADF2A965DB3C@oracle.com> <541843D9.8050708@oracle.com> <54350028.30002@oracle.com> <5436B707.20306@oracle.com> Message-ID: <31A8C2C1-6038-456E-895D-2EC967BACFB7@oracle.com> We ran compile-octane.js with a large number of iterations and code caching disabled. We didn?t single out any scripts, so mandrel might be interesting to look at like a single benchmark payload, yes. /M On 09 Oct 2014, at 18:25, Hannes Wallnoefer wrote: > Hi Andreas, > > This looks good. Some minor javadoc nitpicks: > > - First and last @param for ParserContextFunctionNode constructor do not exist > - Your @param tags often miss a description > - I think the proper way to link to an enum value is #VALUE, e.g. {@link CompilationState#PARSED} in FunctionNode > > Apart from these minor issues the patch looks good. > > Out of curiosity, what scripts did you use for performance testing? Mandreel might be interesting. > > Hannes > > Am 2014-10-08 um 11:13 schrieb Andreas Gabrielsson: >> Now all of Attila's comments should be fixed. I have also removed some public setters that were not needed anymore. >> >> Me and Marcus run a few performance tests and they passed, there were basically no difference. >> >> New webrev is at: http://cr.openjdk.java.net/~lagergren/8012518.5/ >> >> Andreas >> >> On 2014-09-16 16:06, Andreas Gabrielsson wrote: >>> I have fixed the thing you list below, thank you. >>> New webrev uploaded at: http://cr.openjdk.java.net/~lagergren/8012518.3/ >>> On 2014-09-16 10:50, Attila Szegedi wrote: >>>> .hgignore: >>>> -what's OpenJDK policy for these? I see we have .idea/* in there; how about we put .externalToolBuilders/* and .settings/* there instead? >>>> >>>> Block.java: >>>> - I don't like variables named "tmp" anything. "terminalFlags"? >>>> - New public constructors are entirely undocumented. Not that the old one had quality documentation, but still? >>>> - private constructor no longer sets finish. Why is it still in the parameter list? >>>> >>>> ForNode.java: >>>> - undocumented public constructor >>>> >>>> LoopNode.java: >>>> - undocumented protected constructor parameters >>>> >>>> WhileNode.java >>>> - undocumented public constructor parameters >>>> >>>> In all the new classes for parser context implementation: >>>> - add empty line between package declaration and imports >>>> - the import ordering doesn't follow our source code policy of "strict alphabetical, no grouping separator lines" >>>> - do these classes need to be public? >>>> >>>> Parser.java: >>>> - many local variables and method parameters could be declared final. >>>> - I generally dislike assigning an expression only used once to a local variable, e.g. >>>> List statements = newBlock.getStatements(); >>>> return new Block(blockToken, finish, newBlock.getFlags(), statements); >>>> or >>>> FunctionNode scriptFunction = createFunctionNode(script, functionToken, ident, new ArrayList(), FunctionNode.Kind.SCRIPT, functionLine, programBody); >>>> return scriptFunction; >>>> and there are more. >>>> >>>> BaseParserContextNode.java: >>>> - several cases of missing space before opening curly brace >>>> - missing "final"s on function parameters >>>> - missing documentation >>>> >>>> ParserContext.java >>>> - getLastStatement(): consider extracting common subexpression stack[sp - 1].getStatements() into a local variable >>>> - if you made push() generic as public T push(final T node) then you wouldn't need casting its return values in Parser. >>>> >>>> ParserContextFunctionNode.java >>>> - consider extracting the (flags & FunctionNode.SOME_FLAG) != 0 pattern into a boolean getFlag(final int flag) function >>>> >>>> Most of these remarks are related to stylistic issues: we try to ensure everything has a JavaDoc, we're strict about using the "final" keyword everywhere possible (you can have an Eclipse save action that adds them), we have a set policy for organizing imports so that different people's IDE settings don't cause unnecessary noise in diffs, etc. You'll get the hang of it as you go. Nice work overall! >>>> >>>> Attila. >>>> >>>> On Sep 15, 2014, at 5:01 PM, Andreas Gabrielsson wrote: >>>> >>>>> Webrev: http://cr.openjdk.java.net/~lagergren/8012518.2/ >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8012518 >>> >> > From sundararajan.athijegannathan at oracle.com Fri Oct 10 06:16:52 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 10 Oct 2014 11:46:52 +0530 Subject: RFR 8060101: AssertionError: __noSuchProperty__ placeholder called from NativeJavaImporter Message-ID: <543779D4.4050903@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8060101/ Thanks, -Sundar From attila.szegedi at oracle.com Fri Oct 10 07:33:14 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 10 Oct 2014 09:33:14 +0200 Subject: RFR 8060101: AssertionError: __noSuchProperty__ placeholder called from NativeJavaImporter In-Reply-To: <543779D4.4050903@oracle.com> References: <543779D4.4050903@oracle.com> Message-ID: <5A55812A-C53E-440C-9979-DCFF28958FF5@oracle.com> +1 On Oct 10, 2014, at 8:16 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8060101/ > > Thanks, > -Sundar From attila.szegedi at oracle.com Fri Oct 10 07:39:19 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 10 Oct 2014 09:39:19 +0200 Subject: Please review JDK-8012518 In-Reply-To: <54350028.30002@oracle.com> References: <5416FF44.4070804@oracle.com> <30117576-1E53-4D27-800D-ADF2A965DB3C@oracle.com> <541843D9.8050708@oracle.com> <54350028.30002@oracle.com> Message-ID: <5E5E1053-24A7-4FA4-A66F-7757BD8E7637@oracle.com> All looks good to me (with Hannes' remarks). +1. On Oct 8, 2014, at 11:13 AM, Andreas Gabrielsson wrote: > Now all of Attila's comments should be fixed. I have also removed some public setters that were not needed anymore. > > Me and Marcus run a few performance tests and they passed, there were basically no difference. > > New webrev is at: http://cr.openjdk.java.net/~lagergren/8012518.5/ > > Andreas > > On 2014-09-16 16:06, Andreas Gabrielsson wrote: >> I have fixed the thing you list below, thank you. >> New webrev uploaded at: http://cr.openjdk.java.net/~lagergren/8012518.3/ >> On 2014-09-16 10:50, Attila Szegedi wrote: >>> .hgignore: >>> -what's OpenJDK policy for these? I see we have .idea/* in there; how about we put .externalToolBuilders/* and .settings/* there instead? >>> >>> Block.java: >>> - I don't like variables named "tmp" anything. "terminalFlags"? >>> - New public constructors are entirely undocumented. Not that the old one had quality documentation, but still? >>> - private constructor no longer sets finish. Why is it still in the parameter list? >>> >>> ForNode.java: >>> - undocumented public constructor >>> >>> LoopNode.java: >>> - undocumented protected constructor parameters >>> >>> WhileNode.java >>> - undocumented public constructor parameters >>> >>> In all the new classes for parser context implementation: >>> - add empty line between package declaration and imports >>> - the import ordering doesn't follow our source code policy of "strict alphabetical, no grouping separator lines" >>> - do these classes need to be public? >>> >>> Parser.java: >>> - many local variables and method parameters could be declared final. >>> - I generally dislike assigning an expression only used once to a local variable, e.g. >>> List statements = newBlock.getStatements(); >>> return new Block(blockToken, finish, newBlock.getFlags(), statements); >>> or >>> FunctionNode scriptFunction = createFunctionNode(script, functionToken, ident, new ArrayList(), FunctionNode.Kind.SCRIPT, functionLine, programBody); >>> return scriptFunction; >>> and there are more. >>> >>> BaseParserContextNode.java: >>> - several cases of missing space before opening curly brace >>> - missing "final"s on function parameters >>> - missing documentation >>> >>> ParserContext.java >>> - getLastStatement(): consider extracting common subexpression stack[sp - 1].getStatements() into a local variable >>> - if you made push() generic as public T push(final T node) then you wouldn't need casting its return values in Parser. >>> >>> ParserContextFunctionNode.java >>> - consider extracting the (flags & FunctionNode.SOME_FLAG) != 0 pattern into a boolean getFlag(final int flag) function >>> >>> Most of these remarks are related to stylistic issues: we try to ensure everything has a JavaDoc, we're strict about using the "final" keyword everywhere possible (you can have an Eclipse save action that adds them), we have a set policy for organizing imports so that different people's IDE settings don't cause unnecessary noise in diffs, etc. You'll get the hang of it as you go. Nice work overall! >>> >>> Attila. >>> >>> On Sep 15, 2014, at 5:01 PM, Andreas Gabrielsson wrote: >>> >>>> Webrev: http://cr.openjdk.java.net/~lagergren/8012518.2/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8012518 >> > From sundararajan.athijegannathan at oracle.com Fri Oct 10 10:47:05 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 10 Oct 2014 16:17:05 +0530 Subject: RFR 8060101: AssertionError: __noSuchProperty__ placeholder called from NativeJavaImporter In-Reply-To: <5A55812A-C53E-440C-9979-DCFF28958FF5@oracle.com> References: <543779D4.4050903@oracle.com> <5A55812A-C53E-440C-9979-DCFF28958FF5@oracle.com> Message-ID: <5437B929.40400@oracle.com> Sorry I forgot __noSuchMethod__ case. Updated fix and test for that as well... Please review updated webrev http://cr.openjdk.java.net/~sundar/8060101/webrev.01/ Thanks -Sundar On Friday 10 October 2014 01:03 PM, Attila Szegedi wrote: > +1 > > On Oct 10, 2014, at 8:16 AM, A. Sundararajan wrote: > >> Please review http://cr.openjdk.java.net/~sundar/8060101/ >> >> Thanks, >> -Sundar From attila.szegedi at oracle.com Fri Oct 10 10:59:41 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 10 Oct 2014 12:59:41 +0200 Subject: RFR 8060101: AssertionError: __noSuchProperty__ placeholder called from NativeJavaImporter In-Reply-To: <5437B929.40400@oracle.com> References: <543779D4.4050903@oracle.com> <5A55812A-C53E-440C-9979-DCFF28958FF5@oracle.com> <5437B929.40400@oracle.com> Message-ID: <6753020B-F9BA-4DCA-93F6-8AD6FB06B64F@oracle.com> +1 on updated. On Oct 10, 2014, at 12:47 PM, A. Sundararajan wrote: > Sorry I forgot __noSuchMethod__ case. Updated fix and test for that as well... > > Please review updated webrev http://cr.openjdk.java.net/~sundar/8060101/webrev.01/ > > Thanks > -Sundar > > > On Friday 10 October 2014 01:03 PM, Attila Szegedi wrote: >> +1 >> >> On Oct 10, 2014, at 8:16 AM, A. Sundararajan wrote: >> >>> Please review http://cr.openjdk.java.net/~sundar/8060101/ >>> >>> Thanks, >>> -Sundar > From james.laskey at oracle.com Fri Oct 10 12:11:04 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 10 Oct 2014 09:11:04 -0300 Subject: RFR 8060101: AssertionError: __noSuchProperty__ placeholder called from NativeJavaImporter In-Reply-To: <5437B929.40400@oracle.com> References: <543779D4.4050903@oracle.com> <5A55812A-C53E-440C-9979-DCFF28958FF5@oracle.com> <5437B929.40400@oracle.com> Message-ID: +1 On Oct 10, 2014, at 7:47 AM, A. Sundararajan wrote: > Sorry I forgot __noSuchMethod__ case. Updated fix and test for that as well... > > Please review updated webrev http://cr.openjdk.java.net/~sundar/8060101/webrev.01/ > > Thanks > -Sundar > > > On Friday 10 October 2014 01:03 PM, Attila Szegedi wrote: >> +1 >> >> On Oct 10, 2014, at 8:16 AM, A. Sundararajan wrote: >> >>> Please review http://cr.openjdk.java.net/~sundar/8060101/ >>> >>> Thanks, >>> -Sundar > From kishori.sharan at gmail.com Fri Oct 10 17:38:23 2014 From: kishori.sharan at gmail.com (Kishori Sharan) Date: Fri, 10 Oct 2014 12:38:23 -0500 Subject: Behavior of Object.bindProperties() Method of Nashorn Message-ID: Hello Everyone, I was experimenting with the Object.bindProperties() method in Nashorn and found a few weird behaviors. I would like to ask two questions: 1. Is there a comprehensive documentation for this method, except at https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-loadWithNewGlobal 2. Is it a bug as explained in the following snippet of code? The following code does not bind the x, y, and z properties of obj2 to obj because obj already has properties with the same names. Is it documented somewhere? var obj = {x:10, y:20, z:30}; var obj2 = {x:100, y:200, z:300}; // bind properties of 'obj2' to 'obj' Object.bindProperties(obj, obj2); print(obj.x, obj.y, obj.z); print(obj2.x, obj2.y, obj2.z); --------------------------------- 10 20 30 100 200 300 -------------------------------- Now, let us add a new property to obj2. The new property is bound to obj, but obj reads the new property's value as null: var obj = {x:10, y:20, z:30}; var obj2 = {x:100, y:200, z:300}; // Add a new property to obj2 obj2.u = 600; // bind properties of 'obj2' to 'obj' Object.bindProperties(obj, obj2); print(obj.x, obj.y, obj.z, obj.u); // obj.u is null. Why? print(obj2.x, obj2.y, obj2.z, obj2.u); --------------------------------- 10 20 30 null 100 200 300 600 -------------------------------- And, here is another variant of the code that works. This time, I started the target object as empty. Now, adding the new property to the source works fine. var obj = {}; var obj2 = {x:100, y:200, z:300}; // Add a new property to obj2 obj2.u = 600; // bind properties of 'obj2' to 'obj' Object.bindProperties(obj, obj2); print(obj.x, obj.y, obj.z, obj.u); // obj.u is correct.It is 600 print(obj2.x, obj2.y, obj2.z, obj2.u); ---------------------------- 100 200 300 600 100 200 300 600 ---------------------------- I am using JDK version 1.8.0_20. Thanks Kishori From smourachov at gmail.com Sun Oct 12 19:07:18 2014 From: smourachov at gmail.com (Serguei Mourachov) Date: Sun, 12 Oct 2014 12:07:18 -0700 Subject: Multiple globals using the same thread Message-ID: <543AD166.4040701@gmail.com> We have a project where several thousands of script "instances" should be called/executed using limited number of threads. Is it possible to use multiple global objects invoking script functions from the same thread? From attila.szegedi at oracle.com Mon Oct 13 07:48:10 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 13 Oct 2014 09:48:10 +0200 Subject: Multiple globals using the same thread In-Reply-To: <543AD166.4040701@gmail.com> References: <543AD166.4040701@gmail.com> Message-ID: Globals don't have a thread affinity, but they're also not threadsafe (since JavaScript as a language isn't). This means that you can have multiple threads share one Global, but not concurrently; you'll need to provide synchronization around thread access to your Global, to make sure only one thread is using it at any given time. Attila. On Oct 12, 2014, at 9:07 PM, Serguei Mourachov wrote: > We have a project where several thousands of script "instances" should be called/executed using limited number of threads. > Is it possible to use multiple global objects invoking script functions from the same thread? > From sundararajan.athijegannathan at oracle.com Mon Oct 13 07:58:56 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 13 Oct 2014 13:28:56 +0530 Subject: Multiple globals using the same thread In-Reply-To: References: <543AD166.4040701@gmail.com> Message-ID: <543B8640.9030507@oracle.com> If the question is about can I use mulitple globals in the same thread, yes that is also possible. Just create another javax.script.Bindings and set it as ENGINE_SCOPE in your ScriptEngine instance. Any future "eval" on that engine will use a fresh 'global' scope object. Within a script, you can use loadWithNewGlobal function to load a script into a fresh JS global scope object. See also https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions -Sundar On Monday 13 October 2014 01:18 PM, Attila Szegedi wrote: > Globals don't have a thread affinity, but they're also not threadsafe (since JavaScript as a language isn't). This means that you can have multiple threads share one Global, but not concurrently; you'll need to provide synchronization around thread access to your Global, to make sure only one thread is using it at any given time. > > Attila. > > On Oct 12, 2014, at 9:07 PM, Serguei Mourachov wrote: > >> We have a project where several thousands of script "instances" should be called/executed using limited number of threads. >> Is it possible to use multiple global objects invoking script functions from the same thread? >> From andreas.gabrielsson at oracle.com Mon Oct 13 08:20:10 2014 From: andreas.gabrielsson at oracle.com (Andreas Gabrielsson) Date: Mon, 13 Oct 2014 10:20:10 +0200 Subject: Please review JDK-8012518 In-Reply-To: <5436B707.20306@oracle.com> References: <5416FF44.4070804@oracle.com> <30117576-1E53-4D27-800D-ADF2A965DB3C@oracle.com> <541843D9.8050708@oracle.com> <54350028.30002@oracle.com> <5436B707.20306@oracle.com> Message-ID: <543B8B3A.9070804@oracle.com> Hi, New webrev at http://cr.openjdk.java.net/~lagergren/8012518.6/. I have fixed the issues you point out. Regarding the performance testing Marcus already replied with an accurate answer. Andreas On 2014-10-09 18:25, Hannes Wallnoefer wrote: > Hi Andreas, > > This looks good. Some minor javadoc nitpicks: > > - First and last @param for ParserContextFunctionNode constructor do > not exist > - Your @param tags often miss a description > - I think the proper way to link to an enum value is #VALUE, e.g. > {@link CompilationState#PARSED} in FunctionNode > > Apart from these minor issues the patch looks good. > > Out of curiosity, what scripts did you use for performance testing? > Mandreel might be interesting. > > Hannes > > Am 2014-10-08 um 11:13 schrieb Andreas Gabrielsson: >> Now all of Attila's comments should be fixed. I have also removed >> some public setters that were not needed anymore. >> >> Me and Marcus run a few performance tests and they passed, there were >> basically no difference. >> >> New webrev is at: http://cr.openjdk.java.net/~lagergren/8012518.5/ >> >> Andreas >> >> On 2014-09-16 16:06, Andreas Gabrielsson wrote: >>> I have fixed the thing you list below, thank you. >>> New webrev uploaded at: >>> http://cr.openjdk.java.net/~lagergren/8012518.3/ >>> On 2014-09-16 10:50, Attila Szegedi wrote: >>>> .hgignore: >>>> -what's OpenJDK policy for these? I see we have .idea/* in there; >>>> how about we put .externalToolBuilders/* and .settings/* there >>>> instead? >>>> >>>> Block.java: >>>> - I don't like variables named "tmp" anything. "terminalFlags"? >>>> - New public constructors are entirely undocumented. Not that the >>>> old one had quality documentation, but still? >>>> - private constructor no longer sets finish. Why is it still in the >>>> parameter list? >>>> >>>> ForNode.java: >>>> - undocumented public constructor >>>> >>>> LoopNode.java: >>>> - undocumented protected constructor parameters >>>> >>>> WhileNode.java >>>> - undocumented public constructor parameters >>>> >>>> In all the new classes for parser context implementation: >>>> - add empty line between package declaration and imports >>>> - the import ordering doesn't follow our source code policy of >>>> "strict alphabetical, no grouping separator lines" >>>> - do these classes need to be public? >>>> >>>> Parser.java: >>>> - many local variables and method parameters could be declared final. >>>> - I generally dislike assigning an expression only used once to a >>>> local variable, e.g. >>>> List statements = newBlock.getStatements(); >>>> return new Block(blockToken, finish, newBlock.getFlags(), >>>> statements); >>>> or >>>> FunctionNode scriptFunction = createFunctionNode(script, >>>> functionToken, ident, new ArrayList(), >>>> FunctionNode.Kind.SCRIPT, functionLine, programBody); >>>> return scriptFunction; >>>> and there are more. >>>> >>>> BaseParserContextNode.java: >>>> - several cases of missing space before opening curly brace >>>> - missing "final"s on function parameters >>>> - missing documentation >>>> >>>> ParserContext.java >>>> - getLastStatement(): consider extracting common subexpression >>>> stack[sp - 1].getStatements() into a local variable >>>> - if you made push() generic as public >>> ParserContextNode> T push(final T node) then you wouldn't need >>>> casting its return values in Parser. >>>> >>>> ParserContextFunctionNode.java >>>> - consider extracting the (flags & FunctionNode.SOME_FLAG) != 0 >>>> pattern into a boolean getFlag(final int flag) function >>>> >>>> Most of these remarks are related to stylistic issues: we try to >>>> ensure everything has a JavaDoc, we're strict about using the >>>> "final" keyword everywhere possible (you can have an Eclipse save >>>> action that adds them), we have a set policy for organizing imports >>>> so that different people's IDE settings don't cause unnecessary >>>> noise in diffs, etc. You'll get the hang of it as you go. Nice work >>>> overall! >>>> >>>> Attila. >>>> >>>> On Sep 15, 2014, at 5:01 PM, Andreas Gabrielsson >>>> wrote: >>>> >>>>> Webrev: http://cr.openjdk.java.net/~lagergren/8012518.2/ >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8012518 >>> >> > From hannes.wallnoefer at oracle.com Mon Oct 13 10:44:57 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 13 Oct 2014 12:44:57 +0200 Subject: Please review JDK-8012518 In-Reply-To: <543B8B3A.9070804@oracle.com> References: <5416FF44.4070804@oracle.com> <30117576-1E53-4D27-800D-ADF2A965DB3C@oracle.com> <541843D9.8050708@oracle.com> <54350028.30002@oracle.com> <5436B707.20306@oracle.com> <543B8B3A.9070804@oracle.com> Message-ID: <543BAD29.1090904@oracle.com> Looks good! Hannes Am 2014-10-13 um 10:20 schrieb Andreas Gabrielsson: > Hi, > > New webrev at http://cr.openjdk.java.net/~lagergren/8012518.6/. I have > fixed the issues you point out. > > Regarding the performance testing Marcus already replied with an > accurate answer. > > Andreas > > On 2014-10-09 18:25, Hannes Wallnoefer wrote: >> Hi Andreas, >> >> This looks good. Some minor javadoc nitpicks: >> >> - First and last @param for ParserContextFunctionNode constructor do >> not exist >> - Your @param tags often miss a description >> - I think the proper way to link to an enum value is #VALUE, e.g. >> {@link CompilationState#PARSED} in FunctionNode >> >> Apart from these minor issues the patch looks good. >> >> Out of curiosity, what scripts did you use for performance testing? >> Mandreel might be interesting. >> >> Hannes >> >> Am 2014-10-08 um 11:13 schrieb Andreas Gabrielsson: >>> Now all of Attila's comments should be fixed. I have also removed >>> some public setters that were not needed anymore. >>> >>> Me and Marcus run a few performance tests and they passed, there >>> were basically no difference. >>> >>> New webrev is at: http://cr.openjdk.java.net/~lagergren/8012518.5/ >>> >>> Andreas >>> >>> On 2014-09-16 16:06, Andreas Gabrielsson wrote: >>>> I have fixed the thing you list below, thank you. >>>> New webrev uploaded at: >>>> http://cr.openjdk.java.net/~lagergren/8012518.3/ >>>> On 2014-09-16 10:50, Attila Szegedi wrote: >>>>> .hgignore: >>>>> -what's OpenJDK policy for these? I see we have .idea/* in there; >>>>> how about we put .externalToolBuilders/* and .settings/* there >>>>> instead? >>>>> >>>>> Block.java: >>>>> - I don't like variables named "tmp" anything. "terminalFlags"? >>>>> - New public constructors are entirely undocumented. Not that the >>>>> old one had quality documentation, but still? >>>>> - private constructor no longer sets finish. Why is it still in >>>>> the parameter list? >>>>> >>>>> ForNode.java: >>>>> - undocumented public constructor >>>>> >>>>> LoopNode.java: >>>>> - undocumented protected constructor parameters >>>>> >>>>> WhileNode.java >>>>> - undocumented public constructor parameters >>>>> >>>>> In all the new classes for parser context implementation: >>>>> - add empty line between package declaration and imports >>>>> - the import ordering doesn't follow our source code policy of >>>>> "strict alphabetical, no grouping separator lines" >>>>> - do these classes need to be public? >>>>> >>>>> Parser.java: >>>>> - many local variables and method parameters could be declared final. >>>>> - I generally dislike assigning an expression only used once to a >>>>> local variable, e.g. >>>>> List statements = newBlock.getStatements(); >>>>> return new Block(blockToken, finish, newBlock.getFlags(), >>>>> statements); >>>>> or >>>>> FunctionNode scriptFunction = createFunctionNode(script, >>>>> functionToken, ident, new ArrayList(), >>>>> FunctionNode.Kind.SCRIPT, functionLine, programBody); >>>>> return scriptFunction; >>>>> and there are more. >>>>> >>>>> BaseParserContextNode.java: >>>>> - several cases of missing space before opening curly brace >>>>> - missing "final"s on function parameters >>>>> - missing documentation >>>>> >>>>> ParserContext.java >>>>> - getLastStatement(): consider extracting common subexpression >>>>> stack[sp - 1].getStatements() into a local variable >>>>> - if you made push() generic as public >>>> ParserContextNode> T push(final T node) then you wouldn't need >>>>> casting its return values in Parser. >>>>> >>>>> ParserContextFunctionNode.java >>>>> - consider extracting the (flags & FunctionNode.SOME_FLAG) != 0 >>>>> pattern into a boolean getFlag(final int flag) function >>>>> >>>>> Most of these remarks are related to stylistic issues: we try to >>>>> ensure everything has a JavaDoc, we're strict about using the >>>>> "final" keyword everywhere possible (you can have an Eclipse save >>>>> action that adds them), we have a set policy for organizing >>>>> imports so that different people's IDE settings don't cause >>>>> unnecessary noise in diffs, etc. You'll get the hang of it as you >>>>> go. Nice work overall! >>>>> >>>>> Attila. >>>>> >>>>> On Sep 15, 2014, at 5:01 PM, Andreas Gabrielsson >>>>> wrote: >>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~lagergren/8012518.2/ >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8012518 >>>> >>> >> > From hannes.wallnoefer at oracle.com Mon Oct 13 13:22:37 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 13 Oct 2014 15:22:37 +0200 Subject: Review request for JDK-8060011: Concatenating an array and converting it to Java gives wrong result Message-ID: <543BD21D.90700@oracle.com> Please review JDK-8060011: Concatenating an array and converting it to Java gives wrong result: http://cr.openjdk.java.net/~hannesw/8060011/ Note that in addition to fixing the actual bug, the webrev lowers the maximum for various java array index operations from Integer.MAX_VALUE to (Integer.MAX_VALUE - 1). I'm pretty sure this is correct, but given that various VMs have lower maximum array sizes and would throw OOM with common heap sizes, it seems impossible to write a practical test for this. Hannes From marcus.lagergren at oracle.com Mon Oct 13 13:26:35 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 13 Oct 2014 15:26:35 +0200 Subject: Review request for JDK-8060011: Concatenating an array and converting it to Java gives wrong result In-Reply-To: <543BD21D.90700@oracle.com> References: <543BD21D.90700@oracle.com> Message-ID: <350AD22A-2B3E-45A2-AF2F-962D688FEE53@oracle.com> +1. This looks very nice, Hannes. /M On 13 Oct 2014, at 15:22, Hannes Wallnoefer wrote: > Please review JDK-8060011: Concatenating an array and converting it to Java gives wrong result: > > http://cr.openjdk.java.net/~hannesw/8060011/ > > Note that in addition to fixing the actual bug, the webrev lowers the maximum for various java array index operations from Integer.MAX_VALUE to (Integer.MAX_VALUE - 1). I'm pretty sure this is correct, but given that various VMs have lower maximum array sizes and would throw OOM with common heap sizes, it seems impossible to write a practical test for this. > > Hannes From attila.szegedi at oracle.com Mon Oct 13 13:41:09 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 13 Oct 2014 15:41:09 +0200 Subject: Review request for JDK-8060011: Concatenating an array and converting it to Java gives wrong result In-Reply-To: <543BD21D.90700@oracle.com> References: <543BD21D.90700@oracle.com> Message-ID: <59069211-D898-479B-9BE9-4A95F734E626@oracle.com> +1 On Oct 13, 2014, at 3:22 PM, Hannes Wallnoefer wrote: > Please review JDK-8060011: Concatenating an array and converting it to Java gives wrong result: > > http://cr.openjdk.java.net/~hannesw/8060011/ > > Note that in addition to fixing the actual bug, the webrev lowers the maximum for various java array index operations from Integer.MAX_VALUE to (Integer.MAX_VALUE - 1). I'm pretty sure this is correct, but given that various VMs have lower maximum array sizes and would throw OOM with common heap sizes, it seems impossible to write a practical test for this. > > Hannes From sundararajan.athijegannathan at oracle.com Mon Oct 13 13:59:33 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 13 Oct 2014 19:29:33 +0530 Subject: RFR 8050977: Java8 Javascript Nashorn exception: no current Global instance for nashorn Message-ID: <543BDAC5.70303@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8050977/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8050977 Thanks, -Sundar From attila.szegedi at oracle.com Mon Oct 13 15:04:08 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 13 Oct 2014 17:04:08 +0200 Subject: RFR 8050977: Java8 Javascript Nashorn exception: no current Global instance for nashorn In-Reply-To: <543BDAC5.70303@oracle.com> References: <543BDAC5.70303@oracle.com> Message-ID: <4BFF6C18-86B0-4D4A-9A0D-8097534B1A91@oracle.com> +1 On Oct 13, 2014, at 3:59 PM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8050977/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8050977 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Mon Oct 13 15:54:57 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 13 Oct 2014 17:54:57 +0200 Subject: RFR 8050977: Java8 Javascript Nashorn exception: no current Global instance for nashorn In-Reply-To: <543BDAC5.70303@oracle.com> References: <543BDAC5.70303@oracle.com> Message-ID: <543BF5D1.90506@oracle.com> +1 Am 2014-10-13 um 15:59 schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8050977/webrev.01/ > for https://bugs.openjdk.java.net/browse/JDK-8050977 > > Thanks, > -Sundar From attila.szegedi at oracle.com Mon Oct 13 18:05:00 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 13 Oct 2014 20:05:00 +0200 Subject: Review request for JDK-8060238 Message-ID: <83A0EBA4-D689-4421-B9B2-C7B223EFF1B0@oracle.com> Please review JDK-8060238 at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 13 18:12:54 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 13 Oct 2014 23:42:54 +0530 Subject: Review request for JDK-8060238 In-Reply-To: <83A0EBA4-D689-4421-B9B2-C7B223EFF1B0@oracle.com> References: <83A0EBA4-D689-4421-B9B2-C7B223EFF1B0@oracle.com> Message-ID: <543C1626.4070809@oracle.com> +1 On Monday 13 October 2014 11:35 PM, Attila Szegedi wrote: > Please review JDK-8060238 at for > > Thanks, > Attila. From attila.szegedi at oracle.com Mon Oct 13 18:34:20 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 13 Oct 2014 20:34:20 +0200 Subject: Review request for JDK-8060242 Message-ID: <48698C7B-4164-4DA2-A697-9EFD5794FBAB@oracle.com> Please review JDK-8060242 at for The fix is mostly in the TypeEvaluator.java, the rest is just plumbing (ArrayBufferView has to be public so I can us it with instanceof; array data subclasses for buffer views need to support optimistic operations; Int/Long/Number/ObjectArrayData now inherit they getOptimisticType() from ContinuousArrayData; finally there was a genuine data type bug where NativeUint32Array reported its array element type to be int instead of long). Thanks, Attila. From attila.szegedi at oracle.com Mon Oct 13 18:53:40 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 13 Oct 2014 20:53:40 +0200 Subject: Review request for JDK-8060241 Message-ID: <8B6C7C4B-6383-46A2-9349-F31613CFAA91@oracle.com> Please review JDK-8060241 at for Thanks, Attila. From david at code.davidpcaldwell.com Mon Oct 13 21:37:40 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Mon, 13 Oct 2014 17:37:40 -0400 Subject: Running Nashorn under java.lang.instrument Message-ID: So if I run Nashorn under a Java agent, I can't start it. I haven't yet dug into the error, but when I invoke: return new ScriptEngineManager().getEngineByName("nashorn") != null , which is my "is Nashorn installed" check, the following prints to System.err: ScriptEngineManager providers.next(): javax.script.ScriptEngineFactory: Provider jdk.nashorn.api.scripting.NashornScriptEngineFactory could not be instantiated Does anyone immediately know what would be wrong? My Transformer in the class does this: if (protectionDomain == null) return null; ... so it shouldn't be attempting to transform any Nashorn classes. On the other hand, if it's relevant, the ClassLoader that loaded the class above that executes return new ScriptEngineManager() ... is not loaded by the system class loader; it's loaded by an URLClassLoader that sits on top of that (it does delegate to the system class loader). Under normal circumstances, this wouldn't make a difference, but just in case ... Anyone immediately have an idea what I might be dealing with here? -- David P. Caldwell http://www.davidpcaldwell.com/ From vladimir.x.ivanov at oracle.com Mon Oct 13 23:01:17 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 14 Oct 2014 03:01:17 +0400 Subject: Running Nashorn under java.lang.instrument In-Reply-To: References: Message-ID: <543C59BD.9060701@oracle.com> David, There was a bug fixed recently (JDK-8058536 [1]), which blocked usage of java.lang.invoke from java agents. Unfortunately, the fix is not part of any release yet. Latest 8u40 & 9 early access builds should contain it. Please, give them a try. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8058536 On 10/14/14, 1:37 AM, David P. Caldwell wrote: > So if I run Nashorn under a Java agent, I can't start it. I haven't > yet dug into the error, but when I invoke: > > return new ScriptEngineManager().getEngineByName("nashorn") != null > > , which is my "is Nashorn installed" check, the following prints to System.err: > > ScriptEngineManager providers.next(): > javax.script.ScriptEngineFactory: Provider > jdk.nashorn.api.scripting.NashornScriptEngineFactory could not be > instantiated > > Does anyone immediately know what would be wrong? > > My Transformer in the class does this: > > if (protectionDomain == null) return null; > > ... so it shouldn't be attempting to transform any Nashorn classes. > > On the other hand, if it's relevant, the ClassLoader that loaded the > class above that executes return new ScriptEngineManager() ... is not > loaded by the system class loader; it's loaded by an URLClassLoader > that sits on top of that (it does delegate to the system class > loader). Under normal circumstances, this wouldn't make a difference, > but just in case ... > > Anyone immediately have an idea what I might be dealing with here? > > -- David P. Caldwell > http://www.davidpcaldwell.com/ > From sundararajan.athijegannathan at oracle.com Tue Oct 14 07:42:36 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 14 Oct 2014 13:12:36 +0530 Subject: Review request for JDK-8060242 In-Reply-To: <48698C7B-4164-4DA2-A697-9EFD5794FBAB@oracle.com> References: <48698C7B-4164-4DA2-A697-9EFD5794FBAB@oracle.com> Message-ID: <543CD3EC.2020600@oracle.com> +1 On Tuesday 14 October 2014 12:04 AM, Attila Szegedi wrote: > Please review JDK-8060242 at for > > The fix is mostly in the TypeEvaluator.java, the rest is just plumbing (ArrayBufferView has to be public so I can us it with instanceof; array data subclasses for buffer views need to support optimistic operations; Int/Long/Number/ObjectArrayData now inherit they getOptimisticType() from ContinuousArrayData; finally there was a genuine data type bug where NativeUint32Array reported its array element type to be int instead of long). > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Tue Oct 14 07:44:23 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 14 Oct 2014 09:44:23 +0200 Subject: Review request for JDK-8060238 In-Reply-To: <83A0EBA4-D689-4421-B9B2-C7B223EFF1B0@oracle.com> References: <83A0EBA4-D689-4421-B9B2-C7B223EFF1B0@oracle.com> Message-ID: <543CD457.1010906@oracle.com> +1 Am 2014-10-13 um 20:05 schrieb Attila Szegedi: > Please review JDK-8060238 at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Tue Oct 14 07:46:59 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 14 Oct 2014 09:46:59 +0200 Subject: Review request for JDK-8060242 In-Reply-To: <48698C7B-4164-4DA2-A697-9EFD5794FBAB@oracle.com> References: <48698C7B-4164-4DA2-A697-9EFD5794FBAB@oracle.com> Message-ID: <543CD4F3.8000306@oracle.com> +1 There's a blank line missing between methods in NativeUint8Array.java after getLongOptimistic. Hannes Am 2014-10-13 um 20:34 schrieb Attila Szegedi: > Please review JDK-8060242 at for > > The fix is mostly in the TypeEvaluator.java, the rest is just plumbing (ArrayBufferView has to be public so I can us it with instanceof; array data subclasses for buffer views need to support optimistic operations; Int/Long/Number/ObjectArrayData now inherit they getOptimisticType() from ContinuousArrayData; finally there was a genuine data type bug where NativeUint32Array reported its array element type to be int instead of long). > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Tue Oct 14 09:02:12 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 14 Oct 2014 14:32:12 +0530 Subject: RFR 8059443: Logical NOT operator throws NullPointerException for null Boolean return values Message-ID: <543CE694.2060708@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8059443/ for https://bugs.openjdk.java.net/browse/JDK-8059443 Thanks, -Sundar From marcus.lagergren at oracle.com Tue Oct 14 09:22:06 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 14 Oct 2014 11:22:06 +0200 Subject: RFR 8059443: Logical NOT operator throws NullPointerException for null Boolean return values In-Reply-To: <543CE694.2060708@oracle.com> References: <543CE694.2060708@oracle.com> Message-ID: +1 On 14 Oct 2014, at 11:02, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8059443/ for https://bugs.openjdk.java.net/browse/JDK-8059443 > > Thanks, > -Sundar From marcus.lagergren at oracle.com Tue Oct 14 09:23:52 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 14 Oct 2014 11:23:52 +0200 Subject: Review request for JDK-8060242 In-Reply-To: <48698C7B-4164-4DA2-A697-9EFD5794FBAB@oracle.com> References: <48698C7B-4164-4DA2-A697-9EFD5794FBAB@oracle.com> Message-ID: <7B6CF0CF-611D-4E63-96F5-1D8495103166@oracle.com> * final missing in NativeFloat32Array and friends. * I want a unit test that checks that long is the correct representation for uint32 array elements. uint16 should be fine as it's chars I guess. * There is whitespace missing between functions in NativeUint8Array. * Can you check that all unsigned typed arrays work for boundary conditions. Otherwise, looking very good. Nicely spotted. /M On 13 Oct 2014, at 20:34, Attila Szegedi wrote: > Please review JDK-8060242 at for > > The fix is mostly in the TypeEvaluator.java, the rest is just plumbing (ArrayBufferView has to be public so I can us it with instanceof; array data subclasses for buffer views need to support optimistic operations; Int/Long/Number/ObjectArrayData now inherit they getOptimisticType() from ContinuousArrayData; finally there was a genuine data type bug where NativeUint32Array reported its array element type to be int instead of long). > > Thanks, > Attila. From marcus.lagergren at oracle.com Tue Oct 14 09:25:02 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 14 Oct 2014 11:25:02 +0200 Subject: Review request for JDK-8060238 In-Reply-To: <83A0EBA4-D689-4421-B9B2-C7B223EFF1B0@oracle.com> References: <83A0EBA4-D689-4421-B9B2-C7B223EFF1B0@oracle.com> Message-ID: <1CD54D19-E70F-42A9-BAE1-8BFBEE498B33@oracle.com> Can you call the dir ?pessimistic? instead of ?nonoptimistic?, because we use the term ?pessimistic? for the same thing throughout the build.xml file for target names etc? Otherwise +1 On 13 Oct 2014, at 20:05, Attila Szegedi wrote: > Please review JDK-8060238 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Tue Oct 14 09:25:39 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 14 Oct 2014 11:25:39 +0200 Subject: Review request for JDK-8060241 In-Reply-To: <8B6C7C4B-6383-46A2-9349-F31613CFAA91@oracle.com> References: <8B6C7C4B-6383-46A2-9349-F31613CFAA91@oracle.com> Message-ID: Can I get a comment above the field declaration + private static final MethodType EMPTY_INVOCATION_TYPE = MethodType.methodType(Object.class, ScriptFunction.class, Object.class); what it?s for. That would be nice. Otherwise +1 /M On 13 Oct 2014, at 20:53, Attila Szegedi wrote: > Please review JDK-8060241 at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Tue Oct 14 09:30:52 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 14 Oct 2014 11:30:52 +0200 Subject: Review request for JDK-8060241 In-Reply-To: <8B6C7C4B-6383-46A2-9349-F31613CFAA91@oracle.com> References: <8B6C7C4B-6383-46A2-9349-F31613CFAA91@oracle.com> Message-ID: <543CED4C.30207@oracle.com> +1 Am 2014-10-13 um 20:53 schrieb Attila Szegedi: > Please review JDK-8060241 at for > > Thanks, > Attila. From attila.szegedi at oracle.com Tue Oct 14 11:16:12 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 14 Oct 2014 13:16:12 +0200 Subject: Review request for JDK-8060242 In-Reply-To: <7B6CF0CF-611D-4E63-96F5-1D8495103166@oracle.com> References: <48698C7B-4164-4DA2-A697-9EFD5794FBAB@oracle.com> <7B6CF0CF-611D-4E63-96F5-1D8495103166@oracle.com> Message-ID: On Oct 14, 2014, at 11:23 AM, Marcus Lagergren wrote: > * final missing in NativeFloat32Array and friends. Added. > * I want a unit test that checks that long is the correct representation for uint32 array elements. uint16 should be fine as it's chars I guess. The getElementType() was previously only used by NativeArray.PopLinkLogic, so its value in Uint32ArrayData had no effect on anything. Uint32ArrayData getElem() and setElem() have both alway returned/taken long values, so long is the correct value. Which is to say, there's no test that could detect a difference from the behavior before this patch. > * There is whitespace missing between functions in NativeUint8Array. Added. > * Can you check that all unsigned typed arrays work for boundary conditions. Uint16 and Uint8 trivially fit into a 32-bit int, so they have to. Existing tests, specifically NASHORN-377 exercise all of these quite thoroughly, also lots of Octane benchmarks too (pdfjs and mandreel use a lot of Uint8, Uint16, Uint32, Float32). > > Otherwise, looking very good. Nicely spotted. > > /M > > On 13 Oct 2014, at 20:34, Attila Szegedi wrote: > >> Please review JDK-8060242 at for >> >> The fix is mostly in the TypeEvaluator.java, the rest is just plumbing (ArrayBufferView has to be public so I can us it with instanceof; array data subclasses for buffer views need to support optimistic operations; Int/Long/Number/ObjectArrayData now inherit they getOptimisticType() from ContinuousArrayData; finally there was a genuine data type bug where NativeUint32Array reported its array element type to be int instead of long). >> >> Thanks, >> Attila. > From david at code.davidpcaldwell.com Tue Oct 14 11:18:12 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Tue, 14 Oct 2014 07:18:12 -0400 Subject: Running Nashorn under java.lang.instrument In-Reply-To: References: Message-ID: Part of the issue is that I was incorrect that Nashorn would be loaded by the system class loader; it is actually loaded by the extensions class loader, so my code will indeed attempt to instrument Nashorn itself. I don't know whether that should work or not, but it's not what I was trying to do, so I'm going to continue debugging and will report back if and as I find useful things. On Mon, Oct 13, 2014 at 5:37 PM, David P. Caldwell wrote: > So if I run Nashorn under a Java agent, I can't start it. I haven't > yet dug into the error, but when I invoke: > > return new ScriptEngineManager().getEngineByName("nashorn") != null > > , which is my "is Nashorn installed" check, the following prints to System.err: > > ScriptEngineManager providers.next(): > javax.script.ScriptEngineFactory: Provider > jdk.nashorn.api.scripting.NashornScriptEngineFactory could not be > instantiated > > Does anyone immediately know what would be wrong? > > My Transformer in the class does this: > > if (protectionDomain == null) return null; > > ... so it shouldn't be attempting to transform any Nashorn classes. > > On the other hand, if it's relevant, the ClassLoader that loaded the > class above that executes return new ScriptEngineManager() ... is not > loaded by the system class loader; it's loaded by an URLClassLoader > that sits on top of that (it does delegate to the system class > loader). Under normal circumstances, this wouldn't make a difference, > but just in case ... > > Anyone immediately have an idea what I might be dealing with here? > > -- David P. Caldwell > http://www.davidpcaldwell.com/ From marcus.lagergren at oracle.com Tue Oct 14 13:25:12 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 14 Oct 2014 15:25:12 +0200 Subject: Review request for JDK-8060242 In-Reply-To: References: <48698C7B-4164-4DA2-A697-9EFD5794FBAB@oracle.com> <7B6CF0CF-611D-4E63-96F5-1D8495103166@oracle.com> Message-ID: <043F6DE7-0A16-49C7-8C55-87E6FA73F2C1@oracle.com> +1. On 14 Oct 2014, at 13:16, Attila Szegedi wrote: > > On Oct 14, 2014, at 11:23 AM, Marcus Lagergren wrote: > >> * final missing in NativeFloat32Array and friends. > > Added. > >> * I want a unit test that checks that long is the correct representation for uint32 array elements. uint16 should be fine as it's chars I guess. > > The getElementType() was previously only used by NativeArray.PopLinkLogic, so its value in Uint32ArrayData had no effect on anything. Uint32ArrayData getElem() and setElem() have both alway returned/taken long values, so long is the correct value. Which is to say, there's no test that could detect a difference from the behavior before this patch. > >> * There is whitespace missing between functions in NativeUint8Array. > > Added. > >> * Can you check that all unsigned typed arrays work for boundary conditions. > > Uint16 and Uint8 trivially fit into a 32-bit int, so they have to. Existing tests, specifically NASHORN-377 exercise all of these quite thoroughly, also lots of Octane benchmarks too (pdfjs and mandreel use a lot of Uint8, Uint16, Uint32, Float32). > >> >> Otherwise, looking very good. Nicely spotted. >> >> /M >> >> On 13 Oct 2014, at 20:34, Attila Szegedi wrote: >> >>> Please review JDK-8060242 at for >>> >>> The fix is mostly in the TypeEvaluator.java, the rest is just plumbing (ArrayBufferView has to be public so I can us it with instanceof; array data subclasses for buffer views need to support optimistic operations; Int/Long/Number/ObjectArrayData now inherit they getOptimisticType() from ContinuousArrayData; finally there was a genuine data type bug where NativeUint32Array reported its array element type to be int instead of long). >>> >>> Thanks, >>> Attila. >> > From marcus.lagergren at oracle.com Tue Oct 14 14:15:32 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 14 Oct 2014 16:15:32 +0200 Subject: Please review JDK-8060471 Message-ID: <78C95957-40D2-4EC7-B1B1-E51FCD51A737@oracle.com> Fairly small change. Contributed by Andreas Gabrielsson - Even when the logger was disabled, expensive stacktraces were generated. Webrev is at: http://cr.openjdk.java.net/~lagergren/8060471/webrev/ /M From attila.szegedi at oracle.com Tue Oct 14 14:19:55 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 14 Oct 2014 16:19:55 +0200 Subject: Please review JDK-8060471 In-Reply-To: <78C95957-40D2-4EC7-B1B1-E51FCD51A737@oracle.com> References: <78C95957-40D2-4EC7-B1B1-E51FCD51A737@oracle.com> Message-ID: +1 On Oct 14, 2014, at 4:15 PM, Marcus Lagergren wrote: > Fairly small change. Contributed by Andreas Gabrielsson - Even when the logger was disabled, expensive stacktraces were generated. > > Webrev is at: http://cr.openjdk.java.net/~lagergren/8060471/webrev/ > > /M > From sundararajan.athijegannathan at oracle.com Tue Oct 14 14:24:01 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 14 Oct 2014 19:54:01 +0530 Subject: Please review JDK-8060471 In-Reply-To: <78C95957-40D2-4EC7-B1B1-E51FCD51A737@oracle.com> References: <78C95957-40D2-4EC7-B1B1-E51FCD51A737@oracle.com> Message-ID: <543D3201.9010202@oracle.com> +1 On Tuesday 14 October 2014 07:45 PM, Marcus Lagergren wrote: > Fairly small change. Contributed by Andreas Gabrielsson - Even when the logger was disabled, expensive stacktraces were generated. > > Webrev is at: http://cr.openjdk.java.net/~lagergren/8060471/webrev/ > > /M > From david at code.davidpcaldwell.com Tue Oct 14 15:07:03 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Tue, 14 Oct 2014 11:07:03 -0400 Subject: Running Nashorn under java.lang.instrument In-Reply-To: References: Message-ID: OK, I actually have this "working" (not crashing) now. I did not have to update my JDK. The main impediment I actually had was the Nashorn is loaded in the extension class loader, and java.lang.instrument-loaded agents are loaded in the application class loader. So in order to get my profiler to work, I have to load it as an extension (i.e., add its location to the java.ext.dirs property). This way the instrumented Nashorn classes can "see" the classes in the agent and invoke them in order to generate profiling data. This doesn't seem ideal but I am not familiar enough with advanced javaagent implementation or bytecode manipulation to know whether there's a better way to approach this. In any case, my original question was about the ability to profile Nashorn applications. So I'll return to that. Right now my profiler emits lots of trees like this: elapsed=38 calls=1 jdk.nashorn.internal.scripts.Script$api_rhino L:34 (Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; elapsed=36 calls=0 (self) elapsed=2 calls=58 jdk.nashorn.internal.scripts.Script$api_rhino :scopeCall (Ljdk/nashorn/internal/runtime/ScriptObject;ILjava/lang/Object;)Ljava/lang/Object; elapsed=0 calls=1 jdk.nashorn.internal.scripts.Script$api_rhino :getMap (I)Ljdk/nashorn/internal/runtime/PropertyMap; elapsed=14 calls=1 jdk.nashorn.internal.scripts.Script$api_rhino L:58 (Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; elapsed=11 calls=1 jdk.nashorn.internal.scripts.Script$api_rhino L:58$L:59 (Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; elapsed=8 calls=1 jdk.nashorn.internal.scripts.Script$=nashorn!mozilla_compat L:52$L:56 (Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; elapsed=4 calls=1 jdk.nashorn.internal.scripts.Script$engine L:35 (Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; elapsed=4 calls=0 (self) elapsed=3 calls=0 (self) elapsed=0 calls=1 jdk.nashorn.internal.scripts.Script$api_rhino L:58$L:59$L:67 (Ljava/lang/Object;)Ljava/lang/Object; elapsed=0 calls=1 jdk.nashorn.internal.scripts.Script$api_rhino :getMap (I)Ljdk/nashorn/internal/runtime/PropertyMap; elapsed=2 calls=1 jdk.nashorn.internal.scripts.Script$api_rhino L:23 (Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; elapsed=1 calls=0 (self) ... and I am still trying to figure out how to translate those into something that would be useful to application developers attempting to do CPU profiling of their code. If anyone has guidance or pointers on how I might pick apart the above inside my Java agent, I'd be grateful! -- David P. Caldwell http://www.davidpcaldwell.com/ On Tue, Oct 14, 2014 at 7:18 AM, David P. Caldwell wrote: > Part of the issue is that I was incorrect that Nashorn would be loaded > by the system class loader; it is actually loaded by the extensions > class loader, so my code will indeed attempt to instrument Nashorn > itself. I don't know whether that should work or not, but it's not > what I was trying to do, so I'm going to continue debugging and will > report back if and as I find useful things. > > On Mon, Oct 13, 2014 at 5:37 PM, David P. Caldwell > wrote: >> So if I run Nashorn under a Java agent, I can't start it. I haven't >> yet dug into the error, but when I invoke: >> >> return new ScriptEngineManager().getEngineByName("nashorn") != null >> >> , which is my "is Nashorn installed" check, the following prints to System.err: >> >> ScriptEngineManager providers.next(): >> javax.script.ScriptEngineFactory: Provider >> jdk.nashorn.api.scripting.NashornScriptEngineFactory could not be >> instantiated >> >> Does anyone immediately know what would be wrong? >> >> My Transformer in the class does this: >> >> if (protectionDomain == null) return null; >> >> ... so it shouldn't be attempting to transform any Nashorn classes. >> >> On the other hand, if it's relevant, the ClassLoader that loaded the >> class above that executes return new ScriptEngineManager() ... is not >> loaded by the system class loader; it's loaded by an URLClassLoader >> that sits on top of that (it does delegate to the system class >> loader). Under normal circumstances, this wouldn't make a difference, >> but just in case ... >> >> Anyone immediately have an idea what I might be dealing with here? >> >> -- David P. Caldwell >> http://www.davidpcaldwell.com/ From sundararajan.athijegannathan at oracle.com Wed Oct 15 12:58:36 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 15 Oct 2014 18:28:36 +0530 Subject: RFR Nashorn: Generated script class name fails --verify-code for names with special chars Message-ID: <543E6F7C.3020703@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8060688/ for https://bugs.openjdk.java.net/browse/JDK-8060688 Thanks, -Sundar From james.laskey at oracle.com Wed Oct 15 13:01:27 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 15 Oct 2014 10:01:27 -0300 Subject: RFR Nashorn: Generated script class name fails --verify-code for names with special chars In-Reply-To: <543E6F7C.3020703@oracle.com> References: <543E6F7C.3020703@oracle.com> Message-ID: <11F37E40-9312-4626-8BBB-3D6768BE1804@oracle.com> +1 On Oct 15, 2014, at 9:58 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8060688/ for https://bugs.openjdk.java.net/browse/JDK-8060688 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Wed Oct 15 13:06:17 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 15 Oct 2014 15:06:17 +0200 Subject: RFR Nashorn: Generated script class name fails --verify-code for names with special chars In-Reply-To: <543E6F7C.3020703@oracle.com> References: <543E6F7C.3020703@oracle.com> Message-ID: <543E7149.9000906@oracle.com> +1 Am 2014-10-15 um 14:58 schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8060688/ for > https://bugs.openjdk.java.net/browse/JDK-8060688 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Wed Oct 15 13:06:29 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 15 Oct 2014 18:36:29 +0530 Subject: RFR Nashorn: Generated script class name fails --verify-code for names with special chars In-Reply-To: <11F37E40-9312-4626-8BBB-3D6768BE1804@oracle.com> References: <543E6F7C.3020703@oracle.com> <11F37E40-9312-4626-8BBB-3D6768BE1804@oracle.com> Message-ID: <543E7155.7010504@oracle.com> Trying to figure out how to file a bug against ASM. Basically ASM's verifier enforces strict java identifier for class names. But, method names accept relaxed JVM symbol syntax. The current nashorn fix is a workaround for ASM issue. How to reproduce using jdk 8u20's jjs jjs --verify-code -doe java.lang.IllegalArgumentException: Invalid class name (must be a fully qualified class name in internal form): jdk/nashorn/internal/scripts/Script$\^shell java.lang.IllegalArgumentException: Invalid class name (must be a fully qualified class name in internal form): jdk/nashorn/internal/scripts/Script$\^shell at jdk.internal.org.objectweb.asm.util.CheckMethodAdapter.checkInternalName(CheckMethodAdapter.java:1380) at jdk.internal.org.objectweb.asm.util.CheckMethodAdapter.checkInternalName(CheckMethodAdapter.java:1347) at jdk.internal.org.objectweb.asm.util.CheckClassAdapter.visit(CheckClassAdapter.java:412) at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:651) at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:535) at jdk.internal.org.objectweb.asm.util.CheckClassAdapter.verify(CheckClassAdapter.java:241) at jdk.nashorn.internal.runtime.Context.verify(Context.java:889) at jdk.nashorn.internal.runtime.Context$ContextCodeInstaller.verify(Context.java:174) at jdk.nashorn.internal.codegen.CompilationPhase$8.transform(CompilationPhase.java:414) at jdk.nashorn.internal.codegen.CompilationPhase.apply(CompilationPhase.java:513) at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:361) at jdk.nashorn.internal.runtime.Context.compile(Context.java:1071) at jdk.nashorn.internal.runtime.Context.eval(Context.java:552) at jdk.nashorn.tools.Shell.readEvalPrint(Shell.java:410) at jdk.nashorn.tools.Shell.run(Shell.java:157) at jdk.nashorn.tools.Shell.main(Shell.java:132) at jdk.nashorn.tools.Shell.main(Shell.java:111) Nashorn uses "" to be class name (after safe escaping as \^shell\_ as described @ https://blogs.oracle.com/jrose/entry/symbolic_freedom_in_the_vm). While VM is fine with that name, ASM's verifier does not like it. Thanks -Sundar On Wednesday 15 October 2014 06:31 PM, Jim Laskey (Oracle) wrote: > +1 > > On Oct 15, 2014, at 9:58 AM, A. Sundararajan wrote: > >> Please review http://cr.openjdk.java.net/~sundar/8060688/ for https://bugs.openjdk.java.net/browse/JDK-8060688 >> >> Thanks, >> -Sundar From jeramiehicks at hotmail.com Thu Oct 16 03:19:17 2014 From: jeramiehicks at hotmail.com (Jeramie Hicks) Date: Wed, 15 Oct 2014 22:19:17 -0500 Subject: Reading JO4/NativeArray in HashMap Message-ID: I'm not sure if this is the right place to ask, as I'm fairly new to this whole scripting thing. But I've been banging my head against the wall for about 4 days and can't seem to make any progress. Here's the really short version. I have a custom (extended) HashMap in Java. I put() it into the engine, eval the script, everything works great. When the script is done and I'm back in Java, my poor HashMap is now full of NativeArrays and JO4s. I gotta JSON-up all this data and I can't seem to find any way into those objects (and even if so, I don't want to depend on talking straight to internals). I really, really don't want to burden the script with any boilerplate to make this work; the script currently runs beautifully with nice clean statements like "dataStore.xyz = [5,6,7];" so I'd hate to junk it up with a bunch of manual function calls to just make this to work. I can see the data I need is RIGHT THERE in my HashMap... what step am I missing? Thanks. More specific info at http://stackoverflow.com/questions/26392602/reading-nashorn-jo4-and-nativearray Much obliged for your time. - Jeramie Hicks From marcus.lagergren at oracle.com Thu Oct 16 08:13:32 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 16 Oct 2014 10:13:32 +0200 Subject: RFR Nashorn: Generated script class name fails --verify-code for names with special chars In-Reply-To: <543E7155.7010504@oracle.com> References: <543E6F7C.3020703@oracle.com> <11F37E40-9312-4626-8BBB-3D6768BE1804@oracle.com> <543E7155.7010504@oracle.com> Message-ID: <393775B0-58C3-4350-8881-36BBE734F60D@oracle.com> +1. But is this the fastest way to write the code though? The indexOf in the loop is another O(n). How about a RegExp match for a precompiled regexp? That might of course be even slower. I doubt that it shows up as a bottleneck right now, but we might want to think about it as investigation for future enhancement and file a separate enhancement CR. /M On 15 Oct 2014, at 15:06, A. Sundararajan wrote: > Trying to figure out how to file a bug against ASM. Basically ASM's verifier enforces strict java identifier for class names. But, method names accept relaxed JVM symbol syntax. > > The current nashorn fix is a workaround for ASM issue. > > How to reproduce using jdk 8u20's jjs > > jjs --verify-code -doe > > java.lang.IllegalArgumentException: Invalid class name (must be a fully qualified class name in internal form): jdk/nashorn/internal/scripts/Script$\^shell > java.lang.IllegalArgumentException: Invalid class name (must be a fully qualified class name in internal form): jdk/nashorn/internal/scripts/Script$\^shell > at jdk.internal.org.objectweb.asm.util.CheckMethodAdapter.checkInternalName(CheckMethodAdapter.java:1380) > at jdk.internal.org.objectweb.asm.util.CheckMethodAdapter.checkInternalName(CheckMethodAdapter.java:1347) > at jdk.internal.org.objectweb.asm.util.CheckClassAdapter.visit(CheckClassAdapter.java:412) > at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:651) > at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:535) > at jdk.internal.org.objectweb.asm.util.CheckClassAdapter.verify(CheckClassAdapter.java:241) > at jdk.nashorn.internal.runtime.Context.verify(Context.java:889) > at jdk.nashorn.internal.runtime.Context$ContextCodeInstaller.verify(Context.java:174) > at jdk.nashorn.internal.codegen.CompilationPhase$8.transform(CompilationPhase.java:414) > at jdk.nashorn.internal.codegen.CompilationPhase.apply(CompilationPhase.java:513) > at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:361) > at jdk.nashorn.internal.runtime.Context.compile(Context.java:1071) > at jdk.nashorn.internal.runtime.Context.eval(Context.java:552) > at jdk.nashorn.tools.Shell.readEvalPrint(Shell.java:410) > at jdk.nashorn.tools.Shell.run(Shell.java:157) > at jdk.nashorn.tools.Shell.main(Shell.java:132) > at jdk.nashorn.tools.Shell.main(Shell.java:111) > > Nashorn uses "" to be class name (after safe escaping as \^shell\_ as described @ https://blogs.oracle.com/jrose/entry/symbolic_freedom_in_the_vm). While VM is fine with that name, ASM's verifier does not like it. > > Thanks > -Sundar > > On Wednesday 15 October 2014 06:31 PM, Jim Laskey (Oracle) wrote: >> +1 >> >> On Oct 15, 2014, at 9:58 AM, A. Sundararajan wrote: >> >>> Please review http://cr.openjdk.java.net/~sundar/8060688/ for https://bugs.openjdk.java.net/browse/JDK-8060688 >>> >>> Thanks, >>> -Sundar > From attila.szegedi at oracle.com Thu Oct 16 09:18:38 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 16 Oct 2014 11:18:38 +0200 Subject: Review request for JDK-8061113 Message-ID: Please review JDK-8061113 at for Thanks, Attila. From hannes.wallnoefer at oracle.com Thu Oct 16 09:22:31 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 16 Oct 2014 11:22:31 +0200 Subject: Review request for JDK-8061113 In-Reply-To: References: Message-ID: <543F8E57.3050204@oracle.com> +1 Am 2014-10-16 um 11:18 schrieb Attila Szegedi: > Please review JDK-8061113 at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Thu Oct 16 11:22:43 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 16 Oct 2014 16:52:43 +0530 Subject: RFR Nashorn: Generated script class name fails --verify-code for names with special chars In-Reply-To: <393775B0-58C3-4350-8881-36BBE734F60D@oracle.com> References: <543E6F7C.3020703@oracle.com> <11F37E40-9312-4626-8BBB-3D6768BE1804@oracle.com> <543E7155.7010504@oracle.com> <393775B0-58C3-4350-8881-36BBE734F60D@oracle.com> Message-ID: <543FAA83.3070307@oracle.com> The current workaround fix in Nashorn is about --verify-code mode - which is a sort of debug mode really. The real fix is to be done in ASM - at which point we can remove nashorn workaround. I don't think it is worth spending time to optimize this. -Sundar On Thursday 16 October 2014 01:43 PM, Marcus Lagergren wrote: > +1. But is this the fastest way to write the code though? The indexOf in the loop is another O(n). How about a RegExp match for a precompiled regexp? That might of course be even slower. > > I doubt that it shows up as a bottleneck right now, but we might want to think about it as investigation for future enhancement and file a separate enhancement CR. > > /M > > > On 15 Oct 2014, at 15:06, A. Sundararajan wrote: > >> Trying to figure out how to file a bug against ASM. Basically ASM's verifier enforces strict java identifier for class names. But, method names accept relaxed JVM symbol syntax. >> >> The current nashorn fix is a workaround for ASM issue. >> >> How to reproduce using jdk 8u20's jjs >> >> jjs --verify-code -doe >> >> java.lang.IllegalArgumentException: Invalid class name (must be a fully qualified class name in internal form): jdk/nashorn/internal/scripts/Script$\^shell >> java.lang.IllegalArgumentException: Invalid class name (must be a fully qualified class name in internal form): jdk/nashorn/internal/scripts/Script$\^shell >> at jdk.internal.org.objectweb.asm.util.CheckMethodAdapter.checkInternalName(CheckMethodAdapter.java:1380) >> at jdk.internal.org.objectweb.asm.util.CheckMethodAdapter.checkInternalName(CheckMethodAdapter.java:1347) >> at jdk.internal.org.objectweb.asm.util.CheckClassAdapter.visit(CheckClassAdapter.java:412) >> at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:651) >> at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:535) >> at jdk.internal.org.objectweb.asm.util.CheckClassAdapter.verify(CheckClassAdapter.java:241) >> at jdk.nashorn.internal.runtime.Context.verify(Context.java:889) >> at jdk.nashorn.internal.runtime.Context$ContextCodeInstaller.verify(Context.java:174) >> at jdk.nashorn.internal.codegen.CompilationPhase$8.transform(CompilationPhase.java:414) >> at jdk.nashorn.internal.codegen.CompilationPhase.apply(CompilationPhase.java:513) >> at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:361) >> at jdk.nashorn.internal.runtime.Context.compile(Context.java:1071) >> at jdk.nashorn.internal.runtime.Context.eval(Context.java:552) >> at jdk.nashorn.tools.Shell.readEvalPrint(Shell.java:410) >> at jdk.nashorn.tools.Shell.run(Shell.java:157) >> at jdk.nashorn.tools.Shell.main(Shell.java:132) >> at jdk.nashorn.tools.Shell.main(Shell.java:111) >> >> Nashorn uses "" to be class name (after safe escaping as \^shell\_ as described @ https://blogs.oracle.com/jrose/entry/symbolic_freedom_in_the_vm). While VM is fine with that name, ASM's verifier does not like it. >> >> Thanks >> -Sundar >> >> On Wednesday 15 October 2014 06:31 PM, Jim Laskey (Oracle) wrote: >>> +1 >>> >>> On Oct 15, 2014, at 9:58 AM, A. Sundararajan wrote: >>> >>>> Please review http://cr.openjdk.java.net/~sundar/8060688/ for https://bugs.openjdk.java.net/browse/JDK-8060688 >>>> >>>> Thanks, >>>> -Sundar From sundararajan.athijegannathan at oracle.com Thu Oct 16 11:35:14 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 16 Oct 2014 17:05:14 +0530 Subject: Review request for JDK-8061113 In-Reply-To: References: Message-ID: <543FAD72.2020401@oracle.com> +1 On Thursday 16 October 2014 02:48 PM, Attila Szegedi wrote: > Please review JDK-8061113 at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Thu Oct 16 13:44:21 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 16 Oct 2014 19:14:21 +0530 Subject: ScriptObjectMirrors Message-ID: <543FCBB5.8090200@oracle.com> There were many questions in this list and elsewhere on ScriptObjectMirror. This email is to clarify those. Nashorn represents JavaScript objects as instances of implementation class called jdk.nashorn.internal.runtime.ScriptObject or one of it's subclasses (like NativeArray, NativeRegExp etc. - or even generated ones like jdk.nashorn.internal.scripts.JO4 etc) When ScriptObjects are returned from a script function or evaluated script code, ScriptEngine.eval returns an instanceof jdk.nashorn.api.scripting.ScriptObjectMirror. http://cr.openjdk.java.net/~sundar/jdk.nashorn.api/9/javadoc/jdk/nashorn/api/scripting/ScriptObjectMirror.html Example: ScriptEngine e = new ScriptEngineManager().getEngineByName("nashorn"); Object obj = e.eval("var obj = { foo: 23 }"); // obj is an instance of ScriptObjectMirror Caller can cast the result to ScriptObjectMirror to access properties of that script object or call methods on it. All javax.script interface methods returning Object (ScriptEngine.eval, Invocable.invokeFunction, Invocable.invokeMethod) return ScriptObjectMirror if underlying script or script function/method returns a JS object. But, if you call any Java method accepting Object type param or assign to element of Object[], then Nashorn was not wrapping ScriptObject in the past. i.e., 'raw' ScriptObject (or subclass) instances "escaped" to Java layer. If you try to cast those to ScriptObjectMirror from Java code, you got ClassCastException. Also, if you passed such raw object as "self" parameter for Invocable.invokeMethod, you would IllegalArgumentException. This was causing a lot of confusion - script objects got to java code sometimes as wrapped mirror objects and sometimes as 'raw' objects! With a recent change http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a8d44c7c2ac0 in jdk9 and the corresponding backport to jdk8u-dev http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/a35c8136c045 the way nashorn wraps internal ScriptObjects to ScriptObjectMirror has changed. Script objects are always wrapped to ScriptObjectMirror - even when you're calling Java method that accepts "Object" type value. Also, return values from java methods returning Object are "unwrapped" (if the return value is a ScriptObjectMirror) when it gets to script execution. Example: // list gets ScriptObjectMirror as element engine.eval("var m = new java.util.HashMap(); l.put('myobj', { foo: 33 });"); engine.eval("var obj = m.get('myobj'); // obj gets unwrapped as ScriptObject here"); With this change, raw ScriptObjects don't escape to Java layer at all. Hope this helps, -Sundar From sundararajan.athijegannathan at oracle.com Thu Oct 16 15:44:01 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 16 Oct 2014 21:14:01 +0530 Subject: Reading JO4/NativeArray in HashMap In-Reply-To: References: Message-ID: <543FE7C1.1050507@oracle.com> Please check this out: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003676.html Summary: in jdk8u40 and jdk9, ScriptObjects (like NativeArray, JO4) are always wrapped as ScriptObjectMirror when crossing to Java layer. -Sundar On Thursday 16 October 2014 08:49 AM, Jeramie Hicks wrote: > I'm not sure if this is the right place to ask, as I'm fairly new to this whole scripting thing. But I've been banging my head against the wall for about 4 days and can't seem to make any progress. > Here's the really short version. I have a custom (extended) HashMap in Java. I put() it into the engine, eval the script, everything works great. When the script is done and I'm back in Java, my poor HashMap is now full of NativeArrays and JO4s. I gotta JSON-up all this data and I can't seem to find any way into those objects (and even if so, I don't want to depend on talking straight to internals). I really, really don't want to burden the script with any boilerplate to make this work; the script currently runs beautifully with nice clean statements like "dataStore.xyz = [5,6,7];" so I'd hate to junk it up with a bunch of manual function calls to just make this to work. I can see the data I need is RIGHT THERE in my HashMap... what step am I missing? Thanks. > More specific info at http://stackoverflow.com/questions/26392602/reading-nashorn-jo4-and-nativearray > Much obliged for your time. - Jeramie Hicks From sundararajan.athijegannathan at oracle.com Thu Oct 16 15:55:04 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 16 Oct 2014 21:25:04 +0530 Subject: Behavior of Object.bindProperties() Method of Nashorn In-Reply-To: References: Message-ID: <543FEA58.9010708@oracle.com> Object.bindProperties considers properties at the time of bindings only. No "tracking" of object after it is bound. Also, only properties that don't exist in target object are bound from source (again check is at the time of binding). Hope this helps, -Sundar On Friday 10 October 2014 11:08 PM, Kishori Sharan wrote: > Hello Everyone, > > I was experimenting with the Object.bindProperties() method in Nashorn and > found a few weird behaviors. I would like to ask two questions: > 1. Is there a comprehensive documentation for this method, except at > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-loadWithNewGlobal > 2. Is it a bug as explained in the following snippet of code? > > The following code does not bind the x, y, and z properties of obj2 to obj > because obj already has properties with the same names. Is it documented > somewhere? > > var obj = {x:10, y:20, z:30}; > > var obj2 = {x:100, y:200, z:300}; > > > > // bind properties of 'obj2' to 'obj' > > Object.bindProperties(obj, obj2); > > > > print(obj.x, obj.y, obj.z); > > print(obj2.x, obj2.y, obj2.z); > > --------------------------------- > > 10 20 30 > > 100 200 300 > > -------------------------------- > > Now, let us add a new property to obj2. The new property is bound to obj, > but obj reads the new property's value as null: > > var obj = {x:10, y:20, z:30}; > > var obj2 = {x:100, y:200, z:300}; > > > > // Add a new property to obj2 > > obj2.u = 600; > > > > // bind properties of 'obj2' to 'obj' > > Object.bindProperties(obj, obj2); > > > > print(obj.x, obj.y, obj.z, obj.u); // obj.u is null. Why? > > print(obj2.x, obj2.y, obj2.z, obj2.u); > > > > --------------------------------- > > 10 20 30 null > > 100 200 300 600 > > -------------------------------- > > And, here is another variant of the code that works. This time, I started > the target object as empty. Now, adding the new property to the source > works fine. > > var obj = {}; > > var obj2 = {x:100, y:200, z:300}; > > > > // Add a new property to obj2 > > obj2.u = 600; > > > > // bind properties of 'obj2' to 'obj' > > Object.bindProperties(obj, obj2); > > > > print(obj.x, obj.y, obj.z, obj.u); // obj.u is correct.It is 600 > > print(obj2.x, obj2.y, obj2.z, obj2.u); > > > > ---------------------------- > > 100 200 300 600 > > 100 200 300 600 > > ---------------------------- > > I am using JDK version 1.8.0_20. > Thanks > Kishori From sundararajan.athijegannathan at oracle.com Thu Oct 16 16:02:10 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 16 Oct 2014 21:32:10 +0530 Subject: Behavior of Object.bindProperties() Method of Nashorn In-Reply-To: <543FEA58.9010708@oracle.com> References: <543FEA58.9010708@oracle.com> Message-ID: <543FEC02.4070806@oracle.com> And I expanded wiki page section on bindProperties after your question :-) https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Object.bindProperties Thanks -Sundar On Thursday 16 October 2014 09:25 PM, A. Sundararajan wrote: > Object.bindProperties considers properties at the time of bindings > only. No "tracking" of object after it is bound. Also, only properties > that don't exist in target object are bound from source (again check > is at the time of binding). > > Hope this helps, > -Sundar > > On Friday 10 October 2014 11:08 PM, Kishori Sharan wrote: >> Hello Everyone, >> >> I was experimenting with the Object.bindProperties() method in >> Nashorn and >> found a few weird behaviors. I would like to ask two questions: >> 1. Is there a comprehensive documentation for this method, except at >> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-loadWithNewGlobal >> >> 2. Is it a bug as explained in the following snippet of code? >> >> The following code does not bind the x, y, and z properties of obj2 >> to obj >> because obj already has properties with the same names. Is it documented >> somewhere? >> >> var obj = {x:10, y:20, z:30}; >> >> var obj2 = {x:100, y:200, z:300}; >> >> >> >> // bind properties of 'obj2' to 'obj' >> >> Object.bindProperties(obj, obj2); >> >> >> >> print(obj.x, obj.y, obj.z); >> >> print(obj2.x, obj2.y, obj2.z); >> >> --------------------------------- >> >> 10 20 30 >> >> 100 200 300 >> >> -------------------------------- >> >> Now, let us add a new property to obj2. The new property is bound to >> obj, >> but obj reads the new property's value as null: >> >> var obj = {x:10, y:20, z:30}; >> >> var obj2 = {x:100, y:200, z:300}; >> >> >> >> // Add a new property to obj2 >> >> obj2.u = 600; >> >> >> >> // bind properties of 'obj2' to 'obj' >> >> Object.bindProperties(obj, obj2); >> >> >> >> print(obj.x, obj.y, obj.z, obj.u); // obj.u is null. Why? >> >> print(obj2.x, obj2.y, obj2.z, obj2.u); >> >> >> >> --------------------------------- >> >> 10 20 30 null >> >> 100 200 300 600 >> >> -------------------------------- >> >> And, here is another variant of the code that works. This time, I >> started >> the target object as empty. Now, adding the new property to the source >> works fine. >> >> var obj = {}; >> >> var obj2 = {x:100, y:200, z:300}; >> >> >> >> // Add a new property to obj2 >> >> obj2.u = 600; >> >> >> >> // bind properties of 'obj2' to 'obj' >> >> Object.bindProperties(obj, obj2); >> >> >> >> print(obj.x, obj.y, obj.z, obj.u); // obj.u is correct.It is 600 >> >> print(obj2.x, obj2.y, obj2.z, obj2.u); >> >> >> >> ---------------------------- >> >> 100 200 300 600 >> >> 100 200 300 600 >> >> ---------------------------- >> >> I am using JDK version 1.8.0_20. >> Thanks >> Kishori > From smourachov at gmail.com Fri Oct 17 03:53:04 2014 From: smourachov at gmail.com (Serguei Mourachov) Date: Thu, 16 Oct 2014 20:53:04 -0700 Subject: ScriptObjectMirrors In-Reply-To: <543FCBB5.8090200@oracle.com> References: <543FCBB5.8090200@oracle.com> Message-ID: <544092A0.3000304@gmail.com> Sundar Will it also affect classes implementing JSObject? IMO, we should have an option to disable this wrap/unwrap behavior in cases when it significantly affecting performance. SM On 10/16/2014 6:44 AM, A. Sundararajan wrote: > There were many questions in this list and elsewhere on > ScriptObjectMirror. This email is to clarify those. > > Nashorn represents JavaScript objects as instances of implementation > class called jdk.nashorn.internal.runtime.ScriptObject or one of it's > subclasses (like NativeArray, NativeRegExp etc. - or even generated > ones like jdk.nashorn.internal.scripts.JO4 etc) > > When ScriptObjects are returned from a script function or evaluated > script code, ScriptEngine.eval returns an instanceof > jdk.nashorn.api.scripting.ScriptObjectMirror. > > http://cr.openjdk.java.net/~sundar/jdk.nashorn.api/9/javadoc/jdk/nashorn/api/scripting/ScriptObjectMirror.html > > > Example: > > ScriptEngine e = new > ScriptEngineManager().getEngineByName("nashorn"); > Object obj = e.eval("var obj = { foo: 23 }"); // obj is an > instance of ScriptObjectMirror > > Caller can cast the result to ScriptObjectMirror to access properties > of that script object or call methods on it. All javax.script > interface methods returning Object (ScriptEngine.eval, > Invocable.invokeFunction, Invocable.invokeMethod) return > ScriptObjectMirror if underlying script or script function/method > returns a JS object. > > But, if you call any Java method accepting Object type param or assign > to element of Object[], then Nashorn was not wrapping ScriptObject in > the past. i.e., 'raw' ScriptObject (or subclass) instances "escaped" > to Java layer. If you try to cast those to ScriptObjectMirror from > Java code, you got ClassCastException. Also, if you passed such raw > object as "self" parameter for Invocable.invokeMethod, you would > IllegalArgumentException. This was causing a lot of confusion - script > objects got to java code sometimes as wrapped mirror objects and > sometimes as 'raw' objects! > > With a recent change > > http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a8d44c7c2ac0 > > in jdk9 and the corresponding backport to jdk8u-dev > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/a35c8136c045 > > the way nashorn wraps internal ScriptObjects to ScriptObjectMirror has > changed. Script objects are always wrapped to ScriptObjectMirror - > even when you're calling Java method that accepts "Object" type value. > Also, return values from java methods returning Object are "unwrapped" > (if the return value is a ScriptObjectMirror) when it gets to script > execution. > > Example: > > // list gets ScriptObjectMirror as element > engine.eval("var m = new java.util.HashMap(); l.put('myobj', { > foo: 33 });"); > engine.eval("var obj = m.get('myobj'); // obj gets unwrapped as > ScriptObject here"); > > With this change, raw ScriptObjects don't escape to Java layer at all. > > Hope this helps, > -Sundar From sundararajan.athijegannathan at oracle.com Fri Oct 17 04:01:45 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 17 Oct 2014 09:31:45 +0530 Subject: ScriptObjectMirrors In-Reply-To: <544092A0.3000304@gmail.com> References: <543FCBB5.8090200@oracle.com> <544092A0.3000304@gmail.com> Message-ID: <544094A9.5030407@oracle.com> There is no notion of wrap/unwrap of user implemented JSObject - so those won't be affected. JSObject itself is just another Java type and so would be between script and Java code "as is". Only for Object param types of Java methods will receive wrapped ScriptObjects - argument filter will be inserted for such parameters. Actually a filter is already installed for such params to handle ConsString objects - so ScriptObject wrapping is just another incremental check+wrap in that filter. And Object returning Java methods will have unwrapper filter on return value (on the script side). Other Java parameter types/return type should not be affected at all. Providing another command line option implies we keep checking it in argument/return type filter methods - which would be costly. -Sundar On Friday 17 October 2014 09:23 AM, Serguei Mourachov wrote: > Sundar > > Will it also affect classes implementing JSObject? > IMO, we should have an option to disable this wrap/unwrap behavior in > cases when it significantly affecting performance. > > SM > > On 10/16/2014 6:44 AM, A. Sundararajan wrote: >> There were many questions in this list and elsewhere on >> ScriptObjectMirror. This email is to clarify those. >> >> Nashorn represents JavaScript objects as instances of implementation >> class called jdk.nashorn.internal.runtime.ScriptObject or one of it's >> subclasses (like NativeArray, NativeRegExp etc. - or even generated >> ones like jdk.nashorn.internal.scripts.JO4 etc) >> >> When ScriptObjects are returned from a script function or evaluated >> script code, ScriptEngine.eval returns an instanceof >> jdk.nashorn.api.scripting.ScriptObjectMirror. >> >> http://cr.openjdk.java.net/~sundar/jdk.nashorn.api/9/javadoc/jdk/nashorn/api/scripting/ScriptObjectMirror.html >> >> >> Example: >> >> ScriptEngine e = new >> ScriptEngineManager().getEngineByName("nashorn"); >> Object obj = e.eval("var obj = { foo: 23 }"); // obj is an >> instance of ScriptObjectMirror >> >> Caller can cast the result to ScriptObjectMirror to access properties >> of that script object or call methods on it. All javax.script >> interface methods returning Object (ScriptEngine.eval, >> Invocable.invokeFunction, Invocable.invokeMethod) return >> ScriptObjectMirror if underlying script or script function/method >> returns a JS object. >> >> But, if you call any Java method accepting Object type param or >> assign to element of Object[], then Nashorn was not wrapping >> ScriptObject in the past. i.e., 'raw' ScriptObject (or subclass) >> instances "escaped" to Java layer. If you try to cast those to >> ScriptObjectMirror from Java code, you got ClassCastException. Also, >> if you passed such raw object as "self" parameter for >> Invocable.invokeMethod, you would IllegalArgumentException. This was >> causing a lot of confusion - script objects got to java code >> sometimes as wrapped mirror objects and sometimes as 'raw' objects! >> >> With a recent change >> >> http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a8d44c7c2ac0 >> >> in jdk9 and the corresponding backport to jdk8u-dev >> >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/a35c8136c045 >> >> the way nashorn wraps internal ScriptObjects to ScriptObjectMirror >> has changed. Script objects are always wrapped to ScriptObjectMirror >> - even when you're calling Java method that accepts "Object" type >> value. Also, return values from java methods returning Object are >> "unwrapped" (if the return value is a ScriptObjectMirror) when it >> gets to script execution. >> >> Example: >> >> // list gets ScriptObjectMirror as element >> engine.eval("var m = new java.util.HashMap(); l.put('myobj', { >> foo: 33 });"); >> engine.eval("var obj = m.get('myobj'); // obj gets unwrapped as >> ScriptObject here"); >> >> With this change, raw ScriptObjects don't escape to Java layer at all. >> >> Hope this helps, >> -Sundar > From smourachov at gmail.com Fri Oct 17 04:12:09 2014 From: smourachov at gmail.com (Serguei Mourachov) Date: Thu, 16 Oct 2014 21:12:09 -0700 Subject: ScriptObjectMirrors In-Reply-To: <544094A9.5030407@oracle.com> References: <543FCBB5.8090200@oracle.com> <544092A0.3000304@gmail.com> <544094A9.5030407@oracle.com> Message-ID: <54409719.7080808@gmail.com> I mean methods of JSObject such as (get/set)(Member/Slot) and call(). I hope object passed to/from those will not be wrapped/unwrapped, although the are technically Java methods . SM On 10/16/2014 9:01 PM, A. Sundararajan wrote: > There is no notion of wrap/unwrap of user implemented JSObject - so > those won't be affected. JSObject itself is just another Java type and > so would be between script and Java code "as is". > > Only for Object param types of Java methods will receive wrapped > ScriptObjects - argument filter will be inserted for such parameters. > Actually a filter is already installed for such params to handle > ConsString objects - so ScriptObject wrapping is just another > incremental check+wrap in that filter. And Object returning Java > methods will have unwrapper filter on return value (on the script > side). Other Java parameter types/return type should not be affected > at all. Providing another command line option implies we keep checking > it in argument/return type filter methods - which would be costly. > > -Sundar > > On Friday 17 October 2014 09:23 AM, Serguei Mourachov wrote: >> Sundar >> >> Will it also affect classes implementing JSObject? >> IMO, we should have an option to disable this wrap/unwrap behavior in >> cases when it significantly affecting performance. >> >> SM >> >> On 10/16/2014 6:44 AM, A. Sundararajan wrote: >>> There were many questions in this list and elsewhere on >>> ScriptObjectMirror. This email is to clarify those. >>> >>> Nashorn represents JavaScript objects as instances of implementation >>> class called jdk.nashorn.internal.runtime.ScriptObject or one of >>> it's subclasses (like NativeArray, NativeRegExp etc. - or even >>> generated ones like jdk.nashorn.internal.scripts.JO4 etc) >>> >>> When ScriptObjects are returned from a script function or evaluated >>> script code, ScriptEngine.eval returns an instanceof >>> jdk.nashorn.api.scripting.ScriptObjectMirror. >>> >>> http://cr.openjdk.java.net/~sundar/jdk.nashorn.api/9/javadoc/jdk/nashorn/api/scripting/ScriptObjectMirror.html >>> >>> >>> Example: >>> >>> ScriptEngine e = new >>> ScriptEngineManager().getEngineByName("nashorn"); >>> Object obj = e.eval("var obj = { foo: 23 }"); // obj is an >>> instance of ScriptObjectMirror >>> >>> Caller can cast the result to ScriptObjectMirror to access >>> properties of that script object or call methods on it. All >>> javax.script interface methods returning Object (ScriptEngine.eval, >>> Invocable.invokeFunction, Invocable.invokeMethod) return >>> ScriptObjectMirror if underlying script or script function/method >>> returns a JS object. >>> >>> But, if you call any Java method accepting Object type param or >>> assign to element of Object[], then Nashorn was not wrapping >>> ScriptObject in the past. i.e., 'raw' ScriptObject (or subclass) >>> instances "escaped" to Java layer. If you try to cast those to >>> ScriptObjectMirror from Java code, you got ClassCastException. Also, >>> if you passed such raw object as "self" parameter for >>> Invocable.invokeMethod, you would IllegalArgumentException. This was >>> causing a lot of confusion - script objects got to java code >>> sometimes as wrapped mirror objects and sometimes as 'raw' objects! >>> >>> With a recent change >>> >>> http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a8d44c7c2ac0 >>> >>> in jdk9 and the corresponding backport to jdk8u-dev >>> >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/a35c8136c045 >>> >>> the way nashorn wraps internal ScriptObjects to ScriptObjectMirror >>> has changed. Script objects are always wrapped to ScriptObjectMirror >>> - even when you're calling Java method that accepts "Object" type >>> value. Also, return values from java methods returning Object are >>> "unwrapped" (if the return value is a ScriptObjectMirror) when it >>> gets to script execution. >>> >>> Example: >>> >>> // list gets ScriptObjectMirror as element >>> engine.eval("var m = new java.util.HashMap(); l.put('myobj', { >>> foo: 33 });"); >>> engine.eval("var obj = m.get('myobj'); // obj gets unwrapped as >>> ScriptObject here"); >>> >>> With this change, raw ScriptObjects don't escape to Java layer at all. >>> >>> Hope this helps, >>> -Sundar >> > From sundararajan.athijegannathan at oracle.com Fri Oct 17 04:35:08 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 17 Oct 2014 10:05:08 +0530 Subject: ScriptObjectMirrors In-Reply-To: <54409719.7080808@gmail.com> References: <543FCBB5.8090200@oracle.com> <544092A0.3000304@gmail.com> <544094A9.5030407@oracle.com> <54409719.7080808@gmail.com> Message-ID: <54409C7C.3070907@oracle.com> I need to check that out. But, is there any specific reason why it should be different? User implemented JSObject receives Object (for set, call) and returns Object. If script object is passed as argument to those, do you think that should be wrapped as mirror? if so, why? -Sundar On Friday 17 October 2014 09:42 AM, Serguei Mourachov wrote: > I mean methods of JSObject such as (get/set)(Member/Slot) and call(). > I hope object passed to/from those will not be wrapped/unwrapped, > although the are technically Java methods . > > SM > > On 10/16/2014 9:01 PM, A. Sundararajan wrote: >> There is no notion of wrap/unwrap of user implemented JSObject - so >> those won't be affected. JSObject itself is just another Java type >> and so would be between script and Java code "as is". >> >> Only for Object param types of Java methods will receive wrapped >> ScriptObjects - argument filter will be inserted for such parameters. >> Actually a filter is already installed for such params to handle >> ConsString objects - so ScriptObject wrapping is just another >> incremental check+wrap in that filter. And Object returning Java >> methods will have unwrapper filter on return value (on the script >> side). Other Java parameter types/return type should not be affected >> at all. Providing another command line option implies we keep >> checking it in argument/return type filter methods - which would be >> costly. >> >> -Sundar >> >> On Friday 17 October 2014 09:23 AM, Serguei Mourachov wrote: >>> Sundar >>> >>> Will it also affect classes implementing JSObject? >>> IMO, we should have an option to disable this wrap/unwrap behavior >>> in cases when it significantly affecting performance. >>> >>> SM >>> >>> On 10/16/2014 6:44 AM, A. Sundararajan wrote: >>>> There were many questions in this list and elsewhere on >>>> ScriptObjectMirror. This email is to clarify those. >>>> >>>> Nashorn represents JavaScript objects as instances of >>>> implementation class called >>>> jdk.nashorn.internal.runtime.ScriptObject or one of it's subclasses >>>> (like NativeArray, NativeRegExp etc. - or even generated ones like >>>> jdk.nashorn.internal.scripts.JO4 etc) >>>> >>>> When ScriptObjects are returned from a script function or evaluated >>>> script code, ScriptEngine.eval returns an instanceof >>>> jdk.nashorn.api.scripting.ScriptObjectMirror. >>>> >>>> http://cr.openjdk.java.net/~sundar/jdk.nashorn.api/9/javadoc/jdk/nashorn/api/scripting/ScriptObjectMirror.html >>>> >>>> >>>> Example: >>>> >>>> ScriptEngine e = new >>>> ScriptEngineManager().getEngineByName("nashorn"); >>>> Object obj = e.eval("var obj = { foo: 23 }"); // obj is an >>>> instance of ScriptObjectMirror >>>> >>>> Caller can cast the result to ScriptObjectMirror to access >>>> properties of that script object or call methods on it. All >>>> javax.script interface methods returning Object (ScriptEngine.eval, >>>> Invocable.invokeFunction, Invocable.invokeMethod) return >>>> ScriptObjectMirror if underlying script or script function/method >>>> returns a JS object. >>>> >>>> But, if you call any Java method accepting Object type param or >>>> assign to element of Object[], then Nashorn was not wrapping >>>> ScriptObject in the past. i.e., 'raw' ScriptObject (or subclass) >>>> instances "escaped" to Java layer. If you try to cast those to >>>> ScriptObjectMirror from Java code, you got ClassCastException. >>>> Also, if you passed such raw object as "self" parameter for >>>> Invocable.invokeMethod, you would IllegalArgumentException. This >>>> was causing a lot of confusion - script objects got to java code >>>> sometimes as wrapped mirror objects and sometimes as 'raw' objects! >>>> >>>> With a recent change >>>> >>>> http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a8d44c7c2ac0 >>>> >>>> in jdk9 and the corresponding backport to jdk8u-dev >>>> >>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/a35c8136c045 >>>> >>>> the way nashorn wraps internal ScriptObjects to ScriptObjectMirror >>>> has changed. Script objects are always wrapped to >>>> ScriptObjectMirror - even when you're calling Java method that >>>> accepts "Object" type value. Also, return values from java methods >>>> returning Object are "unwrapped" (if the return value is a >>>> ScriptObjectMirror) when it gets to script execution. >>>> >>>> Example: >>>> >>>> // list gets ScriptObjectMirror as element >>>> engine.eval("var m = new java.util.HashMap(); l.put('myobj', { >>>> foo: 33 });"); >>>> engine.eval("var obj = m.get('myobj'); // obj gets unwrapped as >>>> ScriptObject here"); >>>> >>>> With this change, raw ScriptObjects don't escape to Java layer at all. >>>> >>>> Hope this helps, >>>> -Sundar >>> >> > From smourachov at gmail.com Fri Oct 17 05:12:37 2014 From: smourachov at gmail.com (Serguei Mourachov) Date: Thu, 16 Oct 2014 22:12:37 -0700 Subject: ScriptObjectMirrors In-Reply-To: <54409C7C.3070907@oracle.com> References: <543FCBB5.8090200@oracle.com> <544092A0.3000304@gmail.com> <544094A9.5030407@oracle.com> <54409719.7080808@gmail.com> <54409C7C.3070907@oracle.com> Message-ID: <5440A545.6000805@gmail.com> I *don't think* there should be any (un)wrapping applied to JSObject method calls. The api doc says: "Nashorn will treat objects of such classes just like nashorn script objects." And, personally, I'm fine with that. That will allow me to provide more efficient implementation of java objects injected inside the script environment. I understand the motivation to use (un)wrapping everywhere when crossing Java/JS boundary, but in my particular use-case, where JS is doing a lot of object manipulation and computation, using java objects provided by my code(mainly Maps ans Lists), all the (un)wrapping could be very expensive. SM On 10/16/2014 9:35 PM, A. Sundararajan wrote: > I need to check that out. But, is there any specific reason why it > should be different? User implemented JSObject receives Object (for > set, call) and returns Object. If script object is passed as argument > to those, do you think that should be wrapped as mirror? if so, why? > > -Sundar > > On Friday 17 October 2014 09:42 AM, Serguei Mourachov wrote: >> I mean methods of JSObject such as (get/set)(Member/Slot) and >> call(). I hope object passed to/from those will not be >> wrapped/unwrapped, although the are technically Java methods . >> >> SM >> >> On 10/16/2014 9:01 PM, A. Sundararajan wrote: >>> There is no notion of wrap/unwrap of user implemented JSObject - so >>> those won't be affected. JSObject itself is just another Java type >>> and so would be between script and Java code "as is". >>> >>> Only for Object param types of Java methods will receive wrapped >>> ScriptObjects - argument filter will be inserted for such >>> parameters. Actually a filter is already installed for such params >>> to handle ConsString objects - so ScriptObject wrapping is just >>> another incremental check+wrap in that filter. And Object returning >>> Java methods will have unwrapper filter on return value (on the >>> script side). Other Java parameter types/return type should not be >>> affected at all. Providing another command line option implies we >>> keep checking it in argument/return type filter methods - which >>> would be costly. >>> >>> -Sundar >>> >>> On Friday 17 October 2014 09:23 AM, Serguei Mourachov wrote: >>>> Sundar >>>> >>>> Will it also affect classes implementing JSObject? >>>> IMO, we should have an option to disable this wrap/unwrap behavior >>>> in cases when it significantly affecting performance. >>>> >>>> SM >>>> >>>> On 10/16/2014 6:44 AM, A. Sundararajan wrote: >>>>> There were many questions in this list and elsewhere on >>>>> ScriptObjectMirror. This email is to clarify those. >>>>> >>>>> Nashorn represents JavaScript objects as instances of >>>>> implementation class called >>>>> jdk.nashorn.internal.runtime.ScriptObject or one of it's >>>>> subclasses (like NativeArray, NativeRegExp etc. - or even >>>>> generated ones like jdk.nashorn.internal.scripts.JO4 etc) >>>>> >>>>> When ScriptObjects are returned from a script function or >>>>> evaluated script code, ScriptEngine.eval returns an instanceof >>>>> jdk.nashorn.api.scripting.ScriptObjectMirror. >>>>> >>>>> http://cr.openjdk.java.net/~sundar/jdk.nashorn.api/9/javadoc/jdk/nashorn/api/scripting/ScriptObjectMirror.html >>>>> >>>>> >>>>> Example: >>>>> >>>>> ScriptEngine e = new >>>>> ScriptEngineManager().getEngineByName("nashorn"); >>>>> Object obj = e.eval("var obj = { foo: 23 }"); // obj is an >>>>> instance of ScriptObjectMirror >>>>> >>>>> Caller can cast the result to ScriptObjectMirror to access >>>>> properties of that script object or call methods on it. All >>>>> javax.script interface methods returning Object >>>>> (ScriptEngine.eval, Invocable.invokeFunction, >>>>> Invocable.invokeMethod) return ScriptObjectMirror if underlying >>>>> script or script function/method returns a JS object. >>>>> >>>>> But, if you call any Java method accepting Object type param or >>>>> assign to element of Object[], then Nashorn was not wrapping >>>>> ScriptObject in the past. i.e., 'raw' ScriptObject (or subclass) >>>>> instances "escaped" to Java layer. If you try to cast those to >>>>> ScriptObjectMirror from Java code, you got ClassCastException. >>>>> Also, if you passed such raw object as "self" parameter for >>>>> Invocable.invokeMethod, you would IllegalArgumentException. This >>>>> was causing a lot of confusion - script objects got to java code >>>>> sometimes as wrapped mirror objects and sometimes as 'raw' objects! >>>>> >>>>> With a recent change >>>>> >>>>> http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/a8d44c7c2ac0 >>>>> >>>>> in jdk9 and the corresponding backport to jdk8u-dev >>>>> >>>>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/rev/a35c8136c045 >>>>> >>>>> the way nashorn wraps internal ScriptObjects to ScriptObjectMirror >>>>> has changed. Script objects are always wrapped to >>>>> ScriptObjectMirror - even when you're calling Java method that >>>>> accepts "Object" type value. Also, return values from java methods >>>>> returning Object are "unwrapped" (if the return value is a >>>>> ScriptObjectMirror) when it gets to script execution. >>>>> >>>>> Example: >>>>> >>>>> // list gets ScriptObjectMirror as element >>>>> engine.eval("var m = new java.util.HashMap(); l.put('myobj', { >>>>> foo: 33 });"); >>>>> engine.eval("var obj = m.get('myobj'); // obj gets unwrapped >>>>> as ScriptObject here"); >>>>> >>>>> With this change, raw ScriptObjects don't escape to Java layer at >>>>> all. >>>>> >>>>> Hope this helps, >>>>> -Sundar >>>> >>> >> > From hannes.wallnoefer at oracle.com Fri Oct 17 12:23:46 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 17 Oct 2014 14:23:46 +0200 Subject: Review request for JDK-8059844 In-Reply-To: <040FF823-8635-45AF-95AB-92BDAC8C679B@oracle.com> References: <040FF823-8635-45AF-95AB-92BDAC8C679B@oracle.com> Message-ID: <54410A52.90206@oracle.com> +1 for webrev.02. Good work keeping recompilation overhead at reasonable levels! Hannes Am 2014-10-07 um 13:52 schrieb Attila Szegedi: > Please review JDK-8059844 at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon Oct 20 04:22:30 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 20 Oct 2014 09:52:30 +0530 Subject: RFR 8061257: nashorn ant build script should have a sanity target Message-ID: <54448E06.2070107@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8061257/ for https://bugs.openjdk.java.net/browse/JDK-8061257 Thanks, -Sundar From marcus.lagergren at oracle.com Mon Oct 20 06:13:15 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 20 Oct 2014 10:13:15 +0400 Subject: RFR 8061257: nashorn ant build script should have a sanity target In-Reply-To: <54448E06.2070107@oracle.com> References: <54448E06.2070107@oracle.com> Message-ID: Look good, Sundar! +1 /M On 20 Oct 2014, at 08:22, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8061257/ for https://bugs.openjdk.java.net/browse/JDK-8061257 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Mon Oct 20 06:45:53 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 20 Oct 2014 08:45:53 +0200 Subject: RFR 8061257: nashorn ant build script should have a sanity target In-Reply-To: <54448E06.2070107@oracle.com> References: <54448E06.2070107@oracle.com> Message-ID: <5444AFA1.8010302@oracle.com> +1 I tested and it builds correctly with jdk8 and 9 and reports the proper error with jdk7. Hannes Am 2014-10-20 um 06:22 schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8061257/ for > https://bugs.openjdk.java.net/browse/JDK-8061257 > > Thanks, > -Sundar From attila.szegedi at oracle.com Mon Oct 20 07:56:00 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 20 Oct 2014 09:56:00 +0200 Subject: RFR 8061257: nashorn ant build script should have a sanity target In-Reply-To: <54448E06.2070107@oracle.com> References: <54448E06.2070107@oracle.com> Message-ID: +1 On Oct 20, 2014, at 6:22 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8061257/ for https://bugs.openjdk.java.net/browse/JDK-8061257 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Mon Oct 20 08:33:57 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 20 Oct 2014 10:33:57 +0200 Subject: Review request for JDK-8060724 Message-ID: <5444C8F5.50601@oracle.com> Please review JDK-8060724: ant test262parallel in Nashorn spends a significant amount of time after almost all the tests are run: http://cr.openjdk.java.net/~hannesw/8060724/ This should speed up ant test262parallel significantly. On my computer it goes from 25 minutes down to 14 minutes. Thanks, Hannes From attila.szegedi at oracle.com Mon Oct 20 09:13:19 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 20 Oct 2014 11:13:19 +0200 Subject: Review request for JDK-8060724 In-Reply-To: <5444C8F5.50601@oracle.com> References: <5444C8F5.50601@oracle.com> Message-ID: +1 On Oct 20, 2014, at 10:33 AM, Hannes Wallnoefer wrote: > Please review JDK-8060724: ant test262parallel in Nashorn spends a significant amount of time after almost all the tests are run: > > http://cr.openjdk.java.net/~hannesw/8060724/ > > This should speed up ant test262parallel significantly. On my computer it goes from 25 minutes down to 14 minutes. > > Thanks, > Hannes From marcus.lagergren at oracle.com Mon Oct 20 09:25:34 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 20 Oct 2014 13:25:34 +0400 Subject: Review request for JDK-8060724 In-Reply-To: <5444C8F5.50601@oracle.com> References: <5444C8F5.50601@oracle.com> Message-ID: <3A8EE138-435E-4CB8-8070-6329343581C5@oracle.com> +1. Is it necessary with the ClassInstaller changes as well, if we patch the thread could to be max 4? Regards Marcus On 20 Oct 2014, at 12:33, Hannes Wallnoefer wrote: > Please review JDK-8060724: ant test262parallel in Nashorn spends a significant amount of time after almost all the tests are run: > > http://cr.openjdk.java.net/~hannesw/8060724/ > > This should speed up ant test262parallel significantly. On my computer it goes from 25 minutes down to 14 minutes. > > Thanks, > Hannes From attila.szegedi at oracle.com Mon Oct 20 10:48:07 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 20 Oct 2014 12:48:07 +0200 Subject: Review request for JDK-8059844 In-Reply-To: <54410A52.90206@oracle.com> References: <040FF823-8635-45AF-95AB-92BDAC8C679B@oracle.com> <54410A52.90206@oracle.com> Message-ID: Folks, I had to make minor adjustments for this patch when backporting it to 8. The reason is that constructors for FunctionNode differ in 9 and 8 after JDK-8012518 (bottom up parser), which is a 9-only change (and so the divergence begins?) A difference between the 9 and 8 codebase is available at . Could you please review it? It's only a change in the modified constructors' invocations. Thanks, Attila. On Oct 17, 2014, at 2:23 PM, Hannes Wallnoefer wrote: > +1 for webrev.02. Good work keeping recompilation overhead at reasonable levels! > > Hannes > > Am 2014-10-07 um 13:52 schrieb Attila Szegedi: >> Please review JDK-8059844 at for >> >> Thanks, >> Attila. > From marcus.lagergren at oracle.com Mon Oct 20 10:51:57 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 20 Oct 2014 14:51:57 +0400 Subject: Review request for JDK-8059844 In-Reply-To: References: <040FF823-8635-45AF-95AB-92BDAC8C679B@oracle.com> <54410A52.90206@oracle.com> Message-ID: +1. Sad that the code base diversification between 8 and 9 begins now ? /M On 20 Oct 2014, at 14:48, Attila Szegedi wrote: > Folks, > > I had to make minor adjustments for this patch when backporting it to 8. The reason is that constructors for FunctionNode differ in 9 and 8 after JDK-8012518 (bottom up parser), which is a 9-only change (and so the divergence begins?) > > A difference between the 9 and 8 codebase is available at . Could you please review it? It's only a change in the modified constructors' invocations. > > Thanks, > Attila. > > On Oct 17, 2014, at 2:23 PM, Hannes Wallnoefer wrote: > >> +1 for webrev.02. Good work keeping recompilation overhead at reasonable levels! >> >> Hannes >> >> Am 2014-10-07 um 13:52 schrieb Attila Szegedi: >>> Please review JDK-8059844 at for >>> >>> Thanks, >>> Attila. >> > From hannes.wallnoefer at oracle.com Mon Oct 20 11:57:13 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 20 Oct 2014 13:57:13 +0200 Subject: Review request for JDK-8060724 In-Reply-To: <3A8EE138-435E-4CB8-8070-6329343581C5@oracle.com> References: <5444C8F5.50601@oracle.com> <3A8EE138-435E-4CB8-8070-6329343581C5@oracle.com> Message-ID: <5444F899.3090403@oracle.com> Am 2014-10-20 um 11:25 schrieb Marcus Lagergren: > +1. > > Is it necessary with the ClassInstaller changes as well, if we patch the thread could to be max 4? It's not strictly necessary, but with higher thread counts you'll still hit parallel class installation limits, resulting in slower execution. If you have more than 4 cores you can find out what number of threads works best for you by running: ant -Dtest262-test-sys-prop.test.js.threads=<#ofthreads> test262parallel Let me know if something higher than 4 works better. Hannes > Regards > Marcus > > > On 20 Oct 2014, at 12:33, Hannes Wallnoefer wrote: > >> Please review JDK-8060724: ant test262parallel in Nashorn spends a significant amount of time after almost all the tests are run: >> >> http://cr.openjdk.java.net/~hannesw/8060724/ >> >> This should speed up ant test262parallel significantly. On my computer it goes from 25 minutes down to 14 minutes. >> >> Thanks, >> Hannes From sundararajan.athijegannathan at oracle.com Mon Oct 20 12:13:20 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 20 Oct 2014 17:43:20 +0530 Subject: Review request for JDK-8060724 In-Reply-To: <5444C8F5.50601@oracle.com> References: <5444C8F5.50601@oracle.com> Message-ID: <5444FC60.9030409@oracle.com> +1 On Monday 20 October 2014 02:03 PM, Hannes Wallnoefer wrote: > Please review JDK-8060724: ant test262parallel in Nashorn spends a > significant amount of time after almost all the tests are run: > > http://cr.openjdk.java.net/~hannesw/8060724/ > > This should speed up ant test262parallel significantly. On my computer > it goes from 25 minutes down to 14 minutes. > > Thanks, > Hannes From james.laskey at oracle.com Mon Oct 20 12:36:25 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 20 Oct 2014 09:36:25 -0300 Subject: Review request for JDK-8060724 In-Reply-To: <5444C8F5.50601@oracle.com> References: <5444C8F5.50601@oracle.com> Message-ID: <006AB785-640A-4C5A-80FA-67D10ADD1A8D@oracle.com> +1 On Oct 20, 2014, at 5:33 AM, Hannes Wallnoefer wrote: > Please review JDK-8060724: ant test262parallel in Nashorn spends a significant amount of time after almost all the tests are run: > > http://cr.openjdk.java.net/~hannesw/8060724/ > > This should speed up ant test262parallel significantly. On my computer it goes from 25 minutes down to 14 minutes. > > Thanks, > Hannes From marcus.lagergren at oracle.com Tue Oct 21 06:38:47 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 21 Oct 2014 10:38:47 +0400 Subject: Review request for JDK-8060724 In-Reply-To: <5444F899.3090403@oracle.com> References: <5444C8F5.50601@oracle.com> <3A8EE138-435E-4CB8-8070-6329343581C5@oracle.com> <5444F899.3090403@oracle.com> Message-ID: <63D4ACAF-82FA-4C30-9F61-DDF16A36B577@oracle.com> I was wondering if we can get more throughput by using a class installation queue so that that different threads don?t try to smash through the system dictionary at the same time. It will still be slow and block, but at least we know it can be serialized. On 20 Oct 2014, at 15:57, Hannes Wallnoefer wrote: > Am 2014-10-20 um 11:25 schrieb Marcus Lagergren: >> +1. >> >> Is it necessary with the ClassInstaller changes as well, if we patch the thread could to be max 4? > > It's not strictly necessary, but with higher thread counts you'll still hit parallel class installation limits, resulting in slower execution. > > If you have more than 4 cores you can find out what number of threads works best for you by running: > > ant -Dtest262-test-sys-prop.test.js.threads=<#ofthreads> test262parallel > > Let me know if something higher than 4 works better. > > Hannes > >> Regards >> Marcus >> >> >> On 20 Oct 2014, at 12:33, Hannes Wallnoefer wrote: >> >>> Please review JDK-8060724: ant test262parallel in Nashorn spends a significant amount of time after almost all the tests are run: >>> >>> http://cr.openjdk.java.net/~hannesw/8060724/ >>> >>> This should speed up ant test262parallel significantly. On my computer it goes from 25 minutes down to 14 minutes. >>> >>> Thanks, >>> Hannes > From attila.szegedi at oracle.com Tue Oct 21 10:46:28 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 21 Oct 2014 12:46:28 +0200 Subject: Review request for JDK-8058610 Message-ID: Please review JDK-8058610 at for Thanks, Attila. From marcus.lagergren at oracle.com Tue Oct 21 11:31:15 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 21 Oct 2014 15:31:15 +0400 Subject: Review request for JDK-8058610 In-Reply-To: References: Message-ID: An example in this comment would have helped me understand this sooner. Maybe you can add one? It would be appreciated. + // Can reorder, but can't move conversion into the operand as the operation depends on operands + // exact types for its overflow guarantees. Can these be private? + static Type booleanToInt(final Type t) { + return t == Type.BOOLEAN ? Type.INT : t; + } + + static Type objectToNumber(final Type t) { + return t.isObject() ? Type.NUMBER : t; + } Wasn?t it possible by solving this by always using an indy lmul(jj)j that might throw an UnwarrantedOptimismException containing a double, or is it too expensive to introduce the 53 bit check logic there? Are we using lmul(jj)j elsewhere and not checking this? Otherwise +1 Regards Marcus On 21 Oct 2014, at 14:46, Attila Szegedi wrote: > Please review JDK-8058610 at for > > Thanks, > Attila. From james.laskey at oracle.com Tue Oct 21 11:57:57 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 21 Oct 2014 08:57:57 -0300 Subject: Review request for JDK-8058610 In-Reply-To: References: Message-ID: +1 On Oct 21, 2014, at 7:46 AM, Attila Szegedi wrote: > Please review JDK-8058610 at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Tue Oct 21 12:03:13 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 21 Oct 2014 14:03:13 +0200 Subject: Review request for JDK-8058610 In-Reply-To: References: Message-ID: <54464B81.6060405@oracle.com> +1 Am 2014-10-21 um 12:46 schrieb Attila Szegedi: > Please review JDK-8058610 at for > > Thanks, > Attila. From attila.szegedi at oracle.com Tue Oct 21 12:18:43 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 21 Oct 2014 14:18:43 +0200 Subject: Review request for JDK-8058610 In-Reply-To: References: Message-ID: On Oct 21, 2014, at 1:31 PM, Marcus Lagergren wrote: > An example in this comment would have helped me understand this sooner. Maybe you can add one? It would be appreciated. > + // Can reorder, but can't move conversion into the operand as the operation depends on operands > + // exact types for its overflow guarantees. Modified it to: // Can reorder, but can't move conversion into the operand as the operation depends on operands // exact types for its overflow guarantees. E.g. with {L}{%I}expr1 {L}* {L}{%I}expr2 we are not allowed // to merge {L}{%I} into {%L}, as that can cause subsequent overflows; test for JDK-8058610 contains // concrete cases where this could happen. > Can these be private? They can, but then javac will add synthetic package-private accessors for access from CodeGenerator$TypeBounds. Matter of style, FWIW. I'll "privatize" them. > > + static Type booleanToInt(final Type t) { > + return t == Type.BOOLEAN ? Type.INT : t; > + } > + > + static Type objectToNumber(final Type t) { > + return t.isObject() ? Type.NUMBER : t; > + } > > Wasn?t it possible by solving this by always using an indy lmul(jj)j that might throw an UnwarrantedOptimismException containing a double, or is it too expensive to introduce the 53 bit check logic there? Yes, it is possible (I say as much in this comment: ), but it'd require a more extensive modification of code generator that I'd rather not embark on now. Namely, CodeGenerator.OptimisticOperation has an elaborate criteria for deciding whether it should indeed be optimistic or not (see setting of the isOptimistic flag in its constructor), and it'd have to accommodate the special case of BinaryNodes for arithmetic operations then. > Are we using lmul(jj)j elsewhere and not checking this? No. CodeGenerator's loadMUL and loadASSIGN_MUL are the only cases, and they're covered. FWIW, the tests exercise ADD, SUB, and MUL operations, as this was not constrained to multiplication only. Division and modulo are unaffected as they were treated as special cases anyway, as even without overflowing their results can lead out of the set of integral numbers into floating point numbers. > > Otherwise +1 > > Regards > Marcus > > > On 21 Oct 2014, at 14:46, Attila Szegedi wrote: > >> Please review JDK-8058610 at for >> >> Thanks, >> Attila. > From marcus.lagergren at oracle.com Wed Oct 22 15:34:43 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 22 Oct 2014 08:34:43 -0700 (PDT) Subject: Please review JDK-8061391 Message-ID: <342ce688-e103-429e-9788-24bc72c95d3b@default> Please review this I added specialized builtins for concat, which are up to 10 times faster in microbenchmarks with just one element (or array) being concatenated. While doing this I happened upon some bugs with preventExtensions for arrays, and removed the hateful unreliable SwitchPoint from ContinuousArray, replacing non extensible arrays with an ArrayFilter, which is the way I should have done it in the first place. I also had to turn NoTypedArrayData into a structure that inherited ContinuousArray, or I threw away a lot of optimistic link sites to untouched arrays in ScriptObjects. This has other performance implications (good ones). ant test runs cleanly ant test262parallel runs cleanly octane runs with no regressions, some benchmarks like raytrace and crypto are even a bit faster. There are regressions in octane since the last time I checked, but not due to my fix. I will investigate and file bugs. Bug: https://bugs.openjdk.java.net/browse/JDK-8061391 Webrev: http://cr.openjdk.java.net/~lagergren/8061391/ Regards Marcus From attila.szegedi at oracle.com Wed Oct 22 16:15:07 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 22 Oct 2014 18:15:07 +0200 Subject: Review request for JDK-8061391 Message-ID: <390AE754-737C-487E-B247-7B4B6EDD665B@oracle.com> I'm posting this review request on behalf of Marcus, who's stuck with very unreliable internet connection in a hotel in Russia. Please review JDK-8061391 at for Thanks, Attila. From attila.szegedi at oracle.com Wed Oct 22 16:16:40 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 22 Oct 2014 18:16:40 +0200 Subject: Review request for JDK-8061391 In-Reply-To: <390AE754-737C-487E-B247-7B4B6EDD665B@oracle.com> References: <390AE754-737C-487E-B247-7B4B6EDD665B@oracle.com> Message-ID: Nevermind, Marcus apparently managed to send it out in the meantime; answer with reviews to his original message from about 45 minutes ago instead. On Oct 22, 2014, at 6:15 PM, Attila Szegedi wrote: > I'm posting this review request on behalf of Marcus, who's stuck with very unreliable internet connection in a hotel in Russia. > > Please review JDK-8061391 at for > > Thanks, > Attila. > From hannes.wallnoefer at oracle.com Wed Oct 22 16:34:31 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 22 Oct 2014 18:34:31 +0200 Subject: Review request for JDK-8059813: Type Info Cache flag must must be documented Message-ID: <5447DC97.5000502@oracle.com> Please review JDK-8059813: Type Info Cache flag must must be documented: http://cr.openjdk.java.net/~hannesw/8059813/ Thanks, Hannes From hannes.wallnoefer at oracle.com Wed Oct 22 16:34:52 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 22 Oct 2014 18:34:52 +0200 Subject: Review request for JDK-8059814: jjs -help and document on OTN about jjs should be the same Message-ID: <5447DCAC.1040505@oracle.com> Please review JDK-8059814: jjs -help and document on OTN about jjs should be the same: http://cr.openjdk.java.net/~hannesw/8059814/ Thanks, Hannes From attila.szegedi at oracle.com Wed Oct 22 17:13:31 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 22 Oct 2014 19:13:31 +0200 Subject: Review request for JDK-8059813: Type Info Cache flag must must be documented In-Reply-To: <5447DC97.5000502@oracle.com> References: <5447DC97.5000502@oracle.com> Message-ID: s/that make sure/that makes sure in DEVELOPER_README I'd maybe remove documentation for nashorn.typeInfo.disabled; I actually planned on removing that property, and let only nashorn.typeInfo.maxFiles govern whether it's enabled or disabled. Can we do that (even though the property is there?) nashorn.args.prepend: how about emphasizing that later options overwrite earlier ones, so .prepend is useful for setting defaults that can be overwritten Other than these remarks, +1. On Oct 22, 2014, at 6:34 PM, Hannes Wallnoefer wrote: > Please review JDK-8059813: Type Info Cache flag must must be documented: > > http://cr.openjdk.java.net/~hannesw/8059813/ > > Thanks, > Hannes From attila.szegedi at oracle.com Wed Oct 22 17:13:41 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 22 Oct 2014 19:13:41 +0200 Subject: Review request for JDK-8059814: jjs -help and document on OTN about jjs should be the same In-Reply-To: <5447DCAC.1040505@oracle.com> References: <5447DCAC.1040505@oracle.com> Message-ID: <6FA346C9-EA23-41D1-90A5-D5EF18A8C334@oracle.com> +1 On Oct 22, 2014, at 6:34 PM, Hannes Wallnoefer wrote: > Please review JDK-8059814: jjs -help and document on OTN about jjs should be the same: > > http://cr.openjdk.java.net/~hannesw/8059814/ > > Thanks, > Hannes From kishori.sharan at gmail.com Thu Oct 23 00:23:11 2014 From: kishori.sharan at gmail.com (Kishori Sharan) Date: Wed, 22 Oct 2014 19:23:11 -0500 Subject: Missing ArrayBuffer.isView() Method Message-ID: Hello, Why did Nashorn not implement the ArrayBuffer.isView() static method? The page at https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions describes that Nashorn implements the specification at https://www.khronos.org/registry/typedarray/specs/latest/ that conatins this method. However, this method is missing. The following statement throws an exception: ArrayBuffer.isView(new Int8Array(4)); Thanks Kishori From marcus.lagergren at oracle.com Wed Oct 22 15:08:50 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 22 Oct 2014 19:08:50 +0400 Subject: Please review JDK-8061391 Message-ID: Hi! Please review this! I added specialized builtins for concat, which are up to 10 times faster in microbenchmarks with just one element (or array) being concatenated. While doing this I happened upon some bugs with preventExtensions for arrays, and removed the hateful unreliable SwitchPoint from ContinuousArray, replacing non extensible arrays with an ArrayFilter, which is the way I should have done it in the first place. I also had to turn NoTypedArrayData into a structure that inherited ContinuousArray, or I threw away a lot of optimistic link sites to untouched arrays in ScriptObjects. This has other performance implications (good ones). ant test runs cleanly ant test262parallel runs cleanly octane runs with no regressions, some benchmarks like raytrace and crypto are even a bit faster. There are regressions in octane since the last time I checked, but not due to my fix. I will investigate and file bugs. Bug: https://bugs.openjdk.java.net/browse/JDK-8061391 Webrev: http://cr.openjdk.java.net/~lagergren/8061391/ Regards Marcus From marcus.lagergren at oracle.com Thu Oct 23 08:53:36 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 23 Oct 2014 12:53:36 +0400 Subject: Review request for JDK-8059814: jjs -help and document on OTN about jjs should be the same In-Reply-To: <5447DCAC.1040505@oracle.com> References: <5447DCAC.1040505@oracle.com> Message-ID: <3590DA8A-ED91-4554-8043-C0F60F59E958@oracle.com> Not approved. Rather you should remove the stuff from the OTN. We shall not expose any undocumented options outside -xhelp. Then we have to support them forever, even if they may lack complete relevance in the future, e.g. ?print-lower-parse. Regards Marcus On 22 Oct 2014, at 20:34, Hannes Wallnoefer wrote: > Please review JDK-8059814: jjs -help and document on OTN about jjs should be the same: > > http://cr.openjdk.java.net/~hannesw/8059814/ > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Thu Oct 23 09:01:06 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 23 Oct 2014 11:01:06 +0200 Subject: Review request for JDK-8059813: Type Info Cache flag must must be documented In-Reply-To: References: <5447DC97.5000502@oracle.com> Message-ID: <5448C3D2.5070108@oracle.com> Thanks Attila, I've uploaded a new webrev with the changes you suggested. http://cr.openjdk.java.net/~hannesw/8059813/webrev.01/ Hannes Am 2014-10-22 um 19:13 schrieb Attila Szegedi: > s/that make sure/that makes sure in DEVELOPER_README > > I'd maybe remove documentation for nashorn.typeInfo.disabled; I actually planned on removing that property, and let only nashorn.typeInfo.maxFiles govern whether it's enabled or disabled. Can we do that (even though the property is there?) > > nashorn.args.prepend: how about emphasizing that later options overwrite earlier ones, so .prepend is useful for setting defaults that can be overwritten > > Other than these remarks, +1. > > > On Oct 22, 2014, at 6:34 PM, Hannes Wallnoefer wrote: > >> Please review JDK-8059813: Type Info Cache flag must must be documented: >> >> http://cr.openjdk.java.net/~hannesw/8059813/ >> >> Thanks, >> Hannes From attila.szegedi at oracle.com Thu Oct 23 09:28:03 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 23 Oct 2014 11:28:03 +0200 Subject: Review request for JDK-8059813: Type Info Cache flag must must be documented In-Reply-To: <5448C3D2.5070108@oracle.com> References: <5447DC97.5000502@oracle.com> <5448C3D2.5070108@oracle.com> Message-ID: I found another one that needs to be documented: -Dnashorn.typeInfo.cacheDir This property can be used to set the directory where Nashorn stores the type info cache when -Dnashorn.typeInfo.maxFiles is set to a nonzero value. The default location is platform specific. On Windows, it is "${java.io.tmpdir}\com.oracle.java.NashornTypeInfo". On Linux and Solaris it is "~/.cache/com.oracle.java.NashornTypeInfo". On Mac OS X, it is "~/Library/Caches/com.oracle.java.NashornTypeInfo". On Oct 23, 2014, at 11:01 AM, Hannes Wallnoefer wrote: > Thanks Attila, > > I've uploaded a new webrev with the changes you suggested. > > http://cr.openjdk.java.net/~hannesw/8059813/webrev.01/ > > Hannes > > Am 2014-10-22 um 19:13 schrieb Attila Szegedi: >> s/that make sure/that makes sure in DEVELOPER_README >> >> I'd maybe remove documentation for nashorn.typeInfo.disabled; I actually planned on removing that property, and let only nashorn.typeInfo.maxFiles govern whether it's enabled or disabled. Can we do that (even though the property is there?) >> >> nashorn.args.prepend: how about emphasizing that later options overwrite earlier ones, so .prepend is useful for setting defaults that can be overwritten >> >> Other than these remarks, +1. >> >> >> On Oct 22, 2014, at 6:34 PM, Hannes Wallnoefer wrote: >> >>> Please review JDK-8059813: Type Info Cache flag must must be documented: >>> >>> http://cr.openjdk.java.net/~hannesw/8059813/ >>> >>> Thanks, >>> Hannes > From attila.szegedi at oracle.com Thu Oct 23 10:02:25 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 23 Oct 2014 12:02:25 +0200 Subject: Please review JDK-8061391 In-Reply-To: References: Message-ID: +1 On Oct 22, 2014, at 5:08 PM, Marcus Lagergren wrote: > Hi! Please review this! > > I added specialized builtins for concat, which are up to 10 times faster in microbenchmarks with just one element (or array) being concatenated. > While doing this I happened upon some bugs with preventExtensions for arrays, and removed the hateful unreliable SwitchPoint from ContinuousArray, replacing non extensible arrays with an ArrayFilter, which is the way I should have done it in the first place. > I also had to turn NoTypedArrayData into a structure that inherited ContinuousArray, or I threw away a lot of optimistic link sites to untouched arrays in ScriptObjects. This has other performance implications (good ones). > > ant test runs cleanly > ant test262parallel runs cleanly > octane runs with no regressions, some benchmarks like raytrace and crypto are even a bit faster. > > There are regressions in octane since the last time I checked, but not due to my fix. I will investigate and file bugs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061391 > Webrev: http://cr.openjdk.java.net/~lagergren/8061391/ > > Regards > Marcus > From hannes.wallnoefer at oracle.com Thu Oct 23 10:16:44 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 23 Oct 2014 12:16:44 +0200 Subject: Review request for JDK-8059813: Type Info Cache flag must must be documented In-Reply-To: References: <5447DC97.5000502@oracle.com> <5448C3D2.5070108@oracle.com> Message-ID: <5448D58C.5020200@oracle.com> Thanks Attila, updated again. http://cr.openjdk.java.net/~hannesw/8059813/webrev.02/ Am 2014-10-23 um 11:28 schrieb Attila Szegedi: > I found another one that needs to be documented: > > -Dnashorn.typeInfo.cacheDir > > This property can be used to set the directory where Nashorn stores the > type info cache when -Dnashorn.typeInfo.maxFiles is set to a nonzero > value. The default location is platform specific. On Windows, it is > "${java.io.tmpdir}\com.oracle.java.NashornTypeInfo". On Linux and > Solaris it is "~/.cache/com.oracle.java.NashornTypeInfo". On Mac OS X, > it is "~/Library/Caches/com.oracle.java.NashornTypeInfo". > > > On Oct 23, 2014, at 11:01 AM, Hannes Wallnoefer wrote: > >> Thanks Attila, >> >> I've uploaded a new webrev with the changes you suggested. >> >> http://cr.openjdk.java.net/~hannesw/8059813/webrev.01/ >> >> Hannes >> >> Am 2014-10-22 um 19:13 schrieb Attila Szegedi: >>> s/that make sure/that makes sure in DEVELOPER_README >>> >>> I'd maybe remove documentation for nashorn.typeInfo.disabled; I actually planned on removing that property, and let only nashorn.typeInfo.maxFiles govern whether it's enabled or disabled. Can we do that (even though the property is there?) >>> >>> nashorn.args.prepend: how about emphasizing that later options overwrite earlier ones, so .prepend is useful for setting defaults that can be overwritten >>> >>> Other than these remarks, +1. >>> >>> >>> On Oct 22, 2014, at 6:34 PM, Hannes Wallnoefer wrote: >>> >>>> Please review JDK-8059813: Type Info Cache flag must must be documented: >>>> >>>> http://cr.openjdk.java.net/~hannesw/8059813/ >>>> >>>> Thanks, >>>> Hannes From attila.szegedi at oracle.com Thu Oct 23 11:26:29 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 23 Oct 2014 13:26:29 +0200 Subject: Review request for JDK-8061955 Message-ID: Please review JDK-8061955 at for Thanks, Attila. From hannes.wallnoefer at oracle.com Thu Oct 23 11:57:07 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 23 Oct 2014 13:57:07 +0200 Subject: Please review JDK-8061391 In-Reply-To: <342ce688-e103-429e-9788-24bc72c95d3b@default> References: <342ce688-e103-429e-9788-24bc72c95d3b@default> Message-ID: <5448ED13.6040502@oracle.com> DeletedRangeArrayFilter.isEmpty should not override ArrayData.isEmpty as semantics are different. The easiest way to solve this would be to move new isEmpty method from ArrayData to ContinuousArrayData. Otherwise +1, nice work! Hannes Am 2014-10-22 um 17:34 schrieb Marcus Lagergren: > Please review this > > I added specialized builtins for concat, which are up to 10 times faster in microbenchmarks with just one element (or array) being concatenated. > While doing this I happened upon some bugs with preventExtensions for arrays, and removed the hateful unreliable SwitchPoint from ContinuousArray, replacing non extensible arrays with an ArrayFilter, which is the way I should have done it in the first place. > I also had to turn NoTypedArrayData into a structure that inherited ContinuousArray, or I threw away a lot of optimistic link sites to untouched arrays in ScriptObjects. This has other performance implications (good ones). > > ant test runs cleanly > ant test262parallel runs cleanly > octane runs with no regressions, some benchmarks like raytrace and crypto are even a bit faster. > > There are regressions in octane since the last time I checked, but not due to my fix. I will investigate and file bugs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061391 > Webrev: http://cr.openjdk.java.net/~lagergren/8061391/ > > Regards > Marcus From attila.szegedi at oracle.com Thu Oct 23 12:27:38 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 23 Oct 2014 14:27:38 +0200 Subject: Review request for JDK-8061957 Message-ID: <2FAEC3A6-6F53-468F-ACE3-DDED6A8C5FED@oracle.com> Please review JDK-8061957 at for Thanks, Attila. From hannes.wallnoefer at oracle.com Thu Oct 23 12:34:09 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 23 Oct 2014 14:34:09 +0200 Subject: Review request for JDK-8061955 In-Reply-To: References: Message-ID: <5448F5C1.2070106@oracle.com> +1 Am 2014-10-23 um 13:26 schrieb Attila Szegedi: > Please review JDK-8061955 at for > > Thanks, > Attila. From james.laskey at oracle.com Thu Oct 23 14:18:29 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 23 Oct 2014 11:18:29 -0300 Subject: Review request for JDK-8061955 In-Reply-To: References: Message-ID: <68E47E98-A0DC-40AF-9547-2257C2D70EA0@oracle.com> +1 On Oct 23, 2014, at 8:26 AM, Attila Szegedi wrote: > Please review JDK-8061955 at for > > Thanks, > Attila. From james.laskey at oracle.com Thu Oct 23 14:21:43 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 23 Oct 2014 11:21:43 -0300 Subject: Review request for JDK-8059813: Type Info Cache flag must must be documented In-Reply-To: <5447DC97.5000502@oracle.com> References: <5447DC97.5000502@oracle.com> Message-ID: +1 On Oct 22, 2014, at 1:34 PM, Hannes Wallnoefer wrote: > Please review JDK-8059813: Type Info Cache flag must must be documented: > > http://cr.openjdk.java.net/~hannesw/8059813/ > > Thanks, > Hannes From andrey at inlite.ru Thu Oct 23 14:49:00 2014 From: andrey at inlite.ru (=?UTF-8?B?0JDQvdC00YDQtdC5INCX0LDQstGC0YDQsNC60L7Qsg==?=) Date: Thu, 23 Oct 2014 18:49:00 +0400 Subject: Nashorn: error getting object property using string concatenation as a key Message-ID: given a simple AbstractJSObject binded as 'vars' to the script execution context: public class VarsAdapter extends AbstractJSObject { @Override public Object getMember(String name) { return name; } } Javascript source: o = 6; print( '1: '+vars['price_'+o]); print( '2: '+vars['price_6']); print( '3: '+vars[('price_'+o).toString()]); result is: 1: null 2: price_6 3: price_6 in case 1 getMember() is not called. This looks like a bug, From james.laskey at oracle.com Thu Oct 23 15:11:39 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 23 Oct 2014 12:11:39 -0300 Subject: Nashorn: error getting object property using string concatenation as a key In-Reply-To: References: Message-ID: Filed as https://bugs.openjdk.java.net/browse/JI-9016029 On Oct 23, 2014, at 11:49 AM, ?????? ????????? wrote: > given a simple AbstractJSObject binded as 'vars' to the script execution > context: > > public class VarsAdapter extends AbstractJSObject > { > > @Override > public Object getMember(String name) > { > return name; > } > } > > Javascript source: > > o = 6; > print( '1: '+vars['price_'+o]); > print( '2: '+vars['price_6']); > print( '3: '+vars[('price_'+o).toString()]); > > result is: > > 1: null > 2: price_6 > 3: price_6 > > in case 1 getMember() is not called. This looks like a bug, From james.laskey at oracle.com Thu Oct 23 15:12:45 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 23 Oct 2014 12:12:45 -0300 Subject: Missing ArrayBuffer.isView() Method In-Reply-To: References: Message-ID: <4A84E57B-9110-4FB9-A68C-7645DE7ECD3C@oracle.com> Filed as https://bugs.openjdk.java.net/browse/JDK-8061959 On Oct 22, 2014, at 9:23 PM, Kishori Sharan wrote: > Hello, > Why did Nashorn not implement the ArrayBuffer.isView() static method? The > page at > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > describes that Nashorn implements the specification at > https://www.khronos.org/registry/typedarray/specs/latest/ that conatins > this method. However, this method is missing. The following statement > throws an exception: > > ArrayBuffer.isView(new Int8Array(4)); > > > Thanks > Kishori From attila.szegedi at oracle.com Fri Oct 24 11:23:58 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 24 Oct 2014 13:23:58 +0200 Subject: Review request for JDK-8059813: Type Info Cache flag must must be documented In-Reply-To: References: <5447DC97.5000502@oracle.com> Message-ID: <90474BBC-CBE6-473C-BE59-27E70EAFDE3A@oracle.com> +1 On Oct 23, 2014, at 4:21 PM, Jim Laskey (Oracle) wrote: > +1 > > On Oct 22, 2014, at 1:34 PM, Hannes Wallnoefer wrote: > >> Please review JDK-8059813: Type Info Cache flag must must be documented: >> >> http://cr.openjdk.java.net/~hannesw/8059813/ >> >> Thanks, >> Hannes > From hannes.wallnoefer at oracle.com Fri Oct 24 12:06:12 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 24 Oct 2014 14:06:12 +0200 Subject: Review request for JDK-8061957 In-Reply-To: <2FAEC3A6-6F53-468F-ACE3-DDED6A8C5FED@oracle.com> References: <2FAEC3A6-6F53-468F-ACE3-DDED6A8C5FED@oracle.com> Message-ID: <544A40B4.8090702@oracle.com> +1 Am 2014-10-23 um 14:27 schrieb Attila Szegedi: > Please review JDK-8061957 at for > > Thanks, > Attila. From attila.szegedi at oracle.com Fri Oct 24 14:28:56 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 24 Oct 2014 16:28:56 +0200 Subject: Review request for JDK-8062050 Message-ID: <929067E2-D293-43C5-8E29-ECE8C7D80E26@oracle.com> Please review JDK-8062050 at for Thanks, Attila. From rjenks at ti.com Fri Oct 24 16:04:06 2014 From: rjenks at ti.com (Jenks, Robert) Date: Fri, 24 Oct 2014 16:04:06 +0000 Subject: Converting from JFX Webview to Nashorn. Performance trouble Message-ID: After getting back from JavaOne and being excited about Nashorn I decided to try porting our large javascript app to work under Nashorn. Currently we have a JavaFX application with a WebView component where we load our HTML/CSS/Javascript application. In WebView performance has been about half of what we need it to be. The Javascript application is large, very CPU intensive. It does draw to a canvas, but the drawing is very simplistic and infrequent. I completed the port and have been experimenting with it. So far, I am disappointed with the results. I expected additional startup delays due to the JIT, but even after the application is warmed up and the JIT compilation threads go idle, the application is running about twice as slow as the WebView version. I even tried using Java 9 EA and it did help some, but it?s still no where near as fast. I suspect that most of the performance advantages Nashorn gives are related to using the Nashorn (Java) canvas implementation. Since our app isn?t hindered by canvas performance, this doesn?t help. Another interesting observation is that Nashorn is using a HUGE amount of heap space. Our app uses about 300-500MB using the WebView approach, but 3GB under Nashorn. So, unless someone has a suggestion I think I?m going to move on to trying to get V8 running through the Jav8 project. Since our application performs well in Chrome this is about the last option beyond rewriting out app in C or Java. -Robert From james.laskey at oracle.com Fri Oct 24 17:03:38 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 24 Oct 2014 14:03:38 -0300 Subject: Converting from JFX Webview to Nashorn. Performance trouble In-Reply-To: References: Message-ID: Robert, Well, as with any port there has to be localized tweaking. We'd be willing to help you profile and find the bottlenecks. This also helps up find areas we need to improve. Warning about JaV8, as far as I am aware there hasn't been a lot of activity on JaV8 of late. The JNI support was very weak. Cheers, -- Jim On Oct 24, 2014, at 1:04 PM, Jenks, Robert wrote: > After getting back from JavaOne and being excited about Nashorn I decided to try porting our large javascript app to work under Nashorn. Currently we have a JavaFX application with a WebView component where we load our HTML/CSS/Javascript application. In WebView performance has been about half of what we need it to be. The Javascript application is large, very CPU intensive. It does draw to a canvas, but the drawing is very simplistic and infrequent. > > I completed the port and have been experimenting with it. So far, I am disappointed with the results. I expected additional startup delays due to the JIT, but even after the application is warmed up and the JIT compilation threads go idle, the application is running about twice as slow as the WebView version. I even tried using Java 9 EA and it did help some, but it?s still no where near as fast. > > I suspect that most of the performance advantages Nashorn gives are related to using the Nashorn (Java) canvas implementation. Since our app isn?t hindered by canvas performance, this doesn?t help. Another interesting observation is that Nashorn is using a HUGE amount of heap space. Our app uses about 300-500MB using the WebView approach, but 3GB under Nashorn. > > So, unless someone has a suggestion I think I?m going to move on to trying to get V8 running through the Jav8 project. Since our application performs well in Chrome this is about the last option beyond rewriting out app in C or Java. > > -Robert From rjenks at ti.com Fri Oct 24 17:13:51 2014 From: rjenks at ti.com (Jenks, Robert) Date: Fri, 24 Oct 2014 17:13:51 +0000 Subject: Converting from JFX Webview to Nashorn. Performance trouble In-Reply-To: References: Message-ID: Unfortunately I cannot share code without an NDA, but let me ask up the management ladder to see what they want to do. I agree about Jav8. Which is why it was lower priority than Nashorn to test. Fortunately there is very little interaction between Java and Javascript needed for our app. So without disclosing what I?m working on, let me describe a similar application. Imaging that I am working on a GameBoy Emulator. In this case I would have a processor emulator written in Javascript and the ROM as a byte array. The only interaction needed are to inject key events and to get screen updates using screen buffer in virtual memory (javascript array). Most of the Javascript is tiny functions which implement processor opcodes. These opcode functions are all annonymous and stored in an array indexed by the opcode. -Robert On 10/24/14, 12:03 PM, "Jim Laskey (Oracle)" wrote: >Robert, > >Well, as with any port there has to be localized tweaking. We'd be >willing to help you profile and find the bottlenecks. This also helps up >find areas we need to improve. > >Warning about JaV8, as far as I am aware there hasn't been a lot of >activity on JaV8 of late. The JNI support was very weak. > >Cheers, > >-- Jim > > > > >On Oct 24, 2014, at 1:04 PM, Jenks, Robert wrote: > >> After getting back from JavaOne and being excited about Nashorn I >>decided to try porting our large javascript app to work under Nashorn. >>Currently we have a JavaFX application with a WebView component where we >>load our HTML/CSS/Javascript application. In WebView performance has >>been about half of what we need it to be. The Javascript application is >>large, very CPU intensive. It does draw to a canvas, but the drawing is >>very simplistic and infrequent. >> >> I completed the port and have been experimenting with it. So far, I am >>disappointed with the results. I expected additional startup delays due >>to the JIT, but even after the application is warmed up and the JIT >>compilation threads go idle, the application is running about twice as >>slow as the WebView version. I even tried using Java 9 EA and it did >>help some, but it?s still no where near as fast. >> >> I suspect that most of the performance advantages Nashorn gives are >>related to using the Nashorn (Java) canvas implementation. Since our >>app isn?t hindered by canvas performance, this doesn?t help. Another >>interesting observation is that Nashorn is using a HUGE amount of heap >>space. Our app uses about 300-500MB using the WebView approach, but 3GB >>under Nashorn. >> >> So, unless someone has a suggestion I think I?m going to move on to >>trying to get V8 running through the Jav8 project. Since our >>application performs well in Chrome this is about the last option beyond >>rewriting out app in C or Java. >> >> -Robert > From hannes.wallnoefer at oracle.com Fri Oct 24 17:52:02 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 24 Oct 2014 19:52:02 +0200 Subject: Review request for JDK-8062050 In-Reply-To: <929067E2-D293-43C5-8E29-ECE8C7D80E26@oracle.com> References: <929067E2-D293-43C5-8E29-ECE8C7D80E26@oracle.com> Message-ID: <544A91C2.6070906@oracle.com> +1 Am 2014-10-24 um 16:28 schrieb Attila Szegedi: > Please review JDK-8062050 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Sat Oct 25 18:37:20 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Sat, 25 Oct 2014 20:37:20 +0200 Subject: Review request for JDK-8061957 In-Reply-To: <2FAEC3A6-6F53-468F-ACE3-DDED6A8C5FED@oracle.com> References: <2FAEC3A6-6F53-468F-ACE3-DDED6A8C5FED@oracle.com> Message-ID: <7F8C0593-0882-4D23-AA0A-BD0D1158134E@oracle.com> +1 > On 23 Oct 2014, at 14:27, Attila Szegedi wrote: > > Please review JDK-8061957 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Sat Oct 25 18:38:38 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Sat, 25 Oct 2014 20:38:38 +0200 Subject: Review request for JDK-8062050 In-Reply-To: <929067E2-D293-43C5-8E29-ECE8C7D80E26@oracle.com> References: <929067E2-D293-43C5-8E29-ECE8C7D80E26@oracle.com> Message-ID: <150DCD43-51E1-424B-A232-CD69D314BC87@oracle.com> +1 > On 24 Oct 2014, at 16:28, Attila Szegedi wrote: > > Please review JDK-8062050 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Sat Oct 25 18:41:42 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Sat, 25 Oct 2014 20:41:42 +0200 Subject: Converting from JFX Webview to Nashorn. Performance trouble In-Reply-To: References: Message-ID: <9F518788-39A5-4D25-B236-5D92D2B559DD@oracle.com> Any micro/minibenchmarks that you can extract would be very helpful indeed - i.e. those that have similar workloads like your code, but are NDA safe. There are several performance improvements in the 8u40 if you run with ?optimistic-types=true, at the cost of larger warmup (unless you use the code cache). That might help. Regards Marcus > On 24 Oct 2014, at 19:13, Jenks, Robert wrote: > > Unfortunately I cannot share code without an NDA, but let me ask up the > management ladder to see what they want to do. > > I agree about Jav8. Which is why it was lower priority than Nashorn to > test. Fortunately there is very little interaction between Java and > Javascript needed for our app. > > So without disclosing what I?m working on, let me describe a similar > application. Imaging that I am working on a GameBoy Emulator. In this > case I would have a processor emulator written in Javascript and the ROM > as a byte array. The only interaction needed are to inject key events and > to get screen updates using screen buffer in virtual memory (javascript > array). Most of the Javascript is tiny functions which implement > processor opcodes. These opcode functions are all annonymous and stored > in an array indexed by the opcode. > > -Robert > > On 10/24/14, 12:03 PM, "Jim Laskey (Oracle)" > > wrote: > >> Robert, >> >> Well, as with any port there has to be localized tweaking. We'd be >> willing to help you profile and find the bottlenecks. This also helps up >> find areas we need to improve. >> >> Warning about JaV8, as far as I am aware there hasn't been a lot of >> activity on JaV8 of late. The JNI support was very weak. >> >> Cheers, >> >> -- Jim >> >> >> >> >> On Oct 24, 2014, at 1:04 PM, Jenks, Robert wrote: >> >>> After getting back from JavaOne and being excited about Nashorn I >>> decided to try porting our large javascript app to work under Nashorn. >>> Currently we have a JavaFX application with a WebView component where we >>> load our HTML/CSS/Javascript application. In WebView performance has >>> been about half of what we need it to be. The Javascript application is >>> large, very CPU intensive. It does draw to a canvas, but the drawing is >>> very simplistic and infrequent. >>> >>> I completed the port and have been experimenting with it. So far, I am >>> disappointed with the results. I expected additional startup delays due >>> to the JIT, but even after the application is warmed up and the JIT >>> compilation threads go idle, the application is running about twice as >>> slow as the WebView version. I even tried using Java 9 EA and it did >>> help some, but it?s still no where near as fast. >>> >>> I suspect that most of the performance advantages Nashorn gives are >>> related to using the Nashorn (Java) canvas implementation. Since our >>> app isn?t hindered by canvas performance, this doesn?t help. Another >>> interesting observation is that Nashorn is using a HUGE amount of heap >>> space. Our app uses about 300-500MB using the WebView approach, but 3GB >>> under Nashorn. >>> >>> So, unless someone has a suggestion I think I?m going to move on to >>> trying to get V8 running through the Jav8 project. Since our >>> application performs well in Chrome this is about the last option beyond >>> rewriting out app in C or Java. >>> >>> -Robert From sundararajan.athijegannathan at oracle.com Mon Oct 27 11:27:05 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 27 Oct 2014 16:57:05 +0530 Subject: RFR 8062024: Issue with date.setFullYear when time other than midnight Message-ID: <544E2C09.3060205@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8062024/ for https://bugs.openjdk.java.net/browse/JDK-8062024 Thanks -Sundar From james.laskey at oracle.com Mon Oct 27 11:37:53 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 27 Oct 2014 08:37:53 -0300 Subject: RFR 8062024: Issue with date.setFullYear when time other than midnight In-Reply-To: <544E2C09.3060205@oracle.com> References: <544E2C09.3060205@oracle.com> Message-ID: <4C9B5CDA-00BC-4E0A-A1DB-3EBCB9CE13AE@oracle.com> +1 On Oct 27, 2014, at 8:27 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8062024/ for https://bugs.openjdk.java.net/browse/JDK-8062024 > > Thanks > -Sundar From marcus.lagergren at oracle.com Mon Oct 27 12:07:50 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 27 Oct 2014 13:07:50 +0100 Subject: RFR 8062024: Issue with date.setFullYear when time other than midnight In-Reply-To: <544E2C09.3060205@oracle.com> References: <544E2C09.3060205@oracle.com> Message-ID: final keyword missing from double val. Otherwise +1 > On 27 Oct 2014, at 12:27, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8062024/ for https://bugs.openjdk.java.net/browse/JDK-8062024 > > Thanks > -Sundar From rjenks at ti.com Mon Oct 27 18:43:13 2014 From: rjenks at ti.com (Jenks, Robert) Date: Mon, 27 Oct 2014 18:43:13 +0000 Subject: Converting from JFX Webview to Nashorn. Performance trouble In-Reply-To: <9F518788-39A5-4D25-B236-5D92D2B559DD@oracle.com> References: <9F518788-39A5-4D25-B236-5D92D2B559DD@oracle.com> Message-ID: I am working on the NDA and I think it should be possible. If not, I will work on a relevant benchmark script. Thanks for the info on the optimistic types. I will give that a try. -Robert From: Marcus Lagergren > Date: Saturday, October 25, 2014 at 1:41 PM To: Robert Jenks > Cc: "Jim Laskey (Oracle)" >, "nashorn-dev at openjdk.java.net" > Subject: Re: Converting from JFX Webview to Nashorn. Performance trouble Any micro/minibenchmarks that you can extract would be very helpful indeed - i.e. those that have similar workloads like your code, but are NDA safe. There are several performance improvements in the 8u40 if you run with ?optimistic-types=true, at the cost of larger warmup (unless you use the code cache). That might help. Regards Marcus On 24 Oct 2014, at 19:13, Jenks, Robert > wrote: Unfortunately I cannot share code without an NDA, but let me ask up the management ladder to see what they want to do. I agree about Jav8. Which is why it was lower priority than Nashorn to test. Fortunately there is very little interaction between Java and Javascript needed for our app. So without disclosing what I?m working on, let me describe a similar application. Imaging that I am working on a GameBoy Emulator. In this case I would have a processor emulator written in Javascript and the ROM as a byte array. The only interaction needed are to inject key events and to get screen updates using screen buffer in virtual memory (javascript array). Most of the Javascript is tiny functions which implement processor opcodes. These opcode functions are all annonymous and stored in an array indexed by the opcode. -Robert On 10/24/14, 12:03 PM, "Jim Laskey (Oracle)" > wrote: Robert, Well, as with any port there has to be localized tweaking. We'd be willing to help you profile and find the bottlenecks. This also helps up find areas we need to improve. Warning about JaV8, as far as I am aware there hasn't been a lot of activity on JaV8 of late. The JNI support was very weak. Cheers, -- Jim On Oct 24, 2014, at 1:04 PM, Jenks, Robert > wrote: After getting back from JavaOne and being excited about Nashorn I decided to try porting our large javascript app to work under Nashorn. Currently we have a JavaFX application with a WebView component where we load our HTML/CSS/Javascript application. In WebView performance has been about half of what we need it to be. The Javascript application is large, very CPU intensive. It does draw to a canvas, but the drawing is very simplistic and infrequent. I completed the port and have been experimenting with it. So far, I am disappointed with the results. I expected additional startup delays due to the JIT, but even after the application is warmed up and the JIT compilation threads go idle, the application is running about twice as slow as the WebView version. I even tried using Java 9 EA and it did help some, but it?s still no where near as fast. I suspect that most of the performance advantages Nashorn gives are related to using the Nashorn (Java) canvas implementation. Since our app isn?t hindered by canvas performance, this doesn?t help. Another interesting observation is that Nashorn is using a HUGE amount of heap space. Our app uses about 300-500MB using the WebView approach, but 3GB under Nashorn. So, unless someone has a suggestion I think I?m going to move on to trying to get V8 running through the Jav8 project. Since our application performs well in Chrome this is about the last option beyond rewriting out app in C or Java. -Robert From james.laskey at oracle.com Mon Oct 27 18:51:02 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 27 Oct 2014 15:51:02 -0300 Subject: Converting from JFX Webview to Nashorn. Performance trouble In-Reply-To: References: <9F518788-39A5-4D25-B236-5D92D2B559DD@oracle.com> Message-ID: <6C957DA6-F339-4D98-84C5-6817BCD191C3@oracle.com> Thank you. On Oct 27, 2014, at 3:43 PM, Jenks, Robert wrote: > I am working on the NDA and I think it should be possible. If not, I will work on a relevant benchmark script. > > Thanks for the info on the optimistic types. I will give that a try. > > -Robert > > From: Marcus Lagergren > Date: Saturday, October 25, 2014 at 1:41 PM > To: Robert Jenks > Cc: "Jim Laskey (Oracle)" , "nashorn-dev at openjdk.java.net" > Subject: Re: Converting from JFX Webview to Nashorn. Performance trouble > > Any micro/minibenchmarks that you can extract would be very helpful indeed - i.e. those that have similar workloads like your code, but are NDA safe. > > There are several performance improvements in the 8u40 if you run with ?optimistic-types=true, at the cost of larger warmup (unless you use the code cache). That might help. > > Regards > Marcus > >> On 24 Oct 2014, at 19:13, Jenks, Robert wrote: >> >> Unfortunately I cannot share code without an NDA, but let me ask up the >> management ladder to see what they want to do. >> >> I agree about Jav8. Which is why it was lower priority than Nashorn to >> test. Fortunately there is very little interaction between Java and >> Javascript needed for our app. >> >> So without disclosing what I?m working on, let me describe a similar >> application. Imaging that I am working on a GameBoy Emulator. In this >> case I would have a processor emulator written in Javascript and the ROM >> as a byte array. The only interaction needed are to inject key events and >> to get screen updates using screen buffer in virtual memory (javascript >> array). Most of the Javascript is tiny functions which implement >> processor opcodes. These opcode functions are all annonymous and stored >> in an array indexed by the opcode. >> >> -Robert >> >> On 10/24/14, 12:03 PM, "Jim Laskey (Oracle)" >> wrote: >> >>> Robert, >>> >>> Well, as with any port there has to be localized tweaking. We'd be >>> willing to help you profile and find the bottlenecks. This also helps up >>> find areas we need to improve. >>> >>> Warning about JaV8, as far as I am aware there hasn't been a lot of >>> activity on JaV8 of late. The JNI support was very weak. >>> >>> Cheers, >>> >>> -- Jim >>> >>> >>> >>> >>> On Oct 24, 2014, at 1:04 PM, Jenks, Robert wrote: >>> >>>> After getting back from JavaOne and being excited about Nashorn I >>>> decided to try porting our large javascript app to work under Nashorn. >>>> Currently we have a JavaFX application with a WebView component where we >>>> load our HTML/CSS/Javascript application. In WebView performance has >>>> been about half of what we need it to be. The Javascript application is >>>> large, very CPU intensive. It does draw to a canvas, but the drawing is >>>> very simplistic and infrequent. >>>> >>>> I completed the port and have been experimenting with it. So far, I am >>>> disappointed with the results. I expected additional startup delays due >>>> to the JIT, but even after the application is warmed up and the JIT >>>> compilation threads go idle, the application is running about twice as >>>> slow as the WebView version. I even tried using Java 9 EA and it did >>>> help some, but it?s still no where near as fast. >>>> >>>> I suspect that most of the performance advantages Nashorn gives are >>>> related to using the Nashorn (Java) canvas implementation. Since our >>>> app isn?t hindered by canvas performance, this doesn?t help. Another >>>> interesting observation is that Nashorn is using a HUGE amount of heap >>>> space. Our app uses about 300-500MB using the WebView approach, but 3GB >>>> under Nashorn. >>>> >>>> So, unless someone has a suggestion I think I?m going to move on to >>>> trying to get V8 running through the Jav8 project. Since our >>>> application performs well in Chrome this is about the last option beyond >>>> rewriting out app in C or Java. >>>> >>>> -Robert > From jfleming at linkedin.com Mon Oct 27 19:03:04 2014 From: jfleming at linkedin.com (Josh Fleming) Date: Mon, 27 Oct 2014 19:03:04 +0000 Subject: Nashorn incorrectly binds "this" in constructors created and returned by another function Message-ID: Hi folks, I filed a bug for this on the Oracle site (Review ID: JI-9016048), but was told that this list is the best place to discuss it. So this is a strange one. It seems that the latest release of Nashorn incorrectly binds "this" in a constructor function under the following conditions: * At least 2 level prototype hierarchy (for the sake of discussion let's call them Parent and Child) * Child constructor functions are created and returned by a higher order "factory? function * Child constructors call the Parent constructor, which uses ?this? * Multiple Child prototypes share the same Parent prototype * The Child prototypes disagree in the *number* of their properties When the second Child object instantiates, its constructor calls the Parent constructor, whose ?this? is incorrectly bound to a Parent object rather than the Child. Here's the jrunscript reduction (or https://gist.github.com/joshvfleming/0539f00dd12392483596): // -- BEGIN CODE -- function subclass(parentConstructor, proto) { function C() { parentConstructor.call(this); } C.prototype = Object.create(parentConstructor.prototype); for (var prop in proto) { if (proto.hasOwnProperty(prop)) { C.prototype[prop] = proto[prop]; } } return C; } var Parent = function() { this.init(); }; Parent.prototype = { init: null } var Child1 = subclass(Parent, { prop1: 1, init: function() { print('!!! child 1'); } }); var Child2 = subclass(Parent, { init: function() { print('!!! child 2'); } }); new Child1(); new Child2(); // -- END CODE -- Expected output: !!! child 1 !!! child 2 Actual output: !!! child 1 script error in file scripts/nashorn_this_binding_bug_reduction.js : TypeError: null is not a function in scripts/nashorn_this_binding_bug_reduction.js at line number 19 The script blows up at line 19 (see above or https://gist.github.com/joshvfleming/0539f00dd12392483596) when the Parent constructor tries to call "this.init()". This function has been overridden in the Child objects that we instantiate at the bottom, but Nashorn incorrectly binds "this" to the Parent object, whose ?init? is bound to "null" instead of an "init" function. One especially strange and interesting aspect of this is that it depends on the relative number of properties of the two Child prototypes. The reduction above fails because Child1 has the "prop1" property, but Child2 has none. If you add any property at all to Child2, the error goes away. If you add still another property, the error returns. Affected JRE: Java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) This bug appears to be a regression, as the following older JRE returns the "Expected" output: java version "1.8.0_05" Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) We?re stuck on 1.8.0_05 at this point, because one of our 3rd party libraries uses this inheritance pattern. Thanks, jf From james.laskey at oracle.com Mon Oct 27 19:09:08 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 27 Oct 2014 16:09:08 -0300 Subject: Nashorn incorrectly binds "this" in constructors created and returned by another function In-Reply-To: References: Message-ID: <76526128-AA81-460C-8DC3-103EAA74D63C@oracle.com> Just to let you know this has been promoted to https://bugs.openjdk.java.net/browse/JDK-8062132. We are investigating. On Oct 27, 2014, at 4:03 PM, Josh Fleming wrote: > Hi folks, > > I filed a bug for this on the Oracle site (Review ID: JI-9016048), but was told that this list is the best place to discuss it. > > So this is a strange one. It seems that the latest release of Nashorn incorrectly binds "this" in a constructor function under the following conditions: > > * At least 2 level prototype hierarchy (for the sake of discussion let's call them Parent and Child) > * Child constructor functions are created and returned by a higher order "factory? function > * Child constructors call the Parent constructor, which uses ?this? > * Multiple Child prototypes share the same Parent prototype > * The Child prototypes disagree in the *number* of their properties > > When the second Child object instantiates, its constructor calls the Parent constructor, whose ?this? is incorrectly bound to a Parent object rather than the Child. > > Here's the jrunscript reduction (or https://gist.github.com/joshvfleming/0539f00dd12392483596): > > // -- BEGIN CODE -- > function subclass(parentConstructor, proto) { > function C() { > parentConstructor.call(this); > } > > C.prototype = Object.create(parentConstructor.prototype); > > for (var prop in proto) { > if (proto.hasOwnProperty(prop)) { > C.prototype[prop] = proto[prop]; > } > } > > return C; > } > > var Parent = function() { > this.init(); > }; > > Parent.prototype = { > init: null > } > > var Child1 = subclass(Parent, { > prop1: 1, > init: function() { > print('!!! child 1'); > } > }); > > var Child2 = subclass(Parent, { > init: function() { > print('!!! child 2'); > } > }); > > new Child1(); > new Child2(); > // -- END CODE -- > > Expected output: > > !!! child 1 > !!! child 2 > > Actual output: > > !!! child 1 > script error in file scripts/nashorn_this_binding_bug_reduction.js : TypeError: null is not a function in scripts/nashorn_this_binding_bug_reduction.js at line number 19 > > The script blows up at line 19 (see above or https://gist.github.com/joshvfleming/0539f00dd12392483596) when the Parent constructor tries to call "this.init()". This function has been overridden in the Child objects that we instantiate at the bottom, but Nashorn incorrectly binds "this" to the Parent object, whose ?init? is bound to "null" instead of an "init" function. > > One especially strange and interesting aspect of this is that it depends on the relative number of properties of the two Child prototypes. The reduction above fails because Child1 has the "prop1" property, but Child2 has none. If you add any property at all to Child2, the error goes away. If you add still another property, the error returns. > > Affected JRE: > > Java version "1.8.0_25" > Java(TM) SE Runtime Environment (build 1.8.0_25-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) > > This bug appears to be a regression, as the following older JRE returns the "Expected" output: > > java version "1.8.0_05" > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > We?re stuck on 1.8.0_05 at this point, because one of our 3rd party libraries uses this inheritance pattern. > > > Thanks, > > jf > From sundararajan.athijegannathan at oracle.com Tue Oct 28 10:50:42 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 28 Oct 2014 16:20:42 +0530 Subject: RFR 8062216: [nashorn] regresion test failure with TimeZone Message-ID: <544F7502.70109@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8062216/ for https://bugs.openjdk.java.net/browse/JDK-8062216 -Sundar From hannes.wallnoefer at oracle.com Tue Oct 28 11:14:05 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 28 Oct 2014 12:14:05 +0100 Subject: RFR 8062216: [nashorn] regresion test failure with TimeZone In-Reply-To: <544F7502.70109@oracle.com> References: <544F7502.70109@oracle.com> Message-ID: <544F7A7D.2060700@oracle.com> +1 Am 2014-10-28 um 11:50 schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8062216/ for > https://bugs.openjdk.java.net/browse/JDK-8062216 > > -Sundar > From sundararajan.athijegannathan at oracle.com Tue Oct 28 12:04:57 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 28 Oct 2014 17:34:57 +0530 Subject: [8u40] approval request for 8062216: [nashorn] regresion test failure with TimeZone Message-ID: <544F8669.2000203@oracle.com> Please approve. Bug: https://bugs.openjdk.java.net/browse/JDK-8062216 jdk8 webrev: http://cr.openjdk.java.net/~sundar/8062216/8u40/webrev.00/ jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003744.html Fix backported "as is" without any jdk8 specific changes. -Sundar From marcus.lagergren at oracle.com Tue Oct 28 13:12:48 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 28 Oct 2014 14:12:48 +0100 Subject: RFR 8062216: [nashorn] regresion test failure with TimeZone In-Reply-To: <544F7502.70109@oracle.com> References: <544F7502.70109@oracle.com> Message-ID: <2A7AD1AF-28CB-4F5F-9DBD-86F3E0A8A931@oracle.com> +1 > On 28 Oct 2014, at 11:50, A. Sundararajan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8062216/ for https://bugs.openjdk.java.net/browse/JDK-8062216 > > -Sundar > From jbernardo at linkedin.com Tue Oct 28 23:38:35 2014 From: jbernardo at linkedin.com (John Bernardo) Date: Tue, 28 Oct 2014 23:38:35 +0000 Subject: Object.freeze() on prototype Message-ID: Hi, We?re currently working on getting Nashorn to a usable state in our production environment and currently focusing on improving performance to reach an acceptable state before rollout. Right now, we?re using ScriptEngine.eval() on the script source to set up the JS environment to prevent leaks into the global context. Instead of doing this, one idea we?ve been thinking about is using Object.freeze() on our global boilerplate and passing that around to each ScriptEngine instance we create (one per thread), which could potentially save performance. Is this approach safe? Is there a better/more performant way to achieve a common context? Please advise. JDK = 1_8_0_5 - JB From christoph.gritschenberger at gmail.com Wed Oct 29 12:18:06 2014 From: christoph.gritschenberger at gmail.com (Christoph Gritschenberger) Date: Wed, 29 Oct 2014 13:18:06 +0100 Subject: object with numeric indexes fills up Message-ID: <5450DAFE.4050507@gmail.com> I ran into an oddity when listing the keys of an object today. If I add a value with a numeric key >=524288 and then add more than one value with a key <524288, nashorn fills up the space between the lower indexes. I got some sample-code here: ScriptEngine engine = new ScriptEngineManager().getEngineByName("javascript"); Object eval = engine.eval("var x = {}; x[524287] = 'xxx'; x[1] = 'foo'; x[3] = 'bar'; Object.keys(x);"); System.out.println(((Map) eval).values()); // prints [1, 3, 524287] as expected eval = engine.eval("var x = {}; x[524288] = 'xxx'; x[1] = 'foo'; x[3] = 'bar'; Object.keys(x);"); System.out.println(((Map) eval).values()); // prints [1, 2, 3, 524288] Any idea why that is? kind regards, Christoph From sundararajan.athijegannathan at oracle.com Wed Oct 29 13:24:50 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 29 Oct 2014 18:54:50 +0530 Subject: object with numeric indexes fills up In-Reply-To: <5450DAFE.4050507@gmail.com> References: <5450DAFE.4050507@gmail.com> Message-ID: <5450EAA2.5010101@oracle.com> This is fixed in jdk8u40 and jdk9. You can download 8u40 early access binary from https://jdk8.java.net/download.html regards, -Sundar On Wednesday 29 October 2014 05:48 PM, Christoph Gritschenberger wrote: > I ran into an oddity when listing the keys of an object today. > If I add a value with a numeric key >=524288 and then add more than one > value with a key <524288, nashorn fills up the space between the lower > indexes. > > I got some sample-code here: > > ScriptEngine engine = new > ScriptEngineManager().getEngineByName("javascript"); > Object eval = engine.eval("var x = {}; x[524287] = 'xxx'; x[1] = > 'foo'; x[3] = 'bar'; Object.keys(x);"); > System.out.println(((Map) eval).values()); > // prints [1, 3, 524287] as expected > eval = engine.eval("var x = {}; x[524288] = 'xxx'; x[1] = 'foo'; > x[3] = 'bar'; Object.keys(x);"); > System.out.println(((Map) eval).values()); > // prints [1, 2, 3, 524288] > > Any idea why that is? > > kind regards, > Christoph > > From hannes.wallnoefer at oracle.com Wed Oct 29 15:41:52 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 29 Oct 2014 16:41:52 +0100 Subject: Review request for JDK-8062401: User accessors require boxing and do not support optimistic types Message-ID: <54510AC0.9010005@oracle.com> Please review JDK-8062401: User accessors require boxing and do not support optimistic types: http://cr.openjdk.java.net/~hannesw/8062401/ Thanks, Hannes From james.laskey at oracle.com Wed Oct 29 15:54:00 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 29 Oct 2014 12:54:00 -0300 Subject: Review request for JDK-8062401: User accessors require boxing and do not support optimistic types In-Reply-To: <54510AC0.9010005@oracle.com> References: <54510AC0.9010005@oracle.com> Message-ID: <274459AF-ED25-45A5-A046-5F8EBCC1E4EC@oracle.com> +1 On Oct 29, 2014, at 12:41 PM, Hannes Wallnoefer wrote: > Please review JDK-8062401: User accessors require boxing and do not support optimistic types: > > http://cr.openjdk.java.net/~hannesw/8062401/ > > Thanks, > Hannes From sundararajan.athijegannathan at oracle.com Wed Oct 29 16:42:05 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 29 Oct 2014 22:12:05 +0530 Subject: Object.freeze() on prototype In-Reply-To: References: Message-ID: <545118DD.6050004@oracle.com> Object.freeze(this) will not help. Scripts can still add/modify/delete properties of standard built-in constructors and the "prototype"-s of those. Unless all those are also frozen, script side-effect will still be a problem. -Sundar On Wednesday 29 October 2014 05:08 AM, John Bernardo wrote: > Hi, > > We?re currently working on getting Nashorn to a usable state in our production environment and currently focusing on improving performance to reach an acceptable state before rollout. > > Right now, we?re using ScriptEngine.eval() on the script source to set up the JS environment to prevent leaks into the global context. Instead of doing this, one idea we?ve been thinking about is using Object.freeze() on our global boilerplate and passing that around to each ScriptEngine instance we create (one per thread), which could potentially save performance. > > Is this approach safe? Is there a better/more performant way to achieve a common context? Please advise. > > JDK = 1_8_0_5 > > - JB From bhaidri at linkedin.com Wed Oct 29 19:09:13 2014 From: bhaidri at linkedin.com (Baq Haidri) Date: Wed, 29 Oct 2014 19:09:13 +0000 Subject: Nashorn incorrectly binds "this" in constructors created and returned by another function In-Reply-To: <76526128-AA81-460C-8DC3-103EAA74D63C@oracle.com> References: , <76526128-AA81-460C-8DC3-103EAA74D63C@oracle.com> Message-ID: <0045172AE22223459012420AFC04252B81DFECCB@ESV4-MB03.linkedin.biz> +cpettitt at linkedin.com Hi Jim, Thanks for escalating this so quickly. This one's a pretty important for us as LinkedIn is looking to standardize our production fleet to 8u40 as soon as the GA release is available. Can you give us an idea of whether the fix will make it in to 8u40? ----- baq ________________________________________ From: Jim Laskey (Oracle) [james.laskey at oracle.com] Sent: Monday, October 27, 2014 12:09 PM To: Josh Fleming Cc: nashorn-dev at openjdk.java.net; Mark Pascual; Baq Haidri Subject: Re: Nashorn incorrectly binds "this" in constructors created and returned by another function Just to let you know this has been promoted to https://bugs.openjdk.java.net/browse/JDK-8062132. We are investigating. On Oct 27, 2014, at 4:03 PM, Josh Fleming wrote: > Hi folks, > > I filed a bug for this on the Oracle site (Review ID: JI-9016048), but was told that this list is the best place to discuss it. > > So this is a strange one. It seems that the latest release of Nashorn incorrectly binds "this" in a constructor function under the following conditions: > > * At least 2 level prototype hierarchy (for the sake of discussion let's call them Parent and Child) > * Child constructor functions are created and returned by a higher order "factory? function > * Child constructors call the Parent constructor, which uses ?this? > * Multiple Child prototypes share the same Parent prototype > * The Child prototypes disagree in the *number* of their properties > > When the second Child object instantiates, its constructor calls the Parent constructor, whose ?this? is incorrectly bound to a Parent object rather than the Child. > > Here's the jrunscript reduction (or https://gist.github.com/joshvfleming/0539f00dd12392483596): > > // -- BEGIN CODE -- > function subclass(parentConstructor, proto) { > function C() { > parentConstructor.call(this); > } > > C.prototype = Object.create(parentConstructor.prototype); > > for (var prop in proto) { > if (proto.hasOwnProperty(prop)) { > C.prototype[prop] = proto[prop]; > } > } > > return C; > } > > var Parent = function() { > this.init(); > }; > > Parent.prototype = { > init: null > } > > var Child1 = subclass(Parent, { > prop1: 1, > init: function() { > print('!!! child 1'); > } > }); > > var Child2 = subclass(Parent, { > init: function() { > print('!!! child 2'); > } > }); > > new Child1(); > new Child2(); > // -- END CODE -- > > Expected output: > > !!! child 1 > !!! child 2 > > Actual output: > > !!! child 1 > script error in file scripts/nashorn_this_binding_bug_reduction.js : TypeError: null is not a function in scripts/nashorn_this_binding_bug_reduction.js at line number 19 > > The script blows up at line 19 (see above or https://gist.github.com/joshvfleming/0539f00dd12392483596) when the Parent constructor tries to call "this.init()". This function has been overridden in the Child objects that we instantiate at the bottom, but Nashorn incorrectly binds "this" to the Parent object, whose ?init? is bound to "null" instead of an "init" function. > > One especially strange and interesting aspect of this is that it depends on the relative number of properties of the two Child prototypes. The reduction above fails because Child1 has the "prop1" property, but Child2 has none. If you add any property at all to Child2, the error goes away. If you add still another property, the error returns. > > Affected JRE: > > Java version "1.8.0_25" > Java(TM) SE Runtime Environment (build 1.8.0_25-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) > > This bug appears to be a regression, as the following older JRE returns the "Expected" output: > > java version "1.8.0_05" > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > We?re stuck on 1.8.0_05 at this point, because one of our 3rd party libraries uses this inheritance pattern. > > > Thanks, > > jf > From marcus.lagergren at oracle.com Thu Oct 30 10:43:56 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 30 Oct 2014 11:43:56 +0100 Subject: Review request for JDK-8062401: User accessors require boxing and do not support optimistic types In-Reply-To: <54510AC0.9010005@oracle.com> References: <54510AC0.9010005@oracle.com> Message-ID: <756A8E88-DB55-40E9-9AA5-8074CBB30FE1@oracle.com> +1 What are the performance implications? Have you done some octane runs or something? Furthermore, I?d like to see a comment in the benchmark you?ve added, what it?s for, a reference to the issue number JDK-8062401 in a comment and what the difference before and after was. Otherwise - solid work. Nicely done. Have you discussed with Vladimir Ivanov, the problem he had with box2d and the inlining site in UserAccessorProperty? Will this affect it and make it better? CC:ing Vladimir. Regards Marcus > On 29 Oct 2014, at 16:41, Hannes Wallnoefer wrote: > > Please review JDK-8062401: User accessors require boxing and do not support optimistic types: > > http://cr.openjdk.java.net/~hannesw/8062401/ > > Thanks, > Hannes From marcus.lagergren at oracle.com Thu Oct 30 10:46:28 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Thu, 30 Oct 2014 11:46:28 +0100 Subject: Nashorn incorrectly binds "this" in constructors created and returned by another function In-Reply-To: <0045172AE22223459012420AFC04252B81DFECCB@ESV4-MB03.linkedin.biz> References: <, > <76526128-AA81-460C-8DC3-103EAA74D63C@oracle.com> <0045172AE22223459012420AFC04252B81DFECCB@ESV4-MB03.linkedin.biz> Message-ID: Any bugfix we manage to check in before the end of November will make it into 8u40. Hannes has diagnosed the problem and this is a p2, which is the highest priority of all Nashorn bugs for 8u40 right now (no p1s are filed), so I would say it is very likely it will make it into 8u40. Hannes - can you elaborate? Regards Marcus > On 29 Oct 2014, at 20:09, Baq Haidri wrote: > > +cpettitt at linkedin.com > > Hi Jim, > > Thanks for escalating this so quickly. This one's a pretty important for us as LinkedIn is looking to standardize our production fleet to 8u40 as soon as the GA release is available. Can you give us an idea of whether the fix will make it in to 8u40? > > ----- > baq > > ________________________________________ > From: Jim Laskey (Oracle) [james.laskey at oracle.com] > Sent: Monday, October 27, 2014 12:09 PM > To: Josh Fleming > Cc: nashorn-dev at openjdk.java.net; Mark Pascual; Baq Haidri > Subject: Re: Nashorn incorrectly binds "this" in constructors created and returned by another function > > Just to let you know this has been promoted to https://bugs.openjdk.java.net/browse/JDK-8062132. We are investigating. > > > On Oct 27, 2014, at 4:03 PM, Josh Fleming wrote: > >> Hi folks, >> >> I filed a bug for this on the Oracle site (Review ID: JI-9016048), but was told that this list is the best place to discuss it. >> >> So this is a strange one. It seems that the latest release of Nashorn incorrectly binds "this" in a constructor function under the following conditions: >> >> * At least 2 level prototype hierarchy (for the sake of discussion let's call them Parent and Child) >> * Child constructor functions are created and returned by a higher order "factory? function >> * Child constructors call the Parent constructor, which uses ?this? >> * Multiple Child prototypes share the same Parent prototype >> * The Child prototypes disagree in the *number* of their properties >> >> When the second Child object instantiates, its constructor calls the Parent constructor, whose ?this? is incorrectly bound to a Parent object rather than the Child. >> >> Here's the jrunscript reduction (or https://gist.github.com/joshvfleming/0539f00dd12392483596): >> >> // -- BEGIN CODE -- >> function subclass(parentConstructor, proto) { >> function C() { >> parentConstructor.call(this); >> } >> >> C.prototype = Object.create(parentConstructor.prototype); >> >> for (var prop in proto) { >> if (proto.hasOwnProperty(prop)) { >> C.prototype[prop] = proto[prop]; >> } >> } >> >> return C; >> } >> >> var Parent = function() { >> this.init(); >> }; >> >> Parent.prototype = { >> init: null >> } >> >> var Child1 = subclass(Parent, { >> prop1: 1, >> init: function() { >> print('!!! child 1'); >> } >> }); >> >> var Child2 = subclass(Parent, { >> init: function() { >> print('!!! child 2'); >> } >> }); >> >> new Child1(); >> new Child2(); >> // -- END CODE -- >> >> Expected output: >> >> !!! child 1 >> !!! child 2 >> >> Actual output: >> >> !!! child 1 >> script error in file scripts/nashorn_this_binding_bug_reduction.js : TypeError: null is not a function in scripts/nashorn_this_binding_bug_reduction.js at line number 19 >> >> The script blows up at line 19 (see above or https://gist.github.com/joshvfleming/0539f00dd12392483596) when the Parent constructor tries to call "this.init()". This function has been overridden in the Child objects that we instantiate at the bottom, but Nashorn incorrectly binds "this" to the Parent object, whose ?init? is bound to "null" instead of an "init" function. >> >> One especially strange and interesting aspect of this is that it depends on the relative number of properties of the two Child prototypes. The reduction above fails because Child1 has the "prop1" property, but Child2 has none. If you add any property at all to Child2, the error goes away. If you add still another property, the error returns. >> >> Affected JRE: >> >> Java version "1.8.0_25" >> Java(TM) SE Runtime Environment (build 1.8.0_25-b17) >> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) >> >> This bug appears to be a regression, as the following older JRE returns the "Expected" output: >> >> java version "1.8.0_05" >> Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >> >> We?re stuck on 1.8.0_05 at this point, because one of our 3rd party libraries uses this inheritance pattern. >> >> >> Thanks, >> >> jf >> > From hannes.wallnoefer at oracle.com Thu Oct 30 11:15:25 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 30 Oct 2014 12:15:25 +0100 Subject: Nashorn incorrectly binds "this" in constructors created and returned by another function In-Reply-To: References: <, > <76526128-AA81-460C-8DC3-103EAA74D63C@oracle.com> <0045172AE22223459012420AFC04252B81DFECCB@ESV4-MB03.linkedin.biz> Message-ID: <54521DCD.2000707@oracle.com> I have a fix for this and I'm currently running tests to verify it. This will definitley make it into 8u40. Hannes Am 2014-10-30 um 11:46 schrieb Marcus Lagergren: > Any bugfix we manage to check in before the end of November will make it into 8u40. Hannes has diagnosed the problem and this is a p2, which is the highest priority of all Nashorn bugs for 8u40 right now (no p1s are filed), so I would say it is very likely it will make it into 8u40. Hannes - can you elaborate? > > Regards > Marcus > >> On 29 Oct 2014, at 20:09, Baq Haidri wrote: >> >> +cpettitt at linkedin.com >> >> Hi Jim, >> >> Thanks for escalating this so quickly. This one's a pretty important for us as LinkedIn is looking to standardize our production fleet to 8u40 as soon as the GA release is available. Can you give us an idea of whether the fix will make it in to 8u40? >> >> ----- >> baq >> >> ________________________________________ >> From: Jim Laskey (Oracle) [james.laskey at oracle.com] >> Sent: Monday, October 27, 2014 12:09 PM >> To: Josh Fleming >> Cc: nashorn-dev at openjdk.java.net; Mark Pascual; Baq Haidri >> Subject: Re: Nashorn incorrectly binds "this" in constructors created and returned by another function >> >> Just to let you know this has been promoted to https://bugs.openjdk.java.net/browse/JDK-8062132. We are investigating. >> >> >> On Oct 27, 2014, at 4:03 PM, Josh Fleming wrote: >> >>> Hi folks, >>> >>> I filed a bug for this on the Oracle site (Review ID: JI-9016048), but was told that this list is the best place to discuss it. >>> >>> So this is a strange one. It seems that the latest release of Nashorn incorrectly binds "this" in a constructor function under the following conditions: >>> >>> * At least 2 level prototype hierarchy (for the sake of discussion let's call them Parent and Child) >>> * Child constructor functions are created and returned by a higher order "factory? function >>> * Child constructors call the Parent constructor, which uses ?this? >>> * Multiple Child prototypes share the same Parent prototype >>> * The Child prototypes disagree in the *number* of their properties >>> >>> When the second Child object instantiates, its constructor calls the Parent constructor, whose ?this? is incorrectly bound to a Parent object rather than the Child. >>> >>> Here's the jrunscript reduction (or https://gist.github.com/joshvfleming/0539f00dd12392483596): >>> >>> // -- BEGIN CODE -- >>> function subclass(parentConstructor, proto) { >>> function C() { >>> parentConstructor.call(this); >>> } >>> >>> C.prototype = Object.create(parentConstructor.prototype); >>> >>> for (var prop in proto) { >>> if (proto.hasOwnProperty(prop)) { >>> C.prototype[prop] = proto[prop]; >>> } >>> } >>> >>> return C; >>> } >>> >>> var Parent = function() { >>> this.init(); >>> }; >>> >>> Parent.prototype = { >>> init: null >>> } >>> >>> var Child1 = subclass(Parent, { >>> prop1: 1, >>> init: function() { >>> print('!!! child 1'); >>> } >>> }); >>> >>> var Child2 = subclass(Parent, { >>> init: function() { >>> print('!!! child 2'); >>> } >>> }); >>> >>> new Child1(); >>> new Child2(); >>> // -- END CODE -- >>> >>> Expected output: >>> >>> !!! child 1 >>> !!! child 2 >>> >>> Actual output: >>> >>> !!! child 1 >>> script error in file scripts/nashorn_this_binding_bug_reduction.js : TypeError: null is not a function in scripts/nashorn_this_binding_bug_reduction.js at line number 19 >>> >>> The script blows up at line 19 (see above or https://gist.github.com/joshvfleming/0539f00dd12392483596) when the Parent constructor tries to call "this.init()". This function has been overridden in the Child objects that we instantiate at the bottom, but Nashorn incorrectly binds "this" to the Parent object, whose ?init? is bound to "null" instead of an "init" function. >>> >>> One especially strange and interesting aspect of this is that it depends on the relative number of properties of the two Child prototypes. The reduction above fails because Child1 has the "prop1" property, but Child2 has none. If you add any property at all to Child2, the error goes away. If you add still another property, the error returns. >>> >>> Affected JRE: >>> >>> Java version "1.8.0_25" >>> Java(TM) SE Runtime Environment (build 1.8.0_25-b17) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) >>> >>> This bug appears to be a regression, as the following older JRE returns the "Expected" output: >>> >>> java version "1.8.0_05" >>> Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >>> >>> We?re stuck on 1.8.0_05 at this point, because one of our 3rd party libraries uses this inheritance pattern. >>> >>> >>> Thanks, >>> >>> jf >>> From yikesaroni at gmail.com Thu Oct 30 13:09:16 2014 From: yikesaroni at gmail.com (yikes aroni) Date: Thu, 30 Oct 2014 09:09:16 -0400 Subject: Reusing compiled JS code keeping speed and thread-safety Message-ID: Hi ... I?m using nashorn by embedding it in Java (not via command-line). I can make it work, but I have a two primary challenges: 1) speed of execution; and 2) thread safety. I have a ?base? JS library that I compile more or less like this: ScriptEngineManager *factory* = *new* ScriptEngineManager(); ScriptEngine *baseEngine* = *factory*.getEngineByName("nashorn"); Compilable *baseCompilable* = (Compilable) *baseEngine*; baseCompilable.compile(*new* java.io.FileReader(*pathDsBase*)).eval(); where *pathDsBase* is a file system path to my javascript library. This library isn?t huge, but it takes about 500+ ms to compile and eval(). That?s a long time for my purposes, so I want to do it only once. Other parts of my code then launch multiple Java threads that do various work and occasionally invoke small, ?temporary? Javascript scripts that need to reference objects and functions in this ?base? library. Since I want these small scripts to run fast and thread-safe, I **could** simply create a brand new ScriptEngine every time I want to run one of these small, ?temporary? scripts and recompile the base library into it. Problem with that is that it takes too much time. I?ve tried a lot of approaches -- none have worked. My main approach (which has failed miserably at every turn) is to create a ?base? ScriptEngine, compile the ?base? library into it, then create a ?temporary? ScriptEngine and attempt to set the base bindings / context to it so that the temp ScriptEngine only eval()s the ?temp? script, but has the base library in scope. For example something like this test code: ScriptEngine tempEngine = engineFactory.getScriptEngine(); // a temporary engine. This is the one that will evaluate the ?small? scripts that reference the ?base? script library. ScriptContext ctxBase = *new* SimpleScriptContext(); ctxBase.setBindings(baseEngine.createBindings(), ScriptContext. *GLOBAL_SCOPE*); // evaluate a script at add it to base?s context. This is where the ?base? script libraries would be eval()-ed into the baseEngine context. baseEngine.eval("var y = 'hello';", ctxBase); // Now attempt to set the baseEngine?s bindings (which I assume have y = ?hello? in them (since I?m not clear where they end up, I?ve tried every possible combination or ENGINE and GLOBAL scope.) ScriptContext ctxTemp = *new* SimpleScriptContext(); ctxTemp.setBindings(baseEngine.createBindings(), ScriptContext. *ENGINE_SCOPE*); // Now for the temporary, ?small? script. The print references a variable (y) that I had hoped would be set to the temp engine?s scope from the ?base? engine?s context. String script = "var x = 'world'; print(y + x);"; tempEngine.eval(script, ctxTemp); Exception is Exception in thread "main" *javax.script.ScriptException*: ReferenceError: "y" is not defined in at line number 1 I?ve also tried using loadWithNewGlobal, which solves the threading issue, but doesn?t appear to solve the speed issue: the script has to be recompiled every time. I am sure I am barking up the wrong tree. Can somebody help point me in the right direction for how to do this? Again, my two primary questions are: 1) (Speed) Generally, how do I make it so that I don?t have to re-eval() a large library every time I want to run a script that references it? Or, more specifically, how can I reuse code compiled (eval()ed) by one engine (?base?) in another engine (?temp?)? 2) (Thread-safety) How do I reuse such a library in a way that running the subsequent ?temp? scripts doesn?t pollute the ?base? bindings that I?m reusing? I will be overjoyed if there is a clean solution to this. If not, I will still be happy to clear up this mystery with a ?can?t do that...? if that is, in fact, the answer.... thanks From hannes.wallnoefer at oracle.com Thu Oct 30 13:53:23 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 30 Oct 2014 14:53:23 +0100 Subject: Reusing compiled JS code keeping speed and thread-safety In-Reply-To: References: Message-ID: <545242D3.5050406@oracle.com> Hi, The main requirement for reusing compiled scripts is to use a single script engine. You can use multiple JS environments/globals within a script engine by using multiple bindings/script contexts. The nashorn script engine implements javax.script.Compilable, so you can use the compile methods to get a CompiledScript that can be evaluated with multiple bindings or script contexts. http://docs.oracle.com/javase/7/docs/api/javax/script/Compilable.html Also, we have been improving reuse of compiled scripts since the initial JDK8 release, so later versions of Nashorn may work better. You probably should use JDK 8u20 or even a 8u40 preview release (avalable at ). In those releases, we have added caching of compiled scripts within the script engine, so even plain eval() should be faster as long as you use multiple globals/bindings within the same engine. I hope this helps. Let us know how it goes! Hannes Am 2014-10-30 um 14:09 schrieb yikes aroni: > Hi ... I?m using nashorn by embedding it in Java (not via command-line). I > can make it work, but I have a two primary challenges: 1) speed of > execution; and 2) thread safety. > > > > I have a ?base? JS library that I compile more or less like this: > > > > ScriptEngineManager *factory* = *new* ScriptEngineManager(); > > ScriptEngine *baseEngine* = *factory*.getEngineByName("nashorn"); > > Compilable *baseCompilable* = (Compilable) *baseEngine*; > > baseCompilable.compile(*new* java.io.FileReader(*pathDsBase*)).eval(); > > > > where *pathDsBase* is a file system path to my javascript library. This > library isn?t huge, but it takes about 500+ ms to compile and eval(). > That?s a long time for my purposes, so I want to do it only once. > > > > Other parts of my code then launch multiple Java threads that do various > work and occasionally invoke small, ?temporary? Javascript scripts that > need to reference objects and functions in this ?base? library. Since I > want these small scripts to run fast and thread-safe, I **could** simply > create a brand new ScriptEngine every time I want to run one of these > small, ?temporary? scripts and recompile the base library into it. Problem > with that is that it takes too much time. > > > > I?ve tried a lot of approaches -- none have worked. > > > > My main approach (which has failed miserably at every turn) is to create a > ?base? ScriptEngine, compile the ?base? library into it, then create a > ?temporary? ScriptEngine and attempt to set the base bindings / context to > it so that the temp ScriptEngine only eval()s the ?temp? script, but has > the base library in scope. For example something like this test code: > > > > ScriptEngine tempEngine = engineFactory.getScriptEngine(); // a > temporary engine. This is the one that will evaluate the ?small? scripts > that reference the ?base? script library. > > ScriptContext ctxBase = *new* SimpleScriptContext(); > > ctxBase.setBindings(baseEngine.createBindings(), ScriptContext. > *GLOBAL_SCOPE*); > > // evaluate a script at add it to base?s context. This is where the > ?base? script libraries would be eval()-ed into the baseEngine context. > > baseEngine.eval("var y = 'hello';", ctxBase); > > > > // Now attempt to set the baseEngine?s bindings (which I > assume have y = ?hello? in them (since I?m not clear where they end up, > I?ve tried every possible combination or ENGINE and GLOBAL scope.) > > ScriptContext ctxTemp = *new* SimpleScriptContext(); > > ctxTemp.setBindings(baseEngine.createBindings(), ScriptContext. > *ENGINE_SCOPE*); > > > > // Now for the temporary, ?small? script. The print references a > variable (y) that I had hoped would be set to the temp engine?s scope from > the ?base? engine?s context. > > String script = "var x = 'world'; print(y + x);"; > > tempEngine.eval(script, ctxTemp); > > > > Exception is Exception in thread "main" *javax.script.ScriptException*: > ReferenceError: "y" is not defined in at line number 1 > > > > I?ve also tried using loadWithNewGlobal, which solves the threading issue, > but doesn?t appear to solve the speed issue: the script has to be > recompiled every time. > > > > I am sure I am barking up the wrong tree. Can somebody help point me in the > right direction for how to do this? Again, my two primary questions are: > > > > 1) (Speed) Generally, how do I make it so that I don?t have to re-eval() a > large library every time I want to run a script that references it? Or, > more specifically, how can I reuse code compiled (eval()ed) by one engine > (?base?) in another engine (?temp?)? > > 2) (Thread-safety) How do I reuse such a library in a way that running the > subsequent ?temp? scripts doesn?t pollute the ?base? bindings that I?m > reusing? > > > > I will be overjoyed if there is a clean solution to this. If not, I will > still be happy to clear up this mystery with a ?can?t do that...? if that > is, in fact, the answer.... > > > > thanks From benjamin.sieffert at metrigo.de Thu Oct 30 14:03:43 2014 From: benjamin.sieffert at metrigo.de (Benjamin Sieffert) Date: Thu, 30 Oct 2014 15:03:43 +0100 Subject: Reusing compiled JS code keeping speed and thread-safety In-Reply-To: References: Message-ID: Hello there, we had a similar aim / similar issues with nashorn. Since I don't know your code exactly, I'll just describe our case / what we ended up doing and maybe you can get some ideas off that. We use one ScriptEngine. Among all our threads, just one engine. On start-up we let it compile the library once. The library has no mutable state and is not dependant on global variables. It's just a collection of functions / classes. Then we have a few hundred small javascripts that basically instantiate a class defined by the library and do some configurations on that instance. Any one of these scripts gets evaluated by the engine once and the returned ScriptObjectMirror (the configured javascript object) is then kept on the java side. As this ScriptObjectMirror also does not have any mutable state, we can now safely use it among multiple threads via callMember(). To get nice stack traces, we also wrap each small javascript into a load()-call in the engine and name it. The library is also wrapped in a load()-call. All approaches including some sort of mutable javascript-side state sadly do not seem to be workable. The nashorn devs have (understandably) explicitly stated that since javascript does not define multithreaded semantics, they will not be implementing any. Everything evaluated in a NashornScriptEngine keeps its original context/global, even when seemingly "put" into another engine. You cannot prevent pollution. I tried for some time. : ) Regards On 30 October 2014 14:09, yikes aroni wrote: > Hi ... I?m using nashorn by embedding it in Java (not via command-line). I > can make it work, but I have a two primary challenges: 1) speed of > execution; and 2) thread safety. > > > > I have a ?base? JS library that I compile more or less like this: > > > > ScriptEngineManager *factory* = *new* ScriptEngineManager(); > > ScriptEngine *baseEngine* = *factory*.getEngineByName("nashorn"); > > Compilable *baseCompilable* = (Compilable) *baseEngine*; > > baseCompilable.compile(*new* java.io.FileReader(*pathDsBase*)).eval(); > > > > where *pathDsBase* is a file system path to my javascript library. This > library isn?t huge, but it takes about 500+ ms to compile and eval(). > That?s a long time for my purposes, so I want to do it only once. > > > > Other parts of my code then launch multiple Java threads that do various > work and occasionally invoke small, ?temporary? Javascript scripts that > need to reference objects and functions in this ?base? library. Since I > want these small scripts to run fast and thread-safe, I **could** simply > create a brand new ScriptEngine every time I want to run one of these > small, ?temporary? scripts and recompile the base library into it. Problem > with that is that it takes too much time. > > > > I?ve tried a lot of approaches -- none have worked. > > > > My main approach (which has failed miserably at every turn) is to create a > ?base? ScriptEngine, compile the ?base? library into it, then create a > ?temporary? ScriptEngine and attempt to set the base bindings / context to > it so that the temp ScriptEngine only eval()s the ?temp? script, but has > the base library in scope. For example something like this test code: > > > > ScriptEngine tempEngine = engineFactory.getScriptEngine(); // a > temporary engine. This is the one that will evaluate the ?small? scripts > that reference the ?base? script library. > > ScriptContext ctxBase = *new* SimpleScriptContext(); > > ctxBase.setBindings(baseEngine.createBindings(), ScriptContext. > *GLOBAL_SCOPE*); > > // evaluate a script at add it to base?s context. This is where the > ?base? script libraries would be eval()-ed into the baseEngine context. > > baseEngine.eval("var y = 'hello';", ctxBase); > > > > // Now attempt to set the baseEngine?s bindings (which I > assume have y = ?hello? in them (since I?m not clear where they end up, > I?ve tried every possible combination or ENGINE and GLOBAL scope.) > > ScriptContext ctxTemp = *new* SimpleScriptContext(); > > ctxTemp.setBindings(baseEngine.createBindings(), ScriptContext. > *ENGINE_SCOPE*); > > > > // Now for the temporary, ?small? script. The print references a > variable (y) that I had hoped would be set to the temp engine?s scope from > the ?base? engine?s context. > > String script = "var x = 'world'; print(y + x);"; > > tempEngine.eval(script, ctxTemp); > > > > Exception is Exception in thread "main" *javax.script.ScriptException*: > ReferenceError: "y" is not defined in at line number 1 > > > > I?ve also tried using loadWithNewGlobal, which solves the threading issue, > but doesn?t appear to solve the speed issue: the script has to be > recompiled every time. > > > > I am sure I am barking up the wrong tree. Can somebody help point me in the > right direction for how to do this? Again, my two primary questions are: > > > > 1) (Speed) Generally, how do I make it so that I don?t have to re-eval() a > large library every time I want to run a script that references it? Or, > more specifically, how can I reuse code compiled (eval()ed) by one engine > (?base?) in another engine (?temp?)? > > 2) (Thread-safety) How do I reuse such a library in a way that running the > subsequent ?temp? scripts doesn?t pollute the ?base? bindings that I?m > reusing? > > > > I will be overjoyed if there is a clean solution to this. If not, I will > still be happy to clear up this mystery with a ?can?t do that...? if that > is, in fact, the answer.... > > > > thanks > -- Benjamin Sieffert metrigo GmbH Sternstr. 106 20357 Hamburg Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, Martin Rie? Die Gesellschaft ist eingetragen beim Registergericht Hamburg Nr. HRB 120447. From hannes.wallnoefer at oracle.com Thu Oct 30 14:21:58 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 30 Oct 2014 15:21:58 +0100 Subject: Review request for JDK-8062401: User accessors require boxing and do not support optimistic types In-Reply-To: <756A8E88-DB55-40E9-9AA5-8074CBB30FE1@oracle.com> References: <54510AC0.9010005@oracle.com> <756A8E88-DB55-40E9-9AA5-8074CBB30FE1@oracle.com> Message-ID: <54524986.5040309@oracle.com> Thanks Marcus. All box2d user accessors dealing with primitive values now are fully primitive and optimistic. There is a slight improvement in performance, but I'm not sure it's the best we can get. I'll contact Vladimir about how to find out. I'll also add a comment to the benchmark as you suggested. Hannes Am 2014-10-30 um 11:43 schrieb Marcus Lagergren: > +1 > > What are the performance implications? Have you done some octane runs or something? > > Furthermore, I?d like to see a comment in the benchmark you?ve added, what it?s for, a reference to the issue number JDK-8062401 in a comment and what the difference before and after was. > > Otherwise - solid work. Nicely done. > > Have you discussed with Vladimir Ivanov, the problem he had with box2d and the inlining site in UserAccessorProperty? Will this affect it and make it better? CC:ing Vladimir. > > Regards > Marcus > >> On 29 Oct 2014, at 16:41, Hannes Wallnoefer wrote: >> >> Please review JDK-8062401: User accessors require boxing and do not support optimistic types: >> >> http://cr.openjdk.java.net/~hannesw/8062401/ >> >> Thanks, >> Hannes From yikesaroni at gmail.com Thu Oct 30 14:24:18 2014 From: yikesaroni at gmail.com (yikes aroni) Date: Thu, 30 Oct 2014 10:24:18 -0400 Subject: Reusing compiled JS code keeping speed and thread-safety In-Reply-To: <545242D3.5050406@oracle.com> References: <545242D3.5050406@oracle.com> Message-ID: Thanks for the response Hannes. Is it possible to reuse a single ScriptEngine without polluting its scopes/bindings? To be clear, consider this process: 1) Get a ScriptEngine 2) Precompile a "library" script into ENGINE scope (or GLOBAL?). Do this once and never again. This "library" script has functions, etc., that other, "local" scripts need to run 3) Using the same (?) engine, eval() other scripts that use functions/vars in the "library" Do (3) over and over and over with a wide variety of scripts without polluting the scope in which the "library" lives with the variables of the previous scripts that have run. Is this possible? Again, my requirement (i.e., fond hope) is that a) i not have to re-compile the "library" script; and that b) the scope not be polluted with the local script's variables, etc. Again, thanks! On Thu, Oct 30, 2014 at 9:53 AM, Hannes Wallnoefer < hannes.wallnoefer at oracle.com> wrote: > Hi, > > The main requirement for reusing compiled scripts is to use a single > script engine. You can use multiple JS environments/globals within a script > engine by using multiple bindings/script contexts. The nashorn script > engine implements javax.script.Compilable, so you can use the compile > methods to get a CompiledScript that can be evaluated with multiple > bindings or script contexts. > > http://docs.oracle.com/javase/7/docs/api/javax/script/Compilable.html > > Also, we have been improving reuse of compiled scripts since the initial > JDK8 release, so later versions of Nashorn may work better. You probably > should use JDK 8u20 or even a 8u40 preview release (avalable at < > https://jdk8.java.net/>). In those releases, we have added caching of > compiled scripts within the script engine, so even plain eval() should be > faster as long as you use multiple globals/bindings within the same engine. > > I hope this helps. Let us know how it goes! > > Hannes > > Am 2014-10-30 um 14:09 schrieb yikes aroni: > >> Hi ... I?m using nashorn by embedding it in Java (not via command-line). I >> can make it work, but I have a two primary challenges: 1) speed of >> execution; and 2) thread safety. >> >> >> >> I have a ?base? JS library that I compile more or less like this: >> >> >> >> ScriptEngineManager *factory* = *new* ScriptEngineManager(); >> >> ScriptEngine *baseEngine* = *factory*.getEngineByName("nashorn"); >> >> Compilable *baseCompilable* = (Compilable) *baseEngine*; >> >> baseCompilable.compile(*new* java.io.FileReader(*pathDsBase*)).eval(); >> >> >> >> where *pathDsBase* is a file system path to my javascript library. This >> library isn?t huge, but it takes about 500+ ms to compile and eval(). >> That?s a long time for my purposes, so I want to do it only once. >> >> >> >> Other parts of my code then launch multiple Java threads that do various >> work and occasionally invoke small, ?temporary? Javascript scripts that >> need to reference objects and functions in this ?base? library. Since I >> want these small scripts to run fast and thread-safe, I **could** simply >> create a brand new ScriptEngine every time I want to run one of these >> small, ?temporary? scripts and recompile the base library into it. Problem >> with that is that it takes too much time. >> >> >> >> I?ve tried a lot of approaches -- none have worked. >> >> >> >> My main approach (which has failed miserably at every turn) is to create a >> ?base? ScriptEngine, compile the ?base? library into it, then create a >> ?temporary? ScriptEngine and attempt to set the base bindings / context >> to >> it so that the temp ScriptEngine only eval()s the ?temp? script, but has >> the base library in scope. For example something like this test code: >> >> >> >> ScriptEngine tempEngine = engineFactory.getScriptEngine(); // a >> temporary engine. This is the one that will evaluate the ?small? scripts >> that reference the ?base? script library. >> >> ScriptContext ctxBase = *new* SimpleScriptContext(); >> >> ctxBase.setBindings(baseEngine.createBindings(), ScriptContext. >> *GLOBAL_SCOPE*); >> >> // evaluate a script at add it to base?s context. This is where >> the >> ?base? script libraries would be eval()-ed into the baseEngine context. >> >> baseEngine.eval("var y = 'hello';", ctxBase); >> >> >> >> // Now attempt to set the baseEngine?s bindings (which I >> assume have y = ?hello? in them (since I?m not clear where they end up, >> I?ve tried every possible combination or ENGINE and GLOBAL scope.) >> >> ScriptContext ctxTemp = *new* SimpleScriptContext(); >> >> ctxTemp.setBindings(baseEngine.createBindings(), ScriptContext. >> *ENGINE_SCOPE*); >> >> >> >> // Now for the temporary, ?small? script. The print references a >> variable (y) that I had hoped would be set to the temp engine?s scope from >> the ?base? engine?s context. >> >> String script = "var x = 'world'; print(y + x);"; >> >> tempEngine.eval(script, ctxTemp); >> >> >> >> Exception is Exception in thread "main" *javax.script.ScriptException*: >> ReferenceError: "y" is not defined in at line number 1 >> >> >> >> I?ve also tried using loadWithNewGlobal, which solves the threading issue, >> but doesn?t appear to solve the speed issue: the script has to be >> recompiled every time. >> >> >> >> I am sure I am barking up the wrong tree. Can somebody help point me in >> the >> right direction for how to do this? Again, my two primary questions are: >> >> >> >> 1) (Speed) Generally, how do I make it so that I don?t have to re-eval() a >> large library every time I want to run a script that references it? Or, >> more specifically, how can I reuse code compiled (eval()ed) by one engine >> (?base?) in another engine (?temp?)? >> >> 2) (Thread-safety) How do I reuse such a library in a way that running the >> subsequent ?temp? scripts doesn?t pollute the ?base? bindings that I?m >> reusing? >> >> >> >> I will be overjoyed if there is a clean solution to this. If not, I will >> still be happy to clear up this mystery with a ?can?t do that...? if that >> is, in fact, the answer.... >> >> >> >> thanks >> > > From tal.liron at threecrickets.com Thu Oct 30 14:33:10 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Thu, 30 Oct 2014 22:33:10 +0800 Subject: Reusing compiled JS code keeping speed and thread-safety In-Reply-To: References: Message-ID: <54524C26.3090804@threecrickets.com> As Hannes stated, you can use the lower-level CompiledScript directly, and avoid this "pollution", as you call it. The problem with ScriptEngine (JSR-223) is that it simply doesn't specify threading behavior, so you can't fault the Nashorn team for not adhering to a non-existent spec. If you look around at JSR-223 implementations of other language engines, you'll find a variety of (incompatible) approaches to the problem of threading. I think JSR-223 is simply not a good solution for concurrent applications (unless the implementation for a particular engine does the "right thing" in terms of your expectations). Sorry for self-advertising, but I do think it's relevant: this is exactly the reason why I created Scripturian as an alternative to JSR-223: http://threecrickets.com/scripturian/ The idea was to have a very strictly defined threading model for all engines, exactly so that you can embed them in high-concurrency applications. In some cases this proved impossible: Scala and Kotlin cannot be supported, it seems, do to their reliance on global singletons. But Nashorn, Rhino, Groovy, Quercus (PHP), Luaj, Jython, JRuby, Velocity and Succinct are. Note, though, that for Nashorn you want to use a recent build from the Mercurial repository. Also note that since Nashorn does not, at this point, support caching of compiled code to disk, this Scripturian feature is not supported for Nashorn. The consequence is that Nashorn applications have a *very* slow start-up as compared to other engines, as it needs to compiled all the code, though once it is up and running performance is generally excellent. On 10/30/2014 10:03 PM, Benjamin Sieffert wrote: > Hello there, > > we had a similar aim / similar issues with nashorn. Since I don't know your > code exactly, I'll just describe our case / what we ended up doing and > maybe you can get some ideas off that. > > We use one ScriptEngine. Among all our threads, just one engine. On > start-up we let it compile the library once. The library has no mutable > state and is not dependant on global variables. It's just a collection of > functions / classes. > Then we have a few hundred small javascripts that basically instantiate a > class defined by the library and do some configurations on that instance. > Any one of these scripts gets evaluated by the engine once and the returned > ScriptObjectMirror (the configured javascript object) is then kept on the > java side. As this ScriptObjectMirror also does not have any mutable state, > we can now safely use it among multiple threads via callMember(). > To get nice stack traces, we also wrap each small javascript into a > load()-call in the engine and name it. The library is also wrapped in a > load()-call. > > All approaches including some sort of mutable javascript-side state sadly > do not seem to be workable. The nashorn devs have (understandably) > explicitly stated that since javascript does not define multithreaded > semantics, they will not be implementing any. > Everything evaluated in a NashornScriptEngine keeps its original > context/global, even when seemingly "put" into another engine. You cannot > prevent pollution. I tried for some time. : ) > From yikesaroni at gmail.com Thu Oct 30 15:23:18 2014 From: yikesaroni at gmail.com (yikes aroni) Date: Thu, 30 Oct 2014 11:23:18 -0400 Subject: Reusing compiled JS code keeping speed and thread-safety In-Reply-To: References: Message-ID: Hi Benjamin -- thanks for your response. Interesting approach tho not sure if it'll work for my situation. A couple of questions: > *Any one of these scripts gets evaluated by the engine once and the returned ScriptObjectMirror* Do these ScriptObjectMirror objects have your library in scope somehow? That is, if you load library into the engine, then eval() a secondary script to get a ScriptObjectMirror, how can you call a function on it via callMember() if that function leverages functions/obj/props of the library? > *To get nice stack traces, we also wrap each small javascript into a load()-call in the engine and name it. The library is also wrapped in a load()-call.* Not clear to me. Any chance you could share a code snippet? thanks for your time and thoughts! On Thu, Oct 30, 2014 at 10:03 AM, Benjamin Sieffert < benjamin.sieffert at metrigo.de> wrote: > Hello there, > > we had a similar aim / similar issues with nashorn. Since I don't know > your code exactly, I'll just describe our case / what we ended up doing and > maybe you can get some ideas off that. > > We use one ScriptEngine. Among all our threads, just one engine. On > start-up we let it compile the library once. The library has no mutable > state and is not dependant on global variables. It's just a collection of > functions / classes. > Then we have a few hundred small javascripts that basically instantiate a > class defined by the library and do some configurations on that instance. > Any one of these scripts gets evaluated by the engine once and the returned > ScriptObjectMirror (the configured javascript object) is then kept on the > java side. As this ScriptObjectMirror also does not have any mutable state, > we can now safely use it among multiple threads via callMember(). > To get nice stack traces, we also wrap each small javascript into a > load()-call in the engine and name it. The library is also wrapped in a > load()-call. > > All approaches including some sort of mutable javascript-side state sadly > do not seem to be workable. The nashorn devs have (understandably) > explicitly stated that since javascript does not define multithreaded > semantics, they will not be implementing any. > Everything evaluated in a NashornScriptEngine keeps its original > context/global, even when seemingly "put" into another engine. You cannot > prevent pollution. I tried for some time. : ) > > Regards > > On 30 October 2014 14:09, yikes aroni wrote: > >> Hi ... I?m using nashorn by embedding it in Java (not via command-line). I >> can make it work, but I have a two primary challenges: 1) speed of >> execution; and 2) thread safety. >> >> >> >> I have a ?base? JS library that I compile more or less like this: >> >> >> >> ScriptEngineManager *factory* = *new* ScriptEngineManager(); >> >> ScriptEngine *baseEngine* = *factory*.getEngineByName("nashorn"); >> >> Compilable *baseCompilable* = (Compilable) *baseEngine*; >> >> baseCompilable.compile(*new* java.io.FileReader(*pathDsBase*)).eval(); >> >> >> >> where *pathDsBase* is a file system path to my javascript library. This >> library isn?t huge, but it takes about 500+ ms to compile and eval(). >> That?s a long time for my purposes, so I want to do it only once. >> >> >> >> Other parts of my code then launch multiple Java threads that do various >> work and occasionally invoke small, ?temporary? Javascript scripts that >> need to reference objects and functions in this ?base? library. Since I >> want these small scripts to run fast and thread-safe, I **could** simply >> create a brand new ScriptEngine every time I want to run one of these >> small, ?temporary? scripts and recompile the base library into it. Problem >> with that is that it takes too much time. >> >> >> >> I?ve tried a lot of approaches -- none have worked. >> >> >> >> My main approach (which has failed miserably at every turn) is to create a >> ?base? ScriptEngine, compile the ?base? library into it, then create a >> ?temporary? ScriptEngine and attempt to set the base bindings / context >> to >> it so that the temp ScriptEngine only eval()s the ?temp? script, but has >> the base library in scope. For example something like this test code: >> >> >> >> ScriptEngine tempEngine = engineFactory.getScriptEngine(); // a >> temporary engine. This is the one that will evaluate the ?small? scripts >> that reference the ?base? script library. >> >> ScriptContext ctxBase = *new* SimpleScriptContext(); >> >> ctxBase.setBindings(baseEngine.createBindings(), ScriptContext. >> *GLOBAL_SCOPE*); >> >> // evaluate a script at add it to base?s context. This is where the >> ?base? script libraries would be eval()-ed into the baseEngine context. >> >> baseEngine.eval("var y = 'hello';", ctxBase); >> >> >> >> // Now attempt to set the baseEngine?s bindings (which I >> assume have y = ?hello? in them (since I?m not clear where they end up, >> I?ve tried every possible combination or ENGINE and GLOBAL scope.) >> >> ScriptContext ctxTemp = *new* SimpleScriptContext(); >> >> ctxTemp.setBindings(baseEngine.createBindings(), ScriptContext. >> *ENGINE_SCOPE*); >> >> >> >> // Now for the temporary, ?small? script. The print references a >> variable (y) that I had hoped would be set to the temp engine?s scope from >> the ?base? engine?s context. >> >> String script = "var x = 'world'; print(y + x);"; >> >> tempEngine.eval(script, ctxTemp); >> >> >> >> Exception is Exception in thread "main" *javax.script.ScriptException*: >> ReferenceError: "y" is not defined in at line number 1 >> >> >> >> I?ve also tried using loadWithNewGlobal, which solves the threading issue, >> but doesn?t appear to solve the speed issue: the script has to be >> recompiled every time. >> >> >> >> I am sure I am barking up the wrong tree. Can somebody help point me in >> the >> right direction for how to do this? Again, my two primary questions are: >> >> >> >> 1) (Speed) Generally, how do I make it so that I don?t have to re-eval() a >> large library every time I want to run a script that references it? Or, >> more specifically, how can I reuse code compiled (eval()ed) by one engine >> (?base?) in another engine (?temp?)? >> >> 2) (Thread-safety) How do I reuse such a library in a way that running the >> subsequent ?temp? scripts doesn?t pollute the ?base? bindings that I?m >> reusing? >> >> >> >> I will be overjoyed if there is a clean solution to this. If not, I will >> still be happy to clear up this mystery with a ?can?t do that...? if that >> is, in fact, the answer.... >> >> >> >> thanks >> > > > > -- > Benjamin Sieffert > metrigo GmbH > Sternstr. 106 > 20357 Hamburg > > Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, > Martin Rie? > Die Gesellschaft ist eingetragen beim Registergericht Hamburg > Nr. HRB 120447. > From hannes.wallnoefer at oracle.com Thu Oct 30 16:00:22 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 30 Oct 2014 17:00:22 +0100 Subject: Review request for JDK-8062132: Nashorn incorrectly binds "this" for constructor created by another function Message-ID: <54526096.6040108@oracle.com> Please review JDK-8062132: Nashorn incorrectly binds "this" for constructor created by another function: http://cr.openjdk.java.net/~hannesw/8062132/ thanks, Hannes From james.laskey at oracle.com Thu Oct 30 16:14:32 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 30 Oct 2014 13:14:32 -0300 Subject: Review request for JDK-8062132: Nashorn incorrectly binds "this" for constructor created by another function In-Reply-To: <54526096.6040108@oracle.com> References: <54526096.6040108@oracle.com> Message-ID: <89CB2D67-572D-49F8-BD00-DAA311612F5D@oracle.com> +1 On Oct 30, 2014, at 1:00 PM, Hannes Wallnoefer wrote: > Please review JDK-8062132: Nashorn incorrectly binds "this" for constructor created by another function: > > http://cr.openjdk.java.net/~hannesw/8062132/ > > thanks, > Hannes From benjamin.sieffert at metrigo.de Thu Oct 30 16:33:07 2014 From: benjamin.sieffert at metrigo.de (Benjamin Sieffert) Date: Thu, 30 Oct 2014 17:33:07 +0100 Subject: Reusing compiled JS code keeping speed and thread-safety In-Reply-To: References: Message-ID: Hello again, if they are eval'ed in the same engine, they will have the library in scope, yes. This is exactly why transferring contexts does not work: All the objects keep working with the context they were created in. Example: engine.eval("function add(a, b) { return a + b; }"); ScriptObjectMirror m = engine.eval("obj = { twice: function(n) { return add(n, n); } }"); m.callMember("twice", 2); // returns 4 You can find the documentation for load with the nashorn docs. It's just a global function that takes an object with fields "name" and "script". It will load (eval) the script and scope its stack traces under the given name. String lib = "function add(a, b) { return a + b; }; \n function broken() { throw 'error!'; };"; engine.put("library", lib); engine.eval("load( { 'name' : 'my library', script: library });"); engine.eval("broken()"); // ScriptException: error! in my library at line number 2 at column number 21 (Putting the String into the engine as a variable is just for readability. You could just inline the code into the call to load. Remember to escape it properly.) Glad if I can help. :) On 30 October 2014 16:23, yikes aroni wrote: > Hi Benjamin -- thanks for your response. Interesting approach tho not sure > if it'll work for my situation. A couple of questions: > > > *Any one of these scripts gets evaluated by the engine once and the > returned ScriptObjectMirror* > Do these ScriptObjectMirror objects have your library in scope somehow? > That is, if you load library into the engine, then eval() a secondary > script to get a ScriptObjectMirror, how can you call a function on it via > callMember() if that function leverages functions/obj/props of the library? > > > *To get nice stack traces, we also wrap each small javascript into a > load()-call in the engine and name it. The library is also wrapped in a > load()-call.* > Not clear to me. Any chance you could share a code snippet? > > thanks for your time and thoughts! > > > On Thu, Oct 30, 2014 at 10:03 AM, Benjamin Sieffert < > benjamin.sieffert at metrigo.de> wrote: > >> Hello there, >> >> we had a similar aim / similar issues with nashorn. Since I don't know >> your code exactly, I'll just describe our case / what we ended up doing and >> maybe you can get some ideas off that. >> >> We use one ScriptEngine. Among all our threads, just one engine. On >> start-up we let it compile the library once. The library has no mutable >> state and is not dependant on global variables. It's just a collection of >> functions / classes. >> Then we have a few hundred small javascripts that basically instantiate a >> class defined by the library and do some configurations on that instance. >> Any one of these scripts gets evaluated by the engine once and the returned >> ScriptObjectMirror (the configured javascript object) is then kept on the >> java side. As this ScriptObjectMirror also does not have any mutable state, >> we can now safely use it among multiple threads via callMember(). >> To get nice stack traces, we also wrap each small javascript into a >> load()-call in the engine and name it. The library is also wrapped in a >> load()-call. >> >> All approaches including some sort of mutable javascript-side state sadly >> do not seem to be workable. The nashorn devs have (understandably) >> explicitly stated that since javascript does not define multithreaded >> semantics, they will not be implementing any. >> Everything evaluated in a NashornScriptEngine keeps its original >> context/global, even when seemingly "put" into another engine. You cannot >> prevent pollution. I tried for some time. : ) >> >> Regards >> >> On 30 October 2014 14:09, yikes aroni wrote: >> >>> Hi ... I?m using nashorn by embedding it in Java (not via command-line). >>> I >>> can make it work, but I have a two primary challenges: 1) speed of >>> execution; and 2) thread safety. >>> >>> >>> >>> I have a ?base? JS library that I compile more or less like this: >>> >>> >>> >>> ScriptEngineManager *factory* = *new* ScriptEngineManager(); >>> >>> ScriptEngine *baseEngine* = *factory*.getEngineByName("nashorn"); >>> >>> Compilable *baseCompilable* = (Compilable) *baseEngine*; >>> >>> baseCompilable.compile(*new* java.io.FileReader(*pathDsBase*)).eval(); >>> >>> >>> >>> where *pathDsBase* is a file system path to my javascript library. This >>> library isn?t huge, but it takes about 500+ ms to compile and eval(). >>> That?s a long time for my purposes, so I want to do it only once. >>> >>> >>> >>> Other parts of my code then launch multiple Java threads that do various >>> work and occasionally invoke small, ?temporary? Javascript scripts that >>> need to reference objects and functions in this ?base? library. Since I >>> want these small scripts to run fast and thread-safe, I **could** simply >>> create a brand new ScriptEngine every time I want to run one of these >>> small, ?temporary? scripts and recompile the base library into it. >>> Problem >>> with that is that it takes too much time. >>> >>> >>> >>> I?ve tried a lot of approaches -- none have worked. >>> >>> >>> >>> My main approach (which has failed miserably at every turn) is to create >>> a >>> ?base? ScriptEngine, compile the ?base? library into it, then create a >>> ?temporary? ScriptEngine and attempt to set the base bindings / context >>> to >>> it so that the temp ScriptEngine only eval()s the ?temp? script, but has >>> the base library in scope. For example something like this test code: >>> >>> >>> >>> ScriptEngine tempEngine = engineFactory.getScriptEngine(); // a >>> temporary engine. This is the one that will evaluate the ?small? scripts >>> that reference the ?base? script library. >>> >>> ScriptContext ctxBase = *new* SimpleScriptContext(); >>> >>> ctxBase.setBindings(baseEngine.createBindings(), ScriptContext. >>> *GLOBAL_SCOPE*); >>> >>> // evaluate a script at add it to base?s context. This is where >>> the >>> ?base? script libraries would be eval()-ed into the baseEngine context. >>> >>> baseEngine.eval("var y = 'hello';", ctxBase); >>> >>> >>> >>> // Now attempt to set the baseEngine?s bindings (which I >>> assume have y = ?hello? in them (since I?m not clear where they end up, >>> I?ve tried every possible combination or ENGINE and GLOBAL scope.) >>> >>> ScriptContext ctxTemp = *new* SimpleScriptContext(); >>> >>> ctxTemp.setBindings(baseEngine.createBindings(), ScriptContext. >>> *ENGINE_SCOPE*); >>> >>> >>> >>> // Now for the temporary, ?small? script. The print references a >>> variable (y) that I had hoped would be set to the temp engine?s scope >>> from >>> the ?base? engine?s context. >>> >>> String script = "var x = 'world'; print(y + x);"; >>> >>> tempEngine.eval(script, ctxTemp); >>> >>> >>> >>> Exception is Exception in thread "main" *javax.script.ScriptException*: >>> ReferenceError: "y" is not defined in at line number 1 >>> >>> >>> >>> I?ve also tried using loadWithNewGlobal, which solves the threading >>> issue, >>> but doesn?t appear to solve the speed issue: the script has to be >>> recompiled every time. >>> >>> >>> >>> I am sure I am barking up the wrong tree. Can somebody help point me in >>> the >>> right direction for how to do this? Again, my two primary questions are: >>> >>> >>> >>> 1) (Speed) Generally, how do I make it so that I don?t have to re-eval() >>> a >>> large library every time I want to run a script that references it? Or, >>> more specifically, how can I reuse code compiled (eval()ed) by one engine >>> (?base?) in another engine (?temp?)? >>> >>> 2) (Thread-safety) How do I reuse such a library in a way that running >>> the >>> subsequent ?temp? scripts doesn?t pollute the ?base? bindings that I?m >>> reusing? >>> >>> >>> >>> I will be overjoyed if there is a clean solution to this. If not, I will >>> still be happy to clear up this mystery with a ?can?t do that...? if that >>> is, in fact, the answer.... >>> >>> >>> >>> thanks >>> >> >> >> >> -- >> Benjamin Sieffert >> metrigo GmbH >> Sternstr. 106 >> 20357 Hamburg >> >> Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, >> Martin Rie? >> Die Gesellschaft ist eingetragen beim Registergericht Hamburg >> Nr. HRB 120447. >> > > -- Benjamin Sieffert metrigo GmbH Sternstr. 106 20357 Hamburg Gesch?ftsf?hrer: Christian M?ller, Tobias Schlottke, Philipp Westermeyer, Martin Rie? Die Gesellschaft ist eingetragen beim Registergericht Hamburg Nr. HRB 120447. From vladimir.x.ivanov at oracle.com Thu Oct 30 16:22:13 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 30 Oct 2014 20:22:13 +0400 Subject: Review request for JDK-8062401: User accessors require boxing and do not support optimistic types In-Reply-To: <756A8E88-DB55-40E9-9AA5-8074CBB30FE1@oracle.com> References: <54510AC0.9010005@oracle.com> <756A8E88-DB55-40E9-9AA5-8074CBB30FE1@oracle.com> Message-ID: <545265B5.4090306@oracle.com> > What are the performance implications? Have you done some octane runs or something? > > Furthermore, I?d like to see a comment in the benchmark you?ve added, what it?s for, a reference to the issue number JDK-8062401 in a comment and what the difference before and after was. > > Otherwise - solid work. Nicely done. > > Have you discussed with Vladimir Ivanov, the problem he had with box2d and the inlining site in UserAccessorProperty? Will this affect it and make it better? CC:ing Vladimir. I looked at box2d w/ the fix and inlining for accessors works fine. It improves Box2D peak performance by 10%. Good work, Hannes! Thanks for fixing this! Best regards, Vladimir Ivanov From bhaidri at linkedin.com Thu Oct 30 17:29:39 2014 From: bhaidri at linkedin.com (Baq Haidri) Date: Thu, 30 Oct 2014 17:29:39 +0000 Subject: Nashorn incorrectly binds "this" in constructors created and returned by another function In-Reply-To: <54521DCD.2000707@oracle.com> References: <, > <76526128-AA81-460C-8DC3-103EAA74D63C@oracle.com> <0045172AE22223459012420AFC04252B81DFECCB@ESV4-MB03.linkedin.biz> , <54521DCD.2000707@oracle.com> Message-ID: <0045172AE22223459012420AFC04252B81DFF285@ESV4-MB03.linkedin.biz> Thanks guys, that's great news. ----- baq ________________________________________ From: Hannes Wallnoefer [hannes.wallnoefer at oracle.com] Sent: Thursday, October 30, 2014 4:15 AM To: Marcus Lagergren; Baq Haidri Cc: nashorn-dev at openjdk.java.net; Mark Pascual Subject: Re: Nashorn incorrectly binds "this" in constructors created and returned by another function I have a fix for this and I'm currently running tests to verify it. This will definitley make it into 8u40. Hannes Am 2014-10-30 um 11:46 schrieb Marcus Lagergren: > Any bugfix we manage to check in before the end of November will make it into 8u40. Hannes has diagnosed the problem and this is a p2, which is the highest priority of all Nashorn bugs for 8u40 right now (no p1s are filed), so I would say it is very likely it will make it into 8u40. Hannes - can you elaborate? > > Regards > Marcus > >> On 29 Oct 2014, at 20:09, Baq Haidri wrote: >> >> +cpettitt at linkedin.com >> >> Hi Jim, >> >> Thanks for escalating this so quickly. This one's a pretty important for us as LinkedIn is looking to standardize our production fleet to 8u40 as soon as the GA release is available. Can you give us an idea of whether the fix will make it in to 8u40? >> >> ----- >> baq >> >> ________________________________________ >> From: Jim Laskey (Oracle) [james.laskey at oracle.com] >> Sent: Monday, October 27, 2014 12:09 PM >> To: Josh Fleming >> Cc: nashorn-dev at openjdk.java.net; Mark Pascual; Baq Haidri >> Subject: Re: Nashorn incorrectly binds "this" in constructors created and returned by another function >> >> Just to let you know this has been promoted to https://bugs.openjdk.java.net/browse/JDK-8062132. We are investigating. >> >> >> On Oct 27, 2014, at 4:03 PM, Josh Fleming wrote: >> >>> Hi folks, >>> >>> I filed a bug for this on the Oracle site (Review ID: JI-9016048), but was told that this list is the best place to discuss it. >>> >>> So this is a strange one. It seems that the latest release of Nashorn incorrectly binds "this" in a constructor function under the following conditions: >>> >>> * At least 2 level prototype hierarchy (for the sake of discussion let's call them Parent and Child) >>> * Child constructor functions are created and returned by a higher order "factory? function >>> * Child constructors call the Parent constructor, which uses ?this? >>> * Multiple Child prototypes share the same Parent prototype >>> * The Child prototypes disagree in the *number* of their properties >>> >>> When the second Child object instantiates, its constructor calls the Parent constructor, whose ?this? is incorrectly bound to a Parent object rather than the Child. >>> >>> Here's the jrunscript reduction (or https://gist.github.com/joshvfleming/0539f00dd12392483596): >>> >>> // -- BEGIN CODE -- >>> function subclass(parentConstructor, proto) { >>> function C() { >>> parentConstructor.call(this); >>> } >>> >>> C.prototype = Object.create(parentConstructor.prototype); >>> >>> for (var prop in proto) { >>> if (proto.hasOwnProperty(prop)) { >>> C.prototype[prop] = proto[prop]; >>> } >>> } >>> >>> return C; >>> } >>> >>> var Parent = function() { >>> this.init(); >>> }; >>> >>> Parent.prototype = { >>> init: null >>> } >>> >>> var Child1 = subclass(Parent, { >>> prop1: 1, >>> init: function() { >>> print('!!! child 1'); >>> } >>> }); >>> >>> var Child2 = subclass(Parent, { >>> init: function() { >>> print('!!! child 2'); >>> } >>> }); >>> >>> new Child1(); >>> new Child2(); >>> // -- END CODE -- >>> >>> Expected output: >>> >>> !!! child 1 >>> !!! child 2 >>> >>> Actual output: >>> >>> !!! child 1 >>> script error in file scripts/nashorn_this_binding_bug_reduction.js : TypeError: null is not a function in scripts/nashorn_this_binding_bug_reduction.js at line number 19 >>> >>> The script blows up at line 19 (see above or https://gist.github.com/joshvfleming/0539f00dd12392483596) when the Parent constructor tries to call "this.init()". This function has been overridden in the Child objects that we instantiate at the bottom, but Nashorn incorrectly binds "this" to the Parent object, whose ?init? is bound to "null" instead of an "init" function. >>> >>> One especially strange and interesting aspect of this is that it depends on the relative number of properties of the two Child prototypes. The reduction above fails because Child1 has the "prop1" property, but Child2 has none. If you add any property at all to Child2, the error goes away. If you add still another property, the error returns. >>> >>> Affected JRE: >>> >>> Java version "1.8.0_25" >>> Java(TM) SE Runtime Environment (build 1.8.0_25-b17) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) >>> >>> This bug appears to be a regression, as the following older JRE returns the "Expected" output: >>> >>> java version "1.8.0_05" >>> Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >>> >>> We?re stuck on 1.8.0_05 at this point, because one of our 3rd party libraries uses this inheritance pattern. >>> >>> >>> Thanks, >>> >>> jf >>> From david at code.davidpcaldwell.com Thu Oct 30 19:42:25 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Thu, 30 Oct 2014 15:42:25 -0400 Subject: Nashorn incorrectly binds "this" in constructors created and returned by another function In-Reply-To: <0045172AE22223459012420AFC04252B81DFF285@ESV4-MB03.linkedin.biz> References: <, > <76526128-AA81-460C-8DC3-103EAA74D63C@oracle.com> <0045172AE22223459012420AFC04252B81DFECCB@ESV4-MB03.linkedin.biz> , <54521DCD.2000707@oracle.com> <0045172AE22223459012420AFC04252B81DFF285@ESV4-MB03.linkedin.biz> Message-ID: <93581169-9A80-40D6-9F78-3180A2A495BA@code.davidpcaldwell.com> It looks plausible that this could be related to my Error prototype issue from a few weeks back. See http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003581.html So I?d be happy to test the fix, or Hannes, in that message there are detailed reproduction instructions for a test case I developed. ? David. On Oct 30, 2014, at 1:29 PM, Baq Haidri wrote: > Thanks guys, that's great news. > > ----- > baq > > ________________________________________ > From: Hannes Wallnoefer [hannes.wallnoefer at oracle.com] > Sent: Thursday, October 30, 2014 4:15 AM > To: Marcus Lagergren; Baq Haidri > Cc: nashorn-dev at openjdk.java.net; Mark Pascual > Subject: Re: Nashorn incorrectly binds "this" in constructors created and returned by another function > > I have a fix for this and I'm currently running tests to verify it. This > will definitley make it into 8u40. > > Hannes > > Am 2014-10-30 um 11:46 schrieb Marcus Lagergren: >> Any bugfix we manage to check in before the end of November will make it into 8u40. Hannes has diagnosed the problem and this is a p2, which is the highest priority of all Nashorn bugs for 8u40 right now (no p1s are filed), so I would say it is very likely it will make it into 8u40. Hannes - can you elaborate? >> >> Regards >> Marcus >> >>> On 29 Oct 2014, at 20:09, Baq Haidri wrote: >>> >>> +cpettitt at linkedin.com >>> >>> Hi Jim, >>> >>> Thanks for escalating this so quickly. This one's a pretty important for us as LinkedIn is looking to standardize our production fleet to 8u40 as soon as the GA release is available. Can you give us an idea of whether the fix will make it in to 8u40? >>> >>> ----- >>> baq >>> >>> ________________________________________ >>> From: Jim Laskey (Oracle) [james.laskey at oracle.com] >>> Sent: Monday, October 27, 2014 12:09 PM >>> To: Josh Fleming >>> Cc: nashorn-dev at openjdk.java.net; Mark Pascual; Baq Haidri >>> Subject: Re: Nashorn incorrectly binds "this" in constructors created and returned by another function >>> >>> Just to let you know this has been promoted to https://bugs.openjdk.java.net/browse/JDK-8062132. We are investigating. >>> >>> >>> On Oct 27, 2014, at 4:03 PM, Josh Fleming wrote: >>> >>>> Hi folks, >>>> >>>> I filed a bug for this on the Oracle site (Review ID: JI-9016048), but was told that this list is the best place to discuss it. >>>> >>>> So this is a strange one. It seems that the latest release of Nashorn incorrectly binds "this" in a constructor function under the following conditions: >>>> >>>> * At least 2 level prototype hierarchy (for the sake of discussion let's call them Parent and Child) >>>> * Child constructor functions are created and returned by a higher order "factory? function >>>> * Child constructors call the Parent constructor, which uses ?this? >>>> * Multiple Child prototypes share the same Parent prototype >>>> * The Child prototypes disagree in the *number* of their properties >>>> >>>> When the second Child object instantiates, its constructor calls the Parent constructor, whose ?this? is incorrectly bound to a Parent object rather than the Child. >>>> >>>> Here's the jrunscript reduction (or https://gist.github.com/joshvfleming/0539f00dd12392483596): >>>> >>>> // -- BEGIN CODE -- >>>> function subclass(parentConstructor, proto) { >>>> function C() { >>>> parentConstructor.call(this); >>>> } >>>> >>>> C.prototype = Object.create(parentConstructor.prototype); >>>> >>>> for (var prop in proto) { >>>> if (proto.hasOwnProperty(prop)) { >>>> C.prototype[prop] = proto[prop]; >>>> } >>>> } >>>> >>>> return C; >>>> } >>>> >>>> var Parent = function() { >>>> this.init(); >>>> }; >>>> >>>> Parent.prototype = { >>>> init: null >>>> } >>>> >>>> var Child1 = subclass(Parent, { >>>> prop1: 1, >>>> init: function() { >>>> print('!!! child 1'); >>>> } >>>> }); >>>> >>>> var Child2 = subclass(Parent, { >>>> init: function() { >>>> print('!!! child 2'); >>>> } >>>> }); >>>> >>>> new Child1(); >>>> new Child2(); >>>> // -- END CODE -- >>>> >>>> Expected output: >>>> >>>> !!! child 1 >>>> !!! child 2 >>>> >>>> Actual output: >>>> >>>> !!! child 1 >>>> script error in file scripts/nashorn_this_binding_bug_reduction.js : TypeError: null is not a function in scripts/nashorn_this_binding_bug_reduction.js at line number 19 >>>> >>>> The script blows up at line 19 (see above or https://gist.github.com/joshvfleming/0539f00dd12392483596) when the Parent constructor tries to call "this.init()". This function has been overridden in the Child objects that we instantiate at the bottom, but Nashorn incorrectly binds "this" to the Parent object, whose ?init? is bound to "null" instead of an "init" function. >>>> >>>> One especially strange and interesting aspect of this is that it depends on the relative number of properties of the two Child prototypes. The reduction above fails because Child1 has the "prop1" property, but Child2 has none. If you add any property at all to Child2, the error goes away. If you add still another property, the error returns. >>>> >>>> Affected JRE: >>>> >>>> Java version "1.8.0_25" >>>> Java(TM) SE Runtime Environment (build 1.8.0_25-b17) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) >>>> >>>> This bug appears to be a regression, as the following older JRE returns the "Expected" output: >>>> >>>> java version "1.8.0_05" >>>> Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >>>> >>>> We?re stuck on 1.8.0_05 at this point, because one of our 3rd party libraries uses this inheritance pattern. >>>> >>>> >>>> Thanks, >>>> >>>> jf >>>> > From hannes.wallnoefer at oracle.com Thu Oct 30 21:35:52 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 30 Oct 2014 22:35:52 +0100 Subject: Nashorn incorrectly binds "this" in constructors created and returned by another function In-Reply-To: <93581169-9A80-40D6-9F78-3180A2A495BA@code.davidpcaldwell.com> References: <, > <76526128-AA81-460C-8DC3-103EAA74D63C@oracle.com> <0045172AE22223459012420AFC04252B81DFECCB@ESV4-MB03.linkedin.biz> , <54521DCD.2000707@oracle.com> <0045172AE22223459012420AFC04252B81DFF285@ESV4-MB03.linkedin.biz> <93581169-9A80-40D6-9F78-3180A2A495BA@code.davidpcaldwell.com> Message-ID: <5452AF38.6050407@oracle.com> It's true that this looks very similar, but it's actually a different issue. I filed a bug for it: https://bugs.openjdk.java.net/browse/JDK-8062583 Regarding the original bug: I have a fix ready and I'll push it as soon as I get a second review. http://cr.openjdk.java.net/~hannesw/8062132/ Hannes Am 2014-10-30 um 20:42 schrieb David P. Caldwell: > It looks plausible that this could be related to my Error prototype > issue from a few weeks back. > > See > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003581.html > > So I?d be happy to test the fix, or Hannes, in that message there are > detailed reproduction instructions for a test case I developed. > > ? David. > On Oct 30, 2014, at 1:29 PM, Baq Haidri > wrote: > >> Thanks guys, that's great news. >> >> ----- >> baq >> >> ________________________________________ >> From: Hannes Wallnoefer [hannes.wallnoefer at oracle.com >> ] >> Sent: Thursday, October 30, 2014 4:15 AM >> To: Marcus Lagergren; Baq Haidri >> Cc: nashorn-dev at openjdk.java.net >> ; Mark Pascual >> Subject: Re: Nashorn incorrectly binds "this" in constructors created >> and returned by another function >> >> I have a fix for this and I'm currently running tests to verify it. This >> will definitley make it into 8u40. >> >> Hannes >> >> Am 2014-10-30 um 11:46 schrieb Marcus Lagergren: >>> Any bugfix we manage to check in before the end of November will >>> make it into 8u40. Hannes has diagnosed the problem and this is a >>> p2, which is the highest priority of all Nashorn bugs for 8u40 right >>> now (no p1s are filed), so I would say it is very likely it will >>> make it into 8u40. Hannes - can you elaborate? >>> >>> Regards >>> Marcus >>> >>>> On 29 Oct 2014, at 20:09, Baq Haidri >>> > wrote: >>>> >>>> +cpettitt at linkedin.com >>>> >>>> Hi Jim, >>>> >>>> Thanks for escalating this so quickly. This one's a pretty >>>> important for us as LinkedIn is looking to standardize our >>>> production fleet to 8u40 as soon as the GA release is available. >>>> Can you give us an idea of whether the fix will make it in to 8u40? >>>> >>>> ----- >>>> baq >>>> >>>> ________________________________________ >>>> From: Jim Laskey (Oracle) [james.laskey at oracle.com >>>> ] >>>> Sent: Monday, October 27, 2014 12:09 PM >>>> To: Josh Fleming >>>> Cc: nashorn-dev at openjdk.java.net >>>> ; Mark Pascual; Baq Haidri >>>> Subject: Re: Nashorn incorrectly binds "this" in constructors >>>> created and returned by another function >>>> >>>> Just to let you know this has been promoted to >>>> https://bugs.openjdk.java.net/browse/JDK-8062132. We are >>>> investigating. >>>> >>>> >>>> On Oct 27, 2014, at 4:03 PM, Josh Fleming >>> > wrote: >>>> >>>>> Hi folks, >>>>> >>>>> I filed a bug for this on the Oracle site (Review ID: JI-9016048), >>>>> but was told that this list is the best place to discuss it. >>>>> >>>>> So this is a strange one. It seems that the latest release of >>>>> Nashorn incorrectly binds "this" in a constructor function under >>>>> the following conditions: >>>>> >>>>> * At least 2 level prototype hierarchy (for the sake of discussion >>>>> let's call them Parent and Child) >>>>> * Child constructor functions are created and returned by a higher >>>>> order "factory? function >>>>> * Child constructors call the Parent constructor, which uses ?this? >>>>> * Multiple Child prototypes share the same Parent prototype >>>>> * The Child prototypes disagree in the *number* of their properties >>>>> >>>>> When the second Child object instantiates, its constructor calls >>>>> the Parent constructor, whose ?this? is incorrectly bound to a >>>>> Parent object rather than the Child. >>>>> >>>>> Here's the jrunscript reduction (or >>>>> https://gist.github.com/joshvfleming/0539f00dd12392483596): >>>>> >>>>> // -- BEGIN CODE -- >>>>> function subclass(parentConstructor, proto) { >>>>> function C() { >>>>> parentConstructor.call(this); >>>>> } >>>>> >>>>> C.prototype = Object.create(parentConstructor.prototype); >>>>> >>>>> for (var prop in proto) { >>>>> if (proto.hasOwnProperty(prop)) { >>>>> C.prototype[prop] = proto[prop]; >>>>> } >>>>> } >>>>> >>>>> return C; >>>>> } >>>>> >>>>> var Parent = function() { >>>>> this.init(); >>>>> }; >>>>> >>>>> Parent.prototype = { >>>>> init: null >>>>> } >>>>> >>>>> var Child1 = subclass(Parent, { >>>>> prop1: 1, >>>>> init: function() { >>>>> print('!!! child 1'); >>>>> } >>>>> }); >>>>> >>>>> var Child2 = subclass(Parent, { >>>>> init: function() { >>>>> print('!!! child 2'); >>>>> } >>>>> }); >>>>> >>>>> new Child1(); >>>>> new Child2(); >>>>> // -- END CODE -- >>>>> >>>>> Expected output: >>>>> >>>>> !!! child 1 >>>>> !!! child 2 >>>>> >>>>> Actual output: >>>>> >>>>> !!! child 1 >>>>> script error in file scripts/nashorn_this_binding_bug_reduction.js >>>>> : TypeError: null is not a function in >>>>> scripts/nashorn_this_binding_bug_reduction.js at line number 19 >>>>> >>>>> The script blows up at line 19 (see above or >>>>> https://gist.github.com/joshvfleming/0539f00dd12392483596) when >>>>> the Parent constructor tries to call "this.init()". This function >>>>> has been overridden in the Child objects that we instantiate at >>>>> the bottom, but Nashorn incorrectly binds "this" to the Parent >>>>> object, whose ?init? is bound to "null" instead of an "init" function. >>>>> >>>>> One especially strange and interesting aspect of this is that it >>>>> depends on the relative number of properties of the two Child >>>>> prototypes. The reduction above fails because Child1 has the >>>>> "prop1" property, but Child2 has none. If you add any property at >>>>> all to Child2, the error goes away. If you add still another >>>>> property, the error returns. >>>>> >>>>> Affected JRE: >>>>> >>>>> Java version "1.8.0_25" >>>>> Java(TM) SE Runtime Environment (build 1.8.0_25-b17) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) >>>>> >>>>> This bug appears to be a regression, as the following older JRE >>>>> returns the "Expected" output: >>>>> >>>>> java version "1.8.0_05" >>>>> Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >>>>> >>>>> We?re stuck on 1.8.0_05 at this point, because one of our 3rd >>>>> party libraries uses this inheritance pattern. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> jf >>>>> >> > From sundararajan.athijegannathan at oracle.com Fri Oct 31 03:05:06 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 31 Oct 2014 08:35:06 +0530 Subject: Nashorn incorrectly binds "this" in constructors created and returned by another function In-Reply-To: <5452AF38.6050407@oracle.com> References: <, > <76526128-AA81-460C-8DC3-103EAA74D63C@oracle.com> <0045172AE22223459012420AFC04252B81DFECCB@ESV4-MB03.linkedin.biz> , <54521DCD.2000707@oracle.com> <0045172AE22223459012420AFC04252B81DFF285@ESV4-MB03.linkedin.biz> <93581169-9A80-40D6-9F78-3180A2A495BA@code.davidpcaldwell.com> <5452AF38.6050407@oracle.com> Message-ID: <5452FC62.9040500@oracle.com> +1 on the review request. -Sundar On Friday 31 October 2014 03:05 AM, Hannes Wallnoefer wrote: > It's true that this looks very similar, but it's actually a different > issue. I filed a bug for it: > > https://bugs.openjdk.java.net/browse/JDK-8062583 > > Regarding the original bug: I have a fix ready and I'll push it as > soon as I get a second review. > > http://cr.openjdk.java.net/~hannesw/8062132/ > > Hannes > > Am 2014-10-30 um 20:42 schrieb David P. Caldwell: >> It looks plausible that this could be related to my Error prototype >> issue from a few weeks back. >> >> See >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-October/003581.html >> >> So I?d be happy to test the fix, or Hannes, in that message there are >> detailed reproduction instructions for a test case I developed. >> >> ? David. >> On Oct 30, 2014, at 1:29 PM, Baq Haidri > > wrote: >> >>> Thanks guys, that's great news. >>> >>> ----- >>> baq >>> >>> ________________________________________ >>> From: Hannes Wallnoefer [hannes.wallnoefer at oracle.com >>> ] >>> Sent: Thursday, October 30, 2014 4:15 AM >>> To: Marcus Lagergren; Baq Haidri >>> Cc: nashorn-dev at openjdk.java.net >>> ; Mark Pascual >>> Subject: Re: Nashorn incorrectly binds "this" in constructors >>> created and returned by another function >>> >>> I have a fix for this and I'm currently running tests to verify it. >>> This >>> will definitley make it into 8u40. >>> >>> Hannes >>> >>> Am 2014-10-30 um 11:46 schrieb Marcus Lagergren: >>>> Any bugfix we manage to check in before the end of November will >>>> make it into 8u40. Hannes has diagnosed the problem and this is a >>>> p2, which is the highest priority of all Nashorn bugs for 8u40 >>>> right now (no p1s are filed), so I would say it is very likely it >>>> will make it into 8u40. Hannes - can you elaborate? >>>> >>>> Regards >>>> Marcus >>>> >>>>> On 29 Oct 2014, at 20:09, Baq Haidri >>>> > wrote: >>>>> >>>>> +cpettitt at linkedin.com >>>>> >>>>> Hi Jim, >>>>> >>>>> Thanks for escalating this so quickly. This one's a pretty >>>>> important for us as LinkedIn is looking to standardize our >>>>> production fleet to 8u40 as soon as the GA release is available. >>>>> Can you give us an idea of whether the fix will make it in to 8u40? >>>>> >>>>> ----- >>>>> baq >>>>> >>>>> ________________________________________ >>>>> From: Jim Laskey (Oracle) [james.laskey at oracle.com >>>>> ] >>>>> Sent: Monday, October 27, 2014 12:09 PM >>>>> To: Josh Fleming >>>>> Cc: nashorn-dev at openjdk.java.net >>>>> ; Mark Pascual; Baq Haidri >>>>> Subject: Re: Nashorn incorrectly binds "this" in constructors >>>>> created and returned by another function >>>>> >>>>> Just to let you know this has been promoted to >>>>> https://bugs.openjdk.java.net/browse/JDK-8062132. We are >>>>> investigating. >>>>> >>>>> >>>>> On Oct 27, 2014, at 4:03 PM, Josh Fleming >>>> > wrote: >>>>> >>>>>> Hi folks, >>>>>> >>>>>> I filed a bug for this on the Oracle site (Review ID: >>>>>> JI-9016048), but was told that this list is the best place to >>>>>> discuss it. >>>>>> >>>>>> So this is a strange one. It seems that the latest release of >>>>>> Nashorn incorrectly binds "this" in a constructor function under >>>>>> the following conditions: >>>>>> >>>>>> * At least 2 level prototype hierarchy (for the sake of >>>>>> discussion let's call them Parent and Child) >>>>>> * Child constructor functions are created and returned by a >>>>>> higher order "factory? function >>>>>> * Child constructors call the Parent constructor, which uses ?this? >>>>>> * Multiple Child prototypes share the same Parent prototype >>>>>> * The Child prototypes disagree in the *number* of their properties >>>>>> >>>>>> When the second Child object instantiates, its constructor calls >>>>>> the Parent constructor, whose ?this? is incorrectly bound to a >>>>>> Parent object rather than the Child. >>>>>> >>>>>> Here's the jrunscript reduction (or >>>>>> https://gist.github.com/joshvfleming/0539f00dd12392483596): >>>>>> >>>>>> // -- BEGIN CODE -- >>>>>> function subclass(parentConstructor, proto) { >>>>>> function C() { >>>>>> parentConstructor.call(this); >>>>>> } >>>>>> >>>>>> C.prototype = Object.create(parentConstructor.prototype); >>>>>> >>>>>> for (var prop in proto) { >>>>>> if (proto.hasOwnProperty(prop)) { >>>>>> C.prototype[prop] = proto[prop]; >>>>>> } >>>>>> } >>>>>> >>>>>> return C; >>>>>> } >>>>>> >>>>>> var Parent = function() { >>>>>> this.init(); >>>>>> }; >>>>>> >>>>>> Parent.prototype = { >>>>>> init: null >>>>>> } >>>>>> >>>>>> var Child1 = subclass(Parent, { >>>>>> prop1: 1, >>>>>> init: function() { >>>>>> print('!!! child 1'); >>>>>> } >>>>>> }); >>>>>> >>>>>> var Child2 = subclass(Parent, { >>>>>> init: function() { >>>>>> print('!!! child 2'); >>>>>> } >>>>>> }); >>>>>> >>>>>> new Child1(); >>>>>> new Child2(); >>>>>> // -- END CODE -- >>>>>> >>>>>> Expected output: >>>>>> >>>>>> !!! child 1 >>>>>> !!! child 2 >>>>>> >>>>>> Actual output: >>>>>> >>>>>> !!! child 1 >>>>>> script error in file >>>>>> scripts/nashorn_this_binding_bug_reduction.js : TypeError: null >>>>>> is not a function in >>>>>> scripts/nashorn_this_binding_bug_reduction.js at line number 19 >>>>>> >>>>>> The script blows up at line 19 (see above or >>>>>> https://gist.github.com/joshvfleming/0539f00dd12392483596) when >>>>>> the Parent constructor tries to call "this.init()". This function >>>>>> has been overridden in the Child objects that we instantiate at >>>>>> the bottom, but Nashorn incorrectly binds "this" to the Parent >>>>>> object, whose ?init? is bound to "null" instead of an "init" >>>>>> function. >>>>>> >>>>>> One especially strange and interesting aspect of this is that it >>>>>> depends on the relative number of properties of the two Child >>>>>> prototypes. The reduction above fails because Child1 has the >>>>>> "prop1" property, but Child2 has none. If you add any property at >>>>>> all to Child2, the error goes away. If you add still another >>>>>> property, the error returns. >>>>>> >>>>>> Affected JRE: >>>>>> >>>>>> Java version "1.8.0_25" >>>>>> Java(TM) SE Runtime Environment (build 1.8.0_25-b17) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) >>>>>> >>>>>> This bug appears to be a regression, as the following older JRE >>>>>> returns the "Expected" output: >>>>>> >>>>>> java version "1.8.0_05" >>>>>> Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >>>>>> >>>>>> We?re stuck on 1.8.0_05 at this point, because one of our 3rd >>>>>> party libraries uses this inheritance pattern. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> jf >>>>>> >>> >> > From marcus.lagergren at oracle.com Fri Oct 31 09:11:18 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 31 Oct 2014 10:11:18 +0100 Subject: Review request for JDK-8062132: Nashorn incorrectly binds "this" for constructor created by another function In-Reply-To: <54526096.6040108@oracle.com> References: <54526096.6040108@oracle.com> Message-ID: <82EA1175-E312-4F87-A8A9-0ED52AAD4CF6@oracle.com> Any performance implications? Otherwise +1 /M > On 30 Oct 2014, at 17:00, Hannes Wallnoefer wrote: > > Please review JDK-8062132: Nashorn incorrectly binds "this" for constructor created by another function: > > http://cr.openjdk.java.net/~hannesw/8062132/ > > thanks, > Hannes From marcus.lagergren at oracle.com Fri Oct 31 09:13:41 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 31 Oct 2014 10:13:41 +0100 Subject: Review request for JDK-8062401: User accessors require boxing and do not support optimistic types In-Reply-To: <545265B5.4090306@oracle.com> References: <54510AC0.9010005@oracle.com> <756A8E88-DB55-40E9-9AA5-8074CBB30FE1@oracle.com> <545265B5.4090306@oracle.com> Message-ID: <5D2B285D-68A3-4B75-93D6-24815EAD8922@oracle.com> Awesome! You rock, Hannes! /M > On 30 Oct 2014, at 17:22, Vladimir Ivanov wrote: > >> What are the performance implications? Have you done some octane runs or something? >> >> Furthermore, I?d like to see a comment in the benchmark you?ve added, what it?s for, a reference to the issue number JDK-8062401 in a comment and what the difference before and after was. >> >> Otherwise - solid work. Nicely done. >> >> Have you discussed with Vladimir Ivanov, the problem he had with box2d and the inlining site in UserAccessorProperty? Will this affect it and make it better? CC:ing Vladimir. > I looked at box2d w/ the fix and inlining for accessors works fine. It improves Box2D peak performance by 10%. > > Good work, Hannes! Thanks for fixing this! > > Best regards, > Vladimir Ivanov > From hannes.wallnoefer at oracle.com Fri Oct 31 09:29:19 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 31 Oct 2014 10:29:19 +0100 Subject: Review request for JDK-8062583: Throwing object with error prototype causes error proto to be caught Message-ID: <5453566F.1090805@oracle.com> Please review JDK-8062583: Throwing object with error prototype causes error proto to be caught: http://cr.openjdk.java.net/~hannesw/8062583/ Thanks, Hannes From hannes.wallnoefer at oracle.com Fri Oct 31 12:24:47 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 31 Oct 2014 13:24:47 +0100 Subject: Review request for JDK-8062132: Nashorn incorrectly binds "this" for constructor created by another function In-Reply-To: <82EA1175-E312-4F87-A8A9-0ED52AAD4CF6@oracle.com> References: <54526096.6040108@oracle.com> <82EA1175-E312-4F87-A8A9-0ED52AAD4CF6@oracle.com> Message-ID: <54537F8F.4010204@oracle.com> I don't see any change in performance. Sundar was concerned about heap usage with test262, but I saw no difference there as well. Hannes Am 2014-10-31 um 10:11 schrieb Marcus Lagergren: > Any performance implications? Otherwise +1 > > /M > >> On 30 Oct 2014, at 17:00, Hannes Wallnoefer wrote: >> >> Please review JDK-8062132: Nashorn incorrectly binds "this" for constructor created by another function: >> >> http://cr.openjdk.java.net/~hannesw/8062132/ >> >> thanks, >> Hannes From jfleming at linkedin.com Fri Oct 31 13:14:15 2014 From: jfleming at linkedin.com (Josh Fleming) Date: Fri, 31 Oct 2014 13:14:15 +0000 Subject: Nashorn incorrectly binds "this" in constructors created and returned by another function In-Reply-To: <54521DCD.2000707@oracle.com> References: <76526128-AA81-460C-8DC3-103EAA74D63C@oracle.com> <0045172AE22223459012420AFC04252B81DFECCB@ESV4-MB03.linkedin.biz> <54521DCD.2000707@oracle.com> Message-ID: That?s great news. Thanks for looking into it! jf On 10/30/14, 7:15 AM, "Hannes Wallnoefer" wrote: >I have a fix for this and I'm currently running tests to verify it. This >will definitley make it into 8u40. > >Hannes > >Am 2014-10-30 um 11:46 schrieb Marcus Lagergren: >> Any bugfix we manage to check in before the end of November will make >>it into 8u40. Hannes has diagnosed the problem and this is a p2, which >>is the highest priority of all Nashorn bugs for 8u40 right now (no p1s >>are filed), so I would say it is very likely it will make it into 8u40. >>Hannes - can you elaborate? >> >> Regards >> Marcus >> >>> On 29 Oct 2014, at 20:09, Baq Haidri wrote: >>> >>> +cpettitt at linkedin.com >>> >>> Hi Jim, >>> >>> Thanks for escalating this so quickly. This one's a pretty important >>>for us as LinkedIn is looking to standardize our production fleet to >>>8u40 as soon as the GA release is available. Can you give us an idea >>>of whether the fix will make it in to 8u40? >>> >>> ----- >>> baq >>> >>> ________________________________________ >>> From: Jim Laskey (Oracle) [james.laskey at oracle.com] >>> Sent: Monday, October 27, 2014 12:09 PM >>> To: Josh Fleming >>> Cc: nashorn-dev at openjdk.java.net; Mark Pascual; Baq Haidri >>> Subject: Re: Nashorn incorrectly binds "this" in constructors created >>>and returned by another function >>> >>> Just to let you know this has been promoted to >>>https://bugs.openjdk.java.net/browse/JDK-8062132. We are investigating. >>> >>> >>> On Oct 27, 2014, at 4:03 PM, Josh Fleming >>>wrote: >>> >>>> Hi folks, >>>> >>>> I filed a bug for this on the Oracle site (Review ID: JI-9016048), >>>>but was told that this list is the best place to discuss it. >>>> >>>> So this is a strange one. It seems that the latest release of Nashorn >>>>incorrectly binds "this" in a constructor function under the following >>>>conditions: >>>> >>>> * At least 2 level prototype hierarchy (for the sake of discussion >>>>let's call them Parent and Child) >>>> * Child constructor functions are created and returned by a higher >>>>order "factory? function >>>> * Child constructors call the Parent constructor, which uses ?this? >>>> * Multiple Child prototypes share the same Parent prototype >>>> * The Child prototypes disagree in the *number* of their properties >>>> >>>> When the second Child object instantiates, its constructor calls the >>>>Parent constructor, whose ?this? is incorrectly bound to a Parent >>>>object rather than the Child. >>>> >>>> Here's the jrunscript reduction (or >>>>https://gist.github.com/joshvfleming/0539f00dd12392483596): >>>> >>>> // -- BEGIN CODE -- >>>> function subclass(parentConstructor, proto) { >>>> function C() { >>>> parentConstructor.call(this); >>>> } >>>> >>>> C.prototype = Object.create(parentConstructor.prototype); >>>> >>>> for (var prop in proto) { >>>> if (proto.hasOwnProperty(prop)) { >>>> C.prototype[prop] = proto[prop]; >>>> } >>>> } >>>> >>>> return C; >>>> } >>>> >>>> var Parent = function() { >>>> this.init(); >>>> }; >>>> >>>> Parent.prototype = { >>>> init: null >>>> } >>>> >>>> var Child1 = subclass(Parent, { >>>> prop1: 1, >>>> init: function() { >>>> print('!!! child 1'); >>>> } >>>> }); >>>> >>>> var Child2 = subclass(Parent, { >>>> init: function() { >>>> print('!!! child 2'); >>>> } >>>> }); >>>> >>>> new Child1(); >>>> new Child2(); >>>> // -- END CODE -- >>>> >>>> Expected output: >>>> >>>> !!! child 1 >>>> !!! child 2 >>>> >>>> Actual output: >>>> >>>> !!! child 1 >>>> script error in file scripts/nashorn_this_binding_bug_reduction.js : >>>>TypeError: null is not a function in >>>>scripts/nashorn_this_binding_bug_reduction.js at line number 19 >>>> >>>> The script blows up at line 19 (see above or >>>>https://gist.github.com/joshvfleming/0539f00dd12392483596) when the >>>>Parent constructor tries to call "this.init()". This function has been >>>>overridden in the Child objects that we instantiate at the bottom, but >>>>Nashorn incorrectly binds "this" to the Parent object, whose ?init? is >>>>bound to "null" instead of an "init" function. >>>> >>>> One especially strange and interesting aspect of this is that it >>>>depends on the relative number of properties of the two Child >>>>prototypes. The reduction above fails because Child1 has the "prop1" >>>>property, but Child2 has none. If you add any property at all to >>>>Child2, the error goes away. If you add still another property, the >>>>error returns. >>>> >>>> Affected JRE: >>>> >>>> Java version "1.8.0_25" >>>> Java(TM) SE Runtime Environment (build 1.8.0_25-b17) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) >>>> >>>> This bug appears to be a regression, as the following older JRE >>>>returns the "Expected" output: >>>> >>>> java version "1.8.0_05" >>>> Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >>>> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >>>> >>>> We?re stuck on 1.8.0_05 at this point, because one of our 3rd party >>>>libraries uses this inheritance pattern. >>>> >>>> >>>> Thanks, >>>> >>>> jf >>>> > From smourachov at gmail.com Fri Oct 31 15:18:38 2014 From: smourachov at gmail.com (Serguei Mourachov) Date: Fri, 31 Oct 2014 08:18:38 -0700 Subject: Passing objects between Nashorn engines Message-ID: <5453A84E.4070904@gmail.com> I'm working on implementing automatic javascript code reloading. The process is implemented using following sequence: when I'm seeing any modification our our JS files, I'm preserving state of our system calling a function returning ScriptObjectMirror, creating new ScriptEngine, and initializing its state passing the ScriptObjectMirror to it. Apparently, it It works as expected in my simple tests, but it seems that the initial ScriptObjectMirror keeps reference to its original global and potentially to other old engine internals. So my question is: is that safe in to share ScriptObjectMirror objects between multiple engines and can I assume it's not going to create a memory leak, keeping all the previous engines in memory after I stopped using them? SM From james.laskey at oracle.com Fri Oct 31 15:25:35 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 31 Oct 2014 12:25:35 -0300 Subject: Review request for JDK-8062583: Throwing object with error prototype causes error proto to be caught In-Reply-To: <5453566F.1090805@oracle.com> References: <5453566F.1090805@oracle.com> Message-ID: <044E22EB-48CF-4308-8806-B40168A943BC@oracle.com> +1 On Oct 31, 2014, at 6:29 AM, Hannes Wallnoefer wrote: > Please review JDK-8062583: Throwing object with error prototype causes error proto to be caught: > > http://cr.openjdk.java.net/~hannesw/8062583/ > > Thanks, > Hannes From marcus.lagergren at oracle.com Fri Oct 31 16:35:36 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 31 Oct 2014 17:35:36 +0100 Subject: Review request for JDK-8062583: Throwing object with error prototype causes error proto to be caught In-Reply-To: <5453566F.1090805@oracle.com> References: <5453566F.1090805@oracle.com> Message-ID: <84F6CB2A-8DD7-49CA-85EA-A0A4832B1555@oracle.com> +1 /M > On 31 Oct 2014, at 10:29, Hannes Wallnoefer wrote: > > Please review JDK-8062583: Throwing object with error prototype causes error proto to be caught: > > http://cr.openjdk.java.net/~hannesw/8062583/ > > Thanks, > Hannes From marcus.lagergren at oracle.com Fri Oct 31 16:40:17 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 31 Oct 2014 17:40:17 +0100 Subject: Review request for JDK-8062132: Nashorn incorrectly binds "this" for constructor created by another function In-Reply-To: <54537F8F.4010204@oracle.com> References: <54526096.6040108@oracle.com> <82EA1175-E312-4F87-A8A9-0ED52AAD4CF6@oracle.com> <54537F8F.4010204@oracle.com> Message-ID: <2DB801BA-B8CB-4891-B0BB-EFF4CCE7A4F6@oracle.com> Ok that?s good. Messing with the prototype history cache could cause side effects that do anything anywhere, so I was a bit scared. ;) Glad it worked out. /M > On 31 Oct 2014, at 13:24, Hannes Wallnoefer wrote: > > I don't see any change in performance. Sundar was concerned about heap usage with test262, but I saw no difference there as well. > > Hannes > > > Am 2014-10-31 um 10:11 schrieb Marcus Lagergren: >> Any performance implications? Otherwise +1 >> >> /M >> >>> On 30 Oct 2014, at 17:00, Hannes Wallnoefer wrote: >>> >>> Please review JDK-8062132: Nashorn incorrectly binds "this" for constructor created by another function: >>> >>> http://cr.openjdk.java.net/~hannesw/8062132/ >>> >>> thanks, >>> Hannes > From david at code.davidpcaldwell.com Fri Oct 31 18:08:21 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Fri, 31 Oct 2014 14:08:21 -0400 Subject: Review request for JDK-8062583: Throwing object with error prototype causes error proto to be caught In-Reply-To: <84F6CB2A-8DD7-49CA-85EA-A0A4832B1555@oracle.com> References: <5453566F.1090805@oracle.com> <84F6CB2A-8DD7-49CA-85EA-A0A4832B1555@oracle.com> Message-ID: What's the process that determines whether this ends up in JDK 8? My reading of this is that it pertains to the JDK 9 repository only, but I'm not sure. -- David P. Caldwell http://www.davidpcaldwell.com/ On Fri, Oct 31, 2014 at 12:35 PM, Marcus Lagergren wrote: > +1 > > /M > >> On 31 Oct 2014, at 10:29, Hannes Wallnoefer wrote: >> >> Please review JDK-8062583: Throwing object with error prototype causes error proto to be caught: >> >> http://cr.openjdk.java.net/~hannesw/8062583/ >> >> Thanks, >> Hannes > From hannes.wallnoefer at oracle.com Fri Oct 31 19:29:42 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 31 Oct 2014 20:29:42 +0100 Subject: Review request for JDK-8062583: Throwing object with error prototype causes error proto to be caught In-Reply-To: References: <5453566F.1090805@oracle.com> <84F6CB2A-8DD7-49CA-85EA-A0A4832B1555@oracle.com> Message-ID: <5453E326.5070301@oracle.com> I pushed the fix to both JDK9 and 8u40, it will appear in some future preview release. You can view the "summary of changes" page to see if it made it to a specific release, e.g. here: https://jdk8.java.net/download.html Hannes Am 2014-10-31 um 19:08 schrieb David P. Caldwell: > What's the process that determines whether this ends up in JDK 8? My > reading of this is that it pertains to the JDK 9 repository only, but > I'm not sure. > > -- David P. Caldwell > http://www.davidpcaldwell.com/ > > On Fri, Oct 31, 2014 at 12:35 PM, Marcus Lagergren > wrote: >> +1 >> >> /M >> >>> On 31 Oct 2014, at 10:29, Hannes Wallnoefer wrote: >>> >>> Please review JDK-8062583: Throwing object with error prototype causes error proto to be caught: >>> >>> http://cr.openjdk.java.net/~hannesw/8062583/ >>> >>> Thanks, >>> Hannes From hannes.wallnoefer at oracle.com Fri Oct 31 19:36:17 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 31 Oct 2014 20:36:17 +0100 Subject: Nashorn incorrectly binds "this" in constructors created and returned by another function In-Reply-To: References: <76526128-AA81-460C-8DC3-103EAA74D63C@oracle.com> <0045172AE22223459012420AFC04252B81DFECCB@ESV4-MB03.linkedin.biz> <54521DCD.2000707@oracle.com> Message-ID: <5453E4B1.80108@oracle.com> I pushed the fix to JDK9 and 8u40. It should appear in some future early access release. Please check the "summary of changes" link to see if the fix is included in a build. https://jdk8.java.net/download.html Hannes Am 2014-10-31 um 14:14 schrieb Josh Fleming: > That?s great news. Thanks for looking into it! > > > jf > > > > > > On 10/30/14, 7:15 AM, "Hannes Wallnoefer" > wrote: > >> I have a fix for this and I'm currently running tests to verify it. This >> will definitley make it into 8u40. >> >> Hannes >> >> Am 2014-10-30 um 11:46 schrieb Marcus Lagergren: >>> Any bugfix we manage to check in before the end of November will make >>> it into 8u40. Hannes has diagnosed the problem and this is a p2, which >>> is the highest priority of all Nashorn bugs for 8u40 right now (no p1s >>> are filed), so I would say it is very likely it will make it into 8u40. >>> Hannes - can you elaborate? >>> >>> Regards >>> Marcus >>> >>>> On 29 Oct 2014, at 20:09, Baq Haidri wrote: >>>> >>>> +cpettitt at linkedin.com >>>> >>>> Hi Jim, >>>> >>>> Thanks for escalating this so quickly. This one's a pretty important >>>> for us as LinkedIn is looking to standardize our production fleet to >>>> 8u40 as soon as the GA release is available. Can you give us an idea >>>> of whether the fix will make it in to 8u40? >>>> >>>> ----- >>>> baq >>>> >>>> ________________________________________ >>>> From: Jim Laskey (Oracle) [james.laskey at oracle.com] >>>> Sent: Monday, October 27, 2014 12:09 PM >>>> To: Josh Fleming >>>> Cc: nashorn-dev at openjdk.java.net; Mark Pascual; Baq Haidri >>>> Subject: Re: Nashorn incorrectly binds "this" in constructors created >>>> and returned by another function >>>> >>>> Just to let you know this has been promoted to >>>> https://bugs.openjdk.java.net/browse/JDK-8062132. We are investigating. >>>> >>>> >>>> On Oct 27, 2014, at 4:03 PM, Josh Fleming >>>> wrote: >>>> >>>>> Hi folks, >>>>> >>>>> I filed a bug for this on the Oracle site (Review ID: JI-9016048), >>>>> but was told that this list is the best place to discuss it. >>>>> >>>>> So this is a strange one. It seems that the latest release of Nashorn >>>>> incorrectly binds "this" in a constructor function under the following >>>>> conditions: >>>>> >>>>> * At least 2 level prototype hierarchy (for the sake of discussion >>>>> let's call them Parent and Child) >>>>> * Child constructor functions are created and returned by a higher >>>>> order "factory? function >>>>> * Child constructors call the Parent constructor, which uses ?this? >>>>> * Multiple Child prototypes share the same Parent prototype >>>>> * The Child prototypes disagree in the *number* of their properties >>>>> >>>>> When the second Child object instantiates, its constructor calls the >>>>> Parent constructor, whose ?this? is incorrectly bound to a Parent >>>>> object rather than the Child. >>>>> >>>>> Here's the jrunscript reduction (or >>>>> https://gist.github.com/joshvfleming/0539f00dd12392483596): >>>>> >>>>> // -- BEGIN CODE -- >>>>> function subclass(parentConstructor, proto) { >>>>> function C() { >>>>> parentConstructor.call(this); >>>>> } >>>>> >>>>> C.prototype = Object.create(parentConstructor.prototype); >>>>> >>>>> for (var prop in proto) { >>>>> if (proto.hasOwnProperty(prop)) { >>>>> C.prototype[prop] = proto[prop]; >>>>> } >>>>> } >>>>> >>>>> return C; >>>>> } >>>>> >>>>> var Parent = function() { >>>>> this.init(); >>>>> }; >>>>> >>>>> Parent.prototype = { >>>>> init: null >>>>> } >>>>> >>>>> var Child1 = subclass(Parent, { >>>>> prop1: 1, >>>>> init: function() { >>>>> print('!!! child 1'); >>>>> } >>>>> }); >>>>> >>>>> var Child2 = subclass(Parent, { >>>>> init: function() { >>>>> print('!!! child 2'); >>>>> } >>>>> }); >>>>> >>>>> new Child1(); >>>>> new Child2(); >>>>> // -- END CODE -- >>>>> >>>>> Expected output: >>>>> >>>>> !!! child 1 >>>>> !!! child 2 >>>>> >>>>> Actual output: >>>>> >>>>> !!! child 1 >>>>> script error in file scripts/nashorn_this_binding_bug_reduction.js : >>>>> TypeError: null is not a function in >>>>> scripts/nashorn_this_binding_bug_reduction.js at line number 19 >>>>> >>>>> The script blows up at line 19 (see above or >>>>> https://gist.github.com/joshvfleming/0539f00dd12392483596) when the >>>>> Parent constructor tries to call "this.init()". This function has been >>>>> overridden in the Child objects that we instantiate at the bottom, but >>>>> Nashorn incorrectly binds "this" to the Parent object, whose ?init? is >>>>> bound to "null" instead of an "init" function. >>>>> >>>>> One especially strange and interesting aspect of this is that it >>>>> depends on the relative number of properties of the two Child >>>>> prototypes. The reduction above fails because Child1 has the "prop1" >>>>> property, but Child2 has none. If you add any property at all to >>>>> Child2, the error goes away. If you add still another property, the >>>>> error returns. >>>>> >>>>> Affected JRE: >>>>> >>>>> Java version "1.8.0_25" >>>>> Java(TM) SE Runtime Environment (build 1.8.0_25-b17) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) >>>>> >>>>> This bug appears to be a regression, as the following older JRE >>>>> returns the "Expected" output: >>>>> >>>>> java version "1.8.0_05" >>>>> Java(TM) SE Runtime Environment (build 1.8.0_05-b13) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) >>>>> >>>>> We?re stuck on 1.8.0_05 at this point, because one of our 3rd party >>>>> libraries uses this inheritance pattern. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> jf >>>>>