From david at code.davidpcaldwell.com Thu May 1 11:35:48 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Thu, 1 May 2014 07:35:48 -0400 Subject: Nashorn caching of processed scripts? In-Reply-To: References: <3087221F-DA0C-47C6-A90C-C0C03DC4D987@oracle.com> Message-ID: For what it's worth, I've learned a bit more about my problem with scopes. I have a set of unit tests that exercise my system, and as such, they are very scope-intensive, because they use scopes as the mechanism for mocking and dependency injection when running the unit tests. They always pass under Rhino. Under Nashorn, these tests intermittently failed because of various mistakes having to do with scoping. In my current tip I believe I've worked around all the unit test failures that are "common" but it's too early to be sure. So, I have a lot of constructs like this: var someFunction = function() { // omitted } this.somePublicFunction() { someFunction(); // ... } What I can tell you is: * The unit tests are continually creating and using scopes to mock the execution context, and they re-enter Nashorn via the non-public evaluateSource(Source,ScriptContext,ScriptContext) and then invoking functions like somePublicFunction() above. * Sometimes, in a non-deterministic way, in scripts like the above, "someFunction" evaluates to undefined inside somePublicFunction. * I can fix the problem in various ways, including making someFunction a property of this or moving it inside somePublicFunction. Given that it's non-deterministic, my suspicion is some kind of race condition or concurrency problem. I mentioned earlier that I thought the problem would occur when I modified code and then stop occurring. It's possible I imagined this pattern, or it's possible that CPU temperature and throttling is what caused it (repeatedly running a large test suite may have affected the concurrency stuff). If I thought about it carefully, I could provide an executable test case based on a previous revision of the code. The good news is, it would just involve checking out some public code at a given revision and running a single command to start the tests. Three pieces of bad news: 1. it's non-deterministic, 2. it's obviously big and tangled so you'd have to figure out how to catch the problem, and 3. I'm using a non-public API (which I am calling from script, no less), so I can't guarantee that's not related to the problem. But with those three caveats, if you're interested, let me know and I'll assemble something. -- David P. Caldwell http://www.davidpcaldwell.com/ From david at code.davidpcaldwell.com Thu May 1 11:53:13 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Thu, 1 May 2014 07:53:13 -0400 Subject: Nashorn caching of processed scripts? In-Reply-To: References: <3087221F-DA0C-47C6-A90C-C0C03DC4D987@oracle.com> Message-ID: A couple of other hints/guesses: My guess is Nashorn caches the compiled version of a given script by examining the Source used to create it. 1. It appears this bug manifests when the same script is loaded into several places, and it appears that if the script loads "wrong" it loads wrong everywhere. In other words, if the script is loaded into one scope and exhibits this behavior, it will exhibit it again within a single execution if it is loaded into another scope. 2. The stack trace seems to lead through LinkerServicesImpl.getGuardedInvocation() and DynamicLinker.relink(). -- David P. Caldwell http://www.davidpcaldwell.com/ On Thu, May 1, 2014 at 7:35 AM, David P. Caldwell wrote: > For what it's worth, I've learned a bit more about my problem with scopes. > > I have a set of unit tests that exercise my system, and as such, they > are very scope-intensive, because they use scopes as the mechanism for > mocking and dependency injection when running the unit tests. > > They always pass under Rhino. > > Under Nashorn, these tests intermittently failed because of various > mistakes having to do with scoping. In my current tip I believe I've > worked around all the unit test failures that are "common" but it's > too early to be sure. > > So, I have a lot of constructs like this: > > var someFunction = function() { > // omitted > } > > this.somePublicFunction() { > someFunction(); > // ... > } > > What I can tell you is: > > * The unit tests are continually creating and using scopes to mock the > execution context, and they re-enter Nashorn via the non-public > evaluateSource(Source,ScriptContext,ScriptContext) and then invoking > functions like somePublicFunction() above. > * Sometimes, in a non-deterministic way, in scripts like the above, > "someFunction" evaluates to undefined inside somePublicFunction. > * I can fix the problem in various ways, including making someFunction > a property of this or moving it inside somePublicFunction. > > Given that it's non-deterministic, my suspicion is some kind of race > condition or concurrency problem. > > I mentioned earlier that I thought the problem would occur when I > modified code and then stop occurring. It's possible I imagined this > pattern, or it's possible that CPU temperature and throttling is what > caused it (repeatedly running a large test suite may have affected the > concurrency stuff). > > If I thought about it carefully, I could provide an executable test > case based on a previous revision of the code. The good news is, it > would just involve checking out some public code at a given revision > and running a single command to start the tests. Three pieces of bad > news: 1. it's non-deterministic, 2. it's obviously big and tangled so > you'd have to figure out how to catch the problem, and 3. I'm using a > non-public API (which I am calling from script, no less), so I can't > guarantee that's not related to the problem. > > But with those three caveats, if you're interested, let me know and > I'll assemble something. > > -- David P. Caldwell > http://www.davidpcaldwell.com/ From sundararajan.athijegannathan at oracle.com Fri May 2 04:23:32 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 02 May 2014 09:53:32 +0530 Subject: Monkey patching a Java class? In-Reply-To: References: Message-ID: <53631DC4.9020902@oracle.com> No, you can't add/remove a method (or public field) of a Java class to use within the script. You could subclass and expose that subclass as "java.io.File" by var oldFile = java.io.File; java.io.File = Java.extend(oldFile, ...) But, I'd not recommend it - besides user can still get original java.io.File via Java.type (unless you do similar hack on Java.type as well!!) Cleaner approach is to expose a script API wrapping java.io.File. -Sundar On Thursday 17 April 2014 12:03 AM, HRJet wrote: > Is it possible to monkey patch a Java class for use within Javascript? > > For example, I want to add a convenience method to java.io.File class, say > "readAsString()". > > Then, in javascript I want to call file.readAsString() where file is an > instance of java.io.File. Note that the file instance may be created by > some third-party code, over which I have no control. > > In Java land, this seems to be usually done with CGLib or AspectJ, etc. > > I was wondering if nashorn had some trick up its sleeve for doing this in > script land, since this sort of thing is common in Javascript. > > thanks, > HRJ From sundararajan.athijegannathan at oracle.com Fri May 2 06:49:55 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 02 May 2014 12:19:55 +0530 Subject: Getting file names on stack traces. In-Reply-To: References: Message-ID: <53634013.2020101@oracle.com> Hi, Sorry for the delayed response (was on vacation). "eval naming" (//@ sourceURL or //# sourceURL) support has been added in jdk9 and backported to jdk8u-dev repo (most likely will be in 8u20). import javax.script.*; public class Main { public static void main(String[] args) throws Exception { ScriptEngineManager m = new ScriptEngineManager(); ScriptEngine e = m.getEngineByName("nashorn"); Compilable c = (Compilable)e; CompiledScript cs = c.compile("throw new Error();\n//# sourceURL=myfile.js"); cs.eval(); } } When you run the above code, you'll see myfile.js as source file name for that script frame throwing error. Not just CompiledScript.eval - any eval - including engine.eval and script 'eval' function accept this // #sourceURL comment and use that value as name for the script "file". See also: https://bugs.openjdk.java.net/browse/JDK-8032068 -Sundar On Tuesday 22 April 2014 01:17 PM, Benjamin Sieffert wrote: > Hi Greg, > > I've also tried to do this, but (without looking into it very extensively) > didn't find a way other than to build a second string that wraps the first > one like this: > > String scriptWithFileName = "load(" > // will be shown as scriptname in stacktraces > + "{ name: \"" + name + '"' + ',' > // the actual script > + "script:" + escapeJavaScript(script) + '"' > + '}' > + ')'; > > It's working as intended and doesn't seem to have any unwanted > side-effects, but of course it would be nice to be able to do this more > cleanly from Java. I guess there's the possibility of calling the > load-extension somewhere, but it doesn't seem to be public (Java) API. > > Hope this helps > > > 2014-04-21 22:02 GMT+02:00 Greg Brail : > >> Let's say that I have some JS code like this: >> >> (function(foo) { >> throw new Error('Sorry, ' + foo); >> }) >> >> and I execute it by reading it into a String variable, then executing it >> using ScriptEngine.eval(string), and then I call the function later, either >> from Java directly or from some other JS code. >> >> Right now, in Nashorn, I see that the stack trace of my exception will >> include the entry: >> >> ":2" >> >> to indicate the "file name" and line number of my error. >> >> I would like instead to stick in a file name so that the file name appears >> instead of "". Is there a way for me to do that? >> >> I did try setting the property "ScriptEngine.FILENAME" on my script >> context, but that seems to be a global context. It works the first time I >> run the script, but if I call the function later on from inside another >> script, the file name doesn't "stick" to the code. >> >> I can provide an example if I need to, but is there anything you guys can >> think of that I can do in order to get a file name to stick to this >> function for the purpose of stack traces? >> >> -- >> *greg brail* | *apigee * | twitter >> @gbrail >> > > From sundararajan.athijegannathan at oracle.com Fri May 2 09:31:24 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 02 May 2014 15:01:24 +0530 Subject: Fuzzing jdk9/dev/nashorn and nashorn/jdk9/nashorn In-Reply-To: <535E580A.8070006@googlemail.com> References: <535E580A.8070006@googlemail.com> Message-ID: <536365EC.3090600@oracle.com> Hi, Sorry for the delay. I've filed an umbrella bug for this: https://bugs.openjdk.java.net/browse/JDK-8042304 Thanks for reporting these issues! -Sundar On Monday 28 April 2014 07:00 PM, Andr? Bargull wrote: > Hi, > > here are the current jsfunfuzz results for jdk9/dev/nashorn at > 794:e88f1df9b412 and nashorn/jdk9/nashorn at 794:77511a74bb48 using > JDK 9 b09. Bugs which are only reproducible in one of the two > repositories are marked as such. Except for the `Function("if(eval('', > eval('', function() {}))) { }")` test case, all other bugs in > jdk9/dev/nashorn look familiar, so most likely they were already > reported some time ago (but I didn't verify it...). > > - Andr? > > -------------- > > Oh, first of all you may want to apply this change. ;-) > > diff --git a/src/jdk/nashorn/tools/Shell.java > b/src/jdk/nashorn/tools/Shell.java > --- a/src/jdk/nashorn/tools/Shell.java > +++ b/src/jdk/nashorn/tools/Shell.java > @@ -448,15 +448,15 @@ public class Shell { > } > > if (res != ScriptRuntime.UNDEFINED) { > err.println(JSType.toString(res)); > } > } > } finally { > if (globalChanged) { > - Context.setGlobal(global); > + Context.setGlobal(oldGlobal); > } > } > > return SUCCESS; > } > } > > -------------- > > > jjs> Function("switch(0) { default: {break;} return }") > Exception in thread "main" java.lang.VerifyError: Code generation bug > in "L:1": likely stack misaligned: java.lang.NullPointerException > > at > jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1582) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:324) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at > jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:52) > at > jdk.nashorn.internal.codegen.CodeGenerator$3.enterFunctionNode(CodeGenerator.java:620) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:323) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at > jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:52) > ... > > > jjs> Function("L: { { break L; } return; }") > Exception in thread "main" java.lang.VerifyError: StackMapTable error: > bad offset > Exception Details: > Location: > jdk/nashorn/internal/scripts/Script$\^function\_.L:1(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; > @0: aload_0 > Reason: > Invalid stackmap specification. > Current Frame: > bci: @12 > flags: { } > locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', > 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject' } > stack: { } > Bytecode: > 0000000: 2ab6 0018 4da7 0007 0000 00bf > Stackmap Table: > full_frame(@8,{},{Object[#52]}) > append_frame(@12,Object[#20],Object[#54],Object[#56]) > > > jjs> Function("L: { while(0)break L; return; }") > Exception in thread "main" java.lang.VerifyError: StackMapTable error: > bad offset > Exception Details: > Location: > jdk/nashorn/internal/scripts/Script$\^function\_.L:1(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; > @0: aload_0 > Reason: > Invalid stackmap specification. > Current Frame: > bci: @19 > flags: { } > locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', > 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject' } > stack: { } > Bytecode: > 0000000: 2ab6 0018 4da7 0006 a700 0b03 9aff fcb2 > 0000010: 002b b0 > Stackmap Table: > append_frame(@8,Object[#52]) > same_frame(@11) > same_frame(@19) > > > jjs> Function("L: {while(0)break L; return [](); }") > Exception in thread "main" java.lang.VerifyError: Code generation bug > in "L:1": likely stack misaligned: > java.lang.ArrayIndexOutOfBoundsException: 0 > at > jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1582) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:324) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at > jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:52) > at > jdk.nashorn.internal.codegen.CodeGenerator$3.enterFunctionNode(CodeGenerator.java:620) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:323) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at > jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:52) > ... > > > [nashorn/jdk9/nashorn] > jjs> Function("do with({}) break ; while(0);") > Exception in thread "main" java.lang.AssertionError > at > jdk.nashorn.internal.codegen.CodeGenerator.popScopes(CodeGenerator.java:807) > at > jdk.nashorn.internal.codegen.CodeGenerator.popScopesUntil(CodeGenerator.java:799) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterBreakNode(CodeGenerator.java:820) > at jdk.nashorn.internal.ir.BreakNode.accept(BreakNode.java:63) > at jdk.nashorn.internal.ir.Node.accept(Node.java:306) > at jdk.nashorn.internal.ir.Block.accept(Block.java:155) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at jdk.nashorn.internal.ir.Block.accept(Block.java:378) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterWithNode(CodeGenerator.java:2820) > at jdk.nashorn.internal.ir.WithNode.accept(WithNode.java:68) > ... > > > [nashorn/jdk9/nashorn] > jjs> Function("while(0)with({}) continue ;") > Exception in thread "main" java.lang.AssertionError > at > jdk.nashorn.internal.codegen.CodeGenerator.popScopes(CodeGenerator.java:807) > at > jdk.nashorn.internal.codegen.CodeGenerator.popScopesUntil(CodeGenerator.java:799) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterContinueNode(CodeGenerator.java:1229) > at jdk.nashorn.internal.ir.ContinueNode.accept(ContinueNode.java:59) > at jdk.nashorn.internal.ir.Node.accept(Node.java:306) > at jdk.nashorn.internal.ir.Block.accept(Block.java:155) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at jdk.nashorn.internal.ir.Block.accept(Block.java:378) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterWithNode(CodeGenerator.java:2820) > at jdk.nashorn.internal.ir.WithNode.accept(WithNode.java:68) > ... > > > [nashorn/jdk9/nashorn] > jjs> Function("eval([]);") > Exception in thread "main" java.lang.AssertionError > at > jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.analyze(LiteralNode.java:659) > at jdk.nashorn.internal.codegen.Attr.leaveLiteralNode(Attr.java:841) > at > jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.accept(LiteralNode.java:872) > at jdk.nashorn.internal.ir.CallNode.accept(CallNode.java:216) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at > jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) > at jdk.nashorn.internal.ir.CallNode.accept(CallNode.java:40) > at > jdk.nashorn.internal.ir.ExpressionStatement.accept(ExpressionStatement.java:67) > at jdk.nashorn.internal.ir.Node.accept(Node.java:306) > at jdk.nashorn.internal.ir.Block.accept(Block.java:155) > ... > > > [nashorn/jdk9/nashorn] > jjs> Function("try{}finally{[]}") > Exception in thread "main" java.lang.AssertionError > at > jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.analyze(LiteralNode.java:659) > at jdk.nashorn.internal.codegen.Attr.leaveLiteralNode(Attr.java:841) > at > jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.accept(LiteralNode.java:872) > at > jdk.nashorn.internal.ir.ExpressionStatement.accept(ExpressionStatement.java:67) > at jdk.nashorn.internal.ir.Node.accept(Node.java:306) > at jdk.nashorn.internal.ir.Block.accept(Block.java:155) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at jdk.nashorn.internal.ir.Block.accept(Block.java:378) > at > jdk.nashorn.internal.ir.BlockStatement.accept(BlockStatement.java:85) > at jdk.nashorn.internal.ir.Node.accept(Node.java:306) > ... > > > [nashorn/jdk9/nashorn] > jjs> Function("try { } catch(x if 1) { try { } catch(x2) { } } ") > Exception in thread "main" java.lang.AssertionError: stacks [] is not > equivalent with [boolean] at join point skip_117 > at > jdk.nashorn.internal.codegen.MethodEmitter.mergeStackTo(MethodEmitter.java:1696) > at > jdk.nashorn.internal.codegen.MethodEmitter.label(MethodEmitter.java:1719) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterTryNode(CodeGenerator.java:2718) > at jdk.nashorn.internal.ir.TryNode.accept(TryNode.java:110) > at jdk.nashorn.internal.ir.Node.accept(Node.java:306) > at jdk.nashorn.internal.ir.Block.accept(Block.java:155) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at jdk.nashorn.internal.ir.Block.accept(Block.java:378) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterBlockStatement(CodeGenerator.java:1257) > at > jdk.nashorn.internal.ir.BlockStatement.accept(BlockStatement.java:84) > ... > > > [nashorn/jdk9/nashorn] > jjs> Function("try { } catch(x if 1) { try { return; } catch(x2) { { > } } } ") > Exception in thread "main" java.lang.AssertionError: Only return value > on stack allowed at return point - depth=2 stack = [boolean, > object] > at > jdk.nashorn.internal.codegen.MethodEmitter._return(MethodEmitter.java:1429) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterReturnNode(CodeGenerator.java:2009) > at jdk.nashorn.internal.ir.ReturnNode.accept(ReturnNode.java:91) > at jdk.nashorn.internal.ir.Node.accept(Node.java:306) > at jdk.nashorn.internal.ir.Block.accept(Block.java:155) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at jdk.nashorn.internal.ir.Block.accept(Block.java:378) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterTryNode(CodeGenerator.java:2632) > at jdk.nashorn.internal.ir.TryNode.accept(TryNode.java:110) > at jdk.nashorn.internal.ir.Node.accept(Node.java:306) > ... > > > [nashorn/jdk9/nashorn] > jjs> try{ Function("Error() * (false)[-0]--") } catch(e){ > e.printStackTrace() } > java.lang.UnsupportedOperationException: getBytecodeStackType > at > jdk.nashorn.internal.codegen.types.Type$7.getBytecodeStackType(Type.java:973) > at > jdk.nashorn.internal.codegen.CodeGenerator.appendType(CodeGenerator.java:4213) > at > jdk.nashorn.internal.codegen.CodeGenerator.getLvarTypesDescriptor(CodeGenerator.java:4199) > at > jdk.nashorn.internal.codegen.CodeGenerator.access$4400(CodeGenerator.java:176) > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.addUnwarrantedOptimismHandlerLabel(CodeGenerator.java:4127) > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4008) > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3952) > at > jdk.nashorn.internal.codegen.CodeGenerator$15.storeNonDiscard(CodeGenerator.java:2908) > at > jdk.nashorn.internal.codegen.CodeGenerator$Store.store(CodeGenerator.java:3840) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterDECINC(CodeGenerator.java:2925) > ... > > > jjs> Function("try { var x = 1, x = null; } finally { }") > Exception in thread "main" java.lang.VerifyError: Stack map does not > match the one at exception handler 14 > Exception Details: > Location: > jdk/nashorn/internal/scripts/Script$\^function\_.L:1(Ljava/lang/Object;)Ljava/lang/Object; > @14: astore_2 > Reason: > Type 'java/lang/Integer' (current frame, locals[1]) is not > assignable to null (stack map, locals[1]) > Current Frame: > bci: @8 > flags: { } > locals: { 'java/lang/Object', 'java/lang/Integer', null } > stack: { 'java/lang/Throwable' } > Stackmap Frame: > bci: @14 > flags: { } > locals: { 'java/lang/Object', null, null } > stack: { 'java/lang/Throwable' } > Bytecode: > 0000000: 014c 014d 04b8 0033 4c01 4ca7 0008 4d2c > 0000010: 4e2d bfb2 002b b0 > Exception Handler Table: > bci [4, 14] => handler: 14 > Stackmap Table: > full_frame(@14,{Object[#61],Null,Null},{Object[#53]}) > same_frame(@19) > > > [nashorn/jdk9/nashorn] > jjs> Function("try { var x = {}, x = []; } catch(x3) { } ") > Exception in thread "main" java.lang.VerifyError: Stack map does not > match the one at exception handler 34 > Exception Details: > Location: > jdk/nashorn/internal/scripts/Script$\^function\_.L:1(Ljava/lang/Object;)Ljava/lang/Object; > @34: astore_2 > Reason: > Type 'jdk/nashorn/internal/scripts/JO4' (current frame, locals[1]) > is not assignable to 'jdk/nashorn/internal/objects/NativeArray' (stack > map, locals[1]) > Current Frame: > bci: @22 > flags: { } > locals: { 'java/lang/Object', 'jdk/nashorn/internal/scripts/JO4', > null } > stack: { 'java/lang/Throwable' } > Stackmap Frame: > bci: @34 > flags: { } > locals: { 'java/lang/Object', > 'jdk/nashorn/internal/objects/NativeArray', null } > stack: { 'java/lang/Throwable' } > Bytecode: > 0000000: 014c 014d bb00 2f59 03b8 001e b700 3259 > 0000010: b800 37b6 003d 4c04 b800 41b8 0045 4ca7 > 0000020: 0013 4d2c 59c1 0049 9900 09c0 0049 b400 > 0000030: 4d4e b200 2bb0 > Exception Handler Table: > bci [4, 34] => handler: 34 > Stackmap Table: > full_frame(@34,{Object[#84],Object[#86],Null},{Object[#71]}) > full_frame(@49,{Object[#84],Object[#86],Object[#71]},{Object[#84]}) > same_frame(@50) > > > [nashorn/jdk9/nashorn] > jjs> Function("[delete this]") > Exception in thread "main" java.lang.AssertionError > at > jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.presetObjectArray(LiteralNode.java:737) > at > jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.getPresets(LiteralNode.java:843) > at > jdk.nashorn.internal.codegen.CodeGenerator.loadArray(CodeGenerator.java:1664) > at > jdk.nashorn.internal.codegen.CodeGenerator.loadLiteral(CodeGenerator.java:1847) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterLiteralNode(CodeGenerator.java:1897) > at > jdk.nashorn.internal.codegen.CodeGenerator.access$900(CodeGenerator.java:176) > at > jdk.nashorn.internal.codegen.CodeGenerator$3.enterLiteralNode(CodeGenerator.java:637) > at > jdk.nashorn.internal.ir.LiteralNode$ArrayLiteralNode.accept(LiteralNode.java:869) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:570) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:549) > ... > > > [jdk9/dev/nashorn] > jjs> try { Function("if(eval('', eval('', function() {}))) { }") } > catch (e) { e.printStackTrace() } > java.lang.ArrayIndexOutOfBoundsException: -2 > at > jdk.nashorn.internal.codegen.CodeGeneratorLexicalContext.nextFreeSlot(CodeGeneratorLexicalContext.java:195) > at > jdk.nashorn.internal.codegen.CodeGenerator.initLocals(CodeGenerator.java:958) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterBlock(CodeGenerator.java:568) > at jdk.nashorn.internal.ir.Block.accept(Block.java:142) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at jdk.nashorn.internal.ir.Block.accept(Block.java:361) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterIfNode(CodeGenerator.java:1154) > at jdk.nashorn.internal.ir.IfNode.accept(IfNode.java:76) > at jdk.nashorn.internal.ir.Node.accept(Node.java:291) > at jdk.nashorn.internal.ir.Block.accept(Block.java:143) > ... > > > [nashorn/jdk9/nashorn] > jjs> try { Function("if(eval('', eval('', function() {}))) { }")() } > catch (e) { e.printStackTrace() } > java.lang.AssertionError > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4012) > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3952) > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3940) > at > jdk.nashorn.internal.codegen.CodeGenerator$4.evalCall(CodeGenerator.java:976) > at > jdk.nashorn.internal.codegen.CodeGenerator$4.enterIdentNode(CodeGenerator.java:993) > at jdk.nashorn.internal.ir.IdentNode.accept(IdentNode.java:111) > at > jdk.nashorn.internal.codegen.CodeGenerator.enterCallNode(CodeGenerator.java:879) > at > jdk.nashorn.internal.codegen.CodeGenerator.access$800(CodeGenerator.java:176) > at > jdk.nashorn.internal.codegen.CodeGenerator$3.enterCallNode(CodeGenerator.java:632) > at jdk.nashorn.internal.ir.CallNode.accept(CallNode.java:210) > ... > > > [nashorn/jdk9/nashorn] > jjs> Function("eval(\"[,,];\", [11,12,13,14].some)")() > Exception in thread "main" java.lang.AssertionError > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4012) > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3952) > at > jdk.nashorn.internal.codegen.CodeGenerator$3.enterAccessNode(CodeGenerator.java:592) > at jdk.nashorn.internal.ir.AccessNode.accept(AccessNode.java:64) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:570) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:549) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:505) > at > jdk.nashorn.internal.codegen.CodeGenerator.loadArgs(CodeGenerator.java:852) > at > jdk.nashorn.internal.codegen.CodeGenerator.loadArgs(CodeGenerator.java:831) > at > jdk.nashorn.internal.codegen.CodeGenerator.loadArgs(CodeGenerator.java:827) > ... > > > [nashorn/jdk9/nashorn] > jjs> Function("eval(\"1.2e3\", ({})[ /x/ ])")() > Exception in thread "main" java.lang.AssertionError > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4012) > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3952) > at > jdk.nashorn.internal.codegen.CodeGenerator$3.enterIndexNode(CodeGenerator.java:611) > at jdk.nashorn.internal.ir.IndexNode.accept(IndexNode.java:59) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:570) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:549) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:505) > at > jdk.nashorn.internal.codegen.CodeGenerator.loadArgs(CodeGenerator.java:852) > at > jdk.nashorn.internal.codegen.CodeGenerator.loadArgs(CodeGenerator.java:831) > at > jdk.nashorn.internal.codegen.CodeGenerator.loadArgs(CodeGenerator.java:827) > ... > > > [nashorn/jdk9/nashorn] > jjs> Function("eval(\"x4\", x3);")() > :2 ReferenceError: "x3" is not defined > jjs> x3={}; x4={} > [object Object] > jjs> Function("eval(\"x4\", x3);")() > Exception in thread "main" java.lang.AssertionError > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:4012) > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3948) > at > jdk.nashorn.internal.codegen.CodeGenerator$OptimisticOperation.emit(CodeGenerator.java:3944) > at > jdk.nashorn.internal.codegen.CodeGenerator.loadIdent(CodeGenerator.java:328) > at > jdk.nashorn.internal.codegen.CodeGenerator.access$500(CodeGenerator.java:176) > at > jdk.nashorn.internal.codegen.CodeGenerator$3.enterIdentNode(CodeGenerator.java:573) > at jdk.nashorn.internal.ir.IdentNode.accept(IdentNode.java:111) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:570) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:549) > at > jdk.nashorn.internal.codegen.CodeGenerator.load(CodeGenerator.java:505) > ... > > > [nashorn/jdk9/nashorn] > jjs> Function("with({5.0000000000000000000000: String()}){(false); }")() > Exception in thread "main" java.lang.VerifyError: Code generation bug > in "L:1": likely stack misaligned: java.lang.AssertionError: int is > not a script object > at > jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1582) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:324) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at > jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:52) > at > jdk.nashorn.internal.codegen.CompilationPhase$9.transform(CompilationPhase.java:330) > at > jdk.nashorn.internal.codegen.CompilationPhase.apply(CompilationPhase.java:436) > at > jdk.nashorn.internal.codegen.Compiler.compileInternal(Compiler.java:278) > at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:257) > at > jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.compileRestOfMethod(RecompilableScriptFunctionData.java:440) > at > jdk.nashorn.internal.runtime.CompiledFunction$OptimismInfo.compileRestOfMethod(CompiledFunction.java:661) > at > jdk.nashorn.internal.runtime.CompiledFunction.handleRewriteException(CompiledFunction.java:615) > at > jdk.nashorn.internal.runtime.CompiledFunction.handleRewriteException(CompiledFunction.java:564) > at jdk.nashorn.internal.scripts.Script$\^shell\_.:program(:1) > at > jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:555) > at > jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:221) > at > jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:376) > at jdk.nashorn.internal.runtime.Context.eval(Context.java:516) > at jdk.nashorn.tools.Shell.readEvalPrint(Shell.java:441) > 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) > Caused by: java.lang.AssertionError: int is not a script object > at > jdk.nashorn.internal.codegen.CodeGenerator.generateContinuationHandler(CodeGenerator.java:4587) > at > jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1563) > ... 21 more > > > [nashorn/jdk9/nashorn] > jjs> Function("try { var x = undefined, x = 5.0000000000000000000000; > } catch(x) { x = undefined; } ")() > Exception in thread "main" java.lang.VerifyError: Stack map does not > match the one at exception handler 27 > Exception Details: > Location: > jdk/nashorn/internal/scripts/Script$Recompilation$1$\^function\_.L:1(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;)Ljava/lang/Object; > @27: astore > Reason: > Type 'java/lang/Object' (current frame, locals[3]) is not > assignable to 'java/lang/Double' (stack map, locals[3]) > Current Frame: > bci: @16 > flags: { } > locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', > 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject', > 'java/lang/Object', null } > stack: { 'java/lang/Throwable' } > Stackmap Frame: > bci: @27 > flags: { } > locals: { 'jdk/nashorn/internal/runtime/ScriptFunction', > 'java/lang/Object', 'jdk/nashorn/internal/runtime/ScriptObject', > 'java/lang/Double', null } > stack: { 'java/lang/Throwable' } > Bytecode: > 0000000: 2ab6 0018 4d01 4e01 3a04 2cba 0024 0000 > 0000010: 4e14 0025 b800 2c4e a700 1e3a 0419 0459 > 0000020: c100 3099 0009 c000 30b4 0034 3a05 2cba > 0000030: 0024 0000 3a05 b200 3db0 > Exception Handler Table: > bci [10, 27] => handler: 27 > Stackmap Table: > full_frame(@27,{Object[#20],Object[#68],Object[#70],Object[#40],Null},{Object[#46]}) > > full_frame(@44,{Object[#20],Object[#68],Object[#70],Object[#40],Object[#46]},{Object[#68]}) > > same_frame(@54) > > > [nashorn/jdk9/nashorn] > jjs> try { Function("(function (x){ x %= this}(false))")() } catch(e) > { e.printStackTrace() } > java.lang.invoke.WrongMethodTypeException: cannot convert > MethodHandle(Object,double)Object to (Object,boolean)Object > at > java.lang.invoke.MethodHandle.asTypeUncached(MethodHandle.java:776) > at java.lang.invoke.MethodHandle.asType(MethodHandle.java:770) > at > jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.addCode(RecompilableScriptFunctionData.java:601) > at > jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.getBest(RecompilableScriptFunctionData.java:610) > at > jdk.nashorn.internal.runtime.ScriptFunctionData.getBestInvoker(ScriptFunctionData.java:223) > at > jdk.nashorn.internal.runtime.ScriptFunction.findCallMethod(ScriptFunction.java:545) > at > jdk.nashorn.internal.runtime.ScriptObject.lookup(ScriptObject.java:1767) > at > jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:100) > at > jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:94) > at > jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176) > ... > > > [nashorn/jdk9/nashorn] > jjs> try { Function("eval.apply.apply(function(){ eval('') })")() } > catch (e) { e.printStackTrace() } > java.lang.IndexOutOfBoundsException: start=4 end=3 > at > java.lang.invoke.MethodType.newIndexOutOfBoundsException(MethodType.java:189) > at > java.lang.invoke.MethodType.dropParameterTypes(MethodType.java:482) > at jdk.internal.dynalink.support.Guards.getTestType(Guards.java:247) > at jdk.internal.dynalink.support.Guards.asType(Guards.java:243) > at > jdk.internal.dynalink.linker.GuardedInvocation.asTypeSafeReturn(GuardedInvocation.java:342) > at > jdk.nashorn.internal.runtime.linker.Bootstrap.asTypeSafeReturn(Bootstrap.java:394) > at > jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:94) > at > jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176) > at > jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124) > at > jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:149) > ... > > > [nashorn/jdk9/nashorn] > jjs> try{ Function("(false % !this) && 0")() } catch (e) { > e.printStackTrace() } > java.lang.ArithmeticException: / by zero > at jdk.nashorn.internal.scripts.Script$\^function\_.L:1(:2) > at jdk.nashorn.internal.scripts.Script$\^shell\_.:program(:1) > at > jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:555) > at > jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:221) > at > jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:376) > at jdk.nashorn.internal.runtime.Context.eval(Context.java:516) > at jdk.nashorn.tools.Shell.readEvalPrint(Shell.java:441) > 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/jdk9/nashorn] > jjs> Function("with({8: 'fafafa'.replace()}){ }")() > Exception in thread "main" java.lang.VerifyError: Code generation bug > in "L:1": likely stack misaligned: java.lang.AssertionError: int is > not a script object > at > jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1582) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:324) > at > jdk.nashorn.internal.ir.LexicalContextNode$Acceptor.accept(LexicalContextNode.java:57) > at > jdk.nashorn.internal.ir.LexicalContextExpression.accept(LexicalContextExpression.java:46) > at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:52) > at > jdk.nashorn.internal.codegen.CompilationPhase$9.transform(CompilationPhase.java:330) > at > jdk.nashorn.internal.codegen.CompilationPhase.apply(CompilationPhase.java:436) > at > jdk.nashorn.internal.codegen.Compiler.compileInternal(Compiler.java:278) > at jdk.nashorn.internal.codegen.Compiler.compile(Compiler.java:257) > at > jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.compileRestOfMethod(RecompilableScriptFunctionData.java:440) > ... > Caused by: java.lang.AssertionError: int is not a script object > at > jdk.nashorn.internal.codegen.CodeGenerator.generateContinuationHandler(CodeGenerator.java:4587) > at > jdk.nashorn.internal.codegen.CodeGenerator.leaveFunctionNode(CodeGenerator.java:1563) > ... 21 more > > > [nashorn/jdk9/nashorn] > jjs> try { Function("new eval(function(){})") } catch (e) { > e.printStackTrace() } > jdk.nashorn.internal.lookup.MethodHandleFactory$LookupException: > java.lang.NoSuchMethodException: no such method: > jdk.nashorn.internal.scripts.Script$\^function\_.L:1$L:2-1(Object)Object/invokeStatic > at > jdk.nashorn.internal.lookup.MethodHandleFactory$StandardMethodHandleFunctionality.findStatic(MethodHandleFactory.java:497) > at > jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.lookupCodeMethod(RecompilableScriptFunctionData.java:534) > at > jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.lookupWithExplicitType(RecompilableScriptFunctionData.java:530) > at > jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.lookup(RecompilableScriptFunctionData.java:526) > at > jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.addCode(RecompilableScriptFunctionData.java:558) > at > jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.initializeCode(RecompilableScriptFunctionData.java:548) > at > jdk.nashorn.internal.codegen.CompileUnit$FunctionInitializer.initializeCode(CompileUnit.java:60) > at > jdk.nashorn.internal.codegen.CompileUnit.initializeFunctionsCode(CompileUnit.java:130) > at jdk.nashorn.internal.codegen.Compiler.install(Compiler.java:394) > at jdk.nashorn.internal.runtime.Context.compile(Context.java:970) > ... > Caused by: java.lang.NoSuchMethodException: no such method: > jdk.nashorn.internal.scripts.Script$\^function\_.L:1$L:2-1(Object)Object/invokeStatic > at > java.lang.invoke.MemberName.makeAccessException(MemberName.java:876) > at > java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:993) > at > java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:1377) > at > java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:774) > at > jdk.nashorn.internal.lookup.MethodHandleFactory$StandardMethodHandleFunctionality.findStatic(MethodHandleFactory.java:494) > ... 21 more > Caused by: java.lang.NoSuchMethodError: > jdk.nashorn.internal.scripts.Script$\^function\_.L:1$L:2-1(Ljava/lang/Object;)Ljava/lang/Object; > at java.lang.invoke.MethodHandleNatives.resolve(Native Method) > at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:965) > at > java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:990) > ... 24 more > > > [nashorn/jdk9/nashorn] > jjs> try{ Function("(function (x) '' )(true)")() }catch(e){ > e.printStackTrace() } > jdk.nashorn.internal.runtime.ParserException: :2:15 Missing > close quote > (function (x) '' )(true) > ^ > at jdk.nashorn.internal.parser.Lexer.error(Lexer.java:1697) > at jdk.nashorn.internal.parser.Lexer.scanString(Lexer.java:995) > at jdk.nashorn.internal.parser.Lexer.lexify(Lexer.java:1606) > at > jdk.nashorn.internal.parser.AbstractParser.getToken(AbstractParser.java:132) > at > jdk.nashorn.internal.parser.AbstractParser.nextToken(AbstractParser.java:211) > at > jdk.nashorn.internal.parser.AbstractParser.nextOrEOL(AbstractParser.java:170) > at > jdk.nashorn.internal.parser.AbstractParser.next(AbstractParser.java:157) > at jdk.nashorn.internal.parser.Parser.parse(Parser.java:281) > at > jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.reparse(RecompilableScriptFunctionData.java:349) > at > jdk.nashorn.internal.runtime.RecompilableScriptFunctionData.compile(RecompilableScriptFunctionData.java:456) > ... > > > [nashorn/jdk9/nashorn] > jjs> Function("Function.prototype.apply.apply([11,12,13,14].sort)")() > :2 TypeError: [Ljava.lang.Object;@96532d6 is not an Object > > => Error message contains internal type descriptor? > From sundararajan.athijegannathan at oracle.com Fri May 2 13:20:41 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 02 May 2014 18:50:41 +0530 Subject: RFR 8027933: Add --const-as-var option Message-ID: <53639BA9.20501@oracle.com> Hi, Please review. Webrev: http://cr.openjdk.java.net/~sundar/8027933/ Bug: https://bugs.openjdk.java.net/browse/JDK-8027933 Thanks -Sundar From james.laskey at oracle.com Fri May 2 13:27:33 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 2 May 2014 10:27:33 -0300 Subject: RFR 8027933: Add --const-as-var option In-Reply-To: <53639BA9.20501@oracle.com> References: <53639BA9.20501@oracle.com> Message-ID: +1 On May 2, 2014, at 10:20 AM, A. Sundararajan wrote: > Hi, > > Please review. > > Webrev: http://cr.openjdk.java.net/~sundar/8027933/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8027933 > > Thanks > -Sundar From hannes.wallnoefer at oracle.com Fri May 2 13:29:36 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 02 May 2014 15:29:36 +0200 Subject: RFR 8027933: Add --const-as-var option In-Reply-To: <53639BA9.20501@oracle.com> References: <53639BA9.20501@oracle.com> Message-ID: <53639DC0.8000405@oracle.com> Looks good. Hannes Am 2014-05-02 15:20, schrieb A. Sundararajan: > Hi, > > Please review. > > Webrev: http://cr.openjdk.java.net/~sundar/8027933/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8027933 > > Thanks > -Sundar From marcus.lagergren at oracle.com Fri May 2 16:24:59 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Fri, 02 May 2014 16:24:59 +0000 Subject: hg: nashorn/jdk9/nashorn: 8041625: AccessorProperty currentType must only by Object.class when non-primitive, and scoping followup problem for lazily generated with bodies Message-ID: <201405021625.s42GP1Yo013231@aojmv0008> Changeset: e41798b06137 Author: lagergren Date: 2014-05-02 18:22 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/e41798b06137 8041625: AccessorProperty currentType must only by Object.class when non-primitive, and scoping followup problem for lazily generated with bodies Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CodeGeneratorLexicalContext.java ! src/jdk/nashorn/internal/codegen/FindScopeDepths.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! test/script/basic/run-octane.js From iman.reih at gmail.com Sat May 3 16:25:37 2014 From: iman.reih at gmail.com (Iman Reihanian) Date: Sat, 3 May 2014 09:25:37 -0700 Subject: How to become Nashorn contributor Message-ID: Hi There, I was looking for how to become a contributor for Nashorn project and I was wondering hoe can I start to help this project but I did not find good tutorial or help, I thought best way is to ask in mailing list if can you suggest me how can I start to contribute on Nashorn project and start coding there. Thank You From james.laskey at oracle.com Sat May 3 17:11:13 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Sat, 3 May 2014 14:11:13 -0300 Subject: How to become Nashorn contributor In-Reply-To: References: Message-ID: <70B05A48-25CF-4393-B86E-BBCD918377D3@oracle.com> Iman, It's pretty straight forward. Follow the guidelines at http://openjdk.java.net/contribute/ . Initially, you need to submit change sets here and one of us will vet the change set and check it in on your behalf (must meet goals of group.) After you've clear a few change sets you'll move up through the ranks. What is your area of interest? Cheers, -- Jim On May 3, 2014, at 1:25 PM, Iman Reihanian wrote: > Hi There, > > I was looking for how to become a contributor for Nashorn project and I was > wondering hoe can I start to help this project but I did not find good > tutorial or help, I thought best way is to ask in mailing list if can you > suggest me how can I start to contribute on Nashorn project and start > coding there. > > > Thank You From iman.reih at gmail.com Sat May 3 17:20:18 2014 From: iman.reih at gmail.com (Iman Reihanian) Date: Sat, 3 May 2014 10:20:18 -0700 Subject: How to become Nashorn contributor In-Reply-To: <70B05A48-25CF-4393-B86E-BBCD918377D3@oracle.com> References: <70B05A48-25CF-4393-B86E-BBCD918377D3@oracle.com> Message-ID: Jim, Thank you for your reply, I am working on java more than 6 years, I am interesting in all of that but I like to work on Nashorn, because of I think this is new and I can fit myself there. On Sat, May 3, 2014 at 10:11 AM, Jim Laskey (Oracle) < james.laskey at oracle.com> wrote: > Iman, > > It's pretty straight forward. Follow the guidelines at > http://openjdk.java.net/contribute/ . Initially, you need to submit > change sets here and one of us will vet the change set and check it in on > your behalf (must meet goals of group.) After you've clear a few change > sets you'll move up through the ranks. > > What is your area of interest? > > Cheers, > > -- Jim > > > On May 3, 2014, at 1:25 PM, Iman Reihanian wrote: > > > Hi There, > > > > I was looking for how to become a contributor for Nashorn project and I > was > > wondering hoe can I start to help this project but I did not find good > > tutorial or help, I thought best way is to ask in mailing list if can you > > suggest me how can I start to contribute on Nashorn project and start > > coding there. > > > > > > Thank You > > From attila.szegedi at oracle.com Mon May 5 12:31:08 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 5 May 2014 14:31:08 +0200 Subject: Review request for JDK-8042118 Message-ID: Please review JDK-8042118 at Note that this is a pretty large changeset, because the change is architecturally big. Namely, it separates types from symbols, and as you can imagine that ripples through the codebase into pretty deep places, together with the need to introduce calculation of static types for local variables etc. The overall benefit (in addition to cleaner architecture for some of the compiler stages) is a noticeable performance improvement we register on benchmarks, stemming from the fact that the compiler can now treat a single local variable as having different types in different parts of the function, and optimize accordingly. I actually wrote up fairly detailed change notes for this, they are below: AccessNode.property is now a String, not an IdentNode Symbol class no longer contains a Type. Expressions have types directly now, either explicit or calculated from their subexpressions. Only identifiers (IdentNode) have symbols. Corollary: there are no longer temporary symbols; Symbol.IS_TEMP is gone, as is TemporarySymbols class. Attr is separated into three phases: AssignSymbols, OptimisticTypesCalculator and LocalVariableTypesCalculator. RangeAnalyzer class is gone. We don?t really need range analysis with optimistic and lvar type calculation. FinalizeTypes class is gone. Fixups that it did are no longer needed. DISCARD node is gone. The knowledge about whether it?s safe to discard a computation is moved into CodeGenerator which has a loadAndDiscard()method now. Some side-effect free discarded computations are now completely eliminated by the code generator. BreakNode and ContinueNode now have a common superclass, JumpStatement. There?s a new class named LocalVariableConversion, that is basically a linked list of triplets of (symbol, fromType, toType) specifying symbol type widenings that need to be performed on entry to a control flow join points. There?s a new interface named JoinPredecessor. It?s implemented by AST nodes that need to carry a LocalVariableConversion as they can either originate an edge to a control flow join point, or can even fully contain one. JoinPredecessor only provides a getter and setter for a LocalVariableConversion; the semantics of control flow for a particular AST node are shared between the LocalVariableTypesCalculator that creates the conversion, and the CodeGenerator that uses it. BranchOptimizer can generate code that inserts local variable conversions on control flow join edges, since short-circuiting logical AND and OR operators contain control flow joins. Sometimes, an arbitrary expression needs to act as a JoinPredecessor (e.g. a test of a for or a while loop precedes the join point that is the target of the continue statement). JoinPredecessorExpression is introduced as a wrapper for an arbitrary Expression that decorates it with JoinPredecessorfunctionality. A single local variable can use multiple JVM method local variable slots now. If it is assigned both an int and later an Object, it?ll have two slots: one for int value, and one for Object. In most extreme case, it can end up using 6 slots: 1 for int, 2 for long, 2 for double, and 1 for Object value. Consequently, if the type calculator can prove that a variable is never read from a particular type, it will not allocate it a slot. A variable that is never read will end up taking up 0 slots and thus effectively get eliminated. On entry to generated methods, it is sometimes now required to copy values from incoming parameter slots if one or more parameter will also later be assigned a different type (storage for a single symbol is continous). E.g. in the below snippet: function f(a, b) { a = 1.0; print(a); a = ""; print(a); return b;} f(1, 2); ?b? needs to be moved from incoming slot 3 for f(callee, this, int a, int b) to slot 6, as ?a? needs 3 additional slots for double and Object values. As a consequence, inferParameters() is no longer needed; method signatures always preserve the type of methods on entry, as the symbol for the parameter (just as any other symbol) is no longer tied to a single type. codegen.Label.Stack is now a misnomer; we?ll end up renaming it to Label.Frame, as it now also carries information about local variable types: what their types are, which ones belong to the same symbol, and which ones are temporary variables. This information is used to ensure that types are consistent at join points as well as for other codegen purposes. Both LocalVariableTypesCalculator and CodeGenerator calculate static reachability precisely. We should not emit dead code that ASM replaces withNOP, NOP, ... ATHROW anymore (except in rest-of methods, where they?re by design). Type.BOOLEAN is automatically treated as Type.INT for purposes of arithmetic operations, as they?re both represented by ints on stack and would be converted to int anyway. Explicit optimistic flags in expressions exist no more. Rather, every expression that can be optimistic will have an assigned type. It?s the job of the CodeGenerator to figure out the appropriate intersection of an expression?s type, it?s coercing type (e.g. if it?s used as a subexpression in bitwise operation it?ll be coerced to int anyway), and its most pessimistic type (if its type can?t be more pessimistic, it isn?t optimistic) and decide whether to emit an optimistic INVOKEDYNAMIC call site or not. Since Expression.isOptimistic() determines if the expression has a narrower type than its most pessimistic type, FunctionNode now uses a different method, FunctionNode.canBeDeoptimized() to determine if it contains optimistic program points. BinaryNode has probably the most complex type calculation; it provides methods for calculating its type, as well as the widest required type of its operands. It also caches the result of the last type calculation as otherwise we?d have some nasty quadratic times in evaluation of types of deep node trees. void return values (of POJO methods) are now converted to Undefined, instead of to null. As a future step, we?ll emit dyn:call for discarded expressions with void return type, and also declare bytecode methods for functions that don?t return an explicit value as void. Finally, the code generator changes. I?m dedicating a separate section to these. CodeGenerator doesn?t have any enterXxx() methods for expressions anymore, only for statements. This is to make the code more robust; an expression never occurs naked in JavaScript, it?s always inside a statement. Instead, there?s loadExpression() (former load()) that has a visitor that delegates to various private loadXxx() methods that contain the code equivalent to the old enterXxx() methods. there?s a LoadScopeVar that encapsulates the loading of a scoped variable; it has a subclass named LoadFastScopeVar. CodeGenerator internally loads expressions using TypeBounds. This is a pair of Type objects - a lower bound and an upper bound. E.g. when loading ?a * b? if we know that ?a? is int and ?b? is long, then the type bound for the operands is [long, double] (?a? must be loaded at least as a long because ?b? is long, and they should never be wider than double, ?cause that?s what the multiplication coerces them to). However, if the ?*? operator is optimistic and typed as long (can?t be int if it has a long operand), then we?ll attempt to load the operands as [int, double] and [long, double]; giving the chance to ?a? to still load as optimistic int and only widening it after load. I think this all works as expected; binary operands widen the lower bounds of their peer operands and potentially of operations (put widening pressure from bottom up), while operations narrow the upper bounds of their operands (put narrowing pressure from top down). We?ll obviously need to stare at final code output of our benchmarks to capture some corner cases that might?ve fell through the cracks? test-first loops (all of them except do-while) are now emitted with their test first, then their body, then an unconditional jump back to the test. I realize this seems less efficient than emitting the test at the end, but unfortunately now that we need to perform type calculations there?s no easy way to do them correctly if we first emit the body, and only afterwards emit the test. I might be able to overcome this later. I spoke with Rickard B?ckman, and he doesn?t think HotSpot cares one way or the other about structuring of the loop. Normally, join points that widen a local variable value type kill the narrower value. Thus, at most one type of the value is live for a symbol at any time. An exception to this are local variables assigned in try blocks if they need to be widened before they can be used in catch blocks. In that case, code in the try block will perform widening as part of the assignment (as we can?t know when will we transfer control to the catch block), but it will keep using the narrower value. The narrower value is only killed (unless reassigned) at the end of the try block. E.g.: var i; try { thisMightThrow(); i = 1; // stored into int slot, and also boxed into Object slot print(i); // uses int slot // int slot dies here } catch(e) { print(i); // must use i Object slot as i can be Undefined } print(i); // also uses i Object slot That?s also the reason why IdentNode implements JoinPredecessor; it needs to be able to carry a conversion on the edge from within try block to catch block when it?s used as the target of an assignment. Since we can?t know when will such a control flow transfer take place, we conservatively move the conversion to the assignment. OptimisticOperation assumed new responsibilities. It is now created holding the Expression and TypeBounds, and it is its sole centralized responsibility to figure out if the operation will indeed be optimistic or not, as an interaction between the expression?s type, its most pessimistic type, and the passed type bounds. It now owns the the dynamicGet(), dynamicSet(), dynamicCall(), replaceCompileTimeProperty(), and convertOptimisticReturnValue() methods that formerly belonged to the CodeGenerator class. Thanks, Attila. From attila.szegedi at oracle.com Mon May 5 12:47:09 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Mon, 05 May 2014 12:47:09 +0000 Subject: hg: nashorn/jdk9/nashorn: 8037572: Add more test cases to check static types Message-ID: <201405051247.s45ClAZQ018988@aojmv0008> Changeset: 07fdc97e6fc1 Author: mnunez Date: 2014-05-05 14:17 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/07fdc97e6fc1 8037572: Add more test cases to check static types Reviewed-by: attila, lagergren + test/script/basic/optimistic_arithmetic_check_type.js + test/script/basic/optimistic_arithmetic_check_type.js.EXPECTED + test/script/basic/optimistic_assignment_check_type.js + test/script/basic/optimistic_assignment_check_type.js.EXPECTED ! test/script/basic/optimistic_check_type.js ! test/script/basic/optimistic_check_type.js.EXPECTED + test/script/basic/optimistic_logical_check_type.js + test/script/basic/optimistic_logical_check_type.js.EXPECTED + test/script/currently-failing/optimistic_check_type_cases.js + test/script/currently-failing/optimistic_check_type_cases.js.EXPECTED From sundararajan.athijegannathan at oracle.com Tue May 6 08:06:49 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 06 May 2014 13:36:49 +0530 Subject: RFR 8042364: Make __proto__ ES6 draft compliant Message-ID: <53689819.8000209@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8042364/ Bug: https://bugs.openjdk.java.net/browse/JDK-8042364 Thanks, -Sundar From hannes.wallnoefer at oracle.com Tue May 6 08:13:17 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 06 May 2014 10:13:17 +0200 Subject: Review request for JDK-8041998: RegExp implementation is not thread-safe Message-ID: <5368999D.6050205@oracle.com> Please review JDK-8041998: RegExp implementation is not thread-safe http://cr.openjdk.java.net/~hannesw/8041998/ This avoids reusing matchers to make regular expressions work with concurrent threads. Thanks, Hannes From sundararajan.athijegannathan at oracle.com Tue May 6 08:45:19 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 06 May 2014 14:15:19 +0530 Subject: Review request for JDK-8041998: RegExp implementation is not thread-safe In-Reply-To: <5368999D.6050205@oracle.com> References: <5368999D.6050205@oracle.com> Message-ID: <5368A11F.2080407@oracle.com> +1 -Sundar On Tuesday 06 May 2014 01:43 PM, Hannes Wallnoefer wrote: > Please review JDK-8041998: RegExp implementation is not thread-safe > > http://cr.openjdk.java.net/~hannesw/8041998/ > > This avoids reusing matchers to make regular expressions work with > concurrent threads. > > Thanks, > Hannes From attila.szegedi at oracle.com Tue May 6 09:17:29 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 6 May 2014 11:17:29 +0200 Subject: Review request for JDK-8041998: RegExp implementation is not thread-safe In-Reply-To: <5368999D.6050205@oracle.com> References: <5368999D.6050205@oracle.com> Message-ID: +1 On May 6, 2014, at 10:13 AM, Hannes Wallnoefer wrote: > Please review JDK-8041998: RegExp implementation is not thread-safe > > http://cr.openjdk.java.net/~hannesw/8041998/ > > This avoids reusing matchers to make regular expressions work with concurrent threads. > > Thanks, > Hannes From attila.szegedi at oracle.com Tue May 6 09:19:25 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 6 May 2014 11:19:25 +0200 Subject: RFR 8042364: Make __proto__ ES6 draft compliant In-Reply-To: <53689819.8000209@oracle.com> References: <53689819.8000209@oracle.com> Message-ID: +1 On May 6, 2014, at 10:06 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8042364/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8042364 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Wed May 7 08:15:52 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 07 May 2014 13:45:52 +0530 Subject: RFR 8041697: CompiledScript slower when eval with binding Message-ID: <5369EBB8.7050105@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8041697/ Bug: https://bugs.openjdk.java.net/browse/JDK-8041697 Related to http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-April/002920.html Thanks, -Sundar From attila.szegedi at oracle.com Wed May 7 08:20:06 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 7 May 2014 10:20:06 +0200 Subject: RFR 8041697: CompiledScript slower when eval with binding In-Reply-To: <5369EBB8.7050105@oracle.com> References: <5369EBB8.7050105@oracle.com> Message-ID: <672F792C-E23C-4AFE-8DD5-17407F45C735@oracle.com> +1 On May 7, 2014, at 10:15 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8041697/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8041697 > > Related to http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-April/002920.html > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Wed May 7 08:26:53 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 07 May 2014 10:26:53 +0200 Subject: RFR 8041697: CompiledScript slower when eval with binding In-Reply-To: <5369EBB8.7050105@oracle.com> References: <5369EBB8.7050105@oracle.com> Message-ID: <5369EE4D.5050808@oracle.com> +1 Am 2014-05-07 10:15, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8041697/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8041697 > > Related to > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-April/002920.html > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Wed May 7 13:17:22 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 07 May 2014 18:47:22 +0530 Subject: RFR 8042600: Add more samples in nashorn/samples directory Message-ID: <536A3262.7060700@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8042600/ Bug: https://bugs.openjdk.java.net/browse/JDK-8042600 Thanks, -Sundar From james.laskey at oracle.com Wed May 7 13:37:03 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 7 May 2014 10:37:03 -0300 Subject: RFR 8042600: Add more samples in nashorn/samples directory In-Reply-To: <536A3262.7060700@oracle.com> References: <536A3262.7060700@oracle.com> Message-ID: <4F281D79-0573-451C-B9D5-54345163FA1F@oracle.com> +1 On May 7, 2014, at 10:17 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8042600/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8042600 > > Thanks, > -Sundar From hannes.wallnoefer at oracle.com Wed May 7 13:53:45 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 07 May 2014 15:53:45 +0200 Subject: RFR 8042600: Add more samples in nashorn/samples directory In-Reply-To: <536A3262.7060700@oracle.com> References: <536A3262.7060700@oracle.com> Message-ID: <536A3AE9.6000603@oracle.com> I would prefer having semicolons after statements, I think it's the more widely accepted form. Otherwise looks very good! Hannes Am 2014-05-07 15:17, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8042600/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8042600 > > Thanks, > -Sundar From sundararajan.athijegannathan at oracle.com Wed May 7 14:50:30 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 07 May 2014 20:20:30 +0530 Subject: RFR 8042600: Add more samples in nashorn/samples directory In-Reply-To: <536A3AE9.6000603@oracle.com> References: <536A3262.7060700@oracle.com> <536A3AE9.6000603@oracle.com> Message-ID: <536A4836.1020809@oracle.com> Thanks. Fixed semicolons in http://cr.openjdk.java.net/~sundar/8042600/webrev.01/ -Sundar On Wednesday 07 May 2014 07:23 PM, Hannes Wallnoefer wrote: > I would prefer having semicolons after statements, I think it's the > more widely accepted form. > > Otherwise looks very good! > > Hannes > > Am 2014-05-07 15:17, schrieb A. Sundararajan: >> Please review http://cr.openjdk.java.net/~sundar/8042600/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8042600 >> >> Thanks, >> -Sundar > From hannes.wallnoefer at oracle.com Thu May 8 08:37:37 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 08 May 2014 10:37:37 +0200 Subject: Review request for JDK-8042118 In-Reply-To: References: Message-ID: <536B4251.1040908@oracle.com> Looks good to me. Only nitpick is a Javadoc error which I commented in Crucible. Hannes Am 2014-05-05 14:31, schrieb Attila Szegedi: > Please review JDK-8042118 at > > Note that this is a pretty large changeset, because the change is architecturally big. Namely, it separates types from symbols, and as you can imagine that ripples through the codebase into pretty deep places, together with the need to introduce calculation of static types for local variables etc. > > The overall benefit (in addition to cleaner architecture for some of the compiler stages) is a noticeable performance improvement we register on benchmarks, stemming from the fact that the compiler can now treat a single local variable as having different types in different parts of the function, and optimize accordingly. > > I actually wrote up fairly detailed change notes for this, they are below: > > AccessNode.property is now a String, not an IdentNode > Symbol class no longer contains a Type. Expressions have types directly now, either explicit or calculated from their subexpressions. > Only identifiers (IdentNode) have symbols. > Corollary: there are no longer temporary symbols; Symbol.IS_TEMP is gone, as is TemporarySymbols class. > Attr is separated into three phases: AssignSymbols, OptimisticTypesCalculator and LocalVariableTypesCalculator. > RangeAnalyzer class is gone. We don?t really need range analysis with optimistic and lvar type calculation. > FinalizeTypes class is gone. Fixups that it did are no longer needed. > DISCARD node is gone. The knowledge about whether it?s safe to discard a computation is moved into CodeGenerator which has a loadAndDiscard()method now. Some side-effect free discarded computations are now completely eliminated by the code generator. > BreakNode and ContinueNode now have a common superclass, JumpStatement. > There?s a new class named LocalVariableConversion, that is basically a linked list of triplets of (symbol, fromType, toType) specifying symbol type widenings that need to be performed on entry to a control flow join points. > There?s a new interface named JoinPredecessor. It?s implemented by AST nodes that need to carry a LocalVariableConversion as they can either originate an edge to a control flow join point, or can even fully contain one. JoinPredecessor only provides a getter and setter for a LocalVariableConversion; the semantics of control flow for a particular AST node are shared between the LocalVariableTypesCalculator that creates the conversion, and the CodeGenerator that uses it. > BranchOptimizer can generate code that inserts local variable conversions on control flow join edges, since short-circuiting logical AND and OR operators contain control flow joins. > Sometimes, an arbitrary expression needs to act as a JoinPredecessor (e.g. a test of a for or a while loop precedes the join point that is the target of the continue statement). JoinPredecessorExpression is introduced as a wrapper for an arbitrary Expression that decorates it with JoinPredecessorfunctionality. > A single local variable can use multiple JVM method local variable slots now. If it is assigned both an int and later an Object, it?ll have two slots: one for int value, and one for Object. In most extreme case, it can end up using 6 slots: 1 for int, 2 for long, 2 for double, and 1 for Object value. > Consequently, if the type calculator can prove that a variable is never read from a particular type, it will not allocate it a slot. A variable that is never read will end up taking up 0 slots and thus effectively get eliminated. > On entry to generated methods, it is sometimes now required to copy values from incoming parameter slots if one or more parameter will also later be assigned a different type (storage for a single symbol is continous). E.g. in the below snippet: > function f(a, b) { a = 1.0; print(a); a = ""; print(a); return b;} > f(1, 2); > ?b? needs to be moved from incoming slot 3 for f(callee, this, int a, int b) to slot 6, as ?a? needs 3 additional slots for double and Object values. > As a consequence, inferParameters() is no longer needed; method signatures always preserve the type of methods on entry, as the symbol for the parameter (just as any other symbol) is no longer tied to a single type. > codegen.Label.Stack is now a misnomer; we?ll end up renaming it to Label.Frame, as it now also carries information about local variable types: what their types are, which ones belong to the same symbol, and which ones are temporary variables. This information is used to ensure that types are consistent at join points as well as for other codegen purposes. > Both LocalVariableTypesCalculator and CodeGenerator calculate static reachability precisely. We should not emit dead code that ASM replaces withNOP, NOP, ... ATHROW anymore (except in rest-of methods, where they?re by design). > Type.BOOLEAN is automatically treated as Type.INT for purposes of arithmetic operations, as they?re both represented by ints on stack and would be converted to int anyway. > Explicit optimistic flags in expressions exist no more. Rather, every expression that can be optimistic will have an assigned type. It?s the job of the CodeGenerator to figure out the appropriate intersection of an expression?s type, it?s coercing type (e.g. if it?s used as a subexpression in bitwise operation it?ll be coerced to int anyway), and its most pessimistic type (if its type can?t be more pessimistic, it isn?t optimistic) and decide whether to emit an optimistic INVOKEDYNAMIC call site or not. > Since Expression.isOptimistic() determines if the expression has a narrower type than its most pessimistic type, FunctionNode now uses a different method, FunctionNode.canBeDeoptimized() to determine if it contains optimistic program points. > BinaryNode has probably the most complex type calculation; it provides methods for calculating its type, as well as the widest required type of its operands. It also caches the result of the last type calculation as otherwise we?d have some nasty quadratic times in evaluation of types of deep node trees. > void return values (of POJO methods) are now converted to Undefined, instead of to null. As a future step, we?ll emit dyn:call for discarded expressions with void return type, and also declare bytecode methods for functions that don?t return an explicit value as void. > Finally, the code generator changes. I?m dedicating a separate section to these. > > CodeGenerator doesn?t have any enterXxx() methods for expressions anymore, only for statements. This is to make the code more robust; an expression never occurs naked in JavaScript, it?s always inside a statement. Instead, there?s loadExpression() (former load()) that has a visitor that delegates to various private loadXxx() methods that contain the code equivalent to the old enterXxx() methods. > there?s a LoadScopeVar that encapsulates the loading of a scoped variable; it has a subclass named LoadFastScopeVar. > CodeGenerator internally loads expressions using TypeBounds. This is a pair of Type objects - a lower bound and an upper bound. E.g. when loading ?a * b? if we know that ?a? is int and ?b? is long, then the type bound for the operands is [long, double] (?a? must be loaded at least as a long because ?b? is long, and they should never be wider than double, ?cause that?s what the multiplication coerces them to). However, if the ?*? operator is optimistic and typed as long (can?t be int if it has a long operand), then we?ll attempt to load the operands as [int, double] and [long, double]; giving the chance to ?a? to still load as optimistic int and only widening it after load. I think this all works as expected; binary operands widen the lower bounds of their peer operands and potentially of operations (put widening pressure from bottom up), while operations narrow the upper bounds of their operands (put narrowing pressure from top down). We?ll obviously need to stare at final code output of our benchmarks to capture some corner cases that might?ve fell through the cracks? > test-first loops (all of them except do-while) are now emitted with their test first, then their body, then an unconditional jump back to the test. I realize this seems less efficient than emitting the test at the end, but unfortunately now that we need to perform type calculations there?s no easy way to do them correctly if we first emit the body, and only afterwards emit the test. I might be able to overcome this later. I spoke with Rickard B?ckman, and he doesn?t think HotSpot cares one way or the other about structuring of the loop. > Normally, join points that widen a local variable value type kill the narrower value. Thus, at most one type of the value is live for a symbol at any time. An exception to this are local variables assigned in try blocks if they need to be widened before they can be used in catch blocks. In that case, code in the try block will perform widening as part of the assignment (as we can?t know when will we transfer control to the catch block), but it will keep using the narrower value. The narrower value is only killed (unless reassigned) at the end of the try block. E.g.: > var i; > try { > thisMightThrow(); > i = 1; // stored into int slot, and also boxed into Object slot > print(i); // uses int slot > // int slot dies here > } catch(e) { > print(i); // must use i Object slot as i can be Undefined > } > print(i); // also uses i Object slot > > That?s also the reason why IdentNode implements JoinPredecessor; it needs to be able to carry a conversion on the edge from within try block to catch block when it?s used as the target of an assignment. Since we can?t know when will such a control flow transfer take place, we conservatively move the conversion to the assignment. > OptimisticOperation assumed new responsibilities. It is now created holding the Expression and TypeBounds, and it is its sole centralized responsibility to figure out if the operation will indeed be optimistic or not, as an interaction between the expression?s type, its most pessimistic type, and the passed type bounds. It now owns the the dynamicGet(), dynamicSet(), dynamicCall(), replaceCompileTimeProperty(), and convertOptimisticReturnValue() methods that formerly belonged to the CodeGenerator class. > Thanks, > Attila. From benjamin.john.evans at gmail.com Thu May 8 12:01:08 2014 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 8 May 2014 13:01:08 +0100 Subject: Missing jjs on Mac OS Message-ID: Hi, It's great having JDK 8 as the "system JDK" on Mac now, but it looks like the current packaging doesn't put jjs into this directory: /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/ which is the location that files from /usr/bin should target. Is there somewhere more official I should report this? Details of my use case below: Thanks, Ben Mac OS 10.7.5 $ java -version 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) $ which java /usr/bin/java From james.laskey at oracle.com Thu May 8 12:20:08 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 8 May 2014 09:20:08 -0300 Subject: Missing jjs on Mac OS In-Reply-To: References: Message-ID: Ben, You have to take it up with Apple. java, javac et al links were 'built' into the OS when Apple controlled Java on Mac OS X. What you have now are ghosts from the past. jjs has been added since Apple handed java maintenance over to Oracle. What you have now are ghosts from the past. Currently, each user has to manually (cd /usr/bin/ ; ln -s $JAVA_HOME/bin/jjs jjs) . Cheers, -- Jim On May 8, 2014, at 9:01 AM, Ben Evans wrote: > Hi, > > It's great having JDK 8 as the "system JDK" on Mac now, but it looks > like the current packaging doesn't put jjs into this directory: > > /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/ > > which is the location that files from /usr/bin should target. > > Is there somewhere more official I should report this? Details of my > use case below: > > Thanks, > > Ben > > Mac OS 10.7.5 > > $ java -version > 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) > > $ which java > /usr/bin/java From benjamin.john.evans at gmail.com Thu May 8 12:23:13 2014 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 8 May 2014 13:23:13 +0100 Subject: Missing jjs on Mac OS In-Reply-To: References: Message-ID: Ok - thanks Jim. Ben On Thu, May 8, 2014 at 1:20 PM, Jim Laskey (Oracle) wrote: > Ben, > > You have to take it up with Apple. java, javac et al links were 'built' into the OS when Apple controlled Java on Mac OS X. What you have now are ghosts from the past. jjs has been added since Apple handed java maintenance over to Oracle. What you have now are ghosts from the past. Currently, each user has to manually (cd /usr/bin/ ; ln -s $JAVA_HOME/bin/jjs jjs) . > > Cheers, > > -- Jim > > > > On May 8, 2014, at 9:01 AM, Ben Evans wrote: > >> Hi, >> >> It's great having JDK 8 as the "system JDK" on Mac now, but it looks >> like the current packaging doesn't put jjs into this directory: >> >> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/ >> >> which is the location that files from /usr/bin should target. >> >> Is there somewhere more official I should report this? Details of my >> use case below: >> >> Thanks, >> >> Ben >> >> Mac OS 10.7.5 >> >> $ java -version >> 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) >> >> $ which java >> /usr/bin/java > From marcus.lagergren at oracle.com Sun May 11 18:27:10 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Sun, 11 May 2014 20:27:10 +0200 Subject: RFR 8042364: Make __proto__ ES6 draft compliant In-Reply-To: <53689819.8000209@oracle.com> References: <53689819.8000209@oracle.com> Message-ID: <19DF6C3F-A231-4BEE-A07C-9F1071CF5A68@oracle.com> +1 (and I hate __proto__) /M On 06 May 2014, at 10:06, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8042364/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8042364 > > Thanks, > -Sundar From marcus.lagergren at oracle.com Sun May 11 18:27:56 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Sun, 11 May 2014 20:27:56 +0200 Subject: RFR 8042600: Add more samples in nashorn/samples directory In-Reply-To: <536A4836.1020809@oracle.com> References: <536A3262.7060700@oracle.com> <536A3AE9.6000603@oracle.com> <536A4836.1020809@oracle.com> Message-ID: +1 Nicely done, Sundar. /M On 07 May 2014, at 16:50, A. Sundararajan wrote: > Thanks. Fixed semicolons in http://cr.openjdk.java.net/~sundar/8042600/webrev.01/ > > -Sundar > > On Wednesday 07 May 2014 07:23 PM, Hannes Wallnoefer wrote: >> I would prefer having semicolons after statements, I think it's the more widely accepted form. >> >> Otherwise looks very good! >> >> Hannes >> >> Am 2014-05-07 15:17, schrieb A. Sundararajan: >>> Please review http://cr.openjdk.java.net/~sundar/8042600/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042600 >>> >>> Thanks, >>> -Sundar >> > From marcelorjava at gmail.com Sun May 11 22:18:41 2014 From: marcelorjava at gmail.com (Marcelo Rodrigues Costa) Date: Sun, 11 May 2014 23:18:41 +0100 Subject: Missing jjs on Mac OS In-Reply-To: References: Message-ID: This worked for me: *Install the JDK8 and create an alias for your JDK's jjs (Nashorn Interpreter), e.g., if you create a file called test.js, you can run the program with:* *$ jjs test.js* *Mac OS = alias jjs=?/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/bin/jjs?* http://stackoverflow.com/questions/15306892/nashorn-in-jdk8-b80 Cheers, 2014-05-08 13:23 GMT+01:00 Ben Evans : > Ok - thanks Jim. > > Ben > > On Thu, May 8, 2014 at 1:20 PM, Jim Laskey (Oracle) > wrote: > > Ben, > > > > You have to take it up with Apple. java, javac et al links were 'built' > into the OS when Apple controlled Java on Mac OS X. What you have now are > ghosts from the past. jjs has been added since Apple handed java > maintenance over to Oracle. What you have now are ghosts from the past. > Currently, each user has to manually (cd /usr/bin/ ; ln -s > $JAVA_HOME/bin/jjs jjs) . > > > > Cheers, > > > > -- Jim > > > > > > > > On May 8, 2014, at 9:01 AM, Ben Evans > wrote: > > > >> Hi, > >> > >> It's great having JDK 8 as the "system JDK" on Mac now, but it looks > >> like the current packaging doesn't put jjs into this directory: > >> > >> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/ > >> > >> which is the location that files from /usr/bin should target. > >> > >> Is there somewhere more official I should report this? Details of my > >> use case below: > >> > >> Thanks, > >> > >> Ben > >> > >> Mac OS 10.7.5 > >> > >> $ java -version > >> 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) > >> > >> $ which java > >> /usr/bin/java > > > -- Marcelo Rodrigues From eaw at woudy.org Mon May 12 04:44:01 2014 From: eaw at woudy.org (Eric Woudenberg) Date: Mon, 12 May 2014 14:44:01 +1000 Subject: Differences between Rhino and Nashorn when using Bindings.remove(x) Message-ID: <53705191.8000506@woudy.org> It appears that in Rhino, doing "myvar = undefined" is the same as doing EngineBindings.remove(myvar), however in Nashorn the EngineBindings.remove() operation behaves quite differently. I've attached a Jython program that I've run under jdk7 and jdk8 that point up the differences (in /RED italics/): > JAVA 7 (RHINO) JAVA 8 (NASHORN) > Case 1: No longer able to store a value after Bindings.remove(). > +----Expr "myvar = 33" +----Expr "myvar = 33" > > myvar = 33 myvar = 33 > Bindings.remove(myvar) Bindings.remove(myvar) > Engine.eval('myvar'): FAILED Engine.eval('myvar'): FAILED > typeof(myvar)=undefined typeof(myvar)=undefined > myvar in bindings: False myvar in bindings: False > myvar = 33 myvar = 33 > /Engine.eval('myvar'): 33 Engine.eval('myvar'): FAILED// > // typeof(myvar)=number typeof(myvar)=undefined// > // myvar in bindings: True myvar in bindings: False/ > Case 2: Bindings.remove() does not remove the value. > +----Expr "var myvar=33" +----Expr "var myvar=33" > > var myvar=33 var myvar=33 > Bindings.remove(myvar) Bindings.remove(myvar) > /Engine.eval('myvar'): FAILED Engine.eval('myvar'): 33// > // typeof(myvar)=undefined typeof(myvar)=number// > // myvar in bindings: False myvar in bindings: True/ > var myvar=33 var myvar=33 > Engine.eval('myvar'): 33 Engine.eval('myvar'): 33 > typeof(myvar)=number typeof(myvar)=number > myvar in bindings: True myvar in bindings: True We previously used Bindings.remove('myvar') and could not understand Nashorn's behavior. We've switched to using "myvar = undefined" and everything seems fine now. Nonetheless, can someone explain why doing Bindings.remove("var") shows this behavior? Thank you, Eric Woudenberg -------------- next part -------------- # Investigate the funny behavior of remove from javax.script import ScriptEngineManager, ScriptContext #from java.lang import System #System.setProperty('nashorn.args','--global-per-engine') def show(ref): try: print " Engine.eval('%s'):" % ref, Engine.eval('%s' % ref) except: print "FAILED" print ' typeof(%s)=%s' % (ref, Engine.eval('typeof(%s)' % ref)) print ' myvar in bindings:', 'myvar' in Bindings def run_setundefined(expr, ref): print '\n %s' % expr Engine.eval(expr, Bindings) Engine.eval('%s=undefined' % ref) print " %s=undefined" % ref show(ref) Engine.eval(expr, Bindings) print ' %s' % expr show(ref) def run_removebinding(expr, ref): print '\n %s' % expr Engine.eval(expr, Bindings) #show(ref) Bindings.remove(ref) print " Bindings.remove(%s)" % ref show(ref) Engine.eval(expr, Bindings) print ' %s' % expr show(ref) def main(): global Engine, Bindings Engine = ScriptEngineManager().getEngineByName("JavaScript") ref = 'myvar' sequence = 'myvar = 33', 'var myvar=33', 'this.myvar = 33' print '********** using Bindings.remove(myvar) **********' for expr in sequence: Bindings = Engine.createBindings() Engine.setBindings(Bindings, ScriptContext.ENGINE_SCOPE) print '\n+----Expr "%s"' % expr run_removebinding(expr, ref) print '\n********** using "myvar = undefined" **********' for expr in sequence: Bindings = Engine.createBindings() Engine.setBindings(Bindings, ScriptContext.ENGINE_SCOPE) print '\n+----Expr "%s" Ref %s ' % (expr, ref) run_setundefined(expr, ref) main() From david at code.davidpcaldwell.com Mon May 12 16:27:47 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Mon, 12 May 2014 12:27:47 -0400 Subject: Rhino shell compatibility Message-ID: I don't know how much compatibility is the goal, and I may be doing something wrong, but it looks like (running JDK 1.8.0_05) there are three incompatibilities between the Rhino shell and the mozilla_compat.js implementation provided with Nashorn. There may be reasons for these incompatibilities. But just in case there are not, 1. readFile appears to be absent, 2. readUrl appears to be absent, 3. The JavaAdapter implementation no longer appears to silently provide delegate methods that return null; instead the default implementation throws UnsupportedOperationException. Obviously I know how to work around these differences, but they cause some software to need modification to run under Nashorn even with the compatibility layer. Thoughts? -- David P. Caldwell http://www.davidpcaldwell.com/ From sundararajan.athijegannathan at oracle.com Tue May 13 03:58:17 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 13 May 2014 09:28:17 +0530 Subject: Rhino shell compatibility In-Reply-To: References: Message-ID: <53719859.5080403@oracle.com> Hi, mozilla_compat.js provides only few things for transition -- not every Rhino shell extension is supported by that. Only a subset of "non-shell" rhino extensions are supported. JavaAdapter in mozilla_compat.js is a cover over nashorn's own Java.extend. Java.extend, Java.type - are stricter in that errors/exceptions are preferred compared to silently returning false/providing empty method etc. Thanks -Sundar On Monday 12 May 2014 09:57 PM, David P. Caldwell wrote: > I don't know how much compatibility is the goal, and I may be doing > something wrong, but it looks like (running JDK 1.8.0_05) there are > three incompatibilities between the Rhino shell and the > mozilla_compat.js implementation provided with Nashorn. > > There may be reasons for these incompatibilities. But just in case > there are not, > > 1. readFile appears to be absent, > 2. readUrl appears to be absent, > 3. The JavaAdapter implementation no longer appears to silently > provide delegate methods that return null; instead the default > implementation throws UnsupportedOperationException. > > Obviously I know how to work around these differences, but they cause > some software to need modification to run under Nashorn even with the > compatibility layer. > > Thoughts? > > -- David P. Caldwell > http://www.davidpcaldwell.com/ From sundararajan.athijegannathan at oracle.com Tue May 13 04:11:36 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 13 May 2014 09:41:36 +0530 Subject: Differences between Rhino and Nashorn when using Bindings.remove(x) In-Reply-To: <53705191.8000506@woudy.org> References: <53705191.8000506@woudy.org> Message-ID: <53719B78.3050105@oracle.com> Yes, nashorn is different from rhino. Please check out https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes Bindings on top of Nashorn's Global tries to follow language rules rather than treating it as "Map". Per language rules, you can't delete a global variable - in strict mode, you'd get a TypeError for attempting to do so. Assigning undefined is better way to go. That way "surprise" of missing variable is minimized. Also, user provided Bindings only "variables" (i.e., not the ones created by "foo = 33" in evaluated code) are treated as "read-only". i.e., not found in Nashorn global scope -- so check out if found in Bindings of ScriptContext (via __noSuchProperty__) Hope this helps, -Sundar On Monday 12 May 2014 10:14 AM, Eric Woudenberg wrote: > It appears that in Rhino, doing "myvar = undefined" is the same as > doing EngineBindings.remove(myvar), however in Nashorn the > EngineBindings.remove() operation behaves quite differently. > > I've attached a Jython program that I've run under jdk7 and jdk8 that > point up the differences (in /RED italics/): > >> JAVA 7 (RHINO) JAVA 8 (NASHORN) >> > Case 1: No longer able to store a value after Bindings.remove(). >> +----Expr "myvar = 33" +----Expr "myvar = 33" >> >> myvar = 33 myvar = 33 >> Bindings.remove(myvar) Bindings.remove(myvar) >> Engine.eval('myvar'): FAILED Engine.eval('myvar'): FAILED >> typeof(myvar)=undefined typeof(myvar)=undefined >> myvar in bindings: False myvar in bindings: False >> myvar = 33 myvar = 33 >> /Engine.eval('myvar'): 33 Engine.eval('myvar'): FAILED// >> // typeof(myvar)=number typeof(myvar)=undefined// >> // myvar in bindings: True myvar in bindings: False/ >> > Case 2: Bindings.remove() does not remove the value. >> +----Expr "var myvar=33" +----Expr "var myvar=33" >> >> var myvar=33 var myvar=33 >> Bindings.remove(myvar) Bindings.remove(myvar) >> /Engine.eval('myvar'): FAILED Engine.eval('myvar'): 33// >> // typeof(myvar)=undefined typeof(myvar)=number// >> // myvar in bindings: False myvar in bindings: True/ >> var myvar=33 var myvar=33 >> Engine.eval('myvar'): 33 Engine.eval('myvar'): 33 >> typeof(myvar)=number typeof(myvar)=number >> myvar in bindings: True myvar in bindings: True > > We previously used Bindings.remove('myvar') and could not understand > Nashorn's behavior. We've switched to using "myvar = undefined" and > everything seems fine now. > > Nonetheless, can someone explain why doing Bindings.remove("var") > shows this behavior? > > Thank you, > Eric Woudenberg > From attila.szegedi at oracle.com Tue May 13 09:30:47 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Tue, 13 May 2014 09:30:47 +0000 Subject: hg: nashorn/jdk9/nashorn: 8042118: Separate types from symbols Message-ID: <201405130930.s4D9UmbL025695@aojmv0008> Changeset: c61d579dd5a8 Author: attila Date: 2014-05-13 11:30 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/c61d579dd5a8 8042118: Separate types from symbols Reviewed-by: hannesw, lagergren ! src/jdk/internal/dynalink/support/TypeUtilities.java ! src/jdk/internal/dynalink/support/messages.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/internal/codegen/ApplySpecialization.java + src/jdk/nashorn/internal/codegen/AssignSymbols.java - src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CodeGeneratorLexicalContext.java ! src/jdk/nashorn/internal/codegen/CompilationEnvironment.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java - src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FindScopeDepths.java ! src/jdk/nashorn/internal/codegen/Label.java + src/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/MapTuple.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java + src/jdk/nashorn/internal/codegen/OptimisticTypesCalculator.java ! src/jdk/nashorn/internal/codegen/ProgramPoints.java - src/jdk/nashorn/internal/codegen/RangeAnalyzer.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/codegen/SplitMethodEmitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/BytecodeNumericOps.java ! src/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk/nashorn/internal/codegen/types/NumberType.java - src/jdk/nashorn/internal/codegen/types/Range.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/BreakableStatement.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/Expression.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java + src/jdk/nashorn/internal/ir/JoinPredecessor.java + src/jdk/nashorn/internal/ir/JoinPredecessorExpression.java + src/jdk/nashorn/internal/ir/JumpStatement.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/LexicalContextExpression.java ! src/jdk/nashorn/internal/ir/LiteralNode.java + src/jdk/nashorn/internal/ir/LocalVariableConversion.java ! src/jdk/nashorn/internal/ir/LoopNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/Optimistic.java ! src/jdk/nashorn/internal/ir/OptimisticLexicalContext.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/Symbol.java - src/jdk/nashorn/internal/ir/TemporarySymbols.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/NashornTextifier.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/OptimisticReturnFilters.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/RewriteException.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/UnwarrantedOptimismException.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/tools/Shell.java ! test/script/basic/JDK-8012083.js ! test/script/basic/JDK-8026137.js ! test/script/basic/NASHORN-737.js.EXPECTED + test/script/basic/boolean_arithmetic.js + test/script/basic/boolean_arithmetic.js.EXPECTED ! test/script/basic/optimistic_check_type.js.EXPECTED ! test/script/basic/optimistic_logical_check_type.js.EXPECTED ! test/script/basic/parser/breakStat.js.EXPECTED ! test/script/basic/parser/continueStat.js.EXPECTED ! test/script/basic/parser/labelledStat.js.EXPECTED ! test/script/basic/parser/lhsExpr.js.EXPECTED ! test/script/basic/run-octane.js ! test/script/basic/runsunspider.js ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java From benjamin.john.evans at gmail.com Tue May 13 11:31:40 2014 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Tue, 13 May 2014 12:31:40 +0100 Subject: Missing jjs on Mac OS In-Reply-To: References: Message-ID: On Sun, May 11, 2014 at 11:18 PM, Marcelo Rodrigues Costa wrote: > This worked for me: > > Install the JDK8 and create an alias for your JDK's jjs (Nashorn > Interpreter), e.g., if you create a file called test.js, you can run the > program with: > > $ jjs test.js > > Mac OS = alias > jjs=?/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre/bin/jjs? Well, yes, but that wasn't really the point. The point is to have a well-behaved "system Java" that doesn't violate the principle of least surprise and is cleanly upgraded. Thanks, Ben From attila.szegedi at oracle.com Tue May 13 12:44:28 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 13 May 2014 14:44:28 +0200 Subject: Review request for JDK-8043002 Message-ID: Please review JDK-8043002 at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Tue May 13 13:04:49 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 13 May 2014 18:34:49 +0530 Subject: Review request for JDK-8043002 In-Reply-To: References: Message-ID: <53721871.6070801@oracle.com> +1 On Tuesday 13 May 2014 06:14 PM, Attila Szegedi wrote: > Please review JDK-8043002 at for > > Thanks, > Attila. From attila.szegedi at oracle.com Tue May 13 13:05:58 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 13 May 2014 15:05:58 +0200 Subject: Review request for JDK-8043003 Message-ID: <3986045F-879E-4FA0-9DF1-263B823AA082@oracle.com> Please review JDK-8043003 at http://cr.openjdk.java.net/~attila/8043003/webrev.00 for https://bugs.openjdk.java.net/browse/JDK-8043003 Thanks, Attila. From attila.szegedi at oracle.com Tue May 13 13:19:25 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Tue, 13 May 2014 13:19:25 +0000 Subject: hg: nashorn/jdk9/nashorn: 8043002: Improve performance of Nashorn equality operators Message-ID: <201405131319.s4DDJQfc005667@aojmv0008> Changeset: ca80b07bd06d Author: attila Date: 2014-05-13 14:54 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/ca80b07bd06d 8043002: Improve performance of Nashorn equality operators Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/DebuggerSupport.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java From sundararajan.athijegannathan at oracle.com Tue May 13 13:20:30 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 13 May 2014 18:50:30 +0530 Subject: Review request for JDK-8043003 In-Reply-To: <3986045F-879E-4FA0-9DF1-263B823AA082@oracle.com> References: <3986045F-879E-4FA0-9DF1-263B823AA082@oracle.com> Message-ID: <53721C1E.8020108@oracle.com> +1 On Tuesday 13 May 2014 06:35 PM, Attila Szegedi wrote: > Please review JDK-8043003 at http://cr.openjdk.java.net/~attila/8043003/webrev.00 for https://bugs.openjdk.java.net/browse/JDK-8043003 > > Thanks, > Attila. From attila.szegedi at oracle.com Tue May 13 13:22:32 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Tue, 13 May 2014 15:22:32 +0200 Subject: Review request for JDK-8043004 Message-ID: Please review JDK-8043004 at for Thanks, Attila. From david at code.davidpcaldwell.com Wed May 14 01:15:15 2014 From: david at code.davidpcaldwell.com (David P. Caldwell) Date: Tue, 13 May 2014 21:15:15 -0400 Subject: Rhino shell compatibility In-Reply-To: <53719859.5080403@oracle.com> References: <53719859.5080403@oracle.com> Message-ID: I guess my view is that since mozilla_compat.js is intended to ease transition, the JavaAdapter cover, for example, should also provide the less strict form; this wouldn't harm the preferred Java.extend target for migration, which could continue to use the stricter form. Similarly, readFile and readUrl wouldn't be hard to implement; I implemented each of them (poorly, but sufficiently) in perhaps 5-7 lines of code. Maybe there are sound reasons to exclude these (particularly if there are technical reasons I don't understand that would make the JavaAdapter defaults difficult), but my view would be, why not provide the smoothest possible glide path when providing a compatibility layer that is explicitly for that purpose? -- David P. Caldwell http://www.davidpcaldwell.com/ On Mon, May 12, 2014 at 11:58 PM, A. Sundararajan wrote: > Hi, > > mozilla_compat.js provides only few things for transition -- not every Rhino > shell extension is supported by that. Only a subset of "non-shell" rhino > extensions are supported. JavaAdapter in mozilla_compat.js is a cover over > nashorn's own Java.extend. Java.extend, Java.type - are stricter in that > errors/exceptions are preferred compared to silently returning > false/providing empty method etc. > > Thanks > -Sundar > > > On Monday 12 May 2014 09:57 PM, David P. Caldwell wrote: >> >> I don't know how much compatibility is the goal, and I may be doing >> something wrong, but it looks like (running JDK 1.8.0_05) there are >> three incompatibilities between the Rhino shell and the >> mozilla_compat.js implementation provided with Nashorn. >> >> There may be reasons for these incompatibilities. But just in case >> there are not, >> >> 1. readFile appears to be absent, >> 2. readUrl appears to be absent, >> 3. The JavaAdapter implementation no longer appears to silently >> provide delegate methods that return null; instead the default >> implementation throws UnsupportedOperationException. >> >> Obviously I know how to work around these differences, but they cause >> some software to need modification to run under Nashorn even with the >> compatibility layer. >> >> Thoughts? >> >> -- David P. Caldwell >> http://www.davidpcaldwell.com/ > > From attila.szegedi at oracle.com Wed May 14 08:51:42 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Wed, 14 May 2014 08:51:42 +0000 Subject: hg: nashorn/jdk9/nashorn: 8043003: Use strongly referenced generic invokers Message-ID: <201405140851.s4E8pivM004069@aojmv0008> Changeset: fbca2b7761ae Author: attila Date: 2014-05-14 10:51 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/fbca2b7761ae 8043003: Use strongly referenced generic invokers Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java From sundararajan.athijegannathan at oracle.com Wed May 14 13:24:46 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 14 May 2014 18:54:46 +0530 Subject: RFR 8043132: Nashorn : all tests failed with java.security.AccessControlException Message-ID: <53736E9E.5000906@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8043132/ Thanks -Sundar From attila.szegedi at oracle.com Wed May 14 13:30:21 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 14 May 2014 15:30:21 +0200 Subject: RFR 8043132: Nashorn : all tests failed with java.security.AccessControlException In-Reply-To: <53736E9E.5000906@oracle.com> References: <53736E9E.5000906@oracle.com> Message-ID: +1 On May 14, 2014, at 3:24 PM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8043132/ > > Thanks > -Sundar From attila.szegedi at oracle.com Wed May 14 13:49:27 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 14 May 2014 15:49:27 +0200 Subject: Review request for JDK-8043133 Message-ID: Please review JDK-8043133 at for Thanks, Attila. From attila.szegedi at oracle.com Wed May 14 13:55:29 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Wed, 14 May 2014 13:55:29 +0000 Subject: hg: nashorn/jdk9/nashorn: 8043004: Reduce variability at JavaAdapter call sites Message-ID: <201405141355.s4EDtTLf022291@aojmv0008> Changeset: fd32489a1cf1 Author: attila Date: 2014-05-14 15:55 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/fd32489a1cf1 8043004: Reduce variability at JavaAdapter call sites Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/DumpBytecode.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java From james.laskey at oracle.com Wed May 14 13:55:19 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Wed, 14 May 2014 10:55:19 -0300 Subject: RFR 8043132: Nashorn : all tests failed with java.security.AccessControlException In-Reply-To: References: <53736E9E.5000906@oracle.com> Message-ID: +1 On May 14, 2014, at 10:30 AM, Attila Szegedi wrote: > +1 > > On May 14, 2014, at 3:24 PM, A. Sundararajan wrote: > >> Please review http://cr.openjdk.java.net/~sundar/8043132/ >> >> Thanks >> -Sundar > From attila.szegedi at oracle.com Wed May 14 14:15:45 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 14 May 2014 16:15:45 +0200 Subject: Review request for JDK-8043137 Message-ID: <08B8356E-8704-41D6-A462-7597DA1F03F8@oracle.com> Please review JDK-8043137 at for Thanks, Attila. From attila.szegedi at oracle.com Wed May 14 14:29:15 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Wed, 14 May 2014 14:29:15 +0000 Subject: hg: nashorn/jdk9/nashorn: 8043137: Collapse long sequences of NOP in Nashorn bytecode output Message-ID: <201405141429.s4EETGxA028250@aojmv0008> Changeset: 1b93607e77f8 Author: attila Date: 2014-05-14 16:29 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/1b93607e77f8 8043137: Collapse long sequences of NOP in Nashorn bytecode output Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/ir/debug/NashornTextifier.java From attila.szegedi at oracle.com Wed May 14 14:30:45 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Wed, 14 May 2014 14:30:45 +0000 Subject: hg: nashorn/jdk9/nashorn: 8043132: Nashorn : all tests failed with java.security.AccessControlException Message-ID: <201405141430.s4EEUjFY028808@aojmv0008> Changeset: 0a26a037c4a4 Author: mnunez Date: 2014-05-14 15:50 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/0a26a037c4a4 8043132: Nashorn : all tests failed with java.security.AccessControlException Reviewed-by: attila, sundar ! make/build.xml From hannes.wallnoefer at oracle.com Wed May 14 14:58:55 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 14 May 2014 16:58:55 +0200 Subject: Review request for JDK-8043133 In-Reply-To: References: Message-ID: <537384AF.30904@oracle.com> Looks good. Hannes Am 2014-05-14 15:49, schrieb Attila Szegedi: > Please review JDK-8043133 at for > > Thanks, > Attila. From attila.szegedi at oracle.com Wed May 14 15:05:10 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Wed, 14 May 2014 15:05:10 +0000 Subject: hg: nashorn/jdk9/nashorn: 8043133: Fix corner cases of JDK-8041995 Message-ID: <201405141505.s4EF5Baa004996@aojmv0008> Changeset: de58e2c828af Author: attila Date: 2014-05-14 17:05 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/de58e2c828af 8043133: Fix corner cases of JDK-8041995 Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8043133.js + test/script/basic/JDK-8043133.js.EXPECTED From attila.szegedi at oracle.com Thu May 15 13:12:41 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Thu, 15 May 2014 15:12:41 +0200 Subject: Review request for JDK-8043235 Message-ID: <9A9335B5-CDE0-4B07-B52D-EF6DD5150CAF@oracle.com> Please review JDK-8043235 at for Thanks, Attila. From attila.szegedi at oracle.com Thu May 15 13:28:54 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Thu, 15 May 2014 13:28:54 +0000 Subject: hg: nashorn/jdk9/nashorn: 8043235: Type-based optimizations interfere with continuation methods Message-ID: <201405151328.s4FDStWe001294@aojmv0008> Changeset: 7fd1338440cc Author: attila Date: 2014-05-15 15:28 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/7fd1338440cc 8043235: Type-based optimizations interfere with continuation methods Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8043235.js + test/script/basic/JDK-8043235.js.EXPECTED From james.laskey at oracle.com Thu May 15 14:13:41 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 15 May 2014 11:13:41 -0300 Subject: Review request for JDK-8043235 In-Reply-To: <9A9335B5-CDE0-4B07-B52D-EF6DD5150CAF@oracle.com> References: <9A9335B5-CDE0-4B07-B52D-EF6DD5150CAF@oracle.com> Message-ID: <9594CA56-6709-40C7-BD56-87B40DEF227E@oracle.com> +1 On May 15, 2014, at 10:12 AM, Attila Szegedi wrote: > Please review JDK-8043235 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Mon May 19 13:37:25 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Mon, 19 May 2014 13:37:25 +0000 Subject: hg: nashorn/jdk9/nashorn: 8034206: Make parts of code pipeline reusable in order to facilitate faster warmup and faster lazy compilation. Message-ID: <201405191337.s4JDbQ9m024692@aojmv0008> Changeset: b8af86040a10 Author: lagergren Date: 2014-05-19 15:29 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/b8af86040a10 8034206: Make parts of code pipeline reusable in order to facilitate faster warmup and faster lazy compilation. Reviewed-by: hannesw, attila ! bin/runopt.sh ! src/jdk/nashorn/internal/codegen/ApplySpecialization.java ! src/jdk/nashorn/internal/codegen/AssignSymbols.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java - src/jdk/nashorn/internal/codegen/CompilationEnvironment.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/codegen/FindScopeDepths.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Label.java ! src/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/OptimisticTypesCalculator.java - src/jdk/nashorn/internal/codegen/ParamTypeMap.java + src/jdk/nashorn/internal/codegen/TypeEvaluator.java + src/jdk/nashorn/internal/codegen/TypeMap.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BlockStatement.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/BreakableStatement.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/Expression.java ! src/jdk/nashorn/internal/ir/ExpressionStatement.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/JoinPredecessorExpression.java ! src/jdk/nashorn/internal/ir/JumpStatement.java ! src/jdk/nashorn/internal/ir/LabelNode.java + src/jdk/nashorn/internal/ir/Labels.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/LoopNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/Optimistic.java ! src/jdk/nashorn/internal/ir/PropertyNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CompiledFunction.java ! src/jdk/nashorn/internal/runtime/CompiledFunctions.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/RewriteException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js From attila.szegedi at oracle.com Mon May 19 15:44:53 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 May 2014 17:44:53 +0200 Subject: Review request for JDK-8043431 Message-ID: <5F9CFDF4-EB26-4DCB-ADD0-EB93EEB63890@oracle.com> Please review JDK-8043431 at for Thanks, Attila. From attila.szegedi at oracle.com Mon May 19 16:24:18 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Mon, 19 May 2014 16:24:18 +0000 Subject: hg: nashorn/jdk9/nashorn: 8043431: Fix yet another corner case of JDK-8041995 Message-ID: <201405191624.s4JGOJQ9023988@aojmv0008> Changeset: 3d99a71c4dca Author: attila Date: 2014-05-19 18:24 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/3d99a71c4dca 8043431: Fix yet another corner case of JDK-8041995 Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8043431.js + test/script/basic/JDK-8043431.js.EXPECTED From hannes.wallnoefer at oracle.com Mon May 19 16:29:08 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 19 May 2014 18:29:08 +0200 Subject: Review request for JDK-8043431 In-Reply-To: <5F9CFDF4-EB26-4DCB-ADD0-EB93EEB63890@oracle.com> References: <5F9CFDF4-EB26-4DCB-ADD0-EB93EEB63890@oracle.com> Message-ID: <537A3154.8040201@oracle.com> Looks good. Hannes Am 2014-05-19 17:44, schrieb Attila Szegedi: > Please review JDK-8043431 at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Mon May 19 16:50:57 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 19 May 2014 22:20:57 +0530 Subject: RFR 8043443: Test framework changes to run script tests without security manager Message-ID: <537A3671.8010505@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8043443/ Thanks -Sundar From attila.szegedi at oracle.com Mon May 19 17:03:38 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 19 May 2014 19:03:38 +0200 Subject: RFR 8043443: Test framework changes to run script tests without security manager In-Reply-To: <537A3671.8010505@oracle.com> References: <537A3671.8010505@oracle.com> Message-ID: <613689FC-1AE0-4E49-A6A1-38BCA86F3302@oracle.com> +1 On May 19, 2014, at 6:50 PM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8043443/ > > Thanks > -Sundar From hannes.wallnoefer at oracle.com Tue May 20 06:22:36 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Tue, 20 May 2014 08:22:36 +0200 Subject: RFR 8043443: Test framework changes to run script tests without security manager In-Reply-To: <537A3671.8010505@oracle.com> References: <537A3671.8010505@oracle.com> Message-ID: <537AF4AC.6030505@oracle.com> Looks good. Hannes Am 2014-05-19 18:50, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8043443/ > > Thanks > -Sundar From marcus.lagergren at oracle.com Tue May 20 08:40:03 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Tue, 20 May 2014 08:40:03 +0000 Subject: hg: nashorn/jdk9/nashorn: 8043504: Octane test harness was missing argument to print_always at one callsite, causing erroneous logging Message-ID: <201405200840.s4K8e4UT022699@aojmv0008> Changeset: 7bd5e4c4e566 Author: lagergren Date: 2014-05-20 10:40 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/7bd5e4c4e566 8043504: Octane test harness was missing argument to print_always at one callsite, causing erroneous logging Reviewed-by: sundar, attila ! test/script/basic/run-octane.js From attila.szegedi at oracle.com Wed May 21 09:22:52 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 21 May 2014 11:22:52 +0200 Subject: Review request for JDK-8043608 Message-ID: <51F2DE8C-2F04-4038-8D24-166BB97B39A8@oracle.com> Please review JDK-8043608 at for Thanks, Attila. From sundararajan.athijegannathan at oracle.com Wed May 21 09:35:16 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 21 May 2014 15:05:16 +0530 Subject: Review request for JDK-8043608 In-Reply-To: <51F2DE8C-2F04-4038-8D24-166BB97B39A8@oracle.com> References: <51F2DE8C-2F04-4038-8D24-166BB97B39A8@oracle.com> Message-ID: <537C7354.8030200@oracle.com> +1 On Wednesday 21 May 2014 02:52 PM, Attila Szegedi wrote: > Please review JDK-8043608 at for > > Thanks, > Attila. From attila.szegedi at oracle.com Wed May 21 10:53:04 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Wed, 21 May 2014 10:53:04 +0000 Subject: hg: nashorn/jdk9/nashorn: 8043608: Make equality tests inline better Message-ID: <201405211053.s4LAr4L9026911@aojmv0008> Changeset: fa3b430e7592 Author: attila Date: 2014-05-21 12:52 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/fa3b430e7592 8043608: Make equality tests inline better Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java From attila.szegedi at oracle.com Wed May 21 13:15:10 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 21 May 2014 15:15:10 +0200 Subject: Review request for JDK-8043605 Message-ID: Please review JDK-8043605 at for Thanks, Attila. From attila.szegedi at oracle.com Wed May 21 13:38:18 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Wed, 21 May 2014 13:38:18 +0000 Subject: hg: nashorn/jdk9/nashorn: 8043605: Enable history for empty property maps Message-ID: <201405211338.s4LDcJkT021645@aojmv0008> Changeset: d73376609bf0 Author: attila Date: 2014-05-21 15:38 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/d73376609bf0 8043605: Enable history for empty property maps Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/PropertyMap.java From marcus.lagergren at oracle.com Wed May 21 14:13:26 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Wed, 21 May 2014 14:13:26 +0000 Subject: hg: nashorn/jdk9/nashorn: 3 new changesets Message-ID: <201405211413.s4LEDScG027700@aojmv0008> Changeset: acc76808d848 Author: lagergren Date: 2014-05-21 16:12 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/acc76808d848 8043633: In order to remove global state outside of contexts, make sure Timing class is an instance and not a static global collection of data. Move into Context. Move -Dnashorn.timing to an official logging option. Reviewed-by: sundar, attila ! bin/runopt.sh ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/Timing.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties Changeset: a91109307ad2 Author: lagergren Date: 2014-05-21 16:12 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/a91109307ad2 8043611: Move timing dependent benchmark for apply2call specialization to currently_failing. It is dependent that nothing takes machine time when doing the two runs, causing spurious assertions. Suggest running octane.raytrace manually instead to verify that this works, or incorporating it in the nightly test suite Reviewed-by: sundar, attila - test/script/basic/apply_to_call/apply_to_call_bench.js - test/script/basic/apply_to_call/apply_to_call_bench.js.EXPECTED + test/script/currently-failing/apply_to_call_bench.js + test/script/currently-failing/apply_to_call_bench.js.EXPECTED Changeset: 06f968255b0a Author: lagergren Date: 2014-05-21 16:12 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/06f968255b0a 8043632: Parallelize class installation and various script fixes. Reviewed-by: sundar, attila + bin/run_octane.sh ! bin/runopt.sh ! docs/DEVELOPER_README ! make/build-benchmark.xml ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/runtime/ScriptEnvironment.java - test/script/basic/ranges_disabled.js - test/script/basic/ranges_disabled.js.EXPECTED - test/script/basic/ranges_enabled.js - test/script/basic/ranges_enabled.js.EXPECTED - test/script/basic/ranges_payload.js From marcus.lagergren at oracle.com Wed May 21 17:47:45 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 21 May 2014 19:47:45 +0200 Subject: Review request for JDK-8043605 In-Reply-To: References: Message-ID: <77C2E31E-0A86-4527-A799-9A550B8B2CF0@oracle.com> Looking good. On 21 May 2014, at 15:15, Attila Szegedi wrote: > Please review JDK-8043605 at for > > Thanks, > Attila. From marcus.lagergren at oracle.com Wed May 21 17:47:52 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Wed, 21 May 2014 19:47:52 +0200 Subject: Review request for JDK-8043608 In-Reply-To: <51F2DE8C-2F04-4038-8D24-166BB97B39A8@oracle.com> References: <51F2DE8C-2F04-4038-8D24-166BB97B39A8@oracle.com> Message-ID: <6C76889D-4A5E-40E5-ABFB-4BD529D7D57A@oracle.com> Looking good. On 21 May 2014, at 11:22, Attila Szegedi wrote: > Please review JDK-8043608 at for > > Thanks, > Attila. From hannes.wallnoefer at oracle.com Thu May 22 14:19:36 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 22 May 2014 16:19:36 +0200 Subject: Review request for JDK-8030202: Nashorn: Multiple RegExp#ignoreCase issues Message-ID: <537E0778.6060704@oracle.com> Please review JDK-8030202: Nashorn: Multiple RegExp#ignoreCase issues: http://cr.openjdk.java.net/~hannesw/8030202/ Thanks, Hannes From sundararajan.athijegannathan at oracle.com Thu May 22 14:55:39 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 22 May 2014 20:25:39 +0530 Subject: Review request for JDK-8030202: Nashorn: Multiple RegExp#ignoreCase issues In-Reply-To: <537E0778.6060704@oracle.com> References: <537E0778.6060704@oracle.com> Message-ID: <537E0FEB.10904@oracle.com> +1 On Thursday 22 May 2014 07:49 PM, Hannes Wallnoefer wrote: > Please review JDK-8030202: Nashorn: Multiple RegExp#ignoreCase issues: > > http://cr.openjdk.java.net/~hannesw/8030202/ > > Thanks, > Hannes From marcus.lagergren at oracle.com Fri May 23 13:43:30 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Fri, 23 May 2014 15:43:30 +0200 Subject: Review request for JDK-8030202: Nashorn: Multiple RegExp#ignoreCase issues In-Reply-To: <537E0778.6060704@oracle.com> References: <537E0778.6060704@oracle.com> Message-ID: +1. Do we need to contribute this upstream to Joni? On 22 May 2014, at 16:19, Hannes Wallnoefer wrote: > Please review JDK-8030202: Nashorn: Multiple RegExp#ignoreCase issues: > > http://cr.openjdk.java.net/~hannesw/8030202/ > > Thanks, > Hannes From hannes.wallnoefer at oracle.com Fri May 23 14:09:18 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 23 May 2014 16:09:18 +0200 Subject: Review request for JDK-8030202: Nashorn: Multiple RegExp#ignoreCase issues In-Reply-To: References: <537E0778.6060704@oracle.com> Message-ID: <537F568E.1010505@oracle.com> Am 2014-05-23 15:43, schrieb Marcus Lagergren: > +1. Do we need to contribute this upstream to Joni? Thanks. The changes are all ECMA/JS specific. Hannes > > On 22 May 2014, at 16:19, Hannes Wallnoefer wrote: > >> Please review JDK-8030202: Nashorn: Multiple RegExp#ignoreCase issues: >> >> http://cr.openjdk.java.net/~hannesw/8030202/ >> >> Thanks, >> Hannes From sundararajan.athijegannathan at oracle.com Mon May 26 08:49:26 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 26 May 2014 14:19:26 +0530 Subject: RFR 8043930: TypeError when attemping to create an instance of non-public class could be better Message-ID: <53830016.4010707@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8043930/ Thanks -Sundar From marcus.lagergren at oracle.com Mon May 26 09:51:29 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Mon, 26 May 2014 11:51:29 +0200 Subject: RFR 8043930: TypeError when attemping to create an instance of non-public class could be better In-Reply-To: <53830016.4010707@oracle.com> References: <53830016.4010707@oracle.com> Message-ID: +1 On 26 May 2014, at 10:49, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8043930/ > > Thanks > -Sundar From attila.szegedi at oracle.com Mon May 26 11:24:28 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Mon, 26 May 2014 13:24:28 +0200 Subject: RFR 8043930: TypeError when attemping to create an instance of non-public class could be better In-Reply-To: <53830016.4010707@oracle.com> References: <53830016.4010707@oracle.com> Message-ID: +1 On May 26, 2014, at 10:49 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8043930/ > > Thanks > -Sundar From sundararajan.athijegannathan at oracle.com Tue May 27 11:45:29 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 27 May 2014 17:15:29 +0530 Subject: RFR 8044000: Access to undefined property yields "null" instead of "undefined" Message-ID: <53847AD9.50601@oracle.com> Hi, Please review http://cr.openjdk.java.net/~sundar/8044000/ Thanks -Sundar From james.laskey at oracle.com Tue May 27 11:51:45 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 27 May 2014 08:51:45 -0300 Subject: RFR 8044000: Access to undefined property yields "null" instead of "undefined" In-Reply-To: <53847AD9.50601@oracle.com> References: <53847AD9.50601@oracle.com> Message-ID: <741D4445-2C97-47D7-B306-0496DD0BFD3D@oracle.com> +1 On May 27, 2014, at 8:45 AM, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8044000/ > > Thanks > -Sundar From marcus.lagergren at oracle.com Tue May 27 19:25:45 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Tue, 27 May 2014 19:25:45 +0000 Subject: hg: nashorn/jdk9/nashorn: 8044012: Integrate the latest best known performance flags int ant octane jobs, and make sure that it's easy to compare 'ant octane-nashorn' and 'ant octane-v8' at the push of a button. (or rather; the entry of a command line) Message-ID: <201405271925.s4RJPk9K024588@aojmv0008> Changeset: 1a307df9ba3a Author: lagergren Date: 2014-05-27 21:25 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/1a307df9ba3a 8044012: Integrate the latest best known performance flags int ant octane jobs, and make sure that it's easy to compare 'ant octane-nashorn' and 'ant octane-v8' at the push of a button. (or rather; the entry of a command line) Reviewed-by: jlaskey, sundar ! docs/DEVELOPER_README ! make/build-benchmark.xml ! make/build.xml ! make/project.properties ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! test/script/basic/run-octane.js From marcus.lagergren at oracle.com Tue May 27 19:27:10 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Tue, 27 May 2014 21:27:10 +0200 Subject: RFR 8044000: Access to undefined property yields "null" instead of "undefined" In-Reply-To: <53847AD9.50601@oracle.com> References: <53847AD9.50601@oracle.com> Message-ID: <83FFB1C8-66D9-4E31-A2D4-019A26046A7C@oracle.com> +1 On 27 May 2014, at 13:45, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8044000/ > > Thanks > -Sundar From marcus.lagergren at oracle.com Wed May 28 12:03:43 2014 From: marcus.lagergren at oracle.com (marcus.lagergren at oracle.com) Date: Wed, 28 May 2014 12:03:43 +0000 Subject: hg: nashorn/jdk9/nashorn: 8044102: Ensure bechmark exclude list for Octane benchmarks is in only one place, project.properties, and fix benchmark harness Message-ID: <201405281203.s4SC3jeq023932@aojmv0008> Changeset: 4e97628f17be Author: lagergren Date: 2014-05-28 13:58 +0200 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/4e97628f17be 8044102: Ensure bechmark exclude list for Octane benchmarks is in only one place, project.properties, and fix benchmark harness Reviewed-by: attila, sundar ! bin/fixwhitespace.sh ! make/build-benchmark.xml ! make/build.xml ! make/project.properties ! test/script/basic/runsunspider.js From attila.szegedi at oracle.com Wed May 28 15:14:59 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Wed, 28 May 2014 17:14:59 +0200 Subject: Review request for JDK-8044171 Message-ID: <74477F97-AF52-498E-8A56-9D10E5D41424@oracle.com> Please review JDK-8044171 at for Thanks, Attila. From hannes.wallnoefer at oracle.com Wed May 28 15:21:47 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Wed, 28 May 2014 17:21:47 +0200 Subject: Review request for JDK-8044171 In-Reply-To: <74477F97-AF52-498E-8A56-9D10E5D41424@oracle.com> References: <74477F97-AF52-498E-8A56-9D10E5D41424@oracle.com> Message-ID: <5385FF0B.3050301@oracle.com> +1 Am 2014-05-28 17:14, schrieb Attila Szegedi: > Please review JDK-8044171 at for > > Thanks, > Attila. From sundararajan.athijegannathan at oracle.com Fri May 30 11:33:55 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 30 May 2014 17:03:55 +0530 Subject: RFR 8044415: ant makefile should have a target to generate javadoc only for jdk.nashorn.api and sub-packages Message-ID: <53886CA3.5070506@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8044415/ Thanks, -Sundar From attila.szegedi at oracle.com Fri May 30 12:17:21 2014 From: attila.szegedi at oracle.com (Attila Szegedi) Date: Fri, 30 May 2014 14:17:21 +0200 Subject: RFR 8044415: ant makefile should have a target to generate javadoc only for jdk.nashorn.api and sub-packages In-Reply-To: <53886CA3.5070506@oracle.com> References: <53886CA3.5070506@oracle.com> Message-ID: <0B30F7CF-F208-4AD0-987A-66D9DFCE59D4@oracle.com> +1 On May 30, 2014, at 1:33 PM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8044415/ > > Thanks, > -Sundar From james.laskey at oracle.com Fri May 30 12:35:56 2014 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 30 May 2014 09:35:56 -0300 Subject: RFR 8044415: ant makefile should have a target to generate javadoc only for jdk.nashorn.api and sub-packages In-Reply-To: <53886CA3.5070506@oracle.com> References: <53886CA3.5070506@oracle.com> Message-ID: <85925A3D-02E0-473D-9373-ACD1F1746BF6@oracle.com> +1 On May 30, 2014, at 8:33 AM, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8044415/ > > Thanks, > -Sundar