From tom.mcginn at oracle.com Sat Feb 1 07:07:06 2014 From: tom.mcginn at oracle.com (Tom McGinn) Date: Sat, 01 Feb 2014 10:07:06 -0500 Subject: Class.forName? In-Reply-To: References: <52EC352E.2030604@oracle.com> Message-ID: <52ED0D9A.1020203@oracle.com> Thanks Jim - That's what I needed. Here's the working code: var driverClass = Java.type("org.apache.derby.jdbc.ClientDriver"); var driver = new driverClass(); var conn = driver.connect("jdbc:derby://localhost:1527/sample;user=app;password=app", null); var stmt = conn.createStatement(); var rs = stmt.executeQuery("SELECT NAME FROM Customer"); while (rs.next()) { print(rs.getString(1)); } However, this code does not work: var driverManager = Java.type("java.sql.DriverManager"); var conn = driverManager.getConnection("jdbc:derby://localhost:1527/sample;user=app;password=app"); A SQLException is thrown: No suitable driver found for jdbc:derby://localhost:1527/sample;user=app;password=app I may have missed this, but I guess that static initialization blocks are not executed? DriverManager would have executed this during initialization: static { loadInitialDrivers(); println("JDBC DriverManager initialized"); } Thanks again, Tom On 1/31/2014 8:20 PM, Jim Laskey (Oracle) wrote: > Since I don't have the jar handy, I'm just guessing, but why wouldn't you just; > > jjs> var driverClass = Java.type("org.apache.derby.jdbc.ClientDriver"); > > -- Jim > > On Jan 31, 2014, at 7:43 PM, Tom McGinn wrote: > >> Hello - >> >> I am trying to create a JS file that illustrates using Java classes mixed with JS. >> >> I am trying to connect to the sample JavaDB instance, but am not able to load the driver class. >> >> jjs -cp /home/tmcginn/jdk1.8.0/db/lib/derbyclient.jar >> jjs> var driver = "org.apache.derby.jdbc.ClientDriver"; >> jjs> Java.type("java.lang.Class").forName(driver); >> java.lang.RuntimeException: java.lang.ClassNotFoundException: org.apache.derby.jdbc.ClientDriver >> >> I think I am missing something obvious.... >> >> I am running this on Oracle Linux 6 u3 on an OVM. >> >> Thanks, >> >> Tom >> >> -- >> >> >> Tom McGinn | Java Curriculum Developer >> OracleServer Technologies Curriculum Development >> Phone: +1.781.442.0621 >> Mail: tom.mcginn at oracle.com >> Blog: Java Training Beat >> -- Tom McGinn | Java Curriculum Developer OracleServer Technologies Curriculum Development Phone: +1.781.442.0621 Mail: tom.mcginn at oracle.com Blog: Java Training Beat From jean-francois.denise at oracle.com Sat Feb 1 10:15:33 2014 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Sat, 1 Feb 2014 19:15:33 +0100 Subject: Class.forName? In-Reply-To: <52ED0D9A.1020203@oracle.com> References: <52EC352E.2030604@oracle.com> <52ED0D9A.1020203@oracle.com> Message-ID: <7D5B0A1B-A981-4079-92B9-FEE42C7C92F9@oracle.com> Hi Tom, some JDBC initialisation code that works: Java.type("org.apache.derby.jdbc.ClientDriver"); var connection = java.sql.DriverManager.getConnection("jdbc:derby://localhost:1527/sample;user=app;password=app", null); JF On Feb 1, 2014, at 4:07 PM, Tom McGinn wrote: > Thanks Jim - > > That's what I needed. Here's the working code: > > var driverClass = Java.type("org.apache.derby.jdbc.ClientDriver"); > var driver = new driverClass(); > var conn = driver.connect("jdbc:derby://localhost:1527/sample;user=app;password=app", null); > var stmt = conn.createStatement(); > var rs = stmt.executeQuery("SELECT NAME FROM Customer"); > while (rs.next()) { > print(rs.getString(1)); > } > > However, this code does not work: > > var driverManager = Java.type("java.sql.DriverManager"); > var conn = driverManager.getConnection("jdbc:derby://localhost:1527/sample;user=app;password=app"); > > A SQLException is thrown: No suitable driver found for jdbc:derby://localhost:1527/sample;user=app;password=app > > I may have missed this, but I guess that static initialization blocks are not executed? DriverManager would have executed > this during initialization: > > static { > loadInitialDrivers(); > println("JDBC DriverManager initialized"); > } > > Thanks again, > > Tom > > > On 1/31/2014 8:20 PM, Jim Laskey (Oracle) wrote: >> Since I don't have the jar handy, I'm just guessing, but why wouldn't you just; >> >> jjs> var driverClass = Java.type("org.apache.derby.jdbc.ClientDriver"); >> >> -- Jim >> >> On Jan 31, 2014, at 7:43 PM, Tom McGinn wrote: >> >>> Hello - >>> >>> I am trying to create a JS file that illustrates using Java classes mixed with JS. >>> >>> I am trying to connect to the sample JavaDB instance, but am not able to load the driver class. >>> >>> jjs -cp /home/tmcginn/jdk1.8.0/db/lib/derbyclient.jar >>> jjs> var driver = "org.apache.derby.jdbc.ClientDriver"; >>> jjs> Java.type("java.lang.Class").forName(driver); >>> java.lang.RuntimeException: java.lang.ClassNotFoundException: org.apache.derby.jdbc.ClientDriver >>> >>> I think I am missing something obvious.... >>> >>> I am running this on Oracle Linux 6 u3 on an OVM. >>> >>> Thanks, >>> >>> Tom >>> >>> -- >>> >>> >>> Tom McGinn | Java Curriculum Developer >>> OracleServer Technologies Curriculum Development >>> Phone: +1.781.442.0621 >>> Mail: tom.mcginn at oracle.com >>> Blog: Java Training Beat >>> > > -- > > > Tom McGinn | Java Curriculum Developer > OracleServer Technologies Curriculum Development > Phone: +1.781.442.0621 > Mail: tom.mcginn at oracle.com > Blog: Java Training Beat > From buddhi.mihara at live.com Tue Feb 4 10:58:41 2014 From: buddhi.mihara at live.com (buddhi mihara) Date: Wed, 5 Feb 2014 00:58:41 +0600 Subject: expose custome object or function to script environementt Message-ID: i am using second option you suggested.(using jsObject) i used script object class to create a scriptObject called process.(similar to node process) ,but everytime i need to add a function(like abs() function in Math) to this scriptObject do i need to write a java class which extends from jsObject and create a new object of that class or is there any workaround.(in my script i need to access something like process.bind()). From ecki at zusammenkunft.net Tue Feb 4 15:02:32 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 5 Feb 2014 00:02:32 +0100 Subject: JDK8 cleanups? Message-ID: <20140205000232.00006983.ecki@zusammenkunft.net> Hello, not sure if this is the right list, but I will post it here anyway: a) the jdk8 documentation page has a "whats new in jdk8" section and this section lists "jjs", however on the doc page itself only jrunscript is mentioned: http://download.java.net/jdk8/docs/technotes/tools/index.html#enhancements b) On the jrunscript documentation page is a sentence which I do not understand (or the content behind the link is missing): http://download.java.net/jdk8/docs/technotes/tools/windows/jrunscript.html #See Also #If JavaScript is used, then before it evaluates a user defined script, #the jrunscript command initializes certain built-in functions and #objects. These JavaScript built-ins are documented in JsDoc-Toolkit at #http://code.google.com/p/jsdoc-toolkit/ Is this also true for nashorn, or where can I get this list? c) this wiki page is broken: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation d) I guess on this page the word nashorn (or jjs/jrunscript or tools) should be mentioned, the current scripting section more looks like the integrated java scripting not the tools: http://download.java.net/jdk8/docs/technotes/guides/ e) is there a documentation about a list of all built-in load() scripts of nashorn? I have only found a list for fx: in the user guide. f) both jjs and jrunscript should probably add the scripting guide homepage as a see also resource. g) jjs -h does not mention that there is a -xhelp The actual reason why I was browsing the documentation (and I did not find an answer) is, if there is a inspect() like method in jjs to discover the environment? I was for example courious if there is some JSON support in nashhorn? (or at least an load("nashorn:xxx.js") to add?) From ecki at zusammenkunft.net Tue Feb 4 18:08:16 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 5 Feb 2014 03:08:16 +0100 Subject: jjs with support for Security Manager? Message-ID: <20140205030816.0000036f.ecki@zusammenkunft.net> Hello, I tried to use jjs to do some tests with the Java security manager, however it does not completely work: a) when starting jjs with -Djava.security.manager no SM is installed: C:\Program Files\Java\jdk1.8.0\bin>jjs -Djava.security.manager jjs> java.lang.System.getSecurityManager() null This is normally the job of the launcher, so I guess this is a problem in the jjs binary. b) when installing the SM by hand it seems to have a deny-all policy: C:\Program Files\Java\jdk1.8.0\bin>jjs jjs> var Manager = Java.type("java.lang.SecurityManager") jjs> java.lang.System.setSecurityManager(new Manager) null jjs> java.lang.System.getSecurityManager() java.lang.SecurityManager at 51b279c jjs> java.lang.System.getPropert("java.version") java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.version" "read") jjs> exit() java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "exitVM.0") However I cannot use java.security.debug=all to see where the problem is. No idea why this is. Maybe it is related to the way system properties are set with jjs? Any ideas? Greetings Bernd From ecki at zusammenkunft.net Tue Feb 4 18:31:53 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 5 Feb 2014 03:31:53 +0100 Subject: jjs with support for Security Manager? In-Reply-To: <20140205030816.0000036f.ecki@zusammenkunft.net> References: <20140205030816.0000036f.ecki@zusammenkunft.net> Message-ID: <20140205033153.00006cb4.ecki@zusammenkunft.net> Hello, short follow-up: when using java -Djava.security.manager -Djava.security.debug=all -cp lib\tools.jar jdk.nashorn.tools.Shell the security manager is installed and in effect. However the system policy does not apply. It looks like there is a "new" protection domain "null" which is not granted by java.policy: ... access: domain that failed ProtectionDomain null null java.security.Permissions at 7fe8ea47 ( ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.runtime") ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.scripts") ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.objects") ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.runtime.linker") ("java.lang.RuntimePermission" "accessClassInPackage.jdk.nashorn.internal.runtime.arrays") ) java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.version" "read") jjs> From sundararajan.athijegannathan at oracle.com Tue Feb 4 23:08:45 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 05 Feb 2014 12:38:45 +0530 Subject: jjs with support for Security Manager? In-Reply-To: <20140205030816.0000036f.ecki@zusammenkunft.net> References: <20140205030816.0000036f.ecki@zusammenkunft.net> Message-ID: <52F1E37D.9070908@oracle.com> Hi, The -D System properties are set after jjs tool is initialized. If you want System properties to be initialized before VM is initialized, you should use -J-D. jjs -J-Djava.security.manager foo.js This is true of all JDK bin tools. Any -J option is passed to the VM. So, for example, jjs -J-Xmx1g -J-Djava.security.manager foo.js will set maximum heap size as well as set security manager with the default System policy. Hope this helps, -Sundar On Wednesday 05 February 2014 07:38 AM, Bernd Eckenfels wrote: > Hello, > > I tried to use jjs to do some tests with the Java security manager, > however it does not completely work: > > a) when starting jjs with -Djava.security.manager no SM is installed: > > C:\Program Files\Java\jdk1.8.0\bin>jjs -Djava.security.manager > jjs> java.lang.System.getSecurityManager() > null > > This is normally the job of the launcher, so I guess this is a problem in the jjs binary. > > b) when installing the SM by hand it seems to have a deny-all policy: > > C:\Program Files\Java\jdk1.8.0\bin>jjs > jjs> var Manager = Java.type("java.lang.SecurityManager") > jjs> java.lang.System.setSecurityManager(new Manager) > null > jjs> java.lang.System.getSecurityManager() > java.lang.SecurityManager at 51b279c > jjs> java.lang.System.getPropert("java.version") > java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.version" "read") > jjs> exit() > java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "exitVM.0") > > However I cannot use java.security.debug=all to see where the problem is. No idea why this is. Maybe it is related to the way system properties are set with jjs? Any ideas? > > Greetings > Bernd From sundararajan.athijegannathan at oracle.com Tue Feb 4 23:16:09 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 05 Feb 2014 12:46:09 +0530 Subject: expose custome object or function to script environementt In-Reply-To: References: Message-ID: <52F1E539.4050602@oracle.com> The question is not clear. Avatar.js uses plain javascript and some Java to implement node.js. It does not use any other magic. If you want your object to support functions, you could do that in many ways: var process = { foo: function() {....} }; process.foo(); Am I missing something? -Sundar On Wednesday 05 February 2014 12:28 AM, buddhi mihara wrote: > i am using second option you suggested.(using jsObject) > i used script object class to create a scriptObject called process.(similar to node process) ,but everytime i need to add a function(like abs() function in Math) to this scriptObject do i need to write a java class which extends from jsObject and create a new object of that class or is there any workaround.(in my script i need to access something like process.bind()). From sundararajan.athijegannathan at oracle.com Tue Feb 4 23:25:39 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 05 Feb 2014 12:55:39 +0530 Subject: JDK8 cleanups? In-Reply-To: <20140205000232.00006983.ecki@zusammenkunft.net> References: <20140205000232.00006983.ecki@zusammenkunft.net> Message-ID: <52F1E773.8090005@oracle.com> Hi, Inline responses below.. On Wednesday 05 February 2014 04:32 AM, Bernd Eckenfels wrote: > Hello, > > not sure if this is the right list, but I will post it here anyway: > > a) the jdk8 documentation page has a "whats new in jdk8" section and > this section lists "jjs", however on the doc page itself only > jrunscript is mentioned: > > http://download.java.net/jdk8/docs/technotes/tools/index.html#enhancements Looks like a doc oversight. I'll notify. > > b) On the jrunscript documentation page is a sentence which I do not > understand (or the content behind the link is missing): > > http://download.java.net/jdk8/docs/technotes/tools/windows/jrunscript.html > #See Also > #If JavaScript is used, then before it evaluates a user defined script, > #the jrunscript command initializes certain built-in functions and > #objects. These JavaScript built-ins are documented in JsDoc-Toolkit at > #http://code.google.com/p/jsdoc-toolkit/ jrunscript runs "init.js" bundled in the tool itself. This is historical. "jjs" does not run that script. > Is this also true for nashorn, or where can I get this list? > > c) this wiki page is broken: > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation By "broken", do you say any information is missing? or you can't access it? > > d) I guess on this page the word nashorn (or jjs/jrunscript or tools) > should be mentioned, the current scripting section more looks like the > integrated java scripting not the tools: > http://download.java.net/jdk8/docs/technotes/guides/ > > e) is there a documentation about a list of all built-in load() > scripts of nashorn? I have only found a list for fx: in the user guide. Same wiki page - left panel has link to this page: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > f) both jjs and jrunscript should probably add the scripting guide > homepage as a see also resource. Scripting guide is meant for programmatic access for nashorn or any other javax.script compliant engines. Not sure if we should include jjs and jrunscript info there. > g) jjs -h does not mention that there is a -xhelp Options displayed by '-h' are the supported option. The options displayed by '-xhelp' (including -xhelp) are 'experimental' - may be modified/removed in future. > The actual reason why I was browsing the documentation (and I did not > find an answer) is, if there is a inspect() like method in jjs to > discover the environment? I was for example courious if there is some > JSON support in nashhorn? (or at least an load("nashorn:xxx.js") to > add?) JSON is supported because Nashorn implements ECMAScript 5.1 spec - which includes JSON object. http://www.ecma-international.org/ecma-262/5.1/ As I said earlier, nashorn specific extensions are documented here: https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions There is no 'inspect'. But, you can do the following in 'jjs': jjs> Object.getOwnPropertyNames(this) Hope this helps -Sundar From ecki at zusammenkunft.net Wed Feb 5 00:21:05 2014 From: ecki at zusammenkunft.net (Bernd) Date: Wed, 5 Feb 2014 09:21:05 +0100 Subject: JDK8 cleanups? In-Reply-To: References: <20140205000232.00006983.ecki@zusammenkunft.net> <52F1E773.8090005@oracle.com> Message-ID: Oop sent before including list ... answers inline. Greetings ---------- Weitergeleitete Nachricht ---------- Von: "Bernd" Datum: 05.02.2014 09:15 Betreff: Re: JDK8 cleanups? An: "A. Sundararajan" Cc: Am 05.02.2014 08:26 schrieb "A. Sundararajan" < sundararajan.athijegannathan at oracle.com>: >> b) On the jrunscript documentation page is a sentence which I do not >> understand (or the content behind the link is missing): >> >> http://download.java.net/jdk8/docs/technotes/tools/windows/jrunscript.html >> #See Also >> #If JavaScript is used, then before it evaluates a user defined script, >> #the jrunscript command initializes certain built-in functions and >> #objects. These JavaScript built-ins are documented in JsDoc-Toolkit at >> #http://code.google.com/p/jsdoc-toolkit/ > > > jrunscript runs "init.js" bundled in the tool itself. This is historical. "jjs" does not run that script. Did I miss the doc of this init.js under the link or should the link be fixed? I would add the startup description to its own section and reserve see also for references. >> Is this also true for nashorn, or where can I get this list? So for nashorn only the ecma script objects (like Math) are bound? -scripting is registering the documented extensions, what about -strict? >> c) this wiki page is broken: >> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation > > > By "broken", do you say any information is missing? or you can't access it? Hm, I mean the formatting (and I had the impression the links did not work, but they actually do, so sorry for the false alarm) >> e) is there a documentation about a list of all built-in load() >> scripts of nashorn? I have only found a list for fx: in the user guide. > > > Same wiki page - left panel has link to this page: > > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions It lists the prefixes (fx and nashorn) but not the available script names (or where to find the resources). Is nashorn: a resource loader scheme? >> f) both jjs and jrunscript should probably add the scripting guide >> homepage as a see also resource. > > Scripting guide is meant for programmatic access for nashorn or any other javax.script compliant engines. Yes, I mean the scripting start page or directly the nashorn user guide, the section about the scripting extension is relevant ( http://download.java.net/jdk8/docs/technotes/guides/scripting/nashorn/shell.html#sthref24 ) > There is no 'inspect'. But, you can do the following in 'jjs': > > jjs> Object.getOwnPropertyNames(this) Ah cool, are there any synthetic objects hidden? > Hope this helps Indeed, thanks! Bernd From buddhi.mihara at live.com Wed Feb 5 00:46:17 2014 From: buddhi.mihara at live.com (buddhi mihara) Date: Wed, 5 Feb 2014 14:46:17 +0600 Subject: expose custome object or function to script environementt Message-ID: what i mean is without using javascript we can use java to expose scriptObject to javascript environment.(just like Math Object. ). i need to add a function as a property of that function.(like abs function in Math Object). so i add a property called bind to my process object and when user ask var foo = process.bind(param); i create a new object of bind class.(bind class is a class which inherits from JSObject class).what i ask is think if i need to add multiple function to scriptObject process in java level do i need to write a separate class which inherits from JSObject, for each of that function or is there any alternatives. i asked this because in every global object like Math.oracle use following structure @Function(attributes = Attribute.NOT_ENUMERABLE) public static Object toString(final Object self) { return getBoolean(self).toString(); } i want to attach all the function to process object in java level thank you From sundararajan.athijegannathan at oracle.com Wed Feb 5 00:48:02 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 05 Feb 2014 14:18:02 +0530 Subject: JDK8 cleanups? In-Reply-To: References: <20140205000232.00006983.ecki@zusammenkunft.net> <52F1E773.8090005@oracle.com> Message-ID: <52F1FAC2.7050502@oracle.com> * "init.js" is just internal name of the initialization script used by jrunscript. The functions, objects exposed by it are linked from here: http://docs.oracle.com/javase/7/docs/technotes/tools/share/jrunscript.html @ http://docs.oracle.com/javase/7/docs/technotes/tools/share/jsdocs/allclasses-noframe.html As I said, nashorn's 'jjs' does not run this resource script from jrunscript. * jjs -h talks about command line options like -strict, -scripting. -strict is to enable ECMAScript "use strict" mode from command line option rather than including it in scripts. See also http://es5.github.io/#x10.1.1 -scripting https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions explains syntax and global extensions available only in -scripting mode. You may want to look for (-scripting mode only) sections. * Object.getOwnPropertyNames lists all properties - enumerable or not. This is as per ECMAScript spec. PS. As for jdk8 tool docs, I still don't see new tools like 'jdeps'. I'd assume tools page is to yet to be updated for jdk8 specific tools. As I said earlier, I'll notify. -Sundar On Wednesday 05 February 2014 01:51 PM, Bernd wrote: > Oop sent before including list ... answers inline. Greetings > ---------- Weitergeleitete Nachricht ---------- > Von: "Bernd" > Datum: 05.02.2014 09:15 > Betreff: Re: JDK8 cleanups? > An: "A. Sundararajan" > Cc: > > > Am 05.02.2014 08:26 schrieb "A. Sundararajan" < > sundararajan.athijegannathan at oracle.com>: >>> b) On the jrunscript documentation page is a sentence which I do not >>> understand (or the content behind the link is missing): >>> >>> > http://download.java.net/jdk8/docs/technotes/tools/windows/jrunscript.html >>> #See Also >>> #If JavaScript is used, then before it evaluates a user defined script, >>> #the jrunscript command initializes certain built-in functions and >>> #objects. These JavaScript built-ins are documented in JsDoc-Toolkit at >>> #http://code.google.com/p/jsdoc-toolkit/ >> >> jrunscript runs "init.js" bundled in the tool itself. This is historical. > "jjs" does not run that script. > > Did I miss the doc of this init.js under the link or should the link be > fixed? I would add the startup description to its own section and reserve > see also for references. > >>> Is this also true for nashorn, or where can I get this list? > So for nashorn only the ecma script objects (like Math) are bound? > -scripting is registering the documented extensions, what about -strict? > >>> c) this wiki page is broken: >>> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+Documentation >> >> By "broken", do you say any information is missing? or you can't access > it? > > Hm, I mean the formatting (and I had the impression the links did not work, > but they actually do, so sorry for the false alarm) > >>> e) is there a documentation about a list of all built-in load() >>> scripts of nashorn? I have only found a list for fx: in the user guide. >> >> Same wiki page - left panel has link to this page: >> >> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions > It lists the prefixes (fx and nashorn) but not the available script names > (or where to find the resources). Is nashorn: a resource loader scheme? > >>> f) both jjs and jrunscript should probably add the scripting guide >>> homepage as a see also resource. >> Scripting guide is meant for programmatic access for nashorn or any other > javax.script compliant engines. > > Yes, I mean the scripting start page or directly the nashorn user guide, > the section about the scripting extension is relevant ( > http://download.java.net/jdk8/docs/technotes/guides/scripting/nashorn/shell.html#sthref24 > ) > >> There is no 'inspect'. But, you can do the following in 'jjs': >> >> jjs> Object.getOwnPropertyNames(this) > Ah cool, are there any synthetic objects hidden? > >> Hope this helps > Indeed, thanks! > > Bernd From ecki at zusammenkunft.net Wed Feb 5 00:57:59 2014 From: ecki at zusammenkunft.net (Bernd) Date: Wed, 5 Feb 2014 09:57:59 +0100 Subject: JDK8 cleanups? In-Reply-To: <52F1FAC2.7050502@oracle.com> References: <20140205000232.00006983.ecki@zusammenkunft.net> <52F1E773.8090005@oracle.com> <52F1FAC2.7050502@oracle.com> Message-ID: Am 05.02.2014 09:49 schrieb "A. Sundararajan" < sundararajan.athijegannathan at oracle.com>: > > * "init.js" is just internal name of the initialization script used by jrunscript. The functions, objects exposed by it are linked from here: > > http://docs.oracle.com/javase/7/docs/technotes/tools/share/jrunscript.html > > @ http://docs.oracle.com/javase/7/docs/technotes/tools/share/jsdocs/allclasses-noframe.html The JDK8 version* of that page has a link which is wrong, most likely a Todo to run the jsdoc tool * http://download.java.net/jdk8/docs/technotes/tools/windows/jrunscript.html From ecki at zusammenkunft.net Wed Feb 5 02:22:19 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 5 Feb 2014 11:22:19 +0100 Subject: jjs with support for Security Manager? In-Reply-To: <52F1E37D.9070908@oracle.com> References: <20140205030816.0000036f.ecki@zusammenkunft.net> <52F1E37D.9070908@oracle.com> Message-ID: <20140205112219.000078f9.ecki@zusammenkunft.net> Hello, Am Wed, 05 Feb 2014 12:38:45 +0530 schrieb "A. Sundararajan" : > The -D System properties are set after jjs tool is initialized. If > you want System properties to be initialized before VM is > initialized, you should use -J-D. > > jjs -J-Djava.security.manager foo.js > > This is true of all JDK bin tools. Any -J option is passed to the VM. Yes true, I haven't thought of it because jjs supports the -D syntax and the property is actually set (but obviously too late). So with "jjs -J-Djava.security.manager" I can actually start a instance where the SM is enabled. If I use it to start a *.js file it actually works (the default permissions granted apply - see below). However in interactive mode the policy does not match. Not sure if this is a required function (it would be certainly good for testing): $ export JAVA_HOME=/c/Program\ Files/Java/jdk1.8.0/ $ cat $TEMP/sec.js var System = Java.type("java.lang.System") System.out.printf("java.version=%s%n", System.getProperty("java.version")) exit(2) // expected to fail $ "$JAVA_HOME/bin/jjs" -J-Djava.security.manager $TEMP/sec.js java.version=1.8.0 Exception in thread "main" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "exitVM.2") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkExit(SecurityManager.java:761) at java.lang.Runtime.exit(Runtime.java:107) at java.lang.System.exit(System.java:968) at jdk.nashorn.internal.objects.Global.exit(Global.java:889) at jdk.nashorn.internal.scripts.Script$sec.runScript(C:/Users/eckenfel/AppData/Local/Temp/sec.js:3) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:498) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:206) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:378) at jdk.nashorn.tools.Shell.apply(Shell.java:381) at jdk.nashorn.tools.Shell.runScripts(Shell.java:310) at jdk.nashorn.tools.Shell.run(Shell.java:166) at jdk.nashorn.tools.Shell.main(Shell.java:130) at jdk.nashorn.tools.Shell.main(Shell.java:109) $ "$JAVA_HOME/bin/jjs" -J-Djava.security.manager jjs> java.lang.System.getProperty("java.version") java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.version" "read") From sundararajan.athijegannathan at oracle.com Wed Feb 5 03:06:38 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Wed, 05 Feb 2014 16:36:38 +0530 Subject: JDK8 cleanups? In-Reply-To: References: <20140205000232.00006983.ecki@zusammenkunft.net> <52F1E773.8090005@oracle.com> <52F1FAC2.7050502@oracle.com> Message-ID: <52F21B3E.4070803@oracle.com> Saw that and notified to docs team. Thanks for notifying .. -Sundar On Wednesday 05 February 2014 02:27 PM, Bernd wrote: > Am 05.02.2014 09:49 schrieb "A. Sundararajan" < > sundararajan.athijegannathan at oracle.com>: >> * "init.js" is just internal name of the initialization script used by > jrunscript. The functions, objects exposed by it are linked from here: >> http://docs.oracle.com/javase/7/docs/technotes/tools/share/jrunscript.html >> >> @ > http://docs.oracle.com/javase/7/docs/technotes/tools/share/jsdocs/allclasses-noframe.html > > The JDK8 version* of that page has a link which is wrong, most likely a > Todo to run the jsdoc tool > > * http://download.java.net/jdk8/docs/technotes/tools/windows/jrunscript.html From buddhi.mihara at live.com Wed Feb 5 03:25:10 2014 From: buddhi.mihara at live.com (buddhi mihara) Date: Wed, 5 Feb 2014 17:25:10 +0600 Subject: get default string value Message-ID: i registered a custom object call process using java(class extends from ScriptObject class).but when i do following it throws an exceptions var obj = {foo:23};Object.bindProperties(process,obj) Exception in thread "main" ECMAScript Exception: TypeError: Cannot get default string value at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:213) at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:185) at jdk.nashorn.internal.objects.Global.getDefaultValue(Global.java:571) at jdk.nashorn.internal.runtime.ScriptObject.getDefaultValue(ScriptObject.java:1257) at jdk.nashorn.internal.runtime.JSType.toPrimitive(JSType.java:264) at jdk.nashorn.internal.runtime.JSType.toStringImpl(JSType.java:901) at jdk.nashorn.internal.runtime.JSType.toString(JSType.java:323) at jdk.nashorn.tools.Shell.readEvalPrint(Shell.java:450) at jdk.nashorn.tools.Shell.run(Shell.java:162) at jdk.nashorn.tools.Shell.main(Shell.java:134) at jdk.nashorn.tools.Shell.main(Shell.java:113) solution please From sundararajan.athijegannathan at oracle.com Thu Feb 6 03:03:10 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 06 Feb 2014 16:33:10 +0530 Subject: RFR 8033763: Add tests to assert map identity of certain objects Message-ID: <52F36BEE.2080305@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8033763/ Bug: https://bugs.openjdk.java.net/browse/JDK-8033763 Thanks -Sundar From hannes.wallnoefer at oracle.com Thu Feb 6 03:58:32 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 06 Feb 2014 12:58:32 +0100 Subject: RFR 8033763: Add tests to assert map identity of certain objects In-Reply-To: <52F36BEE.2080305@oracle.com> References: <52F36BEE.2080305@oracle.com> Message-ID: <52F378E8.1060107@oracle.com> +1 Am 2014-02-06 12:03, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8033763/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8033763 > > Thanks > -Sundar From sundararajan.athijegannathan at oracle.com Thu Feb 6 07:08:40 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 06 Feb 2014 20:38:40 +0530 Subject: doc bugs Message-ID: <52F3A578.2000502@oracle.com> Filed these doc/tools bugs: https://bugs.openjdk.java.net/browse/JDK-8033766 https://bugs.openjdk.java.net/browse/JDK-8033767 Thanks for reporting. -Sundar On Wednesday 05 February 2014 02:27 PM, Bernd wrote: >/ Am 05.02.2014 09:49 schrieb "A. Sundararajan" < />/ sundararajan.athijegannathan at oracle.com >: />>/ * "init.js" is just internal name of the initialization script used by />/ jrunscript. The functions, objects exposed by it are linked from here: />>/ http://docs.oracle.com/javase/7/docs/technotes/tools/share/jrunscript.html />>/ />>/ @ />/ http://docs.oracle.com/javase/7/docs/technotes/tools/share/jsdocs/allclasses-noframe.html />/ />/ The JDK8 version* of that page has a link which is wrong, most likely a />/ Todo to run the jsdoc tool />/ />/ *http://download.java.net/jdk8/docs/technotes/tools/windows/jrunscript.html / From tom.mcginn at oracle.com Thu Feb 6 07:40:26 2014 From: tom.mcginn at oracle.com (Tom McGinn) Date: Thu, 06 Feb 2014 10:40:26 -0500 Subject: Java typeName and isType functions? Message-ID: <52F3ACEA.6050305@oracle.com> Hi Jim, et al - For completeness (I am writing this lesson on Nashorn for an Oracle course), can you give me a one sentence description of the Java.isType and Java.typeName functions? Thanks, Tom -- Tom McGinn | Java Curriculum Developer OracleServer Technologies Curriculum Development Phone: +1.781.442.0621 Mail: tom.mcginn at oracle.com Blog: Java Training Beat From sundararajan.athijegannathan at oracle.com Thu Feb 6 07:52:18 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 06 Feb 2014 21:22:18 +0530 Subject: Java typeName and isType functions? In-Reply-To: <52F3ACEA.6050305@oracle.com> References: <52F3ACEA.6050305@oracle.com> Message-ID: <52F3AFB2.30808@oracle.com> Hi, Java.isType(obj) - Returns true if the specified object 'obj' is a Java type object. i.e., it was obtained by an earlier Java.type call jjs> var Vector = Java.type("java.util.Vector"); jjs> Java.isType(Vector) true jjs> Java.isType(334) false Java.typeName(obj) - Returns fully qualified name of the type object specified (as a string) jjs> Java.typeName(Vector) java.util.Vector Thanks, -Sundar On Thursday 06 February 2014 09:10 PM, Tom McGinn wrote: > Hi Jim, et al - > > For completeness (I am writing this lesson on Nashorn for an Oracle > course), can you give me > a one sentence description of the Java.isType and Java.typeName > functions? > > Thanks, > > Tom From frank.westlake at gmail.com Thu Feb 6 07:59:50 2014 From: frank.westlake at gmail.com (Frank Westlake) Date: Thu, 06 Feb 2014 07:59:50 -0800 Subject: Java typeName and isType functions? In-Reply-To: <52F3AFB2.30808@oracle.com> References: <52F3ACEA.6050305@oracle.com> <52F3AFB2.30808@oracle.com> Message-ID: <52F3B176.8070508@gmail.com> On Thursday 06 February 2014 09:10 PM, Tom McGinn wrote: > ... can you give me a one sentence description of the Java.isType and Java.typeName > functions? On 02/06/2014 07:52 AM, A. Sundararajan wrote: > Java.isType(obj) - Returns true if the specified object 'obj' is a Java > type object. i.e., it was obtained by an earlier Java.type call > > jjs> var Vector = Java.type("java.util.Vector"); > jjs> Java.isType(Vector) > true > jjs> Java.isType(334) > false > > Java.typeName(obj) - Returns fully qualified name of the type object > specified (as a string) > > jjs> Java.typeName(Vector) > java.util.Vector Just add a period at the end there and it will be a sentence. Frank From sundararajan.athijegannathan at oracle.com Fri Feb 7 04:49:44 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 07 Feb 2014 18:19:44 +0530 Subject: Permissions for eval code [jjs with support for Security Manager?] Message-ID: <52F4D668.7060703@oracle.com> Hi, Sorry I forgot to address the following issue. Filed a bug: https://bugs.openjdk.java.net/browse/JDK-8033924 It is bug that "eval" code does not get the default permissions. Thanks for reporting. -Sundar ----------------- Hello, Am Wed, 05 Feb 2014 12:38:45 +0530 schrieb "A. Sundararajan" >: >/ The -D System properties are set after jjs tool is initialized. If />/ you want System properties to be initialized before VM is />/ initialized, you should use -J-D. />/ />/ jjs -J-Djava.security.manager foo.js />/ />/ This is true of all JDK bin tools. Any -J option is passed to the VM. / Yes true, I haven't thought of it because jjs supports the -D syntax and the property is actually set (but obviously too late). So with "jjs -J-Djava.security.manager" I can actually start a instance where the SM is enabled. If I use it to start a *.js file it actually works (the default permissions granted apply - see below). However in interactive mode the policy does not match. Not sure if this is a required function (it would be certainly good for testing): $ export JAVA_HOME=/c/Program\ Files/Java/jdk1.8.0/ $ cat $TEMP/sec.js var System = Java.type("java.lang.System") System.out.printf("java.version=%s%n", System.getProperty("java.version")) exit(2) // expected to fail $ "$JAVA_HOME/bin/jjs" -J-Djava.security.manager $TEMP/sec.js java.version=1.8.0 Exception in thread "main" java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "exitVM.2") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) at java.security.AccessController.checkPermission(AccessController.java:884) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkExit(SecurityManager.java:761) at java.lang.Runtime.exit(Runtime.java:107) at java.lang.System.exit(System.java:968) at jdk.nashorn.internal.objects.Global.exit(Global.java:889) at jdk.nashorn.internal.scripts.Script$sec.runScript(C:/Users/eckenfel/AppData/Local/Temp/sec.js:3) at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:498) at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:206) at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:378) at jdk.nashorn.tools.Shell.apply(Shell.java:381) at jdk.nashorn.tools.Shell.runScripts(Shell.java:310) at jdk.nashorn.tools.Shell.run(Shell.java:166) at jdk.nashorn.tools.Shell.main(Shell.java:130) at jdk.nashorn.tools.Shell.main(Shell.java:109) $ "$JAVA_HOME/bin/jjs" -J-Djava.security.manager jjs> java.lang.System.getProperty("java.version") java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.version" "read") From sundararajan.athijegannathan at oracle.com Fri Feb 7 05:05:15 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 07 Feb 2014 18:35:15 +0530 Subject: RFR 8033924: Default permissions are not given for eval code Message-ID: <52F4DA0B.80808@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8033924/ Thanks -Sundar From volker.simonis at gmail.com Fri Feb 7 08:36:03 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 7 Feb 2014 17:36:03 +0100 Subject: Compilation failure due to mismatching internal classes in the boot JDK Message-ID: Hi Florain, Sundar, I just had the same problem. The problem is that when calling nasgen, we need to put the newly generated nasgen (also includes the asm classes) and nashorn classes into the bootclasspath instead of just putting them into the classpath. Otherwise, the corresponding classes of the boot jdk will be used, which may be potentially wrong. The build always succeeds with a jdk7 boot jdk, because Java 7 does not has neither the nasgen nor the asm classes. It also succeeds with pretty new jdk8 boot jdk because they already contain the right version of the needed classes. But in general, using these classes from the boot jdk is simply wrong, because the boot jdk may contain an arbitrary version of these classes (it may not even be an OpenJKD/Oracle jdk). I've filed bug: "nasgen needs the newly build nasgen and nashorn classes in the bootclasspath" (https://bugs.openjdk.java.net/browse/JDK-8033951) for this and will soon post a webrev with the fix. Regards, Volker > With this version, > > changeset: 713:76f606690a45 > tag: tip > user: sundar > date: Fri Jan 17 20:09:47 2014 +0530 > summary: 8032060: PropertyMap of Error objects is not stable > > I get the following but failure: > > /usr/lib/jvm/java-1.8.0/bin/java -Xms64M -Xmx1100M -XX:ThreadStackSize=1536 \ > -cp "/home/fweimer/src/ext/java/jdk9-dev/build/linux-x86_64-normal-server-release/nashorn/nasgen_classes:/home/fweimer/src/ext/java/jdk9-dev/build/linux-x86_64-normal-server-release/nashorn/nashorn_classes" \ > jdk.nashorn.internal.tools.nasgen.Main /home/fweimer/src/ext/java/jdk9-dev/build/linux-x86_64-normal-server-release/nashorn/classes jdk.nashorn.internal.objects /home/fweimer/src/ext/java/jdk9-dev/build/linux-x86_64-normal-server-release/nashorn/classes > Exception in thread "main" java.lang.NoSuchMethodError: jdk.internal.org.objectweb.asm.MethodVisitor.visitMethodInsn(ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;Z)V > at jdk.nashorn.internal.tools.nasgen.ScriptClassInstrumentor$2.visitInsn(ScriptClassInstrumentor.java:148) > at jdk.internal.org.objectweb.asm.MethodVisitor.visitInsn(MethodVisitor.java:367) > at jdk.nashorn.internal.tools.nasgen.ScriptClassInstrumentor.emitStaticInitializer(ScriptClassInstrumentor.java:242) > at jdk.nashorn.internal.tools.nasgen.ScriptClassInstrumentor.visitEnd(ScriptClassInstrumentor.java:201) > at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:726) > at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:535) > at jdk.nashorn.internal.tools.nasgen.Main.process(Main.java:121) > at jdk.nashorn.internal.tools.nasgen.Main.processAll(Main.java:88) > at jdk.nashorn.internal.tools.nasgen.Main.main(Main.java:62) > > Would it be possible to run nasgen with the built JDK and not the bootstrap JDK? Then the such a dependency on internal JDK classes matters less. > > -- > Florian Weimer / Red Hat Product Security Team > > From volker.simonis at gmail.com Fri Feb 7 08:44:36 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 7 Feb 2014 17:44:36 +0100 Subject: RFR(XS): 8033951: nasgen needs the newly build nasgen and nashorn classes in the bootclasspath Message-ID: Hi, could you please review the following tiny change which fixes an issue in the nashorn build: https://bugs.openjdk.java.net/browse/JDK-8033951 http://cr.openjdk.java.net/~simonis/webrevs/8033951/ This fix is for jdk9 but I shink it should be down-ported into 8udev as well. Here some background information: During the nashorn build, the nasgen tool is called as follows: /bin/java \ -Xms64M -Xmx1100M \ -XX:PermSize=32m \ -XX:MaxPermSize=160m \ -XX:ThreadStackSize=1536 \ -cp "/nashorn/nasgen_classes:/nashorn/nashorn_classes"\ jdk.nashorn.internal.tools.nasgen.Main \ /nashorn/classes jdk.nashorn.internal.objects /nashorn/classes The problem is that the call puts the newly created nashorn and nasgen class (which also include the required asm class) into the class path. This will lead to problems, if the boot jdk contains different version of some of these classes. Until now, this problem was seldom, because jdk7 doens't contain any of these classes, so no conflicts could occur. But building a new version of jdk8/jdk9 with an older jdk8 boot-jdk may lead to build errors like this: /share/software/Java/jdk1.8.0_ea_b70/bin/java -Xms64M -Xmx1100M -XX:ThreadStackSize=1536 \ -Xbootclasspath/p:"/tmp/jdk9-client-opt/nashorn/nasgen_classes" -cp "/tmp/jdk9-client-opt/nashorn/nashorn_classes" \ jdk.nashorn.internal.tools.nasgen.Main /tmp/jdk9-client-opt/nashorn/classes jdk.nashorn.internal.objects /tmp/jdk9-client-opt/nashorn/classes Exception in thread "main" java.lang.NoClassDefFoundError: jdk/nashorn/internal/objects/annotations/ScriptClass at jdk.nashorn.internal.tools.nasgen.ScriptClassInfo.(ScriptClassInfo.java:52) at jdk.nashorn.internal.tools.nasgen.ScriptClassInfoCollector.visitAnnotation(ScriptClassInfoCollector.java:82) at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:670) at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:535) at jdk.nashorn.internal.tools.nasgen.ClassGenerator.getScriptClassInfo(ClassGenerator.java:370) at jdk.nashorn.internal.tools.nasgen.ClassGenerator.getScriptClassInfo(ClassGenerator.java:365) at jdk.nashorn.internal.tools.nasgen.Main.process(Main.java:104) at jdk.nashorn.internal.tools.nasgen.Main.processAll(Main.java:88) at jdk.nashorn.internal.tools.nasgen.Main.main(Main.java:62) make[1]: *** [/tmp/jdk9-client-opt/nashorn/classes/_the.nasgen.run] Error 1 make[1]: Leaving directory `/net/usr.work/d046063/OpenJDK/jdk9-client/nashorn/make' Also see the message "Compilation failure due to mismatching internal classes in the boot JDK" at http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002687.html The fix for this is easy - just put the required classes in the boot class path instead just in the class path. Regards, Volker From volker.simonis at gmail.com Fri Feb 7 10:38:47 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 7 Feb 2014 19:38:47 +0100 Subject: RFR(XS): 8033951: nasgen needs the newly build nasgen and nashorn classes in the bootclasspath In-Reply-To: <52F51349.9030908@oracle.com> References: <52F51349.9030908@oracle.com> Message-ID: Hi Erik, thanks for the review. The Windows build is still running and I won't submit until it doesn't finish successfully. Regards, Volker On Fri, Feb 7, 2014 at 6:09 PM, Erik Joelsson wrote: > Hello Volker, > > The patch looks good to me. Have you tried it on windows? I think the > quoting is correct, but would like to be sure. > > /Erik > > > On 2014-02-07 17:44, Volker Simonis wrote: >> >> Hi, >> >> could you please review the following tiny change which fixes an issue >> in the nashorn build: >> >> https://bugs.openjdk.java.net/browse/JDK-8033951 >> http://cr.openjdk.java.net/~simonis/webrevs/8033951/ >> >> This fix is for jdk9 but I shink it should be down-ported into 8udev as >> well. >> >> Here some background information: >> >> During the nashorn build, the nasgen tool is called as follows: >> >> /bin/java \ >> -Xms64M -Xmx1100M \ >> -XX:PermSize=32m \ >> -XX:MaxPermSize=160m \ >> -XX:ThreadStackSize=1536 \ >> -cp >> "/nashorn/nasgen_classes:/nashorn/nashorn_classes"\ >> jdk.nashorn.internal.tools.nasgen.Main \ >> /nashorn/classes jdk.nashorn.internal.objects >> /nashorn/classes >> >> The problem is that the call puts the newly created nashorn and nasgen >> class (which also include the required asm class) into the class path. >> This will lead to problems, if the boot jdk contains different version >> of some of these classes. >> >> Until now, this problem was seldom, because jdk7 doens't contain any >> of these classes, so no conflicts could occur. But building a new >> version of jdk8/jdk9 with an older jdk8 boot-jdk may lead to build >> errors like this: >> >> /share/software/Java/jdk1.8.0_ea_b70/bin/java -Xms64M -Xmx1100M >> -XX:ThreadStackSize=1536 \ >> >> -Xbootclasspath/p:"/tmp/jdk9-client-opt/nashorn/nasgen_classes" >> -cp "/tmp/jdk9-client-opt/nashorn/nashorn_classes" \ >> jdk.nashorn.internal.tools.nasgen.Main >> /tmp/jdk9-client-opt/nashorn/classes jdk.nashorn.internal.objects >> /tmp/jdk9-client-opt/nashorn/classes >> Exception in thread "main" java.lang.NoClassDefFoundError: >> jdk/nashorn/internal/objects/annotations/ScriptClass >> at >> jdk.nashorn.internal.tools.nasgen.ScriptClassInfo.(ScriptClassInfo.java:52) >> at >> jdk.nashorn.internal.tools.nasgen.ScriptClassInfoCollector.visitAnnotation(ScriptClassInfoCollector.java:82) >> at >> jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:670) >> at >> jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:535) >> at >> jdk.nashorn.internal.tools.nasgen.ClassGenerator.getScriptClassInfo(ClassGenerator.java:370) >> at >> jdk.nashorn.internal.tools.nasgen.ClassGenerator.getScriptClassInfo(ClassGenerator.java:365) >> at jdk.nashorn.internal.tools.nasgen.Main.process(Main.java:104) >> at >> jdk.nashorn.internal.tools.nasgen.Main.processAll(Main.java:88) >> at jdk.nashorn.internal.tools.nasgen.Main.main(Main.java:62) >> make[1]: *** [/tmp/jdk9-client-opt/nashorn/classes/_the.nasgen.run] Error >> 1 >> make[1]: Leaving directory >> `/net/usr.work/d046063/OpenJDK/jdk9-client/nashorn/make' >> >> Also see the message "Compilation failure due to mismatching internal >> classes in the boot JDK" at >> >> http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002687.html >> >> The fix for this is easy - just put the required classes in the boot >> class path instead just in the class path. >> >> Regards, >> Volker > > From ecki at zusammenkunft.net Sat Feb 8 01:37:57 2014 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 8 Feb 2014 10:37:57 +0100 Subject: Permissions for eval code [jjs with support for Security Manager?] In-Reply-To: <52F4D668.7060703@oracle.com> References: <52F4D668.7060703@oracle.com> Message-ID: <20140208103757.00000a18.ecki@zusammenkunft.net> Am Fri, 07 Feb 2014 18:19:44 +0530 schrieb "A. Sundararajan" : > Hi, > > Sorry I forgot to address the following issue. Filed a bug: > https://bugs.openjdk.java.net/browse/JDK-8033924 > > It is bug that "eval" code does not get the default permissions. > > Thanks for reporting. > > -Sundar Thanks Sundar for reporting this. I wonder if it is defined what codebase a evaluated piece of Java code should have (besides the general permission settings). Is there anything planned or existing? If I understand the patch correctly there is no specific code source which can matched by policy (and no support for signing scripts). Greetings Bernd From walter.higgins at gmail.com Sun Feb 9 14:03:36 2014 From: walter.higgins at gmail.com (Walter Higgins) Date: Sun, 9 Feb 2014 22:03:36 +0000 Subject: Is delete threaded? Message-ID: Hi , Something odd I've noticed in Nashorn (it doesn't happen in JRE 6 or 7)... I have some code which sets a global variable for a short period of time then deletes the global when it's no longer needed. (my code runs as part of an in-game plugin that takes javascript expressions from an in-game command prompt).. global.self = commandSender; try { var result = scriptingEngine.eval( jsExpression ); ... } catch (e ) { } finally { delete global.self; } If say jsExpression is ' self ' then the first time round, scriptingEngine.eval will return the 'self' object. The 2nd and subsequent times this code is executed though, self will be null, which is odd. I can work around this by using the new native 'eval()' function but the above code worked in JRE 6 and 7. Now it only works once only in JRE8. -- Walter Higgins Mobile: (+353) 086 8511600 Website: http://walterhiggins.net/ From erik.joelsson at oracle.com Fri Feb 7 09:09:29 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 07 Feb 2014 18:09:29 +0100 Subject: RFR(XS): 8033951: nasgen needs the newly build nasgen and nashorn classes in the bootclasspath In-Reply-To: References: Message-ID: <52F51349.9030908@oracle.com> Hello Volker, The patch looks good to me. Have you tried it on windows? I think the quoting is correct, but would like to be sure. /Erik On 2014-02-07 17:44, Volker Simonis wrote: > Hi, > > could you please review the following tiny change which fixes an issue > in the nashorn build: > > https://bugs.openjdk.java.net/browse/JDK-8033951 > http://cr.openjdk.java.net/~simonis/webrevs/8033951/ > > This fix is for jdk9 but I shink it should be down-ported into 8udev as well. > > Here some background information: > > During the nashorn build, the nasgen tool is called as follows: > > /bin/java \ > -Xms64M -Xmx1100M \ > -XX:PermSize=32m \ > -XX:MaxPermSize=160m \ > -XX:ThreadStackSize=1536 \ > -cp "/nashorn/nasgen_classes:/nashorn/nashorn_classes"\ > jdk.nashorn.internal.tools.nasgen.Main \ > /nashorn/classes jdk.nashorn.internal.objects > /nashorn/classes > > The problem is that the call puts the newly created nashorn and nasgen > class (which also include the required asm class) into the class path. > This will lead to problems, if the boot jdk contains different version > of some of these classes. > > Until now, this problem was seldom, because jdk7 doens't contain any > of these classes, so no conflicts could occur. But building a new > version of jdk8/jdk9 with an older jdk8 boot-jdk may lead to build > errors like this: > > /share/software/Java/jdk1.8.0_ea_b70/bin/java -Xms64M -Xmx1100M > -XX:ThreadStackSize=1536 \ > -Xbootclasspath/p:"/tmp/jdk9-client-opt/nashorn/nasgen_classes" > -cp "/tmp/jdk9-client-opt/nashorn/nashorn_classes" \ > jdk.nashorn.internal.tools.nasgen.Main > /tmp/jdk9-client-opt/nashorn/classes jdk.nashorn.internal.objects > /tmp/jdk9-client-opt/nashorn/classes > Exception in thread "main" java.lang.NoClassDefFoundError: > jdk/nashorn/internal/objects/annotations/ScriptClass > at jdk.nashorn.internal.tools.nasgen.ScriptClassInfo.(ScriptClassInfo.java:52) > at jdk.nashorn.internal.tools.nasgen.ScriptClassInfoCollector.visitAnnotation(ScriptClassInfoCollector.java:82) > at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:670) > at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:535) > at jdk.nashorn.internal.tools.nasgen.ClassGenerator.getScriptClassInfo(ClassGenerator.java:370) > at jdk.nashorn.internal.tools.nasgen.ClassGenerator.getScriptClassInfo(ClassGenerator.java:365) > at jdk.nashorn.internal.tools.nasgen.Main.process(Main.java:104) > at jdk.nashorn.internal.tools.nasgen.Main.processAll(Main.java:88) > at jdk.nashorn.internal.tools.nasgen.Main.main(Main.java:62) > make[1]: *** [/tmp/jdk9-client-opt/nashorn/classes/_the.nasgen.run] Error 1 > make[1]: Leaving directory > `/net/usr.work/d046063/OpenJDK/jdk9-client/nashorn/make' > > Also see the message "Compilation failure due to mismatching internal > classes in the boot JDK" at > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002687.html > > The fix for this is easy - just put the required classes in the boot > class path instead just in the class path. > > Regards, > Volker From hannes.wallnoefer at oracle.com Mon Feb 10 00:23:11 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Mon, 10 Feb 2014 09:23:11 +0100 Subject: Is delete threaded? In-Reply-To: References: Message-ID: <52F88C6F.9050700@oracle.com> Hi Walter, this is a problem with callsites for global configurable variables not being properly guarded. I encountered this problem independently and it will be fixed in my next commit, but I created a bug to track it and add a test case. https://bugs.openjdk.java.net/browse/JDK-8034055 Thanks, Hannes Am 2014-02-09 23:03, schrieb Walter Higgins: > Hi , > > Something odd I've noticed in Nashorn (it doesn't happen in JRE 6 or 7)... > > I have some code which sets a global variable for a short period of time > then deletes the global when it's no longer needed. (my code runs as part > of an in-game plugin that takes javascript expressions from an in-game > command prompt).. > > global.self = commandSender; > try { > var result = scriptingEngine.eval( jsExpression ); > ... > } catch (e ) { > } finally { > delete global.self; > } > > If say jsExpression is ' self ' then the first time round, > scriptingEngine.eval will return the 'self' object. The 2nd and subsequent > times this code is executed though, self will be null, which is odd. > > I can work around this by using the new native 'eval()' function but the > above code worked in JRE 6 and 7. Now it only works once only in JRE8. > From sundararajan.athijegannathan at oracle.com Mon Feb 10 00:36:50 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 10 Feb 2014 14:06:50 +0530 Subject: Permissions for eval code [jjs with support for Security Manager?] In-Reply-To: <20140208103757.00000a18.ecki@zusammenkunft.net> References: <52F4D668.7060703@oracle.com> <20140208103757.00000a18.ecki@zusammenkunft.net> Message-ID: <52F88FA2.5030201@oracle.com> No. There is no plan to use Java caller's ( the code evaluating the script) code source for scripts. The current fix is to make sure evaluated script gets permissions given to all code. (A CodeSource with null URL is used - which results in such permissions being given to scripts). There is already support for script URL based security. i.e., if you use "load" function with a URL, the script loaded from URL gets security permissions given for that URL (in your security policy). And no - no signing of scripts supported. Thanks -Sundar On Saturday 08 February 2014 03:07 PM, Bernd Eckenfels wrote: > Am Fri, 07 Feb 2014 18:19:44 +0530 > schrieb "A. Sundararajan" : > >> Hi, >> >> Sorry I forgot to address the following issue. Filed a bug: >> https://bugs.openjdk.java.net/browse/JDK-8033924 >> >> It is bug that "eval" code does not get the default permissions. >> >> Thanks for reporting. >> >> -Sundar > Thanks Sundar for reporting this. I wonder if it is defined what > codebase a evaluated piece of Java code should have (besides the > general permission settings). Is there anything planned or existing? If > I understand the patch correctly there is no specific code source which > can matched by policy (and no support for signing scripts). > > Greetings > Bernd From sundararajan.athijegannathan at oracle.com Mon Feb 10 03:27:50 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 10 Feb 2014 16:57:50 +0530 Subject: RFR(XS): 8033951: nasgen needs the newly build nasgen and nashorn classes in the bootclasspath In-Reply-To: References: Message-ID: <52F8B7B6.6070903@oracle.com> Hi, Thanks for the patch. -Sundar On Friday 07 February 2014 10:14 PM, Volker Simonis wrote: > Hi, > > could you please review the following tiny change which fixes an issue > in the nashorn build: > > https://bugs.openjdk.java.net/browse/JDK-8033951 > http://cr.openjdk.java.net/~simonis/webrevs/8033951/ > > This fix is for jdk9 but I shink it should be down-ported into 8udev as well. > > Here some background information: > > During the nashorn build, the nasgen tool is called as follows: > > /bin/java \ > -Xms64M -Xmx1100M \ > -XX:PermSize=32m \ > -XX:MaxPermSize=160m \ > -XX:ThreadStackSize=1536 \ > -cp "/nashorn/nasgen_classes:/nashorn/nashorn_classes"\ > jdk.nashorn.internal.tools.nasgen.Main \ > /nashorn/classes jdk.nashorn.internal.objects > /nashorn/classes > > The problem is that the call puts the newly created nashorn and nasgen > class (which also include the required asm class) into the class path. > This will lead to problems, if the boot jdk contains different version > of some of these classes. > > Until now, this problem was seldom, because jdk7 doens't contain any > of these classes, so no conflicts could occur. But building a new > version of jdk8/jdk9 with an older jdk8 boot-jdk may lead to build > errors like this: > > /share/software/Java/jdk1.8.0_ea_b70/bin/java -Xms64M -Xmx1100M > -XX:ThreadStackSize=1536 \ > -Xbootclasspath/p:"/tmp/jdk9-client-opt/nashorn/nasgen_classes" > -cp "/tmp/jdk9-client-opt/nashorn/nashorn_classes" \ > jdk.nashorn.internal.tools.nasgen.Main > /tmp/jdk9-client-opt/nashorn/classes jdk.nashorn.internal.objects > /tmp/jdk9-client-opt/nashorn/classes > Exception in thread "main" java.lang.NoClassDefFoundError: > jdk/nashorn/internal/objects/annotations/ScriptClass > at jdk.nashorn.internal.tools.nasgen.ScriptClassInfo.(ScriptClassInfo.java:52) > at jdk.nashorn.internal.tools.nasgen.ScriptClassInfoCollector.visitAnnotation(ScriptClassInfoCollector.java:82) > at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:670) > at jdk.internal.org.objectweb.asm.ClassReader.accept(ClassReader.java:535) > at jdk.nashorn.internal.tools.nasgen.ClassGenerator.getScriptClassInfo(ClassGenerator.java:370) > at jdk.nashorn.internal.tools.nasgen.ClassGenerator.getScriptClassInfo(ClassGenerator.java:365) > at jdk.nashorn.internal.tools.nasgen.Main.process(Main.java:104) > at jdk.nashorn.internal.tools.nasgen.Main.processAll(Main.java:88) > at jdk.nashorn.internal.tools.nasgen.Main.main(Main.java:62) > make[1]: *** [/tmp/jdk9-client-opt/nashorn/classes/_the.nasgen.run] Error 1 > make[1]: Leaving directory > `/net/usr.work/d046063/OpenJDK/jdk9-client/nashorn/make' > > Also see the message "Compilation failure due to mismatching internal > classes in the boot JDK" at > http://mail.openjdk.java.net/pipermail/nashorn-dev/2014-January/002687.html > > The fix for this is easy - just put the required classes in the boot > class path instead just in the class path. > > Regards, > Volker From james_ladd at hotmail.com Mon Feb 10 17:34:34 2014 From: james_ladd at hotmail.com (James Ladd) Date: Tue, 11 Feb 2014 12:34:34 +1100 Subject: JRuby executing JS w Nashorn ... In-Reply-To: References: Message-ID: I asked about jRuby executing javascript with Nashorn a while ago. It was simple and here is the code should anyone else need to do it. factory = javax.script.ScriptEngineManager.new engine = factory.getEngineByName 'nashorn' bindings = engine.createBindings engine.eval javascript_code, bindings Yes it is easy but sometimes its good to see and cut-n-paste. - James. From jaroslav.bachorik at oracle.com Wed Feb 12 08:24:18 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 12 Feb 2014 17:24:18 +0100 Subject: JS DSL for java bytecode "symbolic assembler" Message-ID: <52FBA032.7080902@oracle.com> Per Sundar's recommendation I am posting this small heads up. I've created a small tool called "jvmasm", currently located at GitHub (https://github.com/jbachorik/jvmasm) which allows hand crafting java bytecode using JavaScript. A sample class definition would look like this: var classDef = { name: "pkg.MyClass", methods: [ ctr = { name: "", exceptions: "java.lang.Exception", code: function(g) { with(g) { ALOAD(self("java.lang.Object")) INVOKESPECIAL("java.lang.Object", "", null, null) ALOAD(self("pkg.MyClass")) INVOKEVIRTUAL("pkg.MyClass", "finalMethod", null, "java.lang.String") RETURN() } } }, finalMethod = { name: "finalMethod", access: Opcodes.ACC_PUBLIC + Opcodes.ACC_FINAL, ret: "java.lang.String", code: function(g) { with (g) { // need start and end labels for the var scope var l1 = LABEL() var l2 = LABEL() // declare a variable // VAR(name, type, genericSignature, startLabel, endLabel) var x = VAR("x", Type.INT_TYPE, null, l1, l2) LABEL(l1) // put an integer constant of 10 on stack ICONST(10) // store the stack top value to the *x* variable ISTORE(x) // put a long constant of 24325 on stack LCONST(24325) // load the *x* variable and put it on stack ILOAD(x) // put a string constant on stack LDC("Got it") LABEL(l2) // return the stack top value (a string constant) ARETURN() } } } ] } Should you find this tool useful, please, let me know. Thanks, -JB- From sundararajan.athijegannathan at oracle.com Fri Feb 14 04:25:40 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 14 Feb 2014 17:55:40 +0530 Subject: RFR 8011964: need indexed access to externally-managed ByteBuffer Message-ID: <52FE0B44.9000705@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8011964/ Thanks -Sundar From hannes.wallnoefer at oracle.com Fri Feb 14 04:55:51 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Fri, 14 Feb 2014 13:55:51 +0100 Subject: RFR 8011964: need indexed access to externally-managed ByteBuffer In-Reply-To: <52FE0B44.9000705@oracle.com> References: <52FE0B44.9000705@oracle.com> Message-ID: <52FE1257.9010804@oracle.com> Looks good to me Hannes Am 2014-02-14 13:25, schrieb A. Sundararajan: > Please review http://cr.openjdk.java.net/~sundar/8011964/ > > Thanks > -Sundar From marcus.lagergren at oracle.com Sat Feb 15 04:47:11 2014 From: marcus.lagergren at oracle.com (Marcus Lagergren) Date: Sat, 15 Feb 2014 13:47:11 +0100 Subject: RFR 8011964: need indexed access to externally-managed ByteBuffer In-Reply-To: <52FE0B44.9000705@oracle.com> References: <52FE0B44.9000705@oracle.com> Message-ID: +1. Good performance boost from this on avatar.js. /M On 14 Feb 2014, at 13:25, A. Sundararajan wrote: > Please review http://cr.openjdk.java.net/~sundar/8011964/ > > Thanks > -Sundar From michel at undercouch.de Wed Feb 19 07:39:34 2014 From: michel at undercouch.de (=?ISO-8859-15?Q?Michel_Kr=E4mer?=) Date: Wed, 19 Feb 2014 16:39:34 +0100 Subject: Performance issues Message-ID: <5304D036.8010202@undercouch.de> Hi folks, I'm experiencing very drastic performance issues with Nashorn (JDK 8 b129) compared to Rhino. My script takes almost 13 minutes instead of 16 seconds! I hope you guys can tell me what's going on here. I've recently tested citeproc-java (https://github.com/michel-kraemer/citeproc-java) under JDK8 in order to make sure it keeps running flawlessly when the next Java version comes out. citeproc-java uses citeproc-js under the hood which is a rather large JavaScript library consisting of one file of about 540 KB, 13.500 lines of code (https://bitbucket.org/fbennett/citeproc-js/wiki/Home). Previously I used Rhino to execute the JavaScript and it worked quite well. There is a test suite consisting of 758 tests. Running this suite takes about 16 seconds (JavaScript compiled to byte code) or 46 secs (interpreted JavaScript). However, if I try to run the same test suite with Oracle Nashorn it takes 12.5 minutes! (see timings below) This is a very drastic performance drop and I was very surprised to see this. Is there some way to debug Nashorn in order to find out what is actually going on here? Timings on my computer (i5-3570K, 3.4 GHz, 4 cores, 16 GB RAM): Rhino 1.7R4 (JavaScript compiled to byte code): 16.176 secs Rhino 1.7R3 (bundled w/ JDK 7, interpreted JavaScript): 45.970 secs Nashorn (JDK 8 b129): 754.266 secs Steps to reproduce (no prerequisites other than JDK8): git clone https://github.com/michel-kraemer/citeproc-java.git cd citeproc-java ./gradlew runTestSuite -PscriptRunnerType=rhino ./gradlew runTestSuite -PscriptRunnerType=jre Cheers, Michel From sundararajan.athijegannathan at oracle.com Wed Feb 19 19:36:15 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 20 Feb 2014 09:06:15 +0530 Subject: Performance issues In-Reply-To: <5304D036.8010202@undercouch.de> References: <5304D036.8010202@undercouch.de> Message-ID: <5305782F.9020604@oracle.com> Hi, Thanks for writing to us. Two things: 1) 'rhino' mode uses Rhino's API directly (Context ..). For nashorn, it uses 'javax.script' engine API. I thought may be on jdk7, I could run 'jre' mode and try jdk7's embedded rhino based javax.script engine. After clean and re-run test with jdk7 results in FAILURE: Build failed with an exception. * Where: Build file '/home/sundar/src/citeproc-java/build.gradle' line: 230 * What went wrong: A problem occurred evaluating root project 'citeproc-java'. > org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED With jdk8, 'jre' and 'rhino' mode run fine 2) Json handling for rhino uses RhinoJsonBuilder which uses Scriptable of Rhino. For nashorn, it uses 'string json builder' - which presumably involves more string handling? If you can tell me how to run with jdk7, then perhaps we can have proper comparison. 'jre' mode on jdk7 with rhino javax.script engine and 'jre' mode on jdk8 with nashorn javax.script engine. Thanks -Sundar On Wednesday 19 February 2014 09:09 PM, Michel Kr?mer wrote: > Hi folks, > > I'm experiencing very drastic performance issues with Nashorn (JDK 8 > b129) compared to Rhino. My script takes almost 13 minutes instead of > 16 seconds! I hope you guys can tell me what's going on here. > > I've recently tested citeproc-java > (https://github.com/michel-kraemer/citeproc-java) under JDK8 in order > to make sure it keeps running flawlessly when the next Java version > comes out. citeproc-java uses citeproc-js under the hood which is a > rather large JavaScript library consisting of one file of about 540 > KB, 13.500 lines of code > (https://bitbucket.org/fbennett/citeproc-js/wiki/Home). > > Previously I used Rhino to execute the JavaScript and it worked quite > well. There is a test suite consisting of 758 tests. Running this > suite takes about 16 seconds (JavaScript compiled to byte code) or 46 > secs (interpreted JavaScript). However, if I try to run the same test > suite with Oracle Nashorn it takes 12.5 minutes! (see timings below) > > This is a very drastic performance drop and I was very surprised to > see this. Is there some way to debug Nashorn in order to find out what > is actually going on here? > > Timings on my computer (i5-3570K, 3.4 GHz, 4 cores, 16 GB RAM): > > Rhino 1.7R4 (JavaScript compiled to byte code): > 16.176 secs > > Rhino 1.7R3 (bundled w/ JDK 7, interpreted JavaScript): > 45.970 secs > > Nashorn (JDK 8 b129): > 754.266 secs > > Steps to reproduce (no prerequisites other than JDK8): > > git clone https://github.com/michel-kraemer/citeproc-java.git > cd citeproc-java > ./gradlew runTestSuite -PscriptRunnerType=rhino > ./gradlew runTestSuite -PscriptRunnerType=jre > > Cheers, > Michel From sundararajan.athijegannathan at oracle.com Wed Feb 19 23:32:08 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 20 Feb 2014 13:02:08 +0530 Subject: Performance issues In-Reply-To: <5305A0F5.4080304@undercouch.de> References: <5304D036.8010202@undercouch.de> <5305782F.9020604@oracle.com> <5305A0F5.4080304@undercouch.de> Message-ID: <5305AF78.4050909@oracle.com> Hi Michel, Nope. Doesn't seem to help. BTW, I did clean last time too - didn't do git clean. But this time I did that as well. I thought I'll do this and check diff --git a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java index d2524d2..21a5281 100644 --- a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java +++ b/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java @@ -31,6 +31,7 @@ import org.mozilla.javascript.Wrapper; import de.undercouch.citeproc.helper.CSLUtils; import de.undercouch.citeproc.helper.json.JsonBuilder; +import de.undercouch.citeproc.helper.json.StringJsonBuilder; /** * Executes JavaScript scripts using Mozilla Rhino @@ -204,7 +205,8 @@ public class RhinoScriptRunner extends AbstractScriptRunner @Override public JsonBuilder createJsonBuilder() { - return new RhinoJsonBuilder(scope, this); + return new StringJsonBuilder(this); + // return new RhinoJsonBuilder(scope, this); } Basically making sure both nashorn and rhino use the same json mechanism (rhino json builder uses Scriptable - just wanted to see how far that difference contributes). When I did clean and re-build - this time with jdk8, I got this: Using script runner: Mozilla Rhino 1.7 release 4 2012 06 18 :runTestSuite FAILED FAILURE: Build failed with an exception. * Where: Build file '/home/sundar/src/citeproc-java/build.gradle' line: 128 * What went wrong: Execution failed for task ':runTestSuite'. > java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: Could not update items * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED Total time: 3 mins 35.962 secs If there is anyway to avoid gradle dependency and run it straight - say by 'ant' or some such, it would be very useful. Thanks -Sundar On Thursday 20 February 2014 12:00 PM, Michel Kr?mer wrote: > Dear Sundar, > > Thanks for your help. I see that you familiarized yourself with the > code already. I appreciate that very much! > > You're right, when you run it in 'rhino' mode it will use code > optimized for Rhino. However, you're also right, it should use JDK7's > embedded Rhino when you run it in 'jre' mode under JDK7. > > I've never seen this error message before. citeproc-java itself does > not use any logging mechanism, but I know that Gradle does. So, the > error must have something to do with Gradle or the particular Gradle > version you're running. Is there another Gradle version already > installed on your system? Please make sure to run the gradlew script > in the project's root directory. It automatically downloads the right > Gradle version. Also make sure to run `./gradlew clean' or even `git > clean -fdx', just in case. > > I hope this helps. Please tell me if the problem persists. > > Thanks, > Michel > > > Am 20.02.2014 04:36, schrieb A. Sundararajan: >> Hi, >> >> Thanks for writing to us. >> >> Two things: >> >> 1) 'rhino' mode uses Rhino's API directly (Context ..). For nashorn, it >> uses 'javax.script' engine API. I thought may be on jdk7, I could run >> 'jre' mode and try jdk7's embedded rhino based javax.script engine. >> After clean and re-run test with jdk7 results in >> >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Build file '/home/sundar/src/citeproc-java/build.gradle' line: 230 >> >> * What went wrong: >> A problem occurred evaluating root project 'citeproc-java'. >> > >> org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V >> >> >> >> * Try: >> Run with --stacktrace option to get the stack trace. Run with --info or >> --debug option to get more log output. >> >> BUILD FAILED >> >> With jdk8, 'jre' and 'rhino' mode run fine >> >> 2) Json handling for rhino uses RhinoJsonBuilder which uses Scriptable >> of Rhino. For nashorn, it uses 'string json builder' - which presumably >> involves more string handling? >> >> If you can tell me how to run with jdk7, then perhaps we can have proper >> comparison. 'jre' mode on jdk7 with rhino javax.script engine and 'jre' >> mode on jdk8 with nashorn javax.script engine. >> >> Thanks >> -Sundar >> >> >> On Wednesday 19 February 2014 09:09 PM, Michel Kr?mer wrote: >>> Hi folks, >>> >>> I'm experiencing very drastic performance issues with Nashorn (JDK 8 >>> b129) compared to Rhino. My script takes almost 13 minutes instead of >>> 16 seconds! I hope you guys can tell me what's going on here. >>> >>> I've recently tested citeproc-java >>> (https://github.com/michel-kraemer/citeproc-java) under JDK8 in order >>> to make sure it keeps running flawlessly when the next Java version >>> comes out. citeproc-java uses citeproc-js under the hood which is a >>> rather large JavaScript library consisting of one file of about 540 >>> KB, 13.500 lines of code >>> (https://bitbucket.org/fbennett/citeproc-js/wiki/Home). >>> >>> Previously I used Rhino to execute the JavaScript and it worked quite >>> well. There is a test suite consisting of 758 tests. Running this >>> suite takes about 16 seconds (JavaScript compiled to byte code) or 46 >>> secs (interpreted JavaScript). However, if I try to run the same test >>> suite with Oracle Nashorn it takes 12.5 minutes! (see timings below) >>> >>> This is a very drastic performance drop and I was very surprised to >>> see this. Is there some way to debug Nashorn in order to find out what >>> is actually going on here? >>> >>> Timings on my computer (i5-3570K, 3.4 GHz, 4 cores, 16 GB RAM): >>> >>> Rhino 1.7R4 (JavaScript compiled to byte code): >>> 16.176 secs >>> >>> Rhino 1.7R3 (bundled w/ JDK 7, interpreted JavaScript): >>> 45.970 secs >>> >>> Nashorn (JDK 8 b129): >>> 754.266 secs >>> >>> Steps to reproduce (no prerequisites other than JDK8): >>> >>> git clone https://github.com/michel-kraemer/citeproc-java.git >>> cd citeproc-java >>> ./gradlew runTestSuite -PscriptRunnerType=rhino >>> ./gradlew runTestSuite -PscriptRunnerType=jre >>> >>> Cheers, >>> Michel >> >> From sundararajan.athijegannathan at oracle.com Thu Feb 20 00:15:29 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 20 Feb 2014 13:45:29 +0530 Subject: Performance issues In-Reply-To: <5305B861.1080002@undercouch.de> References: <5304D036.8010202@undercouch.de> <5305782F.9020604@oracle.com> <5305A0F5.4080304@undercouch.de> <5305AF78.4050909@oracle.com> <5305B861.1080002@undercouch.de> Message-ID: <5305B9A1.5050408@oracle.com> Since I can't clean/run on jdk7 - nor don't understand the code base much, I suggest you do the following (when I try to figure out ways to clean /build/run at my end). * You can use javax.script.Invocable interface's methods to invoke specific functions rather than doing 'eval' of function/method calls. * You can also call specific object methods by invokeMethod method. * To have proper comparison, we should do Json as string and eval in both cases or have Scriptable-like access + call method in nashorn. If the former is not possible, I suggest go through https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes * Because of string json and eval-for-method, there are lot more evals with nashorn/javax.script. Yes - that is the same with rhino+jdk7+javax.script. But unfortunately I couldn't run that mode at my end (yet). * It is possible to access construct object and put properties in it by ScriptObjectMirror/Bindings/JSObject interface on every script object Thanks -Sundar On Thursday 20 February 2014 01:40 PM, Michel Kr?mer wrote: > Hi! > > Replacing RhinoJsonBuilder by StringJsonBuilder will not work. The way > Rhino is run either directly or through the Script API is just too > different. > > I checked the line the first error occured in (build.gradle:230). It > seems you can just remove everything from line 210 to the end of the > file. It should still run and the error might probably be gone. > > There are other possibilities to run the test suite, but there more > complicated. Let's try this one first. > > Cheers, > Michel > > > Am 20.02.2014 08:32, schrieb A. Sundararajan: >> Hi Michel, >> >> Nope. Doesn't seem to help. BTW, I did clean last time too - didn't do >> git clean. But this time I did that as well. >> >> I thought I'll do this and check >> >> diff --git >> a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >> index d2524d2..21a5281 100644 >> --- a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >> +++ b/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >> @@ -31,6 +31,7 @@ import org.mozilla.javascript.Wrapper; >> >> import de.undercouch.citeproc.helper.CSLUtils; >> import de.undercouch.citeproc.helper.json.JsonBuilder; >> +import de.undercouch.citeproc.helper.json.StringJsonBuilder; >> >> /** >> * Executes JavaScript scripts using Mozilla Rhino >> @@ -204,7 +205,8 @@ public class RhinoScriptRunner extends >> AbstractScriptRunner >> >> @Override >> public JsonBuilder createJsonBuilder() { >> - return new RhinoJsonBuilder(scope, this); >> + return new StringJsonBuilder(this); >> + // return new RhinoJsonBuilder(scope, this); >> } >> >> >> Basically making sure both nashorn and rhino use the same json mechanism >> (rhino json builder uses Scriptable - just wanted to see how far that >> difference contributes). >> >> >> When I did clean and re-build - this time with jdk8, >> >> I got this: >> >> Using script runner: Mozilla Rhino 1.7 release 4 2012 06 18 >> :runTestSuite FAILED >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Build file '/home/sundar/src/citeproc-java/build.gradle' line: 128 >> >> * What went wrong: >> Execution failed for task ':runTestSuite'. >> > java.util.concurrent.ExecutionException: >> java.lang.IllegalArgumentException: Could not update items >> >> * Try: >> Run with --stacktrace option to get the stack trace. Run with --info or >> --debug option to get more log output. >> >> BUILD FAILED >> >> Total time: 3 mins 35.962 secs >> >> If there is anyway to avoid gradle dependency and run it straight - say >> by 'ant' or some such, it would be very useful. >> >> Thanks >> -Sundar >> >> On Thursday 20 February 2014 12:00 PM, Michel Kr?mer wrote: >>> Dear Sundar, >>> >>> Thanks for your help. I see that you familiarized yourself with the >>> code already. I appreciate that very much! >>> >>> You're right, when you run it in 'rhino' mode it will use code >>> optimized for Rhino. However, you're also right, it should use JDK7's >>> embedded Rhino when you run it in 'jre' mode under JDK7. >>> >>> I've never seen this error message before. citeproc-java itself does >>> not use any logging mechanism, but I know that Gradle does. So, the >>> error must have something to do with Gradle or the particular Gradle >>> version you're running. Is there another Gradle version already >>> installed on your system? Please make sure to run the gradlew script >>> in the project's root directory. It automatically downloads the right >>> Gradle version. Also make sure to run `./gradlew clean' or even `git >>> clean -fdx', just in case. >>> >>> I hope this helps. Please tell me if the problem persists. >>> >>> Thanks, >>> Michel >>> >>> >>> Am 20.02.2014 04:36, schrieb A. Sundararajan: >>>> Hi, >>>> >>>> Thanks for writing to us. >>>> >>>> Two things: >>>> >>>> 1) 'rhino' mode uses Rhino's API directly (Context ..). For >>>> nashorn, it >>>> uses 'javax.script' engine API. I thought may be on jdk7, I could run >>>> 'jre' mode and try jdk7's embedded rhino based javax.script engine. >>>> After clean and re-run test with jdk7 results in >>>> >>>> >>>> FAILURE: Build failed with an exception. >>>> >>>> * Where: >>>> Build file '/home/sundar/src/citeproc-java/build.gradle' line: 230 >>>> >>>> * What went wrong: >>>> A problem occurred evaluating root project 'citeproc-java'. >>>> > >>>> org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V >>>> >>>> >>>> >>>> >>>> * Try: >>>> Run with --stacktrace option to get the stack trace. Run with >>>> --info or >>>> --debug option to get more log output. >>>> >>>> BUILD FAILED >>>> >>>> With jdk8, 'jre' and 'rhino' mode run fine >>>> >>>> 2) Json handling for rhino uses RhinoJsonBuilder which uses Scriptable >>>> of Rhino. For nashorn, it uses 'string json builder' - which >>>> presumably >>>> involves more string handling? >>>> >>>> If you can tell me how to run with jdk7, then perhaps we can have >>>> proper >>>> comparison. 'jre' mode on jdk7 with rhino javax.script engine and >>>> 'jre' >>>> mode on jdk8 with nashorn javax.script engine. >>>> >>>> Thanks >>>> -Sundar >>>> >>>> >>>> On Wednesday 19 February 2014 09:09 PM, Michel Kr?mer wrote: >>>>> Hi folks, >>>>> >>>>> I'm experiencing very drastic performance issues with Nashorn (JDK 8 >>>>> b129) compared to Rhino. My script takes almost 13 minutes instead of >>>>> 16 seconds! I hope you guys can tell me what's going on here. >>>>> >>>>> I've recently tested citeproc-java >>>>> (https://github.com/michel-kraemer/citeproc-java) under JDK8 in order >>>>> to make sure it keeps running flawlessly when the next Java version >>>>> comes out. citeproc-java uses citeproc-js under the hood which is a >>>>> rather large JavaScript library consisting of one file of about 540 >>>>> KB, 13.500 lines of code >>>>> (https://bitbucket.org/fbennett/citeproc-js/wiki/Home). >>>>> >>>>> Previously I used Rhino to execute the JavaScript and it worked quite >>>>> well. There is a test suite consisting of 758 tests. Running this >>>>> suite takes about 16 seconds (JavaScript compiled to byte code) or 46 >>>>> secs (interpreted JavaScript). However, if I try to run the same test >>>>> suite with Oracle Nashorn it takes 12.5 minutes! (see timings below) >>>>> >>>>> This is a very drastic performance drop and I was very surprised to >>>>> see this. Is there some way to debug Nashorn in order to find out >>>>> what >>>>> is actually going on here? >>>>> >>>>> Timings on my computer (i5-3570K, 3.4 GHz, 4 cores, 16 GB RAM): >>>>> >>>>> Rhino 1.7R4 (JavaScript compiled to byte code): >>>>> 16.176 secs >>>>> >>>>> Rhino 1.7R3 (bundled w/ JDK 7, interpreted JavaScript): >>>>> 45.970 secs >>>>> >>>>> Nashorn (JDK 8 b129): >>>>> 754.266 secs >>>>> >>>>> Steps to reproduce (no prerequisites other than JDK8): >>>>> >>>>> git clone https://github.com/michel-kraemer/citeproc-java.git >>>>> cd citeproc-java >>>>> ./gradlew runTestSuite -PscriptRunnerType=rhino >>>>> ./gradlew runTestSuite -PscriptRunnerType=jre >>>>> >>>>> Cheers, >>>>> Michel >>>> >>>> >> >> From michel at undercouch.de Thu Feb 20 00:22:44 2014 From: michel at undercouch.de (=?ISO-8859-15?Q?Michel_Kr=E4mer?=) Date: Thu, 20 Feb 2014 09:22:44 +0100 Subject: Performance issues In-Reply-To: <5305B9A1.5050408@oracle.com> References: <5304D036.8010202@undercouch.de> <5305782F.9020604@oracle.com> <5305A0F5.4080304@undercouch.de> <5305AF78.4050909@oracle.com> <5305B861.1080002@undercouch.de> <5305B9A1.5050408@oracle.com> Message-ID: <5305BB54.20009@undercouch.de> OK. I understand that the code base is too large to debug. I thought you could just tell me some magic parameter to trace down callsite misses or whatever *LOL* but it seems to be more complicated. I'll try to compile a minimal example executing the javascript code, in order to rule out everything related to the way Nashorn is called. I'll get back to you. Thanks! Michel Am 20.02.2014 09:15, schrieb A. Sundararajan: > Since I can't clean/run on jdk7 - nor don't understand the code base > much, I suggest you do the following (when I try to figure out ways to > clean /build/run at my end). > > * You can use javax.script.Invocable interface's methods to invoke > specific functions rather than doing 'eval' of function/method calls. > > * You can also call specific object methods by invokeMethod method. > > * To have proper comparison, we should do Json as string and eval in > both cases or have Scriptable-like access + call method in nashorn. If > the former is not possible, I suggest go through > https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes > > * Because of string json and eval-for-method, there are lot more evals > with nashorn/javax.script. Yes - that is the same with > rhino+jdk7+javax.script. But unfortunately I couldn't run that mode at > my end (yet). > > * It is possible to access construct object and put properties in it by > ScriptObjectMirror/Bindings/JSObject interface on every script object > > Thanks > -Sundar > > > On Thursday 20 February 2014 01:40 PM, Michel Kr?mer wrote: >> Hi! >> >> Replacing RhinoJsonBuilder by StringJsonBuilder will not work. The way >> Rhino is run either directly or through the Script API is just too >> different. >> >> I checked the line the first error occured in (build.gradle:230). It >> seems you can just remove everything from line 210 to the end of the >> file. It should still run and the error might probably be gone. >> >> There are other possibilities to run the test suite, but there more >> complicated. Let's try this one first. >> >> Cheers, >> Michel >> >> >> Am 20.02.2014 08:32, schrieb A. Sundararajan: >>> Hi Michel, >>> >>> Nope. Doesn't seem to help. BTW, I did clean last time too - didn't do >>> git clean. But this time I did that as well. >>> >>> I thought I'll do this and check >>> >>> diff --git >>> a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>> index d2524d2..21a5281 100644 >>> --- a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>> +++ b/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>> @@ -31,6 +31,7 @@ import org.mozilla.javascript.Wrapper; >>> >>> import de.undercouch.citeproc.helper.CSLUtils; >>> import de.undercouch.citeproc.helper.json.JsonBuilder; >>> +import de.undercouch.citeproc.helper.json.StringJsonBuilder; >>> >>> /** >>> * Executes JavaScript scripts using Mozilla Rhino >>> @@ -204,7 +205,8 @@ public class RhinoScriptRunner extends >>> AbstractScriptRunner >>> >>> @Override >>> public JsonBuilder createJsonBuilder() { >>> - return new RhinoJsonBuilder(scope, this); >>> + return new StringJsonBuilder(this); >>> + // return new RhinoJsonBuilder(scope, this); >>> } >>> >>> >>> Basically making sure both nashorn and rhino use the same json mechanism >>> (rhino json builder uses Scriptable - just wanted to see how far that >>> difference contributes). >>> >>> >>> When I did clean and re-build - this time with jdk8, >>> >>> I got this: >>> >>> Using script runner: Mozilla Rhino 1.7 release 4 2012 06 18 >>> :runTestSuite FAILED >>> >>> FAILURE: Build failed with an exception. >>> >>> * Where: >>> Build file '/home/sundar/src/citeproc-java/build.gradle' line: 128 >>> >>> * What went wrong: >>> Execution failed for task ':runTestSuite'. >>> > java.util.concurrent.ExecutionException: >>> java.lang.IllegalArgumentException: Could not update items >>> >>> * Try: >>> Run with --stacktrace option to get the stack trace. Run with --info or >>> --debug option to get more log output. >>> >>> BUILD FAILED >>> >>> Total time: 3 mins 35.962 secs >>> >>> If there is anyway to avoid gradle dependency and run it straight - say >>> by 'ant' or some such, it would be very useful. >>> >>> Thanks >>> -Sundar >>> >>> On Thursday 20 February 2014 12:00 PM, Michel Kr?mer wrote: >>>> Dear Sundar, >>>> >>>> Thanks for your help. I see that you familiarized yourself with the >>>> code already. I appreciate that very much! >>>> >>>> You're right, when you run it in 'rhino' mode it will use code >>>> optimized for Rhino. However, you're also right, it should use JDK7's >>>> embedded Rhino when you run it in 'jre' mode under JDK7. >>>> >>>> I've never seen this error message before. citeproc-java itself does >>>> not use any logging mechanism, but I know that Gradle does. So, the >>>> error must have something to do with Gradle or the particular Gradle >>>> version you're running. Is there another Gradle version already >>>> installed on your system? Please make sure to run the gradlew script >>>> in the project's root directory. It automatically downloads the right >>>> Gradle version. Also make sure to run `./gradlew clean' or even `git >>>> clean -fdx', just in case. >>>> >>>> I hope this helps. Please tell me if the problem persists. >>>> >>>> Thanks, >>>> Michel >>>> >>>> >>>> Am 20.02.2014 04:36, schrieb A. Sundararajan: >>>>> Hi, >>>>> >>>>> Thanks for writing to us. >>>>> >>>>> Two things: >>>>> >>>>> 1) 'rhino' mode uses Rhino's API directly (Context ..). For >>>>> nashorn, it >>>>> uses 'javax.script' engine API. I thought may be on jdk7, I could run >>>>> 'jre' mode and try jdk7's embedded rhino based javax.script engine. >>>>> After clean and re-run test with jdk7 results in >>>>> >>>>> >>>>> FAILURE: Build failed with an exception. >>>>> >>>>> * Where: >>>>> Build file '/home/sundar/src/citeproc-java/build.gradle' line: 230 >>>>> >>>>> * What went wrong: >>>>> A problem occurred evaluating root project 'citeproc-java'. >>>>> > >>>>> org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V >>>>> >>>>> >>>>> >>>>> >>>>> * Try: >>>>> Run with --stacktrace option to get the stack trace. Run with >>>>> --info or >>>>> --debug option to get more log output. >>>>> >>>>> BUILD FAILED >>>>> >>>>> With jdk8, 'jre' and 'rhino' mode run fine >>>>> >>>>> 2) Json handling for rhino uses RhinoJsonBuilder which uses Scriptable >>>>> of Rhino. For nashorn, it uses 'string json builder' - which >>>>> presumably >>>>> involves more string handling? >>>>> >>>>> If you can tell me how to run with jdk7, then perhaps we can have >>>>> proper >>>>> comparison. 'jre' mode on jdk7 with rhino javax.script engine and >>>>> 'jre' >>>>> mode on jdk8 with nashorn javax.script engine. >>>>> >>>>> Thanks >>>>> -Sundar >>>>> >>>>> >>>>> On Wednesday 19 February 2014 09:09 PM, Michel Kr?mer wrote: >>>>>> Hi folks, >>>>>> >>>>>> I'm experiencing very drastic performance issues with Nashorn (JDK 8 >>>>>> b129) compared to Rhino. My script takes almost 13 minutes instead of >>>>>> 16 seconds! I hope you guys can tell me what's going on here. >>>>>> >>>>>> I've recently tested citeproc-java >>>>>> (https://github.com/michel-kraemer/citeproc-java) under JDK8 in order >>>>>> to make sure it keeps running flawlessly when the next Java version >>>>>> comes out. citeproc-java uses citeproc-js under the hood which is a >>>>>> rather large JavaScript library consisting of one file of about 540 >>>>>> KB, 13.500 lines of code >>>>>> (https://bitbucket.org/fbennett/citeproc-js/wiki/Home). >>>>>> >>>>>> Previously I used Rhino to execute the JavaScript and it worked quite >>>>>> well. There is a test suite consisting of 758 tests. Running this >>>>>> suite takes about 16 seconds (JavaScript compiled to byte code) or 46 >>>>>> secs (interpreted JavaScript). However, if I try to run the same test >>>>>> suite with Oracle Nashorn it takes 12.5 minutes! (see timings below) >>>>>> >>>>>> This is a very drastic performance drop and I was very surprised to >>>>>> see this. Is there some way to debug Nashorn in order to find out >>>>>> what >>>>>> is actually going on here? >>>>>> >>>>>> Timings on my computer (i5-3570K, 3.4 GHz, 4 cores, 16 GB RAM): >>>>>> >>>>>> Rhino 1.7R4 (JavaScript compiled to byte code): >>>>>> 16.176 secs >>>>>> >>>>>> Rhino 1.7R3 (bundled w/ JDK 7, interpreted JavaScript): >>>>>> 45.970 secs >>>>>> >>>>>> Nashorn (JDK 8 b129): >>>>>> 754.266 secs >>>>>> >>>>>> Steps to reproduce (no prerequisites other than JDK8): >>>>>> >>>>>> git clone https://github.com/michel-kraemer/citeproc-java.git >>>>>> cd citeproc-java >>>>>> ./gradlew runTestSuite -PscriptRunnerType=rhino >>>>>> ./gradlew runTestSuite -PscriptRunnerType=jre >>>>>> >>>>>> Cheers, >>>>>> Michel >>>>> >>>>> >>> >>> > > From sundararajan.athijegannathan at oracle.com Thu Feb 20 00:30:03 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 20 Feb 2014 14:00:03 +0530 Subject: Performance issues In-Reply-To: <5305BB54.20009@undercouch.de> References: <5304D036.8010202@undercouch.de> <5305782F.9020604@oracle.com> <5305A0F5.4080304@undercouch.de> <5305AF78.4050909@oracle.com> <5305B861.1080002@undercouch.de> <5305B9A1.5050408@oracle.com> <5305BB54.20009@undercouch.de> Message-ID: <5305BD0B.6050509@oracle.com> I was trying to do proper comparison and get to the actual difference between the two implementations being compared. Only then we could narrow down and suggest/investigate options. Btw, you can trace callsite misses by -tcs (or --trace-callsites) option of 'jjs' tool. The same option can also be specified by the System property "nashorn.args". For example: jjs -tcs myscript.js java -Dnashorn.args=-tcs -jar MyJar.jar All command line options supported can be seen from jjs -xhelp Looking forward to your minimal example. Thanks -Sundar On Thursday 20 February 2014 01:52 PM, Michel Kr?mer wrote: > OK. I understand that the code base is too large to debug. I thought > you could just tell me some magic parameter to trace down callsite > misses or whatever *LOL* but it seems to be more complicated. > > I'll try to compile a minimal example executing the javascript code, > in order to rule out everything related to the way Nashorn is called. > I'll get back to you. > > Thanks! > Michel > > > Am 20.02.2014 09:15, schrieb A. Sundararajan: >> Since I can't clean/run on jdk7 - nor don't understand the code base >> much, I suggest you do the following (when I try to figure out ways to >> clean /build/run at my end). >> >> * You can use javax.script.Invocable interface's methods to invoke >> specific functions rather than doing 'eval' of function/method calls. >> >> * You can also call specific object methods by invokeMethod method. >> >> * To have proper comparison, we should do Json as string and eval in >> both cases or have Scriptable-like access + call method in nashorn. If >> the former is not possible, I suggest go through >> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes >> >> >> * Because of string json and eval-for-method, there are lot more evals >> with nashorn/javax.script. Yes - that is the same with >> rhino+jdk7+javax.script. But unfortunately I couldn't run that mode at >> my end (yet). >> >> * It is possible to access construct object and put properties in it by >> ScriptObjectMirror/Bindings/JSObject interface on every script object >> >> Thanks >> -Sundar >> >> >> On Thursday 20 February 2014 01:40 PM, Michel Kr?mer wrote: >>> Hi! >>> >>> Replacing RhinoJsonBuilder by StringJsonBuilder will not work. The way >>> Rhino is run either directly or through the Script API is just too >>> different. >>> >>> I checked the line the first error occured in (build.gradle:230). It >>> seems you can just remove everything from line 210 to the end of the >>> file. It should still run and the error might probably be gone. >>> >>> There are other possibilities to run the test suite, but there more >>> complicated. Let's try this one first. >>> >>> Cheers, >>> Michel >>> >>> >>> Am 20.02.2014 08:32, schrieb A. Sundararajan: >>>> Hi Michel, >>>> >>>> Nope. Doesn't seem to help. BTW, I did clean last time too - didn't do >>>> git clean. But this time I did that as well. >>>> >>>> I thought I'll do this and check >>>> >>>> diff --git >>>> a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>>> index d2524d2..21a5281 100644 >>>> --- >>>> a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>>> +++ >>>> b/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>>> @@ -31,6 +31,7 @@ import org.mozilla.javascript.Wrapper; >>>> >>>> import de.undercouch.citeproc.helper.CSLUtils; >>>> import de.undercouch.citeproc.helper.json.JsonBuilder; >>>> +import de.undercouch.citeproc.helper.json.StringJsonBuilder; >>>> >>>> /** >>>> * Executes JavaScript scripts using Mozilla Rhino >>>> @@ -204,7 +205,8 @@ public class RhinoScriptRunner extends >>>> AbstractScriptRunner >>>> >>>> @Override >>>> public JsonBuilder createJsonBuilder() { >>>> - return new RhinoJsonBuilder(scope, this); >>>> + return new StringJsonBuilder(this); >>>> + // return new RhinoJsonBuilder(scope, this); >>>> } >>>> >>>> >>>> Basically making sure both nashorn and rhino use the same json >>>> mechanism >>>> (rhino json builder uses Scriptable - just wanted to see how far that >>>> difference contributes). >>>> >>>> >>>> When I did clean and re-build - this time with jdk8, >>>> >>>> I got this: >>>> >>>> Using script runner: Mozilla Rhino 1.7 release 4 2012 06 18 >>>> :runTestSuite FAILED >>>> >>>> FAILURE: Build failed with an exception. >>>> >>>> * Where: >>>> Build file '/home/sundar/src/citeproc-java/build.gradle' line: 128 >>>> >>>> * What went wrong: >>>> Execution failed for task ':runTestSuite'. >>>> > java.util.concurrent.ExecutionException: >>>> java.lang.IllegalArgumentException: Could not update items >>>> >>>> * Try: >>>> Run with --stacktrace option to get the stack trace. Run with >>>> --info or >>>> --debug option to get more log output. >>>> >>>> BUILD FAILED >>>> >>>> Total time: 3 mins 35.962 secs >>>> >>>> If there is anyway to avoid gradle dependency and run it straight - >>>> say >>>> by 'ant' or some such, it would be very useful. >>>> >>>> Thanks >>>> -Sundar >>>> >>>> On Thursday 20 February 2014 12:00 PM, Michel Kr?mer wrote: >>>>> Dear Sundar, >>>>> >>>>> Thanks for your help. I see that you familiarized yourself with the >>>>> code already. I appreciate that very much! >>>>> >>>>> You're right, when you run it in 'rhino' mode it will use code >>>>> optimized for Rhino. However, you're also right, it should use JDK7's >>>>> embedded Rhino when you run it in 'jre' mode under JDK7. >>>>> >>>>> I've never seen this error message before. citeproc-java itself does >>>>> not use any logging mechanism, but I know that Gradle does. So, the >>>>> error must have something to do with Gradle or the particular Gradle >>>>> version you're running. Is there another Gradle version already >>>>> installed on your system? Please make sure to run the gradlew script >>>>> in the project's root directory. It automatically downloads the right >>>>> Gradle version. Also make sure to run `./gradlew clean' or even `git >>>>> clean -fdx', just in case. >>>>> >>>>> I hope this helps. Please tell me if the problem persists. >>>>> >>>>> Thanks, >>>>> Michel >>>>> >>>>> >>>>> Am 20.02.2014 04:36, schrieb A. Sundararajan: >>>>>> Hi, >>>>>> >>>>>> Thanks for writing to us. >>>>>> >>>>>> Two things: >>>>>> >>>>>> 1) 'rhino' mode uses Rhino's API directly (Context ..). For >>>>>> nashorn, it >>>>>> uses 'javax.script' engine API. I thought may be on jdk7, I could >>>>>> run >>>>>> 'jre' mode and try jdk7's embedded rhino based javax.script engine. >>>>>> After clean and re-run test with jdk7 results in >>>>>> >>>>>> >>>>>> FAILURE: Build failed with an exception. >>>>>> >>>>>> * Where: >>>>>> Build file '/home/sundar/src/citeproc-java/build.gradle' line: 230 >>>>>> >>>>>> * What went wrong: >>>>>> A problem occurred evaluating root project 'citeproc-java'. >>>>>> > >>>>>> org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> * Try: >>>>>> Run with --stacktrace option to get the stack trace. Run with >>>>>> --info or >>>>>> --debug option to get more log output. >>>>>> >>>>>> BUILD FAILED >>>>>> >>>>>> With jdk8, 'jre' and 'rhino' mode run fine >>>>>> >>>>>> 2) Json handling for rhino uses RhinoJsonBuilder which uses >>>>>> Scriptable >>>>>> of Rhino. For nashorn, it uses 'string json builder' - which >>>>>> presumably >>>>>> involves more string handling? >>>>>> >>>>>> If you can tell me how to run with jdk7, then perhaps we can have >>>>>> proper >>>>>> comparison. 'jre' mode on jdk7 with rhino javax.script engine and >>>>>> 'jre' >>>>>> mode on jdk8 with nashorn javax.script engine. >>>>>> >>>>>> Thanks >>>>>> -Sundar >>>>>> >>>>>> >>>>>> On Wednesday 19 February 2014 09:09 PM, Michel Kr?mer wrote: >>>>>>> Hi folks, >>>>>>> >>>>>>> I'm experiencing very drastic performance issues with Nashorn >>>>>>> (JDK 8 >>>>>>> b129) compared to Rhino. My script takes almost 13 minutes >>>>>>> instead of >>>>>>> 16 seconds! I hope you guys can tell me what's going on here. >>>>>>> >>>>>>> I've recently tested citeproc-java >>>>>>> (https://github.com/michel-kraemer/citeproc-java) under JDK8 in >>>>>>> order >>>>>>> to make sure it keeps running flawlessly when the next Java version >>>>>>> comes out. citeproc-java uses citeproc-js under the hood which is a >>>>>>> rather large JavaScript library consisting of one file of about 540 >>>>>>> KB, 13.500 lines of code >>>>>>> (https://bitbucket.org/fbennett/citeproc-js/wiki/Home). >>>>>>> >>>>>>> Previously I used Rhino to execute the JavaScript and it worked >>>>>>> quite >>>>>>> well. There is a test suite consisting of 758 tests. Running this >>>>>>> suite takes about 16 seconds (JavaScript compiled to byte code) >>>>>>> or 46 >>>>>>> secs (interpreted JavaScript). However, if I try to run the same >>>>>>> test >>>>>>> suite with Oracle Nashorn it takes 12.5 minutes! (see timings >>>>>>> below) >>>>>>> >>>>>>> This is a very drastic performance drop and I was very surprised to >>>>>>> see this. Is there some way to debug Nashorn in order to find out >>>>>>> what >>>>>>> is actually going on here? >>>>>>> >>>>>>> Timings on my computer (i5-3570K, 3.4 GHz, 4 cores, 16 GB RAM): >>>>>>> >>>>>>> Rhino 1.7R4 (JavaScript compiled to byte code): >>>>>>> 16.176 secs >>>>>>> >>>>>>> Rhino 1.7R3 (bundled w/ JDK 7, interpreted JavaScript): >>>>>>> 45.970 secs >>>>>>> >>>>>>> Nashorn (JDK 8 b129): >>>>>>> 754.266 secs >>>>>>> >>>>>>> Steps to reproduce (no prerequisites other than JDK8): >>>>>>> >>>>>>> git clone https://github.com/michel-kraemer/citeproc-java.git >>>>>>> cd citeproc-java >>>>>>> ./gradlew runTestSuite -PscriptRunnerType=rhino >>>>>>> ./gradlew runTestSuite -PscriptRunnerType=jre >>>>>>> >>>>>>> Cheers, >>>>>>> Michel >>>>>> >>>>>> >>>> >>>> >> >> From michel at undercouch.de Thu Feb 20 04:13:25 2014 From: michel at undercouch.de (=?ISO-8859-15?Q?Michel_Kr=E4mer?=) Date: Thu, 20 Feb 2014 13:13:25 +0100 Subject: Performance issues In-Reply-To: <5305BD0B.6050509@oracle.com> References: <5304D036.8010202@undercouch.de> <5305782F.9020604@oracle.com> <5305A0F5.4080304@undercouch.de> <5305AF78.4050909@oracle.com> <5305B861.1080002@undercouch.de> <5305B9A1.5050408@oracle.com> <5305BB54.20009@undercouch.de> <5305BD0B.6050509@oracle.com> Message-ID: <5305F165.7080907@undercouch.de> Dear Sundar, Here's the minimal example: http://storage.spamihilator.com/public.php?service=files&t=23b6d2e601bca81d461c26c050c0669c&download Just unzip the file and run the following command: java -Xmx1024M -cp . MinimalExample It runs the complete test suite. Some tests fail, but that's OK. Here are my timings: Rhino (JDK7): Total time: 394.80 secs Time construct: 0.38 secs Time parse: 25.07 secs Time run: 368.71 secs 747 of 758 tests successful. Nashorn: Total time: 1168.16 secs Time construct: 3.25 secs Time parse: 309.84 secs Time run: 853.91 secs 747 of 758 tests successful. The tests are slower than before because there's only one thread. In citeproc-java multiple threads are used instead. However, the performance difference is still quite noticeable. Nashorn is almost 3 times slower. It takes a lot more time to parse the JavaScript and also execution time is longer. Hope this helps! Michel Am 20.02.2014 09:30, schrieb A. Sundararajan: > I was trying to do proper comparison and get to the actual difference > between the two implementations being compared. Only then we could > narrow down and suggest/investigate options. > > Btw, you can trace callsite misses by -tcs (or --trace-callsites) option > of 'jjs' tool. The same option can also be specified by the System > property "nashorn.args". For example: > > jjs -tcs myscript.js > java -Dnashorn.args=-tcs -jar MyJar.jar > > All command line options supported can be seen from > > jjs -xhelp > > Looking forward to your minimal example. > > Thanks > -Sundar > > > On Thursday 20 February 2014 01:52 PM, Michel Kr?mer wrote: >> OK. I understand that the code base is too large to debug. I thought >> you could just tell me some magic parameter to trace down callsite >> misses or whatever *LOL* but it seems to be more complicated. >> >> I'll try to compile a minimal example executing the javascript code, >> in order to rule out everything related to the way Nashorn is called. >> I'll get back to you. >> >> Thanks! >> Michel >> >> >> Am 20.02.2014 09:15, schrieb A. Sundararajan: >>> Since I can't clean/run on jdk7 - nor don't understand the code base >>> much, I suggest you do the following (when I try to figure out ways to >>> clean /build/run at my end). >>> >>> * You can use javax.script.Invocable interface's methods to invoke >>> specific functions rather than doing 'eval' of function/method calls. >>> >>> * You can also call specific object methods by invokeMethod method. >>> >>> * To have proper comparison, we should do Json as string and eval in >>> both cases or have Scriptable-like access + call method in nashorn. If >>> the former is not possible, I suggest go through >>> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes >>> >>> >>> * Because of string json and eval-for-method, there are lot more evals >>> with nashorn/javax.script. Yes - that is the same with >>> rhino+jdk7+javax.script. But unfortunately I couldn't run that mode at >>> my end (yet). >>> >>> * It is possible to access construct object and put properties in it by >>> ScriptObjectMirror/Bindings/JSObject interface on every script object >>> >>> Thanks >>> -Sundar >>> >>> >>> On Thursday 20 February 2014 01:40 PM, Michel Kr?mer wrote: >>>> Hi! >>>> >>>> Replacing RhinoJsonBuilder by StringJsonBuilder will not work. The way >>>> Rhino is run either directly or through the Script API is just too >>>> different. >>>> >>>> I checked the line the first error occured in (build.gradle:230). It >>>> seems you can just remove everything from line 210 to the end of the >>>> file. It should still run and the error might probably be gone. >>>> >>>> There are other possibilities to run the test suite, but there more >>>> complicated. Let's try this one first. >>>> >>>> Cheers, >>>> Michel >>>> >>>> >>>> Am 20.02.2014 08:32, schrieb A. Sundararajan: >>>>> Hi Michel, >>>>> >>>>> Nope. Doesn't seem to help. BTW, I did clean last time too - didn't do >>>>> git clean. But this time I did that as well. >>>>> >>>>> I thought I'll do this and check >>>>> >>>>> diff --git >>>>> a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>>>> index d2524d2..21a5281 100644 >>>>> --- >>>>> a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>>>> +++ >>>>> b/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>>>> @@ -31,6 +31,7 @@ import org.mozilla.javascript.Wrapper; >>>>> >>>>> import de.undercouch.citeproc.helper.CSLUtils; >>>>> import de.undercouch.citeproc.helper.json.JsonBuilder; >>>>> +import de.undercouch.citeproc.helper.json.StringJsonBuilder; >>>>> >>>>> /** >>>>> * Executes JavaScript scripts using Mozilla Rhino >>>>> @@ -204,7 +205,8 @@ public class RhinoScriptRunner extends >>>>> AbstractScriptRunner >>>>> >>>>> @Override >>>>> public JsonBuilder createJsonBuilder() { >>>>> - return new RhinoJsonBuilder(scope, this); >>>>> + return new StringJsonBuilder(this); >>>>> + // return new RhinoJsonBuilder(scope, this); >>>>> } >>>>> >>>>> >>>>> Basically making sure both nashorn and rhino use the same json >>>>> mechanism >>>>> (rhino json builder uses Scriptable - just wanted to see how far that >>>>> difference contributes). >>>>> >>>>> >>>>> When I did clean and re-build - this time with jdk8, >>>>> >>>>> I got this: >>>>> >>>>> Using script runner: Mozilla Rhino 1.7 release 4 2012 06 18 >>>>> :runTestSuite FAILED >>>>> >>>>> FAILURE: Build failed with an exception. >>>>> >>>>> * Where: >>>>> Build file '/home/sundar/src/citeproc-java/build.gradle' line: 128 >>>>> >>>>> * What went wrong: >>>>> Execution failed for task ':runTestSuite'. >>>>> > java.util.concurrent.ExecutionException: >>>>> java.lang.IllegalArgumentException: Could not update items >>>>> >>>>> * Try: >>>>> Run with --stacktrace option to get the stack trace. Run with >>>>> --info or >>>>> --debug option to get more log output. >>>>> >>>>> BUILD FAILED >>>>> >>>>> Total time: 3 mins 35.962 secs >>>>> >>>>> If there is anyway to avoid gradle dependency and run it straight - >>>>> say >>>>> by 'ant' or some such, it would be very useful. >>>>> >>>>> Thanks >>>>> -Sundar >>>>> >>>>> On Thursday 20 February 2014 12:00 PM, Michel Kr?mer wrote: >>>>>> Dear Sundar, >>>>>> >>>>>> Thanks for your help. I see that you familiarized yourself with the >>>>>> code already. I appreciate that very much! >>>>>> >>>>>> You're right, when you run it in 'rhino' mode it will use code >>>>>> optimized for Rhino. However, you're also right, it should use JDK7's >>>>>> embedded Rhino when you run it in 'jre' mode under JDK7. >>>>>> >>>>>> I've never seen this error message before. citeproc-java itself does >>>>>> not use any logging mechanism, but I know that Gradle does. So, the >>>>>> error must have something to do with Gradle or the particular Gradle >>>>>> version you're running. Is there another Gradle version already >>>>>> installed on your system? Please make sure to run the gradlew script >>>>>> in the project's root directory. It automatically downloads the right >>>>>> Gradle version. Also make sure to run `./gradlew clean' or even `git >>>>>> clean -fdx', just in case. >>>>>> >>>>>> I hope this helps. Please tell me if the problem persists. >>>>>> >>>>>> Thanks, >>>>>> Michel >>>>>> >>>>>> >>>>>> Am 20.02.2014 04:36, schrieb A. Sundararajan: >>>>>>> Hi, >>>>>>> >>>>>>> Thanks for writing to us. >>>>>>> >>>>>>> Two things: >>>>>>> >>>>>>> 1) 'rhino' mode uses Rhino's API directly (Context ..). For >>>>>>> nashorn, it >>>>>>> uses 'javax.script' engine API. I thought may be on jdk7, I could >>>>>>> run >>>>>>> 'jre' mode and try jdk7's embedded rhino based javax.script engine. >>>>>>> After clean and re-run test with jdk7 results in >>>>>>> >>>>>>> >>>>>>> FAILURE: Build failed with an exception. >>>>>>> >>>>>>> * Where: >>>>>>> Build file '/home/sundar/src/citeproc-java/build.gradle' line: 230 >>>>>>> >>>>>>> * What went wrong: >>>>>>> A problem occurred evaluating root project 'citeproc-java'. >>>>>>> > >>>>>>> org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * Try: >>>>>>> Run with --stacktrace option to get the stack trace. Run with >>>>>>> --info or >>>>>>> --debug option to get more log output. >>>>>>> >>>>>>> BUILD FAILED >>>>>>> >>>>>>> With jdk8, 'jre' and 'rhino' mode run fine >>>>>>> >>>>>>> 2) Json handling for rhino uses RhinoJsonBuilder which uses >>>>>>> Scriptable >>>>>>> of Rhino. For nashorn, it uses 'string json builder' - which >>>>>>> presumably >>>>>>> involves more string handling? >>>>>>> >>>>>>> If you can tell me how to run with jdk7, then perhaps we can have >>>>>>> proper >>>>>>> comparison. 'jre' mode on jdk7 with rhino javax.script engine and >>>>>>> 'jre' >>>>>>> mode on jdk8 with nashorn javax.script engine. >>>>>>> >>>>>>> Thanks >>>>>>> -Sundar >>>>>>> >>>>>>> >>>>>>> On Wednesday 19 February 2014 09:09 PM, Michel Kr?mer wrote: >>>>>>>> Hi folks, >>>>>>>> >>>>>>>> I'm experiencing very drastic performance issues with Nashorn >>>>>>>> (JDK 8 >>>>>>>> b129) compared to Rhino. My script takes almost 13 minutes >>>>>>>> instead of >>>>>>>> 16 seconds! I hope you guys can tell me what's going on here. >>>>>>>> >>>>>>>> I've recently tested citeproc-java >>>>>>>> (https://github.com/michel-kraemer/citeproc-java) under JDK8 in >>>>>>>> order >>>>>>>> to make sure it keeps running flawlessly when the next Java version >>>>>>>> comes out. citeproc-java uses citeproc-js under the hood which is a >>>>>>>> rather large JavaScript library consisting of one file of about 540 >>>>>>>> KB, 13.500 lines of code >>>>>>>> (https://bitbucket.org/fbennett/citeproc-js/wiki/Home). >>>>>>>> >>>>>>>> Previously I used Rhino to execute the JavaScript and it worked >>>>>>>> quite >>>>>>>> well. There is a test suite consisting of 758 tests. Running this >>>>>>>> suite takes about 16 seconds (JavaScript compiled to byte code) >>>>>>>> or 46 >>>>>>>> secs (interpreted JavaScript). However, if I try to run the same >>>>>>>> test >>>>>>>> suite with Oracle Nashorn it takes 12.5 minutes! (see timings >>>>>>>> below) >>>>>>>> >>>>>>>> This is a very drastic performance drop and I was very surprised to >>>>>>>> see this. Is there some way to debug Nashorn in order to find out >>>>>>>> what >>>>>>>> is actually going on here? >>>>>>>> >>>>>>>> Timings on my computer (i5-3570K, 3.4 GHz, 4 cores, 16 GB RAM): >>>>>>>> >>>>>>>> Rhino 1.7R4 (JavaScript compiled to byte code): >>>>>>>> 16.176 secs >>>>>>>> >>>>>>>> Rhino 1.7R3 (bundled w/ JDK 7, interpreted JavaScript): >>>>>>>> 45.970 secs >>>>>>>> >>>>>>>> Nashorn (JDK 8 b129): >>>>>>>> 754.266 secs >>>>>>>> >>>>>>>> Steps to reproduce (no prerequisites other than JDK8): >>>>>>>> >>>>>>>> git clone https://github.com/michel-kraemer/citeproc-java.git >>>>>>>> cd citeproc-java >>>>>>>> ./gradlew runTestSuite -PscriptRunnerType=rhino >>>>>>>> ./gradlew runTestSuite -PscriptRunnerType=jre >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Michel >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > > From buddhi.mihara at live.com Thu Feb 20 04:32:48 2014 From: buddhi.mihara at live.com (buddhi mihara) Date: Thu, 20 Feb 2014 18:32:48 +0600 Subject: run script file @ nashorn startup Message-ID: hi, i have a script file call foo.js. this file use to bind properties to global scope using Object.bindProperties(this,propertyObj); i need to execute this file automatically @ nashorn startuphow can i do that? From sundararajan.athijegannathan at oracle.com Thu Feb 20 04:53:13 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 20 Feb 2014 18:23:13 +0530 Subject: run script file @ nashorn startup In-Reply-To: References: Message-ID: <5305FAB9.2000808@oracle.com> You can execute it in your main java class of your app. You main class would look something like: 1) create ScriptEngineManager 2) create Nashorn script engine 3) eval an init script - say myinit.js - which will contain Object.bindProperties and other init calls 4) eval user script specified in your command line -Sundar On Thursday 20 February 2014 06:02 PM, buddhi mihara wrote: > hi, > i have a script file call foo.js. this file use to bind properties to global scope using Object.bindProperties(this,propertyObj); i need to execute this file automatically @ nashorn startuphow can i do that? From sundararajan.athijegannathan at oracle.com Thu Feb 20 05:00:24 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 20 Feb 2014 18:30:24 +0530 Subject: Performance issues In-Reply-To: <5305F165.7080907@undercouch.de> References: <5304D036.8010202@undercouch.de> <5305782F.9020604@oracle.com> <5305A0F5.4080304@undercouch.de> <5305AF78.4050909@oracle.com> <5305B861.1080002@undercouch.de> <5305B9A1.5050408@oracle.com> <5305BB54.20009@undercouch.de> <5305BD0B.6050509@oracle.com> <5305F165.7080907@undercouch.de> Message-ID: <5305FC68.7090909@oracle.com> Thanks Michel. Thanks -Sundar On Thursday 20 February 2014 05:43 PM, Michel Kr?mer wrote: > Dear Sundar, > > Here's the minimal example: > http://storage.spamihilator.com/public.php?service=files&t=23b6d2e601bca81d461c26c050c0669c&download > > > Just unzip the file and run the following command: > > java -Xmx1024M -cp . MinimalExample > > It runs the complete test suite. Some tests fail, but that's OK. Here > are my timings: > > Rhino (JDK7): > > Total time: 394.80 secs > Time construct: 0.38 secs > Time parse: 25.07 secs > Time run: 368.71 secs > 747 of 758 tests successful. > > Nashorn: > > Total time: 1168.16 secs > Time construct: 3.25 secs > Time parse: 309.84 secs > Time run: 853.91 secs > 747 of 758 tests successful. > > The tests are slower than before because there's only one thread. In > citeproc-java multiple threads are used instead. However, the > performance difference is still quite noticeable. Nashorn is almost 3 > times slower. It takes a lot more time to parse the JavaScript and > also execution time is longer. > > Hope this helps! > > Michel > > > Am 20.02.2014 09:30, schrieb A. Sundararajan: >> I was trying to do proper comparison and get to the actual difference >> between the two implementations being compared. Only then we could >> narrow down and suggest/investigate options. >> >> Btw, you can trace callsite misses by -tcs (or --trace-callsites) option >> of 'jjs' tool. The same option can also be specified by the System >> property "nashorn.args". For example: >> >> jjs -tcs myscript.js >> java -Dnashorn.args=-tcs -jar MyJar.jar >> >> All command line options supported can be seen from >> >> jjs -xhelp >> >> Looking forward to your minimal example. >> >> Thanks >> -Sundar >> >> >> On Thursday 20 February 2014 01:52 PM, Michel Kr?mer wrote: >>> OK. I understand that the code base is too large to debug. I thought >>> you could just tell me some magic parameter to trace down callsite >>> misses or whatever *LOL* but it seems to be more complicated. >>> >>> I'll try to compile a minimal example executing the javascript code, >>> in order to rule out everything related to the way Nashorn is called. >>> I'll get back to you. >>> >>> Thanks! >>> Michel >>> >>> >>> Am 20.02.2014 09:15, schrieb A. Sundararajan: >>>> Since I can't clean/run on jdk7 - nor don't understand the code base >>>> much, I suggest you do the following (when I try to figure out ways to >>>> clean /build/run at my end). >>>> >>>> * You can use javax.script.Invocable interface's methods to invoke >>>> specific functions rather than doing 'eval' of function/method calls. >>>> >>>> * You can also call specific object methods by invokeMethod method. >>>> >>>> * To have proper comparison, we should do Json as string and eval in >>>> both cases or have Scriptable-like access + call method in nashorn. If >>>> the former is not possible, I suggest go through >>>> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes >>>> >>>> >>>> >>>> * Because of string json and eval-for-method, there are lot more evals >>>> with nashorn/javax.script. Yes - that is the same with >>>> rhino+jdk7+javax.script. But unfortunately I couldn't run that mode at >>>> my end (yet). >>>> >>>> * It is possible to access construct object and put properties in >>>> it by >>>> ScriptObjectMirror/Bindings/JSObject interface on every script object >>>> >>>> Thanks >>>> -Sundar >>>> >>>> >>>> On Thursday 20 February 2014 01:40 PM, Michel Kr?mer wrote: >>>>> Hi! >>>>> >>>>> Replacing RhinoJsonBuilder by StringJsonBuilder will not work. The >>>>> way >>>>> Rhino is run either directly or through the Script API is just too >>>>> different. >>>>> >>>>> I checked the line the first error occured in (build.gradle:230). It >>>>> seems you can just remove everything from line 210 to the end of the >>>>> file. It should still run and the error might probably be gone. >>>>> >>>>> There are other possibilities to run the test suite, but there more >>>>> complicated. Let's try this one first. >>>>> >>>>> Cheers, >>>>> Michel >>>>> >>>>> >>>>> Am 20.02.2014 08:32, schrieb A. Sundararajan: >>>>>> Hi Michel, >>>>>> >>>>>> Nope. Doesn't seem to help. BTW, I did clean last time too - >>>>>> didn't do >>>>>> git clean. But this time I did that as well. >>>>>> >>>>>> I thought I'll do this and check >>>>>> >>>>>> diff --git >>>>>> a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>>>>> index d2524d2..21a5281 100644 >>>>>> --- >>>>>> a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>>>>> +++ >>>>>> b/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>>>>> @@ -31,6 +31,7 @@ import org.mozilla.javascript.Wrapper; >>>>>> >>>>>> import de.undercouch.citeproc.helper.CSLUtils; >>>>>> import de.undercouch.citeproc.helper.json.JsonBuilder; >>>>>> +import de.undercouch.citeproc.helper.json.StringJsonBuilder; >>>>>> >>>>>> /** >>>>>> * Executes JavaScript scripts using Mozilla Rhino >>>>>> @@ -204,7 +205,8 @@ public class RhinoScriptRunner extends >>>>>> AbstractScriptRunner >>>>>> >>>>>> @Override >>>>>> public JsonBuilder createJsonBuilder() { >>>>>> - return new RhinoJsonBuilder(scope, this); >>>>>> + return new StringJsonBuilder(this); >>>>>> + // return new RhinoJsonBuilder(scope, this); >>>>>> } >>>>>> >>>>>> >>>>>> Basically making sure both nashorn and rhino use the same json >>>>>> mechanism >>>>>> (rhino json builder uses Scriptable - just wanted to see how far >>>>>> that >>>>>> difference contributes). >>>>>> >>>>>> >>>>>> When I did clean and re-build - this time with jdk8, >>>>>> >>>>>> I got this: >>>>>> >>>>>> Using script runner: Mozilla Rhino 1.7 release 4 2012 06 18 >>>>>> :runTestSuite FAILED >>>>>> >>>>>> FAILURE: Build failed with an exception. >>>>>> >>>>>> * Where: >>>>>> Build file '/home/sundar/src/citeproc-java/build.gradle' line: 128 >>>>>> >>>>>> * What went wrong: >>>>>> Execution failed for task ':runTestSuite'. >>>>>> > java.util.concurrent.ExecutionException: >>>>>> java.lang.IllegalArgumentException: Could not update items >>>>>> >>>>>> * Try: >>>>>> Run with --stacktrace option to get the stack trace. Run with >>>>>> --info or >>>>>> --debug option to get more log output. >>>>>> >>>>>> BUILD FAILED >>>>>> >>>>>> Total time: 3 mins 35.962 secs >>>>>> >>>>>> If there is anyway to avoid gradle dependency and run it straight - >>>>>> say >>>>>> by 'ant' or some such, it would be very useful. >>>>>> >>>>>> Thanks >>>>>> -Sundar >>>>>> >>>>>> On Thursday 20 February 2014 12:00 PM, Michel Kr?mer wrote: >>>>>>> Dear Sundar, >>>>>>> >>>>>>> Thanks for your help. I see that you familiarized yourself with the >>>>>>> code already. I appreciate that very much! >>>>>>> >>>>>>> You're right, when you run it in 'rhino' mode it will use code >>>>>>> optimized for Rhino. However, you're also right, it should use >>>>>>> JDK7's >>>>>>> embedded Rhino when you run it in 'jre' mode under JDK7. >>>>>>> >>>>>>> I've never seen this error message before. citeproc-java itself >>>>>>> does >>>>>>> not use any logging mechanism, but I know that Gradle does. So, the >>>>>>> error must have something to do with Gradle or the particular >>>>>>> Gradle >>>>>>> version you're running. Is there another Gradle version already >>>>>>> installed on your system? Please make sure to run the gradlew >>>>>>> script >>>>>>> in the project's root directory. It automatically downloads the >>>>>>> right >>>>>>> Gradle version. Also make sure to run `./gradlew clean' or even >>>>>>> `git >>>>>>> clean -fdx', just in case. >>>>>>> >>>>>>> I hope this helps. Please tell me if the problem persists. >>>>>>> >>>>>>> Thanks, >>>>>>> Michel >>>>>>> >>>>>>> >>>>>>> Am 20.02.2014 04:36, schrieb A. Sundararajan: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Thanks for writing to us. >>>>>>>> >>>>>>>> Two things: >>>>>>>> >>>>>>>> 1) 'rhino' mode uses Rhino's API directly (Context ..). For >>>>>>>> nashorn, it >>>>>>>> uses 'javax.script' engine API. I thought may be on jdk7, I could >>>>>>>> run >>>>>>>> 'jre' mode and try jdk7's embedded rhino based javax.script >>>>>>>> engine. >>>>>>>> After clean and re-run test with jdk7 results in >>>>>>>> >>>>>>>> >>>>>>>> FAILURE: Build failed with an exception. >>>>>>>> >>>>>>>> * Where: >>>>>>>> Build file '/home/sundar/src/citeproc-java/build.gradle' line: 230 >>>>>>>> >>>>>>>> * What went wrong: >>>>>>>> A problem occurred evaluating root project 'citeproc-java'. >>>>>>>> > >>>>>>>> org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> * Try: >>>>>>>> Run with --stacktrace option to get the stack trace. Run with >>>>>>>> --info or >>>>>>>> --debug option to get more log output. >>>>>>>> >>>>>>>> BUILD FAILED >>>>>>>> >>>>>>>> With jdk8, 'jre' and 'rhino' mode run fine >>>>>>>> >>>>>>>> 2) Json handling for rhino uses RhinoJsonBuilder which uses >>>>>>>> Scriptable >>>>>>>> of Rhino. For nashorn, it uses 'string json builder' - which >>>>>>>> presumably >>>>>>>> involves more string handling? >>>>>>>> >>>>>>>> If you can tell me how to run with jdk7, then perhaps we can have >>>>>>>> proper >>>>>>>> comparison. 'jre' mode on jdk7 with rhino javax.script engine and >>>>>>>> 'jre' >>>>>>>> mode on jdk8 with nashorn javax.script engine. >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Sundar >>>>>>>> >>>>>>>> >>>>>>>> On Wednesday 19 February 2014 09:09 PM, Michel Kr?mer wrote: >>>>>>>>> Hi folks, >>>>>>>>> >>>>>>>>> I'm experiencing very drastic performance issues with Nashorn >>>>>>>>> (JDK 8 >>>>>>>>> b129) compared to Rhino. My script takes almost 13 minutes >>>>>>>>> instead of >>>>>>>>> 16 seconds! I hope you guys can tell me what's going on here. >>>>>>>>> >>>>>>>>> I've recently tested citeproc-java >>>>>>>>> (https://github.com/michel-kraemer/citeproc-java) under JDK8 in >>>>>>>>> order >>>>>>>>> to make sure it keeps running flawlessly when the next Java >>>>>>>>> version >>>>>>>>> comes out. citeproc-java uses citeproc-js under the hood which >>>>>>>>> is a >>>>>>>>> rather large JavaScript library consisting of one file of >>>>>>>>> about 540 >>>>>>>>> KB, 13.500 lines of code >>>>>>>>> (https://bitbucket.org/fbennett/citeproc-js/wiki/Home). >>>>>>>>> >>>>>>>>> Previously I used Rhino to execute the JavaScript and it worked >>>>>>>>> quite >>>>>>>>> well. There is a test suite consisting of 758 tests. Running this >>>>>>>>> suite takes about 16 seconds (JavaScript compiled to byte code) >>>>>>>>> or 46 >>>>>>>>> secs (interpreted JavaScript). However, if I try to run the same >>>>>>>>> test >>>>>>>>> suite with Oracle Nashorn it takes 12.5 minutes! (see timings >>>>>>>>> below) >>>>>>>>> >>>>>>>>> This is a very drastic performance drop and I was very >>>>>>>>> surprised to >>>>>>>>> see this. Is there some way to debug Nashorn in order to find out >>>>>>>>> what >>>>>>>>> is actually going on here? >>>>>>>>> >>>>>>>>> Timings on my computer (i5-3570K, 3.4 GHz, 4 cores, 16 GB RAM): >>>>>>>>> >>>>>>>>> Rhino 1.7R4 (JavaScript compiled to byte code): >>>>>>>>> 16.176 secs >>>>>>>>> >>>>>>>>> Rhino 1.7R3 (bundled w/ JDK 7, interpreted JavaScript): >>>>>>>>> 45.970 secs >>>>>>>>> >>>>>>>>> Nashorn (JDK 8 b129): >>>>>>>>> 754.266 secs >>>>>>>>> >>>>>>>>> Steps to reproduce (no prerequisites other than JDK8): >>>>>>>>> >>>>>>>>> git clone https://github.com/michel-kraemer/citeproc-java.git >>>>>>>>> cd citeproc-java >>>>>>>>> ./gradlew runTestSuite -PscriptRunnerType=rhino >>>>>>>>> ./gradlew runTestSuite -PscriptRunnerType=jre >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Michel >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> From sundararajan.athijegannathan at oracle.com Thu Feb 20 05:38:16 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Thu, 20 Feb 2014 19:08:16 +0530 Subject: Performance issues In-Reply-To: <5305FC68.7090909@oracle.com> References: <5304D036.8010202@undercouch.de> <5305782F.9020604@oracle.com> <5305A0F5.4080304@undercouch.de> <5305AF78.4050909@oracle.com> <5305B861.1080002@undercouch.de> <5305B9A1.5050408@oracle.com> <5305BB54.20009@undercouch.de> <5305BD0B.6050509@oracle.com> <5305F165.7080907@undercouch.de> <5305FC68.7090909@oracle.com> Message-ID: <53060548.2040100@oracle.com> We are investigating. Thanks for reporting the issue. -Sundar On Thursday 20 February 2014 06:30 PM, A. Sundararajan wrote: > Thanks Michel. > > Thanks > -Sundar > > On Thursday 20 February 2014 05:43 PM, Michel Kr?mer wrote: >> Dear Sundar, >> >> Here's the minimal example: >> http://storage.spamihilator.com/public.php?service=files&t=23b6d2e601bca81d461c26c050c0669c&download >> >> >> Just unzip the file and run the following command: >> >> java -Xmx1024M -cp . MinimalExample >> >> It runs the complete test suite. Some tests fail, but that's OK. Here >> are my timings: >> >> Rhino (JDK7): >> >> Total time: 394.80 secs >> Time construct: 0.38 secs >> Time parse: 25.07 secs >> Time run: 368.71 secs >> 747 of 758 tests successful. >> >> Nashorn: >> >> Total time: 1168.16 secs >> Time construct: 3.25 secs >> Time parse: 309.84 secs >> Time run: 853.91 secs >> 747 of 758 tests successful. >> >> The tests are slower than before because there's only one thread. In >> citeproc-java multiple threads are used instead. However, the >> performance difference is still quite noticeable. Nashorn is almost 3 >> times slower. It takes a lot more time to parse the JavaScript and >> also execution time is longer. >> >> Hope this helps! >> >> Michel >> >> >> Am 20.02.2014 09:30, schrieb A. Sundararajan: >>> I was trying to do proper comparison and get to the actual difference >>> between the two implementations being compared. Only then we could >>> narrow down and suggest/investigate options. >>> >>> Btw, you can trace callsite misses by -tcs (or --trace-callsites) >>> option >>> of 'jjs' tool. The same option can also be specified by the System >>> property "nashorn.args". For example: >>> >>> jjs -tcs myscript.js >>> java -Dnashorn.args=-tcs -jar MyJar.jar >>> >>> All command line options supported can be seen from >>> >>> jjs -xhelp >>> >>> Looking forward to your minimal example. >>> >>> Thanks >>> -Sundar >>> >>> >>> On Thursday 20 February 2014 01:52 PM, Michel Kr?mer wrote: >>>> OK. I understand that the code base is too large to debug. I thought >>>> you could just tell me some magic parameter to trace down callsite >>>> misses or whatever *LOL* but it seems to be more complicated. >>>> >>>> I'll try to compile a minimal example executing the javascript code, >>>> in order to rule out everything related to the way Nashorn is called. >>>> I'll get back to you. >>>> >>>> Thanks! >>>> Michel >>>> >>>> >>>> Am 20.02.2014 09:15, schrieb A. Sundararajan: >>>>> Since I can't clean/run on jdk7 - nor don't understand the code base >>>>> much, I suggest you do the following (when I try to figure out >>>>> ways to >>>>> clean /build/run at my end). >>>>> >>>>> * You can use javax.script.Invocable interface's methods to invoke >>>>> specific functions rather than doing 'eval' of function/method calls. >>>>> >>>>> * You can also call specific object methods by invokeMethod method. >>>>> >>>>> * To have proper comparison, we should do Json as string and eval in >>>>> both cases or have Scriptable-like access + call method in >>>>> nashorn. If >>>>> the former is not possible, I suggest go through >>>>> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+jsr223+engine+notes >>>>> >>>>> >>>>> >>>>> * Because of string json and eval-for-method, there are lot more >>>>> evals >>>>> with nashorn/javax.script. Yes - that is the same with >>>>> rhino+jdk7+javax.script. But unfortunately I couldn't run that >>>>> mode at >>>>> my end (yet). >>>>> >>>>> * It is possible to access construct object and put properties in >>>>> it by >>>>> ScriptObjectMirror/Bindings/JSObject interface on every script object >>>>> >>>>> Thanks >>>>> -Sundar >>>>> >>>>> >>>>> On Thursday 20 February 2014 01:40 PM, Michel Kr?mer wrote: >>>>>> Hi! >>>>>> >>>>>> Replacing RhinoJsonBuilder by StringJsonBuilder will not work. >>>>>> The way >>>>>> Rhino is run either directly or through the Script API is just too >>>>>> different. >>>>>> >>>>>> I checked the line the first error occured in (build.gradle:230). It >>>>>> seems you can just remove everything from line 210 to the end of the >>>>>> file. It should still run and the error might probably be gone. >>>>>> >>>>>> There are other possibilities to run the test suite, but there more >>>>>> complicated. Let's try this one first. >>>>>> >>>>>> Cheers, >>>>>> Michel >>>>>> >>>>>> >>>>>> Am 20.02.2014 08:32, schrieb A. Sundararajan: >>>>>>> Hi Michel, >>>>>>> >>>>>>> Nope. Doesn't seem to help. BTW, I did clean last time too - >>>>>>> didn't do >>>>>>> git clean. But this time I did that as well. >>>>>>> >>>>>>> I thought I'll do this and check >>>>>>> >>>>>>> diff --git >>>>>>> a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>>>>>> >>>>>>> index d2524d2..21a5281 100644 >>>>>>> --- >>>>>>> a/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>>>>>> >>>>>>> +++ >>>>>>> b/src/main/java/de/undercouch/citeproc/script/RhinoScriptRunner.java >>>>>>> >>>>>>> @@ -31,6 +31,7 @@ import org.mozilla.javascript.Wrapper; >>>>>>> >>>>>>> import de.undercouch.citeproc.helper.CSLUtils; >>>>>>> import de.undercouch.citeproc.helper.json.JsonBuilder; >>>>>>> +import de.undercouch.citeproc.helper.json.StringJsonBuilder; >>>>>>> >>>>>>> /** >>>>>>> * Executes JavaScript scripts using Mozilla Rhino >>>>>>> @@ -204,7 +205,8 @@ public class RhinoScriptRunner extends >>>>>>> AbstractScriptRunner >>>>>>> >>>>>>> @Override >>>>>>> public JsonBuilder createJsonBuilder() { >>>>>>> - return new RhinoJsonBuilder(scope, this); >>>>>>> + return new StringJsonBuilder(this); >>>>>>> + // return new RhinoJsonBuilder(scope, this); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> Basically making sure both nashorn and rhino use the same json >>>>>>> mechanism >>>>>>> (rhino json builder uses Scriptable - just wanted to see how far >>>>>>> that >>>>>>> difference contributes). >>>>>>> >>>>>>> >>>>>>> When I did clean and re-build - this time with jdk8, >>>>>>> >>>>>>> I got this: >>>>>>> >>>>>>> Using script runner: Mozilla Rhino 1.7 release 4 2012 06 18 >>>>>>> :runTestSuite FAILED >>>>>>> >>>>>>> FAILURE: Build failed with an exception. >>>>>>> >>>>>>> * Where: >>>>>>> Build file '/home/sundar/src/citeproc-java/build.gradle' line: 128 >>>>>>> >>>>>>> * What went wrong: >>>>>>> Execution failed for task ':runTestSuite'. >>>>>>> > java.util.concurrent.ExecutionException: >>>>>>> java.lang.IllegalArgumentException: Could not update items >>>>>>> >>>>>>> * Try: >>>>>>> Run with --stacktrace option to get the stack trace. Run with >>>>>>> --info or >>>>>>> --debug option to get more log output. >>>>>>> >>>>>>> BUILD FAILED >>>>>>> >>>>>>> Total time: 3 mins 35.962 secs >>>>>>> >>>>>>> If there is anyway to avoid gradle dependency and run it straight - >>>>>>> say >>>>>>> by 'ant' or some such, it would be very useful. >>>>>>> >>>>>>> Thanks >>>>>>> -Sundar >>>>>>> >>>>>>> On Thursday 20 February 2014 12:00 PM, Michel Kr?mer wrote: >>>>>>>> Dear Sundar, >>>>>>>> >>>>>>>> Thanks for your help. I see that you familiarized yourself with >>>>>>>> the >>>>>>>> code already. I appreciate that very much! >>>>>>>> >>>>>>>> You're right, when you run it in 'rhino' mode it will use code >>>>>>>> optimized for Rhino. However, you're also right, it should use >>>>>>>> JDK7's >>>>>>>> embedded Rhino when you run it in 'jre' mode under JDK7. >>>>>>>> >>>>>>>> I've never seen this error message before. citeproc-java itself >>>>>>>> does >>>>>>>> not use any logging mechanism, but I know that Gradle does. So, >>>>>>>> the >>>>>>>> error must have something to do with Gradle or the particular >>>>>>>> Gradle >>>>>>>> version you're running. Is there another Gradle version already >>>>>>>> installed on your system? Please make sure to run the gradlew >>>>>>>> script >>>>>>>> in the project's root directory. It automatically downloads the >>>>>>>> right >>>>>>>> Gradle version. Also make sure to run `./gradlew clean' or even >>>>>>>> `git >>>>>>>> clean -fdx', just in case. >>>>>>>> >>>>>>>> I hope this helps. Please tell me if the problem persists. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Michel >>>>>>>> >>>>>>>> >>>>>>>> Am 20.02.2014 04:36, schrieb A. Sundararajan: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Thanks for writing to us. >>>>>>>>> >>>>>>>>> Two things: >>>>>>>>> >>>>>>>>> 1) 'rhino' mode uses Rhino's API directly (Context ..). For >>>>>>>>> nashorn, it >>>>>>>>> uses 'javax.script' engine API. I thought may be on jdk7, I could >>>>>>>>> run >>>>>>>>> 'jre' mode and try jdk7's embedded rhino based javax.script >>>>>>>>> engine. >>>>>>>>> After clean and re-run test with jdk7 results in >>>>>>>>> >>>>>>>>> >>>>>>>>> FAILURE: Build failed with an exception. >>>>>>>>> >>>>>>>>> * Where: >>>>>>>>> Build file '/home/sundar/src/citeproc-java/build.gradle' line: >>>>>>>>> 230 >>>>>>>>> >>>>>>>>> * What went wrong: >>>>>>>>> A problem occurred evaluating root project 'citeproc-java'. >>>>>>>>> > >>>>>>>>> org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;[Ljava/lang/Object;Ljava/lang/Throwable;)V >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> * Try: >>>>>>>>> Run with --stacktrace option to get the stack trace. Run with >>>>>>>>> --info or >>>>>>>>> --debug option to get more log output. >>>>>>>>> >>>>>>>>> BUILD FAILED >>>>>>>>> >>>>>>>>> With jdk8, 'jre' and 'rhino' mode run fine >>>>>>>>> >>>>>>>>> 2) Json handling for rhino uses RhinoJsonBuilder which uses >>>>>>>>> Scriptable >>>>>>>>> of Rhino. For nashorn, it uses 'string json builder' - which >>>>>>>>> presumably >>>>>>>>> involves more string handling? >>>>>>>>> >>>>>>>>> If you can tell me how to run with jdk7, then perhaps we can have >>>>>>>>> proper >>>>>>>>> comparison. 'jre' mode on jdk7 with rhino javax.script engine and >>>>>>>>> 'jre' >>>>>>>>> mode on jdk8 with nashorn javax.script engine. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Sundar >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wednesday 19 February 2014 09:09 PM, Michel Kr?mer wrote: >>>>>>>>>> Hi folks, >>>>>>>>>> >>>>>>>>>> I'm experiencing very drastic performance issues with Nashorn >>>>>>>>>> (JDK 8 >>>>>>>>>> b129) compared to Rhino. My script takes almost 13 minutes >>>>>>>>>> instead of >>>>>>>>>> 16 seconds! I hope you guys can tell me what's going on here. >>>>>>>>>> >>>>>>>>>> I've recently tested citeproc-java >>>>>>>>>> (https://github.com/michel-kraemer/citeproc-java) under JDK8 in >>>>>>>>>> order >>>>>>>>>> to make sure it keeps running flawlessly when the next Java >>>>>>>>>> version >>>>>>>>>> comes out. citeproc-java uses citeproc-js under the hood >>>>>>>>>> which is a >>>>>>>>>> rather large JavaScript library consisting of one file of >>>>>>>>>> about 540 >>>>>>>>>> KB, 13.500 lines of code >>>>>>>>>> (https://bitbucket.org/fbennett/citeproc-js/wiki/Home). >>>>>>>>>> >>>>>>>>>> Previously I used Rhino to execute the JavaScript and it worked >>>>>>>>>> quite >>>>>>>>>> well. There is a test suite consisting of 758 tests. Running >>>>>>>>>> this >>>>>>>>>> suite takes about 16 seconds (JavaScript compiled to byte code) >>>>>>>>>> or 46 >>>>>>>>>> secs (interpreted JavaScript). However, if I try to run the same >>>>>>>>>> test >>>>>>>>>> suite with Oracle Nashorn it takes 12.5 minutes! (see timings >>>>>>>>>> below) >>>>>>>>>> >>>>>>>>>> This is a very drastic performance drop and I was very >>>>>>>>>> surprised to >>>>>>>>>> see this. Is there some way to debug Nashorn in order to find >>>>>>>>>> out >>>>>>>>>> what >>>>>>>>>> is actually going on here? >>>>>>>>>> >>>>>>>>>> Timings on my computer (i5-3570K, 3.4 GHz, 4 cores, 16 GB RAM): >>>>>>>>>> >>>>>>>>>> Rhino 1.7R4 (JavaScript compiled to byte code): >>>>>>>>>> 16.176 secs >>>>>>>>>> >>>>>>>>>> Rhino 1.7R3 (bundled w/ JDK 7, interpreted JavaScript): >>>>>>>>>> 45.970 secs >>>>>>>>>> >>>>>>>>>> Nashorn (JDK 8 b129): >>>>>>>>>> 754.266 secs >>>>>>>>>> >>>>>>>>>> Steps to reproduce (no prerequisites other than JDK8): >>>>>>>>>> >>>>>>>>>> git clone https://github.com/michel-kraemer/citeproc-java.git >>>>>>>>>> cd citeproc-java >>>>>>>>>> ./gradlew runTestSuite -PscriptRunnerType=rhino >>>>>>>>>> ./gradlew runTestSuite -PscriptRunnerType=jre >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Michel >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > From tal.liron at threecrickets.com Mon Feb 24 10:12:31 2014 From: tal.liron at threecrickets.com (Tal Liron) Date: Tue, 25 Feb 2014 02:12:31 +0800 Subject: Fwd: GC overhead limit exceeded In-Reply-To: <52DA2462.1040800@threecrickets.com> References: <52C7B0FC.4040407@threecrickets.com> <52C811F1.4090202@threecrickets.com> <52C8171D.1000402@threecrickets.com> <52DA2462.1040800@threecrickets.com> Message-ID: <530B8B8F.80909@threecrickets.com> I've been away for a month. Has anyone with knowhow followed up on this? The issue is still present. On 01/18/2014 02:51 PM, Tal Liron wrote: > I have a new dump that will hopefully be more useful: > > https://dl.dropboxusercontent.com/u/122806/jvm8_gc2.zip > > From what I can tell, indeed lambda forms are way out of control here. > Generally, too, there is a huge amount of Nashorn-related instances, > which may be related. > > (Note that Log4j 2.0 also seems to be having a serious memory leak! I > have opened a bug about it over there.) > > On 01/06/2014 01:57 PM, Benjamin Sieffert wrote: >> Hi everyone, >> >> we have been observing similar symptoms from 7u40 onwards (using >> nashorn-backport with j7 -- j8 has the same problems as 7u40 and 7u45... >> 7u25 is the last version that works fine) and suspect the cause to be >> the >> JSR-292 changes that took place there. Iirc I already asked over on >> their >> mailing list. Here's the link: >> http://mail.openjdk.java.net/pipermail/mlvm-dev/2013-December/005586.html >> >> The fault might as well lie with nashorn, though. It's certainly worth >> investigating. >> >> Regards >> > From sundararajan.athijegannathan at oracle.com Tue Feb 25 03:50:23 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Tue, 25 Feb 2014 17:20:23 +0530 Subject: RFR 8030197: Nashorn: Object.defineProperty() can be lured to change fixed NaN property Message-ID: <530C837F.60407@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8030197/ Bug: https://bugs.openjdk.java.net/browse/JDK-8030197 Thanks -Sundar From attila.szegedi at oracle.com Wed Feb 26 05:02:12 2014 From: attila.szegedi at oracle.com (attila.szegedi at oracle.com) Date: Wed, 26 Feb 2014 13:02:12 +0000 Subject: hg: nashorn/jdk9/nashorn: 43 new changesets Message-ID: <20140226130301.1573162F44@hg.openjdk.java.net> Changeset: c041d151d7e6 Author: sundar Date: 2014-01-15 14:51 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/c041d151d7e6 8031715: Indexed access to java package not working Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8031715.js + test/script/basic/JDK-8031715.js.EXPECTED Changeset: b2ca350d8415 Author: sundar Date: 2014-01-16 21:26 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/b2ca350d8415 8031983: Error objects should capture stack at the constructor Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/runtime/ECMAException.java + test/script/basic/JDK-8031983.js + test/script/basic/JDK-8031983.js.EXPECTED ! test/script/basic/NASHORN-441.js.EXPECTED Changeset: 341f81ebefe0 Author: sundar Date: 2014-01-16 22:50 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/341f81ebefe0 8032004: instance property "message" of Error objects should be non-enumerable Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java + test/script/basic/JDK-8032004.js ! test/script/basic/NASHORN-111.js.EXPECTED Changeset: 76f606690a45 Author: sundar Date: 2014-01-17 20:09 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/76f606690a45 8032060: PropertyMap of Error objects is not stable Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAException.java + test/script/trusted/JDK-8032060.js Changeset: 071eb6953a4a Author: sundar Date: 2014-01-20 19:51 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/071eb6953a4a 8032068: implement @sourceURL and #sourceURL directives Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java + test/script/basic/JDK-8032068.js + test/script/basic/JDK-8032068.js.EXPECTED Changeset: b9fdc55a6e28 Author: chegar Date: 2013-11-03 07:33 +0000 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/b9fdc55a6e28 Merge Changeset: c1049f63d4f5 Author: kizune Date: 2013-12-03 14:13 +0400 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/c1049f63d4f5 Merge Changeset: 39a3e5a4d6d4 Author: kizune Date: 2013-12-05 16:37 +0400 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/39a3e5a4d6d4 Merge - makefiles/BuildNashorn.gmk - makefiles/Makefile Changeset: dd59e60accdd Author: kizune Date: 2013-12-13 22:13 +0400 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/dd59e60accdd Merge Changeset: 7841feee13f5 Author: katleman Date: 2013-12-19 17:24 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/7841feee13f5 Added tag jdk8-b121 for changeset 32631eed0fad ! .hgtags Changeset: 89f838ccd186 Author: asaha Date: 2013-12-20 07:44 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/89f838ccd186 Merge Changeset: 739f3abdfa55 Author: sundar Date: 2013-12-09 09:53 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/739f3abdfa55 Merge Changeset: e452a3797290 Author: sundar Date: 2013-12-12 09:18 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/e452a3797290 Merge Changeset: 0225a7ca37ab Author: lana Date: 2013-12-12 19:19 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/0225a7ca37ab Merge Changeset: 9d112a0e7df7 Author: lana Date: 2013-12-23 14:46 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/9d112a0e7df7 Merge Changeset: a9d41a8055ca Author: asaha Date: 2014-01-02 15:31 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/a9d41a8055ca Merge Changeset: 688f4167f921 Author: katleman Date: 2014-01-03 11:55 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/688f4167f921 Added tag jdk8-b122 for changeset 9d112a0e7df7 ! .hgtags Changeset: 98e7379a4345 Author: asaha Date: 2014-01-03 16:01 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/98e7379a4345 Merge Changeset: 0b4301c79225 Author: katleman Date: 2014-01-10 08:32 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/0b4301c79225 Added tag jdk8-b123 for changeset 688f4167f921 ! .hgtags Changeset: 2334772d5292 Author: asaha Date: 2014-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/2334772d5292 Merge Changeset: 2523105f2165 Author: asaha Date: 2014-01-10 17:08 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/2523105f2165 Merge ! .hgtags Changeset: 1c3fdbe8296a Author: asaha Date: 2014-01-14 08:09 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/1c3fdbe8296a Merge Changeset: 0765d74cc483 Author: asaha Date: 2014-01-15 10:24 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/0765d74cc483 Merge Changeset: e2cd81d404c8 Author: asaha Date: 2014-01-16 21:46 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/e2cd81d404c8 Merge Changeset: 5498391976e0 Author: kizune Date: 2014-01-20 20:42 +0400 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/5498391976e0 Merge Changeset: aa5dad691156 Author: kizune Date: 2014-01-20 20:42 +0400 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/aa5dad691156 Merge Changeset: 3f1385a3bbf5 Author: katleman Date: 2014-01-21 18:17 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/3f1385a3bbf5 Added tag jdk9-b01 for changeset 65347535840f ! .hgtags Changeset: b3517e51f404 Author: lana Date: 2014-01-27 21:01 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/b3517e51f404 Merge ! .hgtags Changeset: 560be4b9f5c4 Author: sundar Date: 2014-01-30 18:26 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/560be4b9f5c4 8032943: Improve reflection in Nashorn Reviewed-by: jlaskey, attila, ahgross ! src/jdk/nashorn/internal/objects/NativeObject.java + test/script/sandbox/classbind.js Changeset: 47f029b11643 Author: sundar Date: 2014-01-30 18:49 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/47f029b11643 8032954: Nashorn: extend Java.extend Reviewed-by: jlaskey, attila, ahgross ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/script/sandbox/classloader.js ! test/script/sandbox/classloader.js.EXPECTED Changeset: 6895d234836c Author: sundar Date: 2014-01-30 19:28 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/6895d234836c 8032948: Nashorn linkages awry Reviewed-by: jlaskey, attila, ahgross ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 66b98808fdff Author: attila Date: 2014-01-30 20:13 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/66b98808fdff 8032681: Issues with Nashorn Reviewed-by: ahgross, jlaskey, sundar + src/jdk/internal/dynalink/linker/GuardedTypeConversion.java ! src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk/internal/dynalink/support/LinkerServicesImpl.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/linker/AdaptationResult.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/basic/JDK-8014647.js ! test/script/basic/JDK-8014647.js.EXPECTED ! test/script/basic/javaclassoverrides.js ! test/script/basic/javaclassoverrides.js.EXPECTED ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java + test/src/jdk/nashorn/test/models/ClassWithFinalFinalizer.java + test/src/jdk/nashorn/test/models/ClassWithInheritedFinalFinalizer.java Changeset: 22420177ec9d Author: sundar Date: 2014-02-06 17:44 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/22420177ec9d 8033763: Add tests to assert map identity of certain objects Reviewed-by: hannesw, lagergren ! make/build.xml ! make/project.properties + test/script/currently-failing/gettersetter.js + test/script/maptests/builtins.js + test/script/maptests/constructor.js + test/script/maptests/maputil.js + test/script/maptests/object_create.js + test/script/maptests/object_literals.js + test/script/maptests/point.js + test/script/maptests/property_add.js + test/script/maptests/property_delete.js + test/script/maptests/proto.js Changeset: 79c69831674f Author: sundar Date: 2014-02-07 18:47 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/79c69831674f 8033924: Default permissions are not given for eval code Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java + test/script/sandbox/safeprops.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 40fcf43dd721 Author: mnunez Date: 2014-02-11 12:05 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/40fcf43dd721 8033231: test fails with java.lang.UnsatisfiedLinkError Reviewed-by: attila, sundar ! test/script/basic/JDK-8026161.js ! test/script/basic/JDK-8026161.js.EXPECTED + test/src/jdk/nashorn/test/models/IntFloatOverloadSelection.java Changeset: 0afcc0851aab Author: sundar Date: 2014-02-14 19:02 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/0afcc0851aab 8011964: need indexed access to externally-managed ByteBuffer Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ByteBufferArrayData.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8011964.js + test/script/basic/JDK-8011964.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptObjectMirrorTest.java Changeset: 52a8849d8046 Author: jeff Date: 2014-01-13 14:45 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/52a8849d8046 7129980: Third Party License Readme update for JDK8 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 4d893e4ec51d Author: jeff Date: 2014-01-28 20:10 +0000 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/4d893e4ec51d 8032816: THIRDPARTYREADME LittleCMS preamble missing JRE 8 & JDK 8 Reviewed-by: lana ! THIRD_PARTY_README Changeset: b47e0ab68807 Author: katleman Date: 2014-02-06 13:09 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/b47e0ab68807 Added tag jdk9-b02 for changeset b3517e51f404 ! .hgtags Changeset: 832f89ff25d9 Author: lana Date: 2014-02-11 11:25 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/832f89ff25d9 Merge Changeset: be732b8850d6 Author: lana Date: 2014-02-20 20:00 -0800 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/be732b8850d6 Merge Changeset: feceb45debac Author: sundar Date: 2014-02-25 18:56 +0530 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/feceb45debac 8030197: Nashorn: Object.defineProperty() can be lured to change fixed NaN property Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/runtime/PropertyDescriptor.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8030197.js Changeset: 26a5fdb90de2 Author: attila Date: 2014-02-26 13:17 +0100 URL: http://hg.openjdk.java.net/nashorn/jdk9/nashorn/rev/26a5fdb90de2 8035820: Optimistic recompilation Reviewed-by: hannesw, jlaskey, sundar Contributed-by: attila.szegedi at oracle.com, marcus.lagergren at oracle.com ! .hgignore + bin/rundiff.sh + bin/runnormal.sh + bin/runnormaldual.sh + bin/runopt.sh + bin/runoptdual.sh + bin/runoptdualcatch.sh ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! make/build.xml ! make/nbproject/ide-targets.xml ! make/project.properties ! src/jdk/internal/dynalink/DynamicLinker.java ! src/jdk/internal/dynalink/DynamicLinkerFactory.java + src/jdk/internal/dynalink/GuardedInvocationFilter.java ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/BeanLinker.java ! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk/internal/dynalink/beans/OverloadedMethod.java ! src/jdk/internal/dynalink/beans/SingleDynamicMethod.java ! src/jdk/internal/dynalink/linker/GuardedInvocation.java ! src/jdk/internal/dynalink/linker/GuardingDynamicLinker.java ! src/jdk/internal/dynalink/linker/LinkRequest.java ! src/jdk/internal/dynalink/linker/LinkerServices.java + src/jdk/internal/dynalink/support/CatchExceptionCombinator.java + src/jdk/internal/dynalink/support/DefaultPrelinkFilter.java ! src/jdk/internal/dynalink/support/LinkRequestImpl.java ! src/jdk/internal/dynalink/support/LinkerServicesImpl.java ! src/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java ! src/jdk/internal/dynalink/support/TypeUtilities.java ! src/jdk/nashorn/api/scripting/JSObject.java ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java + src/jdk/nashorn/internal/IntDeque.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/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/Condition.java ! src/jdk/nashorn/internal/codegen/ConstantData.java + src/jdk/nashorn/internal/codegen/DumpBytecode.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Label.java + src/jdk/nashorn/internal/codegen/LocalStateRestorationInfo.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/ParamTypeMap.java + src/jdk/nashorn/internal/codegen/ProgramPoints.java ! src/jdk/nashorn/internal/codegen/RangeAnalyzer.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/codegen/Splitter.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/BytecodeOps.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/ObjectType.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/BlockStatement.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/Expression.java ! src/jdk/nashorn/internal/ir/FunctionCall.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Node.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/Symbol.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java + src/jdk/nashorn/internal/ir/debug/NashornClassReader.java + src/jdk/nashorn/internal/ir/debug/NashornTextifier.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/lookup/Lookup.java ! src/jdk/nashorn/internal/lookup/MethodHandleFactory.java ! src/jdk/nashorn/internal/lookup/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + src/jdk/nashorn/internal/objects/annotations/Optimistic.java ! src/jdk/nashorn/internal/objects/annotations/Property.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.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/Debug.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/DebuggerSupport.java ! src/jdk/nashorn/internal/runtime/DefaultPropertyAccess.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/FunctionScope.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + src/jdk/nashorn/internal/runtime/OptimisticReturnFilters.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyAccess.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/PropertyMap.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/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java + src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/Undefined.java + src/jdk/nashorn/internal/runtime/UnwarrantedOptimismException.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/ContinuousArray.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapter.java ! src/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/internal/scripts/JO.java ! src/jdk/nashorn/tools/Shell.java ! test/script/assert.js ! test/script/basic/JDK-8025515.js + test/script/basic/JDK-8029384.js + test/script/basic/JDK-8029384.js.EXPECTED ! test/script/basic/JDK-8029467.js ! test/script/basic/JDK-8029667.js ! test/script/basic/exprclosure.js.EXPECTED + test/script/basic/hideLocationProperties.js + test/script/basic/hideLocationProperties.js.EXPECTED + test/script/basic/relinkIndexGetter.js + test/script/basic/relinkIndexGetter.js.EXPECTED ! test/script/basic/run-octane.js - test/script/basic/runsunspider-lazy.js ! test/script/basic/runsunspider.js + test/script/basic/typedarrays2.js + test/script/basic/typedarrays2.js.EXPECTED + test/script/currently-failing/property_delete.js ! test/script/maptests/constructor.js ! test/script/maptests/maputil.js ! test/script/maptests/object_literals.js ! test/script/maptests/point.js ! test/script/maptests/property_add.js - test/script/maptests/property_delete.js ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java ! test/src/jdk/nashorn/api/javaaccess/SharedObject.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java From sergey.lugovoy at oracle.com Wed Feb 26 05:37:09 2014 From: sergey.lugovoy at oracle.com (Serge) Date: Wed, 26 Feb 2014 17:37:09 +0400 Subject: RFR 8028615: jdk.nashorn.x3::some.serious.failure needs more memory to run Message-ID: <530DEE05.8080709@oracle.com> Hi all, Please review http://cr.openjdk.java.net/~yan/8028615/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8028615 -- Regards, Serge Lugovoy From hannes.wallnoefer at oracle.com Thu Feb 27 09:22:14 2014 From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer) Date: Thu, 27 Feb 2014 18:22:14 +0100 Subject: Review request for JDK-8035948 - Redesign property listeners for shared classes Message-ID: <530F7446.6060508@oracle.com> Please review JDK-8035948 - Redesign property listeners for shared classes: http://cr.openjdk.java.net/~hannesw/8035948/ This prepares property maps and property listeners to work better with classes that are reused between JS environments. The central ideas are: - Reuse property maps between globals in order to minimize polymorphism. - Use SoftReferences for property map history to avoid memory leaks - Redesign property listeners to be attatched to property maps only since ScriptObjects are specific to one JS environment. - Reduce number of property listeners by only creating them when needed (when a callsite accesses an inherited property). - Reduce number of prototype history lookups in property maps by using a unique combination of prototype/property maps from the start. Actual class sharing functionality is coming in a later webrev. Let me know if you have any questions about this. Hannes From sundararajan.athijegannathan at oracle.com Thu Feb 27 19:18:06 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 28 Feb 2014 08:48:06 +0530 Subject: Review request for JDK-8035948 - Redesign property listeners for shared classes In-Reply-To: <530F7446.6060508@oracle.com> References: <530F7446.6060508@oracle.com> Message-ID: <530FFFEE.80600@oracle.com> +1 Copyright year in this file has to be 2014. http://cr.openjdk.java.net/~hannesw/8035948/webrev.00/src/jdk/nashorn/internal/runtime/PropertyListeners.java.html -Sundar On Thursday 27 February 2014 10:52 PM, Hannes Wallnoefer wrote: > Please review JDK-8035948 - Redesign property listeners for shared > classes: > > http://cr.openjdk.java.net/~hannesw/8035948/ > > This prepares property maps and property listeners to work better with > classes that are reused between JS environments. The central ideas are: > > - Reuse property maps between globals in order to minimize polymorphism. > - Use SoftReferences for property map history to avoid memory leaks > - Redesign property listeners to be attatched to property maps only > since ScriptObjects are specific to one JS environment. > - Reduce number of property listeners by only creating them when > needed (when a callsite accesses an inherited property). > - Reduce number of prototype history lookups in property maps by > using a unique combination of prototype/property maps from the start. > > Actual class sharing functionality is coming in a later webrev. Let me > know if you have any questions about this. > > Hannes From sundararajan.athijegannathan at oracle.com Fri Feb 28 05:11:13 2014 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Fri, 28 Feb 2014 18:41:13 +0530 Subject: RFR 8028615: jdk.nashorn.x3::some.serious.failure needs more memory to run In-Reply-To: <530DEE05.8080709@oracle.com> References: <530DEE05.8080709@oracle.com> Message-ID: <53108AF1.4030901@oracle.com> Looks confusing to have run.test.xmx=1G run.test.xms=2G (misleading) that -Xmx < -Xms ?? If one of the values is not used in octane, perhaps a different property has to be introduced for octane. Or change xmx and xms both. -Sundar On Wednesday 26 February 2014 07:07 PM, Serge wrote: > Hi all, > Please review http://cr.openjdk.java.net/~yan/8028615/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8028615 >