From marcus.lagergren at oracle.com  Sun Mar  1 22:18:40 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Sun, 1 Mar 2015 23:18:40 +0100
Subject: Help with compiling TypeScript using nashorn
In-Reply-To: <CADJ8MWUNwuqDfQa2=STp3HrpBrFA9DC8bTzC9bjb=fsP-auW_w@mail.gmail.com>
References: <CADJ8MWUNwuqDfQa2=STp3HrpBrFA9DC8bTzC9bjb=fsP-auW_w@mail.gmail.com>
Message-ID: <7BE18ACA-E24D-46BA-A610-CCCF53FBFC3E@oracle.com>

Hi Dan!

Interesting to hear about your project. It sounds very cool. 

I, personally, haven?t tried to play around with the Microsoft type script compiler on Nashorn much lately. I did play around with it a few months back. We should proably get it into the test suite in some form other than the Octane Typescript benchmark. I know Attila was doing some debugging in this benchmark last week, he might have some more recent experience.

My limited TS experience with Nashorn consists mostly of working with our thesis student Andreas Gabrielsson (thesis available to the public very soon) on a frontend that parses typescript and emits it as bytecode using Nashorn as the runtime, not with the industry standard TS compiler as such. Andreas might have more info for you about the current status, as he did a lot of typescript/javascript compilation using the typescript compiler during the thesis. 

I?ll try to find time this week (or someone on the team) to play with the latest typescript to javascript compiler and see if we have a bug here. I?ll file an issue if this is the case.

A quick look at twitter seems to indicate that people are successfully doing things with the TypeScript compiler on Nashorn right now. For example: 
https://twitter.com/smartboyathome/status/570060843267723264 <https://twitter.com/smartboyathome/status/570060843267723264>

We?ll investigate and get back to you as soon as we can.

/M


> On 10 Feb 2015, at 14:25, Dan Bar-Yaakov <danbaryak at gmail.com> wrote:
> 
> Hi
> 
> Marcus, thanks for the reply in LinkedIn. following that, here is a brief
> description of what I'm trying to do:
> 
> I work for Luminis Technologies. We build open source components for
> building modular web applications using OSGi (The Amdatu
> <http://amdatu.org/> Project). We would like to add some components that
> automatically compile frontend resources written in multiple languages
> (typescript, coffeescript, lescss, sass etc.). As the first stage we would
> like to get typescript working, as it's common in many projects that use
> our stack. Since we want to do it automatically on each change, speed is
> critical. That's why I was very glad to learn about your latest nashorn
> performance enhancements.
> 
> To get started I've tried compiling the microsoft TypeScript distribution
> (using Jake) and running it using jjs as I've seen in some examples online
> (j*js tsc.js --optimistic-types=true -- hello.ts* for example) and got the
> following error:
> tsc.js:20361 TypeError: Cannot read property "args" from undefined
> got the same thing when trying in Java code.
> 
> If it is indeed already possible to compile TS using nashorn, I'd really
> appreciate any help you can provide on how to do so.
> 
> Many thanks,
> Dan


From sundararajan.athijegannathan at oracle.com  Mon Mar  2 03:45:38 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 02 Mar 2015 09:15:38 +0530
Subject: Nashorn issue.
In-Reply-To: <CAGXXaX3AOP6ivpAtpourRNz6TwsKVQCNpOO75B8pWLVwF8yX+w@mail.gmail.com>
References: <CAGXXaX3AOP6ivpAtpourRNz6TwsKVQCNpOO75B8pWLVwF8yX+w@mail.gmail.com>
Message-ID: <54F3DCE2.8010904@oracle.com>

Hi,

It is difficult to debug with sketchy details. We need

* jdk8 exact version - update release version number - used. If not 
already using, I/we'd ask you to try 8u40 early access build here 
https://jdk8.java.net/download.html

- This step is to see if this issue is fixed in a recent update.

* a test that can be run at our end to reproduce

Once you've these info, please file a bug and/or send the details to us 
and we'll file a bug.

Thanks,
-Sundar


On Saturday 03 January 2015 08:39 AM, Ratheesh K Kamoor wrote:
> Hello,
>
> I am running in to a weird issue with Nashorn, posted the issue in
> stackoverflow.
>
> http://stackoverflow.com/questions/27347644/illegalargumentexception-exception-from-nashorn-is-it-a-bug-in-java-8
>
>
> Can someone help? Thank you so much for your time
>


From marcus.lagergren at oracle.com  Mon Mar  2 13:45:20 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 2 Mar 2015 14:45:20 +0100
Subject: Help with compiling TypeScript using nashorn
In-Reply-To: <7BE18ACA-E24D-46BA-A610-CCCF53FBFC3E@oracle.com>
References: <CADJ8MWUNwuqDfQa2=STp3HrpBrFA9DC8bTzC9bjb=fsP-auW_w@mail.gmail.com>
	<7BE18ACA-E24D-46BA-A610-CCCF53FBFC3E@oracle.com>
Message-ID: <151046CA-3CD2-4BE6-8DF0-9C1DE1959B7C@oracle.com>

Dan,

I?ve looked briefly at trying to run the Typescript compiler as you described. Can you indicate in more detail the process you go through to reproducible problem? Not sure how to install and use the current Microsoft distribution with Jake as you describe below. If you have some example setup that we can download and use, with step-by-step instructions that?d be ideal. I can run the typescript compler 

Regards
Marcus

> On 01 Mar 2015, at 23:18, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:
> 
> Hi Dan!
> 
> Interesting to hear about your project. It sounds very cool. 
> 
> I, personally, haven?t tried to play around with the Microsoft type script compiler on Nashorn much lately. I did play around with it a few months back. We should proably get it into the test suite in some form other than the Octane Typescript benchmark. I know Attila was doing some debugging in this benchmark last week, he might have some more recent experience.
> 
> My limited TS experience with Nashorn consists mostly of working with our thesis student Andreas Gabrielsson (thesis available to the public very soon) on a frontend that parses typescript and emits it as bytecode using Nashorn as the runtime, not with the industry standard TS compiler as such. Andreas might have more info for you about the current status, as he did a lot of typescript/javascript compilation using the typescript compiler during the thesis. 
> 
> I?ll try to find time this week (or someone on the team) to play with the latest typescript to javascript compiler and see if we have a bug here. I?ll file an issue if this is the case.
> 
> A quick look at twitter seems to indicate that people are successfully doing things with the TypeScript compiler on Nashorn right now. For example: 
> https://twitter.com/smartboyathome/status/570060843267723264 <https://twitter.com/smartboyathome/status/570060843267723264>
> 
> We?ll investigate and get back to you as soon as we can.
> 
> /M
> 
> 
>> On 10 Feb 2015, at 14:25, Dan Bar-Yaakov <danbaryak at gmail.com> wrote:
>> 
>> Hi
>> 
>> Marcus, thanks for the reply in LinkedIn. following that, here is a brief
>> description of what I'm trying to do:
>> 
>> I work for Luminis Technologies. We build open source components for
>> building modular web applications using OSGi (The Amdatu
>> <http://amdatu.org/> Project). We would like to add some components that
>> automatically compile frontend resources written in multiple languages
>> (typescript, coffeescript, lescss, sass etc.). As the first stage we would
>> like to get typescript working, as it's common in many projects that use
>> our stack. Since we want to do it automatically on each change, speed is
>> critical. That's why I was very glad to learn about your latest nashorn
>> performance enhancements.
>> 
>> To get started I've tried compiling the microsoft TypeScript distribution
>> (using Jake) and running it using jjs as I've seen in some examples online
>> (j*js tsc.js --optimistic-types=true -- hello.ts* for example) and got the
>> following error:
>> tsc.js:20361 TypeError: Cannot read property "args" from undefined
>> got the same thing when trying in Java code.
>> 
>> If it is indeed already possible to compile TS using nashorn, I'd really
>> appreciate any help you can provide on how to do so.
>> 
>> Many thanks,
>> Dan
> 


From hannes.wallnoefer at oracle.com  Mon Mar  2 17:19:37 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 02 Mar 2015 18:19:37 +0100
Subject: Nashorn code caching blog post
Message-ID: <54F49BA9.60907@oracle.com>

Hi Jim,

Here's the blog post for the code caching features. There's a few demo 
files included that should be downloadable both individually and as zip 
file.
You'll probably have to adjust these links manually.

Cheers,
Hannes

From hannes.wallnoefer at oracle.com  Mon Mar  2 17:26:02 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 02 Mar 2015 18:26:02 +0100
Subject: Nashorn code caching blog post
In-Reply-To: <54F49BA9.60907@oracle.com>
References: <54F49BA9.60907@oracle.com>
Message-ID: <54F49D2A.7050102@oracle.com>

Sorry, this wasn't supposed to go to nashorn-dev (which also stripped 
the attachments).

In any case the blog post should be up on the Nashorn blog soon :)

Hannes

Am 2015-03-02 um 18:19 schrieb Hannes Wallnoefer:
> Hi Jim,
>
> Here's the blog post for the code caching features. There's a few demo 
> files included that should be downloadable both individually and as 
> zip file.
> You'll probably have to adjust these links manually.
>
> Cheers,
> Hannes


From james.laskey at oracle.com  Mon Mar  2 17:31:17 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Mon, 2 Mar 2015 13:31:17 -0400
Subject: Nashorn code caching blog post
In-Reply-To: <54F49BA9.60907@oracle.com>
References: <54F49BA9.60907@oracle.com>
Message-ID: <4026AFBD-BF8A-4E9F-A224-4AE9C63348F8@oracle.com>

You'll need to put the demos in a public place before I post.  I also have to redo the formating, so supplying me an HTML document will be better.  Otherwise, the doc reads well.

-- Jim







> On Mar 2, 2015, at 1:19 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Hi Jim,
> 
> Here's the blog post for the code caching features. There's a few demo files included that should be downloadable both individually and as zip file.
> You'll probably have to adjust these links manually.
> 
> Cheers,
> Hannes
-------------- next part --------------
> 


From tonyzakula at gmail.com  Mon Mar  2 18:07:41 2015
From: tonyzakula at gmail.com (Tony Zakula)
Date: Mon, 2 Mar 2015 12:07:41 -0600
Subject: Nashorn code caching blog post
In-Reply-To: <4026AFBD-BF8A-4E9F-A224-4AE9C63348F8@oracle.com>
References: <54F49BA9.60907@oracle.com>
	<4026AFBD-BF8A-4E9F-A224-4AE9C63348F8@oracle.com>
Message-ID: <CAC_sW-fV3NdhG9JnBqRzO6VHpzUrcLBB0z+2EpdLKAopBRSajA@mail.gmail.com>

Really looking forward to it when it does arrive. :-)  Working with Nashorn
a lot and excited about the work being done with it.


On Mon, Mar 2, 2015 at 11:31 AM, Jim Laskey (Oracle) <
james.laskey at oracle.com> wrote:

> You'll need to put the demos in a public place before I post.  I also have
> to redo the formating, so supplying me an HTML document will be better.
> Otherwise, the doc reads well.
>
> -- Jim
>
>
>
>
>
>
>
> > On Mar 2, 2015, at 1:19 PM, Hannes Wallnoefer <
> hannes.wallnoefer at oracle.com> wrote:
> >
> > Hi Jim,
> >
> > Here's the blog post for the code caching features. There's a few demo
> files included that should be downloadable both individually and as zip
> file.
> > You'll probably have to adjust these links manually.
> >
> > Cheers,
> > Hannes
>
> >
>
>
>

From james.laskey at oracle.com  Mon Mar  2 18:21:57 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Mon, 2 Mar 2015 14:21:57 -0400
Subject: Nashorn code caching blog post
In-Reply-To: <CAC_sW-fV3NdhG9JnBqRzO6VHpzUrcLBB0z+2EpdLKAopBRSajA@mail.gmail.com>
References: <54F49BA9.60907@oracle.com>
	<4026AFBD-BF8A-4E9F-A224-4AE9C63348F8@oracle.com>
	<CAC_sW-fV3NdhG9JnBqRzO6VHpzUrcLBB0z+2EpdLKAopBRSajA@mail.gmail.com>
Message-ID: <FB7C3942-D0B2-48A3-A362-A19A201F05D8@oracle.com>

Posted https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using <https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using>


From tonyzakula at gmail.com  Mon Mar  2 21:45:52 2015
From: tonyzakula at gmail.com (Tony Zakula)
Date: Mon, 2 Mar 2015 15:45:52 -0600
Subject: Nashorn code caching blog post
In-Reply-To: <FB7C3942-D0B2-48A3-A362-A19A201F05D8@oracle.com>
References: <54F49BA9.60907@oracle.com>
	<4026AFBD-BF8A-4E9F-A224-4AE9C63348F8@oracle.com>
	<CAC_sW-fV3NdhG9JnBqRzO6VHpzUrcLBB0z+2EpdLKAopBRSajA@mail.gmail.com>
	<FB7C3942-D0B2-48A3-A362-A19A201F05D8@oracle.com>
Message-ID: <CAC_sW-fn4g_KRUz-2pabRbK2gkHfhMQewYJ+ZZaM02RjoH_ccQ@mail.gmail.com>

Looks awesome.  Cannot wait to start working with it later this week.

On Mon, Mar 2, 2015 at 12:21 PM, Jim Laskey (Oracle) <
james.laskey at oracle.com> wrote:

> Posted
> https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using
> <
> https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using
> >
>
>

From christian.michon at gmail.com  Tue Mar  3 08:27:41 2015
From: christian.michon at gmail.com (Christian MICHON)
Date: Tue, 3 Mar 2015 09:27:41 +0100
Subject: How to 'properly' extend javax.swing.JFrame with nashorn?
Message-ID: <CACx2yF9K_J76fnkJUUbm3z5Yud2OaCmH3HxtvCSFuHOJMSoGuw@mail.gmail.com>

Hi,

[ I tried to contact Sundar directly (still no answer), but I'd like to get
nashorn devs opinion as well. ]

I'm currently trying to extend a javax.swing.JFrame to make a small gui
using nashorn.

When I'm doing this with java or jruby, it's straight forward and quite
easy to code a contructor of the derived class to customize dimensions for
example.

Yet with nashorn I'm struggling: how is named the constructor?

I've a small snippet below to share: I'd like to know what is supposed to
be in place of XYZ to make frame appear properly (dimensions 800x600).

var myJFrame = Java.extend(javax.swing.JFrame, {
  XYZ: function() {
    setSize(800, 600);
    setVisible(true);
  }
});
var my = new myJFrame();
java.lang.Thread.currentThread().join();


Thanks in advance.
Christian

From sundararajan.athijegannathan at oracle.com  Tue Mar  3 10:50:19 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 03 Mar 2015 16:20:19 +0530
Subject: How to 'properly' extend javax.swing.JFrame with nashorn?
In-Reply-To: <CACx2yF9K_J76fnkJUUbm3z5Yud2OaCmH3HxtvCSFuHOJMSoGuw@mail.gmail.com>
References: <CACx2yF9K_J76fnkJUUbm3z5Yud2OaCmH3HxtvCSFuHOJMSoGuw@mail.gmail.com>
Message-ID: <54F591EB.6020004@oracle.com>

Are you looking for a way to introduce a new constructor? That is not 
supported. The class extension in nashorn is more like Java anonymous 
classes - There too you don't introduce a new constructor - just use 
existing constructor to construct new object.

You can workaround with:

function createMyFrame() {
   var my = Java.extend(.....) { ... }
   my.setSize(800, 600);
   my.visible = true;
   return my;
}

-Sundar

Christian MICHON wrote:
> Hi,
>
> [ I tried to contact Sundar directly (still no answer), but I'd like to get
> nashorn devs opinion as well. ]
>
> I'm currently trying to extend a javax.swing.JFrame to make a small gui
> using nashorn.
>
> When I'm doing this with java or jruby, it's straight forward and quite
> easy to code a contructor of the derived class to customize dimensions for
> example.
>
> Yet with nashorn I'm struggling: how is named the constructor?
>
> I've a small snippet below to share: I'd like to know what is supposed to
> be in place of XYZ to make frame appear properly (dimensions 800x600).
>
> var myJFrame = Java.extend(javax.swing.JFrame, {
>   XYZ: function() {
>     setSize(800, 600);
>     setVisible(true);
>   }
> });
> var my = new myJFrame();
> java.lang.Thread.currentThread().join();
>
>
> Thanks in advance.
> Christian
>   


From christian.michon at gmail.com  Tue Mar  3 11:39:01 2015
From: christian.michon at gmail.com (Christian MICHON)
Date: Tue, 3 Mar 2015 12:39:01 +0100
Subject: How to 'properly' extend javax.swing.JFrame with nashorn?
In-Reply-To: <54F591EB.6020004@oracle.com>
References: <CACx2yF9K_J76fnkJUUbm3z5Yud2OaCmH3HxtvCSFuHOJMSoGuw@mail.gmail.com>
	<54F591EB.6020004@oracle.com>
Message-ID: <CACx2yF_9rqcA7ejzwsPWPXupb7YBYCf6ev6jQdKOpBsziSPyrg@mail.gmail.com>

Hi Sundar,

thanks for the explanation. I was already doing what you suggested, and I
wanted to do it the way I'm used to (without "my." within a sub-class
extension).

Nevermind: nashorn is still a great tool.

On Tue, Mar 3, 2015 at 11:50 AM, A. Sundararajan <
sundararajan.athijegannathan at oracle.com> wrote:

> Are you looking for a way to introduce a new constructor? That is not
> supported. The class extension in nashorn is more like Java anonymous
> classes - There too you don't introduce a new constructor - just use
> existing constructor to construct new object.
>
> You can workaround with:
>
> function createMyFrame() {
>   var my = Java.extend(.....) { ... }
>   my.setSize(800, 600);
>   my.visible = true;
>   return my;
> }
>
> -Sundar
>
>
> Christian MICHON wrote:
>
>> Hi,
>>
>> [ I tried to contact Sundar directly (still no answer), but I'd like to
>> get
>> nashorn devs opinion as well. ]
>>
>> I'm currently trying to extend a javax.swing.JFrame to make a small gui
>> using nashorn.
>>
>> When I'm doing this with java or jruby, it's straight forward and quite
>> easy to code a contructor of the derived class to customize dimensions for
>> example.
>>
>> Yet with nashorn I'm struggling: how is named the constructor?
>>
>> I've a small snippet below to share: I'd like to know what is supposed to
>> be in place of XYZ to make frame appear properly (dimensions 800x600).
>>
>> var myJFrame = Java.extend(javax.swing.JFrame, {
>>   XYZ: function() {
>>     setSize(800, 600);
>>     setVisible(true);
>>   }
>> });
>> var my = new myJFrame();
>> java.lang.Thread.currentThread().join();
>>
>>
>> Thanks in advance.
>> Christian
>>
>>
>
>


-- 
Christian

From attila.szegedi at oracle.com  Tue Mar  3 23:20:29 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 4 Mar 2015 00:20:29 +0100
Subject: Nashorn in JDK 8u40
Message-ID: <E7E4DB55-4859-427E-B9D2-BD1CF5268840@oracle.com>

Hi folks,

JDK 8u40 was released today, and I wanted to take a moment to summarize some of the new stuff in Nashorn since 8u25.

First of all, I want to get the bad news out of the way. There is, unfortunately, a functional regression. It was discovered too late in the development cycle for the fix to make the deadline for 8u40, so we could really do nothing except grit our teeth and accept it'll have to go out like this. Namely, passing of JavaScript arrays to Java methods in the vararg position is broken, for details see <https://bugs.openjdk.java.net/browse/JDK-8072596>. We used to convert the JS array to a Java array of the required type in vararg position, but unfortunately we now convert it to ScriptObjectMirror instead and that causes a ClassCastException (as a ScriptObjectMirror isn't a Java array, obviously). This was not intended and we will revert to the old behavior no later than in the next minor release, 8u60. Temporary workaround (should you choose to upgrade to 8u40) is to use Java.to() explicitly in such situations. I know it's not ideal and it will certainly break someone's existing code; I'm truly sorry about that. Most we can do at the moment is to make you aware of the issue. (The 9 and 8u-dev repositories have a fix, so neither the 9 EA builds nor the shortly coming 8u60 EA builds have the bug.)

Let's move on to brighter things. Here's some new features and improvements in 8u40:

* Nashorn compiler has fairly powerful static type inference capabilities for local variables and expressions now. While JavaScript is notoriously hard to analyze statically, we still put in an analyzer that does a fair job of inferring static types and then using them to emit optimized bytecode. The bytecode emitted for e.g. the "crypto" Octane benchmark is now pretty close to the bytecode you'd get if you compiled a Java implementation of those same algorithms. In other words, Nashorn's gotten much better at both number crunching and asm.js-like workloads. The static type inference is always on.

* Optimistic typing. It actually complements static type inference: what types can't be statically inferred will be speculated upon, from more optimistic (it's an int!) to a less optimistic (it's a floating point number!) to the ultimately not optimistic at all (well, duh, it's an object after all). Nashorn has a full gradual code deoptimization framework, complete with on-stack code replacement built into it now for this purpose. Optimistic typing typically makes the warmup worse, but the warmed-up performance is significantly better, hence it's best for use with long-running applications. It's off by default, you can use the "--optimistic-types=true" command line switch to turn it on. There's a blog post that further elaborates on it: <https://blogs.oracle.com/nashorn/entry/nashorn_performance_work_in_the>. Marcus and I have worked on this since October 2013 and it's great that we finally shipped it to you!

* Function.prototype.bind and Function.prototype.call now work on everything Nashorn can call, *including* POJO methods, instances of @FunctionalInterface classes etc. The tests included with the feature can give you some examples of binding and calling these non-JS callables: <http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ad912b034639/test/script/basic/JDK-8051778.js>. It takes a bit of getting used to, but since POJO methods don't have the Function as their prototype, you can't just invoke "somePojoMethod.bind(...)" but must instead use Function.prototype.bind.call(somePojoMethod, this, args). Yep, you're .call()-ing Function.prototypebind, but hey, you knew JS is a functional language, didn't you? (Horrible protip: you can just type Function.bind instead of Function.prototype.bind, since the Function object is itself a function (being a JS class constructor), that is "Function instanceof Function" holds true). What about Function.prototype.apply, you might ask? Well, apply is by its nature a variable-arity invocation. It should work with vararg POJO methods, but only with them. You invoke it as "Function.apply.call(pojoMethod, ...)". In the future, we might figure out a way to use apply with non-vararg POJO methods too, but no promises on that.

* ClassFilter interface enables you to restrict access to specified Java classes from scripts run by a Nashorn script engine; see <https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/api.html#classfilter_introduction> for details.

Of course, these are the larger things. There is an uncounted number of smaller bugfixes and performance improvements as well. This is just a quick mail that I intended to fire off fast (first and foremost to warn you of the regression); if I forgot to mention any of the new features, I'm sure my teammates will follow up.

Thanks,
  Attila.


From attila.szegedi at oracle.com  Wed Mar  4 10:34:38 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 4 Mar 2015 11:34:38 +0100
Subject: Review request for JDK-8035712
Message-ID: <E1CD54C6-081B-41FB-B603-3922B9D5D64F@oracle.com>

Please review JDK-8035712 at <http://cr.openjdk.java.net/~attila/8035712/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8035712>

The JIRA issue has notes on the implementation: <https://bugs.openjdk.java.net/browse/JDK-8035712?focusedCommentId=13615184&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13615184>

Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Wed Mar  4 12:51:16 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 04 Mar 2015 13:51:16 +0100
Subject: Review request for JDK-8035712
In-Reply-To: <E1CD54C6-081B-41FB-B603-3922B9D5D64F@oracle.com>
References: <E1CD54C6-081B-41FB-B603-3922B9D5D64F@oracle.com>
Message-ID: <54F6FFC4.7000205@oracle.com>

+1

Am 2015-03-04 um 11:34 schrieb Attila Szegedi:
> Please review JDK-8035712 at <http://cr.openjdk.java.net/~attila/8035712/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8035712>
>
> The JIRA issue has notes on the implementation: <https://bugs.openjdk.java.net/browse/JDK-8035712?focusedCommentId=13615184&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13615184>
>
> Thanks,
>    Attila.


From marcus.lagergren at oracle.com  Wed Mar  4 16:17:13 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 4 Mar 2015 17:17:13 +0100
Subject: Review request for JDK-8035712
In-Reply-To: <E1CD54C6-081B-41FB-B603-3922B9D5D64F@oracle.com>
References: <E1CD54C6-081B-41FB-B603-3922B9D5D64F@oracle.com>
Message-ID: <44638093-BEE6-4552-8FF4-02506E82B94D@oracle.com>

+1 if you have done the octane regression analysis.

> On 04 Mar 2015, at 11:34, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Please review JDK-8035712 at <http://cr.openjdk.java.net/~attila/8035712/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8035712>
> 
> The JIRA issue has notes on the implementation: <https://bugs.openjdk.java.net/browse/JDK-8035712?focusedCommentId=13615184&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13615184>
> 
> Thanks,
>  Attila.


From marcus.lagergren at oracle.com  Wed Mar  4 16:25:00 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 4 Mar 2015 17:25:00 +0100
Subject: Nashorn in JDK 8u40
In-Reply-To: <E7E4DB55-4859-427E-B9D2-BD1CF5268840@oracle.com>
References: <E7E4DB55-4859-427E-B9D2-BD1CF5268840@oracle.com>
Message-ID: <CBADABD7-ED6E-422B-8CD7-6BD4C51487A1@oracle.com>

Extremely awesome summary, Attila.

We should probably mention the code cache and the optimization cache as well, which can speed up startup for consecutive runs of a large application by serializing code and optimization info to disk:
https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using <https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using>

There is also, embarrassingly enough, a performance regression that Benjamin Winterberg spotted, having to do with operations on exactly one object and one primitive. Some specialization went away while we were implementing the optimistic type system. Luckily, there are multiple simple workarounds. Sorry about that. https://twitter.com/benontherun/status/573061256132886528 <https://twitter.com/benontherun/status/573061256132886528>  - The issue is https://bugs.openjdk.java.net/browse/JDK-8035712

Several more smallish enhancements and regression fixes are targeted for 8u60. We wanted to put more effort on startup and warmup performance for the first run as well, not just by caching code, but the day only has 24 hours, so that will go into the next major release. The good news here is that we seem to have massive performance improvements on this coming along quite nicely.

Regards
Marcus

> On 04 Mar 2015, at 00:20, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Hi folks,
> 
> JDK 8u40 was released today, and I wanted to take a moment to summarize some of the new stuff in Nashorn since 8u25.
> 
> First of all, I want to get the bad news out of the way. There is, unfortunately, a functional regression. It was discovered too late in the development cycle for the fix to make the deadline for 8u40, so we could really do nothing except grit our teeth and accept it'll have to go out like this. Namely, passing of JavaScript arrays to Java methods in the vararg position is broken, for details see <https://bugs.openjdk.java.net/browse/JDK-8072596>. We used to convert the JS array to a Java array of the required type in vararg position, but unfortunately we now convert it to ScriptObjectMirror instead and that causes a ClassCastException (as a ScriptObjectMirror isn't a Java array, obviously). This was not intended and we will revert to the old behavior no later than in the next minor release, 8u60. Temporary workaround (should you choose to upgrade to 8u40) is to use Java.to() explicitly in such situations. I know it's not ideal and it will certainly break someone's existing code; I'm truly sorry about that. Most we can do at the moment is to make you aware of the issue. (The 9 and 8u-dev repositories have a fix, so neither the 9 EA builds nor the shortly coming 8u60 EA builds have the bug.)
> 
> Let's move on to brighter things. Here's some new features and improvements in 8u40:
> 
> * Nashorn compiler has fairly powerful static type inference capabilities for local variables and expressions now. While JavaScript is notoriously hard to analyze statically, we still put in an analyzer that does a fair job of inferring static types and then using them to emit optimized bytecode. The bytecode emitted for e.g. the "crypto" Octane benchmark is now pretty close to the bytecode you'd get if you compiled a Java implementation of those same algorithms. In other words, Nashorn's gotten much better at both number crunching and asm.js-like workloads. The static type inference is always on.
> 
> * Optimistic typing. It actually complements static type inference: what types can't be statically inferred will be speculated upon, from more optimistic (it's an int!) to a less optimistic (it's a floating point number!) to the ultimately not optimistic at all (well, duh, it's an object after all). Nashorn has a full gradual code deoptimization framework, complete with on-stack code replacement built into it now for this purpose. Optimistic typing typically makes the warmup worse, but the warmed-up performance is significantly better, hence it's best for use with long-running applications. It's off by default, you can use the "--optimistic-types=true" command line switch to turn it on. There's a blog post that further elaborates on it: <https://blogs.oracle.com/nashorn/entry/nashorn_performance_work_in_the>. Marcus and I have worked on this since October 2013 and it's great that we finally shipped it to you!
> 
> * Function.prototype.bind and Function.prototype.call now work on everything Nashorn can call, *including* POJO methods, instances of @FunctionalInterface classes etc. The tests included with the feature can give you some examples of binding and calling these non-JS callables: <http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ad912b034639/test/script/basic/JDK-8051778.js>. It takes a bit of getting used to, but since POJO methods don't have the Function as their prototype, you can't just invoke "somePojoMethod.bind(...)" but must instead use Function.prototype.bind.call(somePojoMethod, this, args). Yep, you're .call()-ing Function.prototypebind, but hey, you knew JS is a functional language, didn't you? (Horrible protip: you can just type Function.bind instead of Function.prototype.bind, since the Function object is itself a function (being a JS class constructor), that is "Function instanceof Function" holds true). What about Function.prototype.apply, you might ask? Well, apply is by its nature a variable-arity invocation. It should work with vararg POJO methods, but only with them. You invoke it as "Function.apply.call(pojoMethod, ...)". In the future, we might figure out a way to use apply with non-vararg POJO methods too, but no promises on that.
> 
> * ClassFilter interface enables you to restrict access to specified Java classes from scripts run by a Nashorn script engine; see <https://docs.oracle.com/javase/8/docs/technotes/guides/scripting/nashorn/api.html#classfilter_introduction> for details.
> 
> Of course, these are the larger things. There is an uncounted number of smaller bugfixes and performance improvements as well. This is just a quick mail that I intended to fire off fast (first and foremost to warn you of the regression); if I forgot to mention any of the new features, I'm sure my teammates will follow up.
> 
> Thanks,
>  Attila.
> 


From marc at openendedgroup.com  Wed Mar  4 22:56:09 2015
From: marc at openendedgroup.com (Marc Downie)
Date: Wed, 4 Mar 2015 16:56:09 -0600
Subject: Custom GuardingDynamicLinker implementations post-JEP220
Message-ID: <CAB+dQxrEk_6UP9kqwT8zQPGBCHyLS-kMDzoAevr2CKu-UxxUHQ@mail.gmail.com>

Dear all,

I've been adding my own GuardingDynamicLinker implementation to the linkers
used by Nashorn to modify how Nashorn thinks about about certain classes /
JVM languages. This has been working absolutely splendidly, and the
Dynalink core of Nashorn has been wonderfully useful. In fact all previous
questions I've had on list about how to customize the appearance of Java to
Javascript (to the same extent that I can do with Jython and JRuby) can
really be answered with "write a custom linker".

Currently, I cause Nashorn's call to AutoDiscovery to see my linker
implementation by having it in a .jar with a
META-INF/services/jdk.internal.dynalink.linker.GuardingDynamicLinker entry
and placing that .jar in lib/ext. But with the abandonment of lib/ext in
JEP 220 (now in recent builds of JDK 9) puts me on notice. Nashorn doesn't
see my linker if I place it later in the classloader tree, and my linker
can't see its super-interface (GuardingDynamicLinker) if it's on the
bootclasspath.

I realize that I've committed the sin of writing 'jdk.internal', but
reading the source of Bootstrap and AutoDiscovery the intent is clear: to
allow additional language runtimes to coexist inside the same linker
ecosystem. A design bug?

Any suggestions, example code, or an escape route, welcome.

Marc.

From sundararajan.athijegannathan at oracle.com  Thu Mar  5 04:10:20 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 05 Mar 2015 09:40:20 +0530
Subject: Custom GuardingDynamicLinker implementations post-JEP220
In-Reply-To: <CAB+dQxrEk_6UP9kqwT8zQPGBCHyLS-kMDzoAevr2CKu-UxxUHQ@mail.gmail.com>
References: <CAB+dQxrEk_6UP9kqwT8zQPGBCHyLS-kMDzoAevr2CKu-UxxUHQ@mail.gmail.com>
Message-ID: <54F7D72C.9040306@oracle.com>

Linker auto discovery is a feature inherited from the dynalink project - 
https://github.com/szegedi/dynalink

Nashorn embeds dynalink code after renaming ( jdk.internal.* ) as 
dynalink is an implementation detail. Auto discovery/pluggable linker is 
not enabled for nashorn.  In addition to using an internal 
implementation class - which may be changed without notice - please note 
that your code using jdk.internal.* dynalink class won't run when there 
is security manager present. jdk.internal.* is declared to be security 
sensitive package in the Java platform default security configuration.

Thanks,
-Sundar

Marc Downie wrote:
> Dear all,
>
> I've been adding my own GuardingDynamicLinker implementation to the linkers
> used by Nashorn to modify how Nashorn thinks about about certain classes /
> JVM languages. This has been working absolutely splendidly, and the
> Dynalink core of Nashorn has been wonderfully useful. In fact all previous
> questions I've had on list about how to customize the appearance of Java to
> Javascript (to the same extent that I can do with Jython and JRuby) can
> really be answered with "write a custom linker".
>
> Currently, I cause Nashorn's call to AutoDiscovery to see my linker
> implementation by having it in a .jar with a
> META-INF/services/jdk.internal.dynalink.linker.GuardingDynamicLinker entry
> and placing that .jar in lib/ext. But with the abandonment of lib/ext in
> JEP 220 (now in recent builds of JDK 9) puts me on notice. Nashorn doesn't
> see my linker if I place it later in the classloader tree, and my linker
> can't see its super-interface (GuardingDynamicLinker) if it's on the
> bootclasspath.
>
> I realize that I've committed the sin of writing 'jdk.internal', but
> reading the source of Bootstrap and AutoDiscovery the intent is clear: to
> allow additional language runtimes to coexist inside the same linker
> ecosystem. A design bug?
>
> Any suggestions, example code, or an escape route, welcome.
>
> Marc.
>   


From marc at openendedgroup.com  Thu Mar  5 05:14:18 2015
From: marc at openendedgroup.com (Marc Downie)
Date: Wed, 4 Mar 2015 23:14:18 -0600
Subject: Custom GuardingDynamicLinker implementations post-JEP220
In-Reply-To: <54F7D72C.9040306@oracle.com>
References: <CAB+dQxrEk_6UP9kqwT8zQPGBCHyLS-kMDzoAevr2CKu-UxxUHQ@mail.gmail.com>
	<54F7D72C.9040306@oracle.com>
Message-ID: <CAB+dQxr7p=aDuObWAZYmRiKXnwVrSsrtF9+qy-eJATCFNKo6ZQ@mail.gmail.com>

So, to summarize, the intention is that Nashorn will no longer participate
in a Dynalink powered multi-language interop or linker plugins? How
disappointing!

best,

Marc.

On Wed, Mar 4, 2015 at 10:10 PM, A. Sundararajan <
sundararajan.athijegannathan at oracle.com> wrote:
>
> Linker auto discovery is a feature inherited from the dynalink project -
https://github.com/szegedi/dynalink
>
> Nashorn embeds dynalink code after renaming ( jdk.internal.* ) as
dynalink is an implementation detail. Auto discovery/pluggable linker is
not enabled for nashorn.  In addition to using an internal implementation
class - which may be changed without notice - please note that your code
using jdk.internal.* dynalink class won't run when there is security
manager present. jdk.internal.* is declared to be security sensitive
package in the Java platform default security configuration.
>
> Thanks,
> -Sundar
>
>
> Marc Downie wrote:
>>
>> Dear all,
>>
>> I've been adding my own GuardingDynamicLinker implementation to the
linkers
>> used by Nashorn to modify how Nashorn thinks about about certain classes
/
>> JVM languages. This has been working absolutely splendidly, and the
>> Dynalink core of Nashorn has been wonderfully useful. In fact all
previous
>> questions I've had on list about how to customize the appearance of Java
to
>> Javascript (to the same extent that I can do with Jython and JRuby) can
>> really be answered with "write a custom linker".
>>
>> Currently, I cause Nashorn's call to AutoDiscovery to see my linker
>> implementation by having it in a .jar with a
>> META-INF/services/jdk.internal.dynalink.linker.GuardingDynamicLinker
entry
>> and placing that .jar in lib/ext. But with the abandonment of lib/ext in
>> JEP 220 (now in recent builds of JDK 9) puts me on notice. Nashorn
doesn't
>> see my linker if I place it later in the classloader tree, and my linker
>> can't see its super-interface (GuardingDynamicLinker) if it's on the
>> bootclasspath.
>>
>> I realize that I've committed the sin of writing 'jdk.internal', but
>> reading the source of Bootstrap and AutoDiscovery the intent is clear: to
>> allow additional language runtimes to coexist inside the same linker
>> ecosystem. A design bug?
>>
>> Any suggestions, example code, or an escape route, welcome.
>>
>> Marc.
>>
>
>

From attila.szegedi at oracle.com  Thu Mar  5 10:42:03 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 5 Mar 2015 11:42:03 +0100
Subject: Custom GuardingDynamicLinker implementations post-JEP220
In-Reply-To: <CAB+dQxr7p=aDuObWAZYmRiKXnwVrSsrtF9+qy-eJATCFNKo6ZQ@mail.gmail.com>
References: <CAB+dQxrEk_6UP9kqwT8zQPGBCHyLS-kMDzoAevr2CKu-UxxUHQ@mail.gmail.com>
	<54F7D72C.9040306@oracle.com>
	<CAB+dQxr7p=aDuObWAZYmRiKXnwVrSsrtF9+qy-eJATCFNKo6ZQ@mail.gmail.com>
Message-ID: <2A497FAD-6DB3-42F7-99AA-CF2197A689E4@oracle.com>

Hi,

first of all - thanks for trying out writing your own linker! Each such attempt is a test (and if hopefully successful, then a validation) of Dynalink's architecture, and I'm glad to hear it is working for you.

Dynalink uses the "normal" service loading mechanism through java.util.ServiceLoader.load(), and I have to admit that I have not given a lot of thought to how does this change with the removal of jre/lib/ext. Wouldn't some of the same issues be encountered by other services, e.g. JDBC drivers etc?

That said, I'd intuitively think (forgive me for not stating anything with certainty, I'm just thinking this aloud as this is new to me as well, and I haven't tried any approach myself so far) that placing your linker on the boot class path with -Xbootclasspath/p:<path-to-your-jar> should work. It'd be weird if it didn't see Dynalink classes when it's in the boot class path. Again - how are other JDK elements using ServiceLoader, most notably JDBC supposed to work then?

A long term escape route is to have Dynalink become publicly supported OpenJDK API. That's an effort I should be driving, but it admittedly didn't have chance to bubble up to the top of my task pile for quite long time. I was also admittedly a bit reluctant about it as I wanted to give it more time to solidify; once it's a public API, changing it will become much harder. In any case, I wouldn't expect it to become a public API for Java 9, there simply isn't time enough for that.

For historical perspective, we initially put Dynalink into Nashorn because it seemed like the best solution for a higher-level semantics linking for a dynamic language. (Well, I'm biased as I'm its author, but the rest of the team seems to share the opinion after three years of using it.) Yes, the package-renamed Dynalink retains its (package-renamed) autodiscovery capabilities, but that's mostly incidental :-(

One somewhat unorthodox solution that might work for you depending on your needs would be to isolate Nashorn source code out of OpenJDK, observing its license (GPLv2 with classpath exception). You could take the source of everything under jdk.nashorn.* package, rename them to your own package, change all the references to jdk.internal.dynalink to org.dynalang.dynalink and all references to jdk.internal.org.objectweb.asm to org.objectweb.asm. Then you end up with a JavaScript runtime that's basically Nashorn, but works with the GitHub version of Dynalink (and the OW2 version of ASM). Should be a mechanical transformation, and it'd give you a multi-language interop capable JS engine until such time that I pull myself together and start shepherding the "Dynalink as supported OpenJDK API" JEP. 

Hope some of this helps.

Best Regards,
  Attila.

On Mar 5, 2015, at 6:14 AM, Marc Downie <marc at openendedgroup.com> wrote:

> So, to summarize, the intention is that Nashorn will no longer participate
> in a Dynalink powered multi-language interop or linker plugins? How
> disappointing!
> 
> best,
> 
> Marc.
> 
> On Wed, Mar 4, 2015 at 10:10 PM, A. Sundararajan <
> sundararajan.athijegannathan at oracle.com> wrote:
>> 
>> Linker auto discovery is a feature inherited from the dynalink project -
> https://github.com/szegedi/dynalink
>> 
>> Nashorn embeds dynalink code after renaming ( jdk.internal.* ) as
> dynalink is an implementation detail. Auto discovery/pluggable linker is
> not enabled for nashorn.  In addition to using an internal implementation
> class - which may be changed without notice - please note that your code
> using jdk.internal.* dynalink class won't run when there is security
> manager present. jdk.internal.* is declared to be security sensitive
> package in the Java platform default security configuration.
>> 
>> Thanks,
>> -Sundar
>> 
>> 
>> Marc Downie wrote:
>>> 
>>> Dear all,
>>> 
>>> I've been adding my own GuardingDynamicLinker implementation to the
> linkers
>>> used by Nashorn to modify how Nashorn thinks about about certain classes
> /
>>> JVM languages. This has been working absolutely splendidly, and the
>>> Dynalink core of Nashorn has been wonderfully useful. In fact all
> previous
>>> questions I've had on list about how to customize the appearance of Java
> to
>>> Javascript (to the same extent that I can do with Jython and JRuby) can
>>> really be answered with "write a custom linker".
>>> 
>>> Currently, I cause Nashorn's call to AutoDiscovery to see my linker
>>> implementation by having it in a .jar with a
>>> META-INF/services/jdk.internal.dynalink.linker.GuardingDynamicLinker
> entry
>>> and placing that .jar in lib/ext. But with the abandonment of lib/ext in
>>> JEP 220 (now in recent builds of JDK 9) puts me on notice. Nashorn
> doesn't
>>> see my linker if I place it later in the classloader tree, and my linker
>>> can't see its super-interface (GuardingDynamicLinker) if it's on the
>>> bootclasspath.
>>> 
>>> I realize that I've committed the sin of writing 'jdk.internal', but
>>> reading the source of Bootstrap and AutoDiscovery the intent is clear: to
>>> allow additional language runtimes to coexist inside the same linker
>>> ecosystem. A design bug?
>>> 
>>> Any suggestions, example code, or an escape route, welcome.
>>> 
>>> Marc.
>>> 
>> 
>> 


From attila.szegedi at oracle.com  Thu Mar  5 10:56:30 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 5 Mar 2015 11:56:30 +0100
Subject: Review request for JDK-8035712
In-Reply-To: <44638093-BEE6-4552-8FF4-02506E82B94D@oracle.com>
References: <E1CD54C6-081B-41FB-B603-3922B9D5D64F@oracle.com>
	<44638093-BEE6-4552-8FF4-02506E82B94D@oracle.com>
Message-ID: <AA1C501B-7237-449A-A7E5-DB59375D7048@oracle.com>

Thanks folks. In the meantime (as part of inspecting that regression that Benjamin Winterberg pointed out)I realized that there often seems to be a significant performance difference between loading an operand as Object and converting to double, and loading it as double (when we're allowed to reorder converts and loads). That is, an "i < size" (where size is in scope and i is double) can be emitted as:

  dload 5 // i
  aload 2 // scope
  invokedynamic dyn:getProp|getElem|getMethod:size(Object;)D // size
  dcmpg

instead of 

  dload 5
  aload 2
  invokedynamic dyn:getProp|getElem|getMethod:size(Object;)Object
  invokestatic JSType.toNumber(Object)
  dcmpg

The first one is actually faster, especially when size is already a number due to dual fields (it was just unprovable statically). For this, I uploaded a small differential patch between what you already reviewed and the new modification. Please review this as well <http://cr.openjdk.java.net/~attila/8035712/webrev.01/>

Thanks,
  Attila.

On Mar 4, 2015, at 5:17 PM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:

> +1 if you have done the octane regression analysis.
> 
>> On 04 Mar 2015, at 11:34, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>> 
>> Please review JDK-8035712 at <http://cr.openjdk.java.net/~attila/8035712/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8035712>
>> 
>> The JIRA issue has notes on the implementation: <https://bugs.openjdk.java.net/browse/JDK-8035712?focusedCommentId=13615184&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13615184>
>> 
>> Thanks,
>> Attila.
> 


From hannes.wallnoefer at oracle.com  Thu Mar  5 11:14:18 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 05 Mar 2015 12:14:18 +0100
Subject: Review request for JDK-8035712
In-Reply-To: <AA1C501B-7237-449A-A7E5-DB59375D7048@oracle.com>
References: <E1CD54C6-081B-41FB-B603-3922B9D5D64F@oracle.com>	<44638093-BEE6-4552-8FF4-02506E82B94D@oracle.com>
	<AA1C501B-7237-449A-A7E5-DB59375D7048@oracle.com>
Message-ID: <54F83A8A.4030007@oracle.com>

+1

Great attention to detail!

Am 2015-03-05 um 11:56 schrieb Attila Szegedi:
> Thanks folks. In the meantime (as part of inspecting that regression that Benjamin Winterberg pointed out)I realized that there often seems to be a significant performance difference between loading an operand as Object and converting to double, and loading it as double (when we're allowed to reorder converts and loads). That is, an "i < size" (where size is in scope and i is double) can be emitted as:
>
>    dload 5 // i
>    aload 2 // scope
>    invokedynamic dyn:getProp|getElem|getMethod:size(Object;)D // size
>    dcmpg
>
> instead of
>
>    dload 5
>    aload 2
>    invokedynamic dyn:getProp|getElem|getMethod:size(Object;)Object
>    invokestatic JSType.toNumber(Object)
>    dcmpg
>
> The first one is actually faster, especially when size is already a number due to dual fields (it was just unprovable statically). For this, I uploaded a small differential patch between what you already reviewed and the new modification. Please review this as well <http://cr.openjdk.java.net/~attila/8035712/webrev.01/>
>
> Thanks,
>    Attila.
>
> On Mar 4, 2015, at 5:17 PM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:
>
>> +1 if you have done the octane regression analysis.
>>
>>> On 04 Mar 2015, at 11:34, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>>
>>> Please review JDK-8035712 at <http://cr.openjdk.java.net/~attila/8035712/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8035712>
>>>
>>> The JIRA issue has notes on the implementation: <https://bugs.openjdk.java.net/browse/JDK-8035712?focusedCommentId=13615184&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13615184>
>>>
>>> Thanks,
>>> Attila.


From marc at openendedgroup.com  Thu Mar  5 13:18:17 2015
From: marc at openendedgroup.com (Marc Downie)
Date: Thu, 5 Mar 2015 07:18:17 -0600
Subject: Custom GuardingDynamicLinker implementations post-JEP220
In-Reply-To: <2A497FAD-6DB3-42F7-99AA-CF2197A689E4@oracle.com>
References: <CAB+dQxrEk_6UP9kqwT8zQPGBCHyLS-kMDzoAevr2CKu-UxxUHQ@mail.gmail.com>
	<54F7D72C.9040306@oracle.com>
	<CAB+dQxr7p=aDuObWAZYmRiKXnwVrSsrtF9+qy-eJATCFNKo6ZQ@mail.gmail.com>
	<2A497FAD-6DB3-42F7-99AA-CF2197A689E4@oracle.com>
Message-ID: <CAB+dQxq15VFSERvs=m8u-iccOY=7+d28CWTMU7dyGCJ0TNF-_Q@mail.gmail.com>

Attila,

1. Many thanks for your constructive email.

2. To my eyes Dynalink, or at least something a lot like it, is an
important part of the future of the JVM --- make it a JEP ! The alternative
? an ecosystem of dynamic languages using Dynalink that don't interop with
Nashorn, also using Dynalink, is daft.

3. Your intuition is correct --- this is important enough to me that I'll
be, reluctantly, building and "shipping" my own Nashorn.

4. bootclasspath/a or /p on 8 doesn't work right now because nashorn.jar is
itself a lib/ext (and bootclasspath is before lib/ext). Bootstrap's static
initializer says:

// Linkers for any additional language runtimes deployed alongside
Nashorn will be picked up by the factory.

factory.setClassLoader(Bootstrap.class.getClassLoader())

which resolves to the Extension classloader in 8 (and thus allows linkers
in lib/ext) and the system ClassLoader in 9 (and thus allows nothing of the
sort). Obviously my "pull request" for this would be to wrap that line in
an Option that can switch to using the ThreadContext ClassLoader instead
(which is the default behavior). Otherwise, you should probably modify that
suggestive comment, since in post JEP 220 there doesn't seem to be an
"alongside" to deploy language runtimes to.

many thanks,

Marc.



On Thu, Mar 5, 2015 at 4:42 AM, Attila Szegedi <attila.szegedi at oracle.com>
wrote:

> Hi,
>
> first of all - thanks for trying out writing your own linker! Each such
> attempt is a test (and if hopefully successful, then a validation) of
> Dynalink's architecture, and I'm glad to hear it is working for you.
>
> Dynalink uses the "normal" service loading mechanism through
> java.util.ServiceLoader.load(), and I have to admit that I have not given a
> lot of thought to how does this change with the removal of jre/lib/ext.
> Wouldn't some of the same issues be encountered by other services, e.g.
> JDBC drivers etc?
>
> That said, I'd intuitively think (forgive me for not stating anything with
> certainty, I'm just thinking this aloud as this is new to me as well, and I
> haven't tried any approach myself so far) that placing your linker on the
> boot class path with -Xbootclasspath/p:<path-to-your-jar> should work. It'd
> be weird if it didn't see Dynalink classes when it's in the boot class
> path. Again - how are other JDK elements using ServiceLoader, most notably
> JDBC supposed to work then?
>
> A long term escape route is to have Dynalink become publicly supported
> OpenJDK API. That's an effort I should be driving, but it admittedly didn't
> have chance to bubble up to the top of my task pile for quite long time. I
> was also admittedly a bit reluctant about it as I wanted to give it more
> time to solidify; once it's a public API, changing it will become much
> harder. In any case, I wouldn't expect it to become a public API for Java
> 9, there simply isn't time enough for that.
>
> For historical perspective, we initially put Dynalink into Nashorn because
> it seemed like the best solution for a higher-level semantics linking for a
> dynamic language. (Well, I'm biased as I'm its author, but the rest of the
> team seems to share the opinion after three years of using it.) Yes, the
> package-renamed Dynalink retains its (package-renamed) autodiscovery
> capabilities, but that's mostly incidental :-(
>
> One somewhat unorthodox solution that might work for you depending on your
> needs would be to isolate Nashorn source code out of OpenJDK, observing its
> license (GPLv2 with classpath exception). You could take the source of
> everything under jdk.nashorn.* package, rename them to your own package,
> change all the references to jdk.internal.dynalink to org.dynalang.dynalink
> and all references to jdk.internal.org.objectweb.asm to org.objectweb.asm.
> Then you end up with a JavaScript runtime that's basically Nashorn, but
> works with the GitHub version of Dynalink (and the OW2 version of ASM).
> Should be a mechanical transformation, and it'd give you a multi-language
> interop capable JS engine until such time that I pull myself together and
> start shepherding the "Dynalink as supported OpenJDK API" JEP.
>
> Hope some of this helps.
>
> Best Regards,
>   Attila.
>
> On Mar 5, 2015, at 6:14 AM, Marc Downie <marc at openendedgroup.com> wrote:
>
> > So, to summarize, the intention is that Nashorn will no longer
> participate
> > in a Dynalink powered multi-language interop or linker plugins? How
> > disappointing!
> >
> > best,
> >
> > Marc.
> >
> > On Wed, Mar 4, 2015 at 10:10 PM, A. Sundararajan <
> > sundararajan.athijegannathan at oracle.com> wrote:
> >>
> >> Linker auto discovery is a feature inherited from the dynalink project -
> > https://github.com/szegedi/dynalink
> >>
> >> Nashorn embeds dynalink code after renaming ( jdk.internal.* ) as
> > dynalink is an implementation detail. Auto discovery/pluggable linker is
> > not enabled for nashorn.  In addition to using an internal implementation
> > class - which may be changed without notice - please note that your code
> > using jdk.internal.* dynalink class won't run when there is security
> > manager present. jdk.internal.* is declared to be security sensitive
> > package in the Java platform default security configuration.
> >>
> >> Thanks,
> >> -Sundar
> >>
> >>
> >> Marc Downie wrote:
> >>>
> >>> Dear all,
> >>>
> >>> I've been adding my own GuardingDynamicLinker implementation to the
> > linkers
> >>> used by Nashorn to modify how Nashorn thinks about about certain
> classes
> > /
> >>> JVM languages. This has been working absolutely splendidly, and the
> >>> Dynalink core of Nashorn has been wonderfully useful. In fact all
> > previous
> >>> questions I've had on list about how to customize the appearance of
> Java
> > to
> >>> Javascript (to the same extent that I can do with Jython and JRuby) can
> >>> really be answered with "write a custom linker".
> >>>
> >>> Currently, I cause Nashorn's call to AutoDiscovery to see my linker
> >>> implementation by having it in a .jar with a
> >>> META-INF/services/jdk.internal.dynalink.linker.GuardingDynamicLinker
> > entry
> >>> and placing that .jar in lib/ext. But with the abandonment of lib/ext
> in
> >>> JEP 220 (now in recent builds of JDK 9) puts me on notice. Nashorn
> > doesn't
> >>> see my linker if I place it later in the classloader tree, and my
> linker
> >>> can't see its super-interface (GuardingDynamicLinker) if it's on the
> >>> bootclasspath.
> >>>
> >>> I realize that I've committed the sin of writing 'jdk.internal', but
> >>> reading the source of Bootstrap and AutoDiscovery the intent is clear:
> to
> >>> allow additional language runtimes to coexist inside the same linker
> >>> ecosystem. A design bug?
> >>>
> >>> Any suggestions, example code, or an escape route, welcome.
> >>>
> >>> Marc.
> >>>
> >>
> >>
>
>

From attila.szegedi at oracle.com  Thu Mar  5 13:37:17 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 5 Mar 2015 14:37:17 +0100
Subject: Custom GuardingDynamicLinker implementations post-JEP220
In-Reply-To: <CAB+dQxq15VFSERvs=m8u-iccOY=7+d28CWTMU7dyGCJ0TNF-_Q@mail.gmail.com>
References: <CAB+dQxrEk_6UP9kqwT8zQPGBCHyLS-kMDzoAevr2CKu-UxxUHQ@mail.gmail.com>
	<54F7D72C.9040306@oracle.com>
	<CAB+dQxr7p=aDuObWAZYmRiKXnwVrSsrtF9+qy-eJATCFNKo6ZQ@mail.gmail.com>
	<2A497FAD-6DB3-42F7-99AA-CF2197A689E4@oracle.com>
	<CAB+dQxq15VFSERvs=m8u-iccOY=7+d28CWTMU7dyGCJ0TNF-_Q@mail.gmail.com>
Message-ID: <58459200-23CF-4A47-870B-7FB8EB9AD4F3@oracle.com>

On Mar 5, 2015, at 2:18 PM, Marc Downie <marc at openendedgroup.com> wrote:

> 
> Attila,
> 
> 1. Many thanks for your constructive email.

I appreciate the appreciation :-)

> 
> 2. To my eyes Dynalink, or at least something a lot like it, is an important part of the future of the JVM --- make it a JEP ! The alternative ? an ecosystem of dynamic languages using Dynalink that don't interop with Nashorn, also using Dynalink, is daft. 
> 
> 3. Your intuition is correct --- this is important enough to me that I'll be, reluctantly, building and "shipping" my own Nashorn.

Well, it isn't that horrible idea. If you get stuck, let me know. I know for fact that it is possible as I did it in the past internally ? back before Java 8 was released, as a means to test Nashorn with Java 7 (something that made sense at the time). Nashorn codebase now has some 8-isms (spurious uses of java.util.function) so targeting 7 is no longer possible, but if you deploy on either 8 or 9, you should be okay.

> 
> 4. bootclasspath/a or /p on 8 doesn't work right now because nashorn.jar is itself a lib/ext (and bootclasspath is before lib/ext). Bootstrap's static initializer says:
> 
> // Linkers for any additional language runtimes deployed alongside Nashorn will be picked up by the factory.
> factory.setClassLoader(Bootstrap.class.getClassLoader())
> 
> which resolves to the Extension classloader in 8 (and thus allows linkers in lib/ext) and the system ClassLoader in 9 (and thus allows nothing of the sort). Obviously my "pull request" for this would be to wrap that line in an Option that can switch to using the ThreadContext ClassLoader instead (which is the default behavior). Otherwise, you should probably modify that suggestive comment, since in post JEP 220 there doesn't seem to be an "alongside" to deploy language runtimes to.

Yeah, that comment is no longer valid in its current form. We discussed this with Sundar after I sent the previous e-mail. I even pointed out that exact same line of code to him :-) I think the best solution would be to have one DynamicLinker per jdk.nashorn.internal.runtime.Context object, and set Context.appLoader as the class loader for the linker factory; Context.appLoader is equivalent to the thread context class loader at the time ScriptEngineFactory.getScriptEngine() was invoked. Of course, this indeed would require me to go through with the JEP first, as Java 9 will still prevent your code from seeing jdk.internal.* stuff?

Best Regards,
  Attila.

> 
> many thanks,
> 
> Marc.
> 
> 
> 
> On Thu, Mar 5, 2015 at 4:42 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> Hi,
> 
> first of all - thanks for trying out writing your own linker! Each such attempt is a test (and if hopefully successful, then a validation) of Dynalink's architecture, and I'm glad to hear it is working for you.
> 
> Dynalink uses the "normal" service loading mechanism through java.util.ServiceLoader.load(), and I have to admit that I have not given a lot of thought to how does this change with the removal of jre/lib/ext. Wouldn't some of the same issues be encountered by other services, e.g. JDBC drivers etc?
> 
> That said, I'd intuitively think (forgive me for not stating anything with certainty, I'm just thinking this aloud as this is new to me as well, and I haven't tried any approach myself so far) that placing your linker on the boot class path with -Xbootclasspath/p:<path-to-your-jar> should work. It'd be weird if it didn't see Dynalink classes when it's in the boot class path. Again - how are other JDK elements using ServiceLoader, most notably JDBC supposed to work then?
> 
> A long term escape route is to have Dynalink become publicly supported OpenJDK API. That's an effort I should be driving, but it admittedly didn't have chance to bubble up to the top of my task pile for quite long time. I was also admittedly a bit reluctant about it as I wanted to give it more time to solidify; once it's a public API, changing it will become much harder. In any case, I wouldn't expect it to become a public API for Java 9, there simply isn't time enough for that.
> 
> For historical perspective, we initially put Dynalink into Nashorn because it seemed like the best solution for a higher-level semantics linking for a dynamic language. (Well, I'm biased as I'm its author, but the rest of the team seems to share the opinion after three years of using it.) Yes, the package-renamed Dynalink retains its (package-renamed) autodiscovery capabilities, but that's mostly incidental :-(
> 
> One somewhat unorthodox solution that might work for you depending on your needs would be to isolate Nashorn source code out of OpenJDK, observing its license (GPLv2 with classpath exception). You could take the source of everything under jdk.nashorn.* package, rename them to your own package, change all the references to jdk.internal.dynalink to org.dynalang.dynalink and all references to jdk.internal.org.objectweb.asm to org.objectweb.asm. Then you end up with a JavaScript runtime that's basically Nashorn, but works with the GitHub version of Dynalink (and the OW2 version of ASM). Should be a mechanical transformation, and it'd give you a multi-language interop capable JS engine until such time that I pull myself together and start shepherding the "Dynalink as supported OpenJDK API" JEP.
> 
> Hope some of this helps.
> 
> Best Regards,
>   Attila.
> 
> On Mar 5, 2015, at 6:14 AM, Marc Downie <marc at openendedgroup.com> wrote:
> 
> > So, to summarize, the intention is that Nashorn will no longer participate
> > in a Dynalink powered multi-language interop or linker plugins? How
> > disappointing!
> >
> > best,
> >
> > Marc.
> >
> > On Wed, Mar 4, 2015 at 10:10 PM, A. Sundararajan <
> > sundararajan.athijegannathan at oracle.com> wrote:
> >>
> >> Linker auto discovery is a feature inherited from the dynalink project -
> > https://github.com/szegedi/dynalink
> >>
> >> Nashorn embeds dynalink code after renaming ( jdk.internal.* ) as
> > dynalink is an implementation detail. Auto discovery/pluggable linker is
> > not enabled for nashorn.  In addition to using an internal implementation
> > class - which may be changed without notice - please note that your code
> > using jdk.internal.* dynalink class won't run when there is security
> > manager present. jdk.internal.* is declared to be security sensitive
> > package in the Java platform default security configuration.
> >>
> >> Thanks,
> >> -Sundar
> >>
> >>
> >> Marc Downie wrote:
> >>>
> >>> Dear all,
> >>>
> >>> I've been adding my own GuardingDynamicLinker implementation to the
> > linkers
> >>> used by Nashorn to modify how Nashorn thinks about about certain classes
> > /
> >>> JVM languages. This has been working absolutely splendidly, and the
> >>> Dynalink core of Nashorn has been wonderfully useful. In fact all
> > previous
> >>> questions I've had on list about how to customize the appearance of Java
> > to
> >>> Javascript (to the same extent that I can do with Jython and JRuby) can
> >>> really be answered with "write a custom linker".
> >>>
> >>> Currently, I cause Nashorn's call to AutoDiscovery to see my linker
> >>> implementation by having it in a .jar with a
> >>> META-INF/services/jdk.internal.dynalink.linker.GuardingDynamicLinker
> > entry
> >>> and placing that .jar in lib/ext. But with the abandonment of lib/ext in
> >>> JEP 220 (now in recent builds of JDK 9) puts me on notice. Nashorn
> > doesn't
> >>> see my linker if I place it later in the classloader tree, and my linker
> >>> can't see its super-interface (GuardingDynamicLinker) if it's on the
> >>> bootclasspath.
> >>>
> >>> I realize that I've committed the sin of writing 'jdk.internal', but
> >>> reading the source of Bootstrap and AutoDiscovery the intent is clear: to
> >>> allow additional language runtimes to coexist inside the same linker
> >>> ecosystem. A design bug?
> >>>
> >>> Any suggestions, example code, or an escape route, welcome.
> >>>
> >>> Marc.
> >>>
> >>
> >>
> 
> 


From attila.szegedi at oracle.com  Thu Mar  5 14:45:26 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 5 Mar 2015 15:45:26 +0100
Subject: Review request for JDK-8074491
Message-ID: <1511D1C6-F7BB-46D9-99C4-99DDEEFCAB34@oracle.com>

Please review JDK-8074491 at <http://cr.openjdk.java.net/~attila/8074491/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8074491>

Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Thu Mar  5 15:06:50 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 05 Mar 2015 16:06:50 +0100
Subject: Review request for JDK-8074491
In-Reply-To: <1511D1C6-F7BB-46D9-99C4-99DDEEFCAB34@oracle.com>
References: <1511D1C6-F7BB-46D9-99C4-99DDEEFCAB34@oracle.com>
Message-ID: <54F8710A.5070006@oracle.com>

+1

Am 2015-03-05 um 15:45 schrieb Attila Szegedi:
> Please review JDK-8074491 at <http://cr.openjdk.java.net/~attila/8074491/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8074491>
>
> Thanks,
>    Attila.


From attila.szegedi at oracle.com  Thu Mar  5 16:23:53 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 5 Mar 2015 17:23:53 +0100
Subject: Review request for JDK-8074487
Message-ID: <3FA7B9FA-29C1-42C3-919F-6496E212AF26@oracle.com>

Please review JDK-8074487 at <http://cr.openjdk.java.net/~attila/8074487/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8074487>

Thanks,
  Attila.

From marcus.lagergren at oracle.com  Fri Mar  6 07:35:47 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Fri, 6 Mar 2015 08:35:47 +0100
Subject: Review request for JDK-8074491
In-Reply-To: <1511D1C6-F7BB-46D9-99C4-99DDEEFCAB34@oracle.com>
References: <1511D1C6-F7BB-46D9-99C4-99DDEEFCAB34@oracle.com>
Message-ID: <5C3C7BB5-C465-40EE-8E2C-AD086C51A4FF@oracle.com>

+1

> On 05 Mar 2015, at 15:45, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Please review JDK-8074491 at <http://cr.openjdk.java.net/~attila/8074491/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8074491>
> 
> Thanks,
>  Attila.


From marcus.lagergren at oracle.com  Fri Mar  6 07:49:01 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Fri, 6 Mar 2015 08:49:01 +0100
Subject: Review request for JDK-8035712
In-Reply-To: <AA1C501B-7237-449A-A7E5-DB59375D7048@oracle.com>
References: <E1CD54C6-081B-41FB-B603-3922B9D5D64F@oracle.com>
	<44638093-BEE6-4552-8FF4-02506E82B94D@oracle.com>
	<AA1C501B-7237-449A-A7E5-DB59375D7048@oracle.com>
Message-ID: <6AE35463-40F9-4B50-A43A-A1859762727B@oracle.com>

+1

> On 05 Mar 2015, at 11:56, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Thanks folks. In the meantime (as part of inspecting that regression that Benjamin Winterberg pointed out)I realized that there often seems to be a significant performance difference between loading an operand as Object and converting to double, and loading it as double (when we're allowed to reorder converts and loads). That is, an "i < size" (where size is in scope and i is double) can be emitted as:
> 
>  dload 5 // i
>  aload 2 // scope
>  invokedynamic dyn:getProp|getElem|getMethod:size(Object;)D // size
>  dcmpg
> 
> instead of 
> 
>  dload 5
>  aload 2
>  invokedynamic dyn:getProp|getElem|getMethod:size(Object;)Object
>  invokestatic JSType.toNumber(Object)
>  dcmpg
> 
> The first one is actually faster, especially when size is already a number due to dual fields (it was just unprovable statically). For this, I uploaded a small differential patch between what you already reviewed and the new modification. Please review this as well <http://cr.openjdk.java.net/~attila/8035712/webrev.01/>
> 
> Thanks,
>  Attila.
> 
> On Mar 4, 2015, at 5:17 PM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:
> 
>> +1 if you have done the octane regression analysis.
>> 
>>> On 04 Mar 2015, at 11:34, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>> 
>>> Please review JDK-8035712 at <http://cr.openjdk.java.net/~attila/8035712/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8035712>
>>> 
>>> The JIRA issue has notes on the implementation: <https://bugs.openjdk.java.net/browse/JDK-8035712?focusedCommentId=13615184&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13615184>
>>> 
>>> Thanks,
>>> Attila.
>> 
> 


From hannes.wallnoefer at oracle.com  Fri Mar  6 09:12:36 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 06 Mar 2015 10:12:36 +0100
Subject: Review request for JDK-8074487
In-Reply-To: <3FA7B9FA-29C1-42C3-919F-6496E212AF26@oracle.com>
References: <3FA7B9FA-29C1-42C3-919F-6496E212AF26@oracle.com>
Message-ID: <54F96F84.6000102@oracle.com>

+1

Am 2015-03-05 um 17:23 schrieb Attila Szegedi:
> Please review JDK-8074487 at <http://cr.openjdk.java.net/~attila/8074487/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8074487>
>
> Thanks,
>    Attila.


From attila.szegedi at oracle.com  Fri Mar  6 12:23:30 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 6 Mar 2015 13:23:30 +0100
Subject: Review request for JDK-8074484
Message-ID: <B874F7CD-1293-425F-B30C-6A958974E20F@oracle.com>

Please review JDK-8074484 at <http://cr.openjdk.java.net/~attila/8074484/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8074484>

Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Fri Mar  6 14:12:55 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 06 Mar 2015 15:12:55 +0100
Subject: Review request for JDK-8074545: Undefined object values in object
	literals with spill properties
Message-ID: <54F9B5E7.80903@oracle.com>

Please review JDK-8074545: Undefined object values in object literals 
with spill properties:

http://cr.openjdk.java.net/~hannesw/8074545/

Thanks,
Hannes

From attila.szegedi at oracle.com  Fri Mar  6 14:20:46 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 6 Mar 2015 15:20:46 +0100
Subject: Review request for JDK-8074545: Undefined object values in object
	literals with spill properties
In-Reply-To: <54F9B5E7.80903@oracle.com>
References: <54F9B5E7.80903@oracle.com>
Message-ID: <EBE1DA07-39FE-45C1-8E2A-6F6EBF73522F@oracle.com>

Minor thing: newProperty is now a dead variable in JSONParser.addObjectProperty; it can be removed.

+1 otherwise.

On Mar 6, 2015, at 3:12 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8074545: Undefined object values in object literals with spill properties:
> 
> http://cr.openjdk.java.net/~hannesw/8074545/
> 
> Thanks,
> Hannes


From hannes.wallnoefer at oracle.com  Fri Mar  6 14:50:17 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 06 Mar 2015 15:50:17 +0100
Subject: Review request for JDK-8074556: Functions should not share allocator
	maps
Message-ID: <54F9BEA9.7060004@oracle.com>

Please review JDK-8074556: Functions should not share allocator maps:

http://cr.openjdk.java.net/~hannesw/8074556/

Thanks,
Hannes

From kajmagnus79 at gmail.com  Sun Mar  8 05:20:34 2015
From: kajmagnus79 at gmail.com (Kaj Magnus Lindberg)
Date: Sun, 8 Mar 2015 06:20:34 +0100
Subject: Nashorn bug in Java 8 u40: Cannot parse JSON: { 0: null, 100: null }
Message-ID: <CAKb=CAqxJMGm5m6E0SiN64k5SLO==breiOPPCtQtS2Ek32YZzQ@mail.gmail.com>

Hi dear Nashorn developers,

There's an ArrayIndexOutOfBoundsException bug when I try to parse this
JSON: '{ "0":null, "100": null }'.

Have a look here:

jjs> JSON.parse('{ "0":null, "65503": null }')
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 65503
jjs>
jjs> JSON.parse('{ "0":null, "100": null }')
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 100
jjs>
jjs> JSON.parse('{ "0":null, "65": null }')
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 65
jjs>
jjs> JSON.parse('{ "0":null, "64": null }')  // Works
[object Object]
jjs>
jjs> JSON.parse('{ "_0":null, "_100": null }')  // Works
[object Object]
jjs>
jjs>

I found a bug report that was fixed that made { 0: null, 64: null } work.
But as you can see above, { 0: null, 65: null } doesn't work.
  https://bugs.openjdk.java.net/browse/JDK-8048718

Version details:

$ java -version
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

$ uname -a
Linux kajmagnus-lt-15 3.19.0-031900-generic #201502091451 SMP Mon Feb 9
14:52:52 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/issue
Linux Mint 17.1 Rebecca \n \l

(This bug wasn't present in an earlier Nashorn version, u20 or u22 or
something like that.)

Best regards,
KajMagnus

From marcus.lagergren at oracle.com  Sun Mar  8 09:28:17 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Sun, 8 Mar 2015 10:28:17 +0100
Subject: Review request for JDK-8074556: Functions should not share
	allocator maps
In-Reply-To: <54F9BEA9.7060004@oracle.com>
References: <54F9BEA9.7060004@oracle.com>
Message-ID: <48407D35-A669-40B8-A2B7-81E41445BF35@oracle.com>

+1

> On 06 Mar 2015, at 15:50, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review JDK-8074556: Functions should not share allocator maps:
> 
> http://cr.openjdk.java.net/~hannesw/8074556/
> 
> Thanks,
> Hannes


From marcus.lagergren at oracle.com  Sun Mar  8 09:28:23 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Sun, 8 Mar 2015 10:28:23 +0100
Subject: Review request for JDK-8074545: Undefined object values in object
	literals with spill properties
In-Reply-To: <54F9B5E7.80903@oracle.com>
References: <54F9B5E7.80903@oracle.com>
Message-ID: <B2C8DCEC-BFB1-41D5-9884-3855BE61D091@oracle.com>

+1

> On 06 Mar 2015, at 15:12, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review JDK-8074545: Undefined object values in object literals with spill properties:
> 
> http://cr.openjdk.java.net/~hannesw/8074545/
> 
> Thanks,
> Hannes


From marcus.lagergren at oracle.com  Sun Mar  8 09:28:28 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Sun, 8 Mar 2015 10:28:28 +0100
Subject: Review request for JDK-8074484
In-Reply-To: <B874F7CD-1293-425F-B30C-6A958974E20F@oracle.com>
References: <B874F7CD-1293-425F-B30C-6A958974E20F@oracle.com>
Message-ID: <1F4E000B-1947-4555-8C3C-635B999E757C@oracle.com>

+1

> On 06 Mar 2015, at 13:23, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Please review JDK-8074484 at <http://cr.openjdk.java.net/~attila/8074484/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8074484>
> 
> Thanks,
>  Attila.


From marcus.lagergren at oracle.com  Sun Mar  8 09:50:32 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Sun, 8 Mar 2015 10:50:32 +0100
Subject: Review request for JDK-8074487
In-Reply-To: <3FA7B9FA-29C1-42C3-919F-6496E212AF26@oracle.com>
References: <3FA7B9FA-29C1-42C3-919F-6496E212AF26@oracle.com>
Message-ID: <B4FCC74C-E276-4356-8662-40C127FA6B1C@oracle.com>

+1

> On 05 Mar 2015, at 17:23, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Please review JDK-8074487 at <http://cr.openjdk.java.net/~attila/8074487/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8074487>
> 
> Thanks,
>  Attila.


From attila.szegedi at oracle.com  Sun Mar  8 13:29:32 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Sun, 8 Mar 2015 14:29:32 +0100
Subject: Review request for JDK-8072426
In-Reply-To: <54E6F4C5.1090402@oracle.com>
References: <A5E06E32-726E-4080-A8CB-696FC191CFD1@oracle.com>
	<54E6F4C5.1090402@oracle.com>
Message-ID: <03102C38-0B8D-49DC-96A8-E1286675D6D6@oracle.com>

Thanks for the reviews. In order to backport this to 8u-dev, I had to make some changes. Namely, since we introduced a default method into the JSObject interface, we could not compile this under jdk8u-dev, as for JDK 8 Nashorn is compiled with "-source 7" as the part of the build process is running Nasgen, which is done with the boot JDK, which is a JDK 7 for 8u[*].

For this reason, the 8u backport doesn't add a new getDefaultValue() method to the JSObject interface, as that ? without the default methods' ability ? wouldn't be a binary compatible class change. Instead, AbstractJSObject gains a getDefaultValue(hint) method with the same behavior as well as a static helper getDefaultValue(jsobj, hint) that delegates to AbstractJSObject.getDefaultValue() for AbstractJSObject, and runs the generic algorithm for any other JSObject. (As a separate task, we'll need to forward-port this static helper into JDK 9 codebase so it stays compatible with 8; I'll soon file a JIRA for that.)

With these in mind, please review the backport changeset at <http://cr.openjdk.java.net/~attila/8072426/webrev.8u>

Thanks,
  Attila.

--
[*] This raises an interesting further issue, namely that this somewhat peculiar dependency disallows use of any Java 8 syntactic construct in Nashorn code destined for 8. Long term, it'd be great if we could either get 8u to use the previous 8 release as its boot JDK, or if we could rewrite Nasgen so that it reads Nashorn .class files, but doesn't load them into the JVM.

On Feb 20, 2015, at 9:48 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> +1
> 
> Nice work!
> 
> Am 2015-02-19 um 18:48 schrieb Attila Szegedi:
>> Please review JDK-8072426 at <http://cr.openjdk.java.net/~attila/8072426/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8072426>
>> 
>> This is what basically became an epic yak shaving exercise after we determined that POJOs aren't subjected to ToPrimitive (earlier known as java.math.RoundingMode.UP != "UP" problem). While we originally advocated for throwing TypeError for POJOs [[DefaultValue]] that would've prevented their implicit toString() in string concatenation too. Instead, I opted to fix this once and forever but it turned out that the biggest issue with it is the fact that JSObject was also not handled correctly for ToPrimitive; fixing that turned out to be the most challenging part, introducing a new JSObject.getDefaultValue() method and deprecating JSObject.toNumber() (which isn't used anymore at all).
>> 
>> As an unexpected boon, JSObjectLinker no longer needs to do any conversions, so its GuardingTypeConverterFactory functionality has been entirely removed. NashornPrimitiveLinker will now automatically take care of converting JSObject instances to various primitive types, as per specification behavior.
>> 
>> Finally, the ScriptRuntime changes to the equals() and equalDifferentType() are purely refactoring of some common type testing subexpressions and conversions, as well as short-circuiting of some comparisons. They aren't strictly necessary for this issue, but just for clear understanding of what's happening it seemed like a good idea to make them more concise (ScriptRuntime.EQ and .NE, of which the two affected methods are sub-parts are also not invoked terribly often, and I'll soon make them be invoked even less frequently.)
>> 
>> Thanks,
>>   Attila.
> 


From tal.liron at threecrickets.com  Sun Mar  8 13:55:36 2015
From: tal.liron at threecrickets.com (Tal Liron)
Date: Sun, 08 Mar 2015 08:55:36 -0500
Subject: Serious bug: "finally" block is run whenever "continue" is reached
Message-ID: <54FC54D8.2010302@threecrickets.com>

This was very hard to discover, but it is real and easy to reproduce. 
Try running this program:

var finalies = 1
var line = 'TEST THIS LINE'
try {
  while ('' !== (line = line.substring(0, line.length - 1))) {
   if (line.length % 2 == 0) {
    continue
   }
   java.lang.System.out.println(line)
  }
}
catch (x) {
   java.lang.System.out.println(x)
}
finally {
  java.lang.System.out.println('Finalies ' + (finalies++))
}

If you run this code, you'll see that the "finally" block is run every 
time "continue" is reached, and then the while loop continues after the 
"finally" block is run. Of course, the "finally" block should only be 
called once in this example, and the while loop should not continue, and 
this broken behavior can lead to serious problems.

(I added the "catch" block only to make sure that exceptions are not 
thrown, and indeed they are not. Sorry about the silly functionality of 
the program, but it's the result of trying to wrap my head around what 
was going on...)

Or maybe I'm crazy and am missing something trivial? The same code runs 
in Rhino without this problem.

The bug appears in the 8u40 release. :(

-Tal

From anthony.vanelverdinghe at gmail.com  Sun Mar  8 14:22:15 2015
From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe)
Date: Sun, 08 Mar 2015 15:22:15 +0100
Subject: Serious bug: "finally" block is run whenever "continue" is reached
In-Reply-To: <54FC54D8.2010302@threecrickets.com>
References: <54FC54D8.2010302@threecrickets.com>
Message-ID: <54FC5B17.3000404@gmail.com>

Hi Tal

This might already have been solved in 9, and backported to 8u60, with 
bug JDK-8067139 [1]: Finally blocks inlined incorrectly

Kind regards,
Anthony

[1] https://bugs.openjdk.java.net/browse/JDK-8067139


On 8/03/2015 14:55, Tal Liron wrote:
> This was very hard to discover, but it is real and easy to reproduce. 
> Try running this program:
>
> var finalies = 1
> var line = 'TEST THIS LINE'
> try {
>  while ('' !== (line = line.substring(0, line.length - 1))) {
>   if (line.length % 2 == 0) {
>    continue
>   }
>   java.lang.System.out.println(line)
>  }
> }
> catch (x) {
>   java.lang.System.out.println(x)
> }
> finally {
>  java.lang.System.out.println('Finalies ' + (finalies++))
> }
>
> If you run this code, you'll see that the "finally" block is run every 
> time "continue" is reached, and then the while loop continues after 
> the "finally" block is run. Of course, the "finally" block should only 
> be called once in this example, and the while loop should not 
> continue, and this broken behavior can lead to serious problems.
>
> (I added the "catch" block only to make sure that exceptions are not 
> thrown, and indeed they are not. Sorry about the silly functionality 
> of the program, but it's the result of trying to wrap my head around 
> what was going on...)
>
> Or maybe I'm crazy and am missing something trivial? The same code 
> runs in Rhino without this problem.
>
> The bug appears in the 8u40 release. :(
>
> -Tal
>
>


From sundararajan.athijegannathan at oracle.com  Mon Mar  9 03:11:55 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 09 Mar 2015 08:41:55 +0530
Subject: Review request for JDK-8072426
In-Reply-To: <03102C38-0B8D-49DC-96A8-E1286675D6D6@oracle.com>
References: <A5E06E32-726E-4080-A8CB-696FC191CFD1@oracle.com>	<54E6F4C5.1090402@oracle.com>
	<03102C38-0B8D-49DC-96A8-E1286675D6D6@oracle.com>
Message-ID: <54FD0F7B.4050506@oracle.com>

+1

On Sunday 08 March 2015 06:59 PM, Attila Szegedi wrote:
> Thanks for the reviews. In order to backport this to 8u-dev, I had to make some changes. Namely, since we introduced a default method into the JSObject interface, we could not compile this under jdk8u-dev, as for JDK 8 Nashorn is compiled with "-source 7" as the part of the build process is running Nasgen, which is done with the boot JDK, which is a JDK 7 for 8u[*].
>
> For this reason, the 8u backport doesn't add a new getDefaultValue() method to the JSObject interface, as that ? without the default methods' ability ? wouldn't be a binary compatible class change. Instead, AbstractJSObject gains a getDefaultValue(hint) method with the same behavior as well as a static helper getDefaultValue(jsobj, hint) that delegates to AbstractJSObject.getDefaultValue() for AbstractJSObject, and runs the generic algorithm for any other JSObject. (As a separate task, we'll need to forward-port this static helper into JDK 9 codebase so it stays compatible with 8; I'll soon file a JIRA for that.)
>
> With these in mind, please review the backport changeset at <http://cr.openjdk.java.net/~attila/8072426/webrev.8u>
>
> Thanks,
>    Attila.
>
> --
> [*] This raises an interesting further issue, namely that this somewhat peculiar dependency disallows use of any Java 8 syntactic construct in Nashorn code destined for 8. Long term, it'd be great if we could either get 8u to use the previous 8 release as its boot JDK, or if we could rewrite Nasgen so that it reads Nashorn .class files, but doesn't load them into the JVM.
>
> On Feb 20, 2015, at 9:48 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>
>> +1
>>
>> Nice work!
>>
>> Am 2015-02-19 um 18:48 schrieb Attila Szegedi:
>>> Please review JDK-8072426 at <http://cr.openjdk.java.net/~attila/8072426/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8072426>
>>>
>>> This is what basically became an epic yak shaving exercise after we determined that POJOs aren't subjected to ToPrimitive (earlier known as java.math.RoundingMode.UP != "UP" problem). While we originally advocated for throwing TypeError for POJOs [[DefaultValue]] that would've prevented their implicit toString() in string concatenation too. Instead, I opted to fix this once and forever but it turned out that the biggest issue with it is the fact that JSObject was also not handled correctly for ToPrimitive; fixing that turned out to be the most challenging part, introducing a new JSObject.getDefaultValue() method and deprecating JSObject.toNumber() (which isn't used anymore at all).
>>>
>>> As an unexpected boon, JSObjectLinker no longer needs to do any conversions, so its GuardingTypeConverterFactory functionality has been entirely removed. NashornPrimitiveLinker will now automatically take care of converting JSObject instances to various primitive types, as per specification behavior.
>>>
>>> Finally, the ScriptRuntime changes to the equals() and equalDifferentType() are purely refactoring of some common type testing subexpressions and conversions, as well as short-circuiting of some comparisons. They aren't strictly necessary for this issue, but just for clear understanding of what's happening it seemed like a good idea to make them more concise (ScriptRuntime.EQ and .NE, of which the two affected methods are sub-parts are also not invoked terribly often, and I'll soon make them be invoked even less frequently.)
>>>
>>> Thanks,
>>>    Attila.


From sundararajan.athijegannathan at oracle.com  Mon Mar  9 06:02:49 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 09 Mar 2015 11:32:49 +0530
Subject: RFR 8074671: Nashorn Parser API
Message-ID: <54FD3789.2040702@oracle.com>

Please review "Nashorn Parser API". Introduces jdk.nashorn.api.tree 
package to support parser API for Nashorn.

JEP: http://openjdk.java.net/jeps/236
Bug: https://bugs.openjdk.java.net/browse/JDK-8074671
Webrev: http://cr.openjdk.java.net/~sundar/8074671/

Simple examples "evalcheck.js" and "withcheck.js" under samples 
directory added.

Thanks to Joe Darcy who helped me with extensive specification review.

Thanks,
-Sundar

From sundararajan.athijegannathan at oracle.com  Mon Mar  9 07:42:51 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 09 Mar 2015 13:12:51 +0530
Subject: Review request for JDK-8074556: Functions should not share
	allocator maps
Message-ID: <54FD4EFB.7030809@oracle.com>

http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-March/004267.html

+1

-Sundar

From attila.szegedi at oracle.com  Mon Mar  9 07:48:06 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 9 Mar 2015 08:48:06 +0100
Subject: Serious bug: "finally" block is run whenever "continue" is reached
In-Reply-To: <54FC5B17.3000404@gmail.com>
References: <54FC54D8.2010302@threecrickets.com> <54FC5B17.3000404@gmail.com>
Message-ID: <8CD3A95C-14E0-4522-9F45-4DD8BD37BDF0@oracle.com>

This isn't new to 8u40; I just tested, and it's broken in 8u31 and 8u25 too. If I had to guess, it has been like this since the initial release. I base my guess on the fact that the way Nashorn compiled finally blocks in presence of control flow transfers (break/continue/return) was unfortunately broken, I myself discovered this last December and fixed it early February ? that's indeed the JIRA issue that Anthony pointed out. Unfortunately, it didn't make it in time for 8u40 :-(

If you're self-deploying, I'd suggest you get an 8u60 EA from <https://jdk8.java.net/download.html> and drop its nashorn.jar into your 8u40 JRE (it'll work). A glance at Mercurial log shows this issue with finally block inlining was picked up for 8u60-b03 build; the currently latest build is 8u60-b05, so it should be in there already. Apologies for the inconvenience. I've been doing a lot of stabilization work lately. I could get ready with some of the issues for 8u40, but there's a bunch of others that I couldn't finish in time?

Attila.

On Mar 8, 2015, at 3:22 PM, Anthony Vanelverdinghe <anthony.vanelverdinghe at gmail.com> wrote:

> Hi Tal
> 
> This might already have been solved in 9, and backported to 8u60, with bug JDK-8067139 [1]: Finally blocks inlined incorrectly
> 
> Kind regards,
> Anthony
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8067139
> 
> 
> On 8/03/2015 14:55, Tal Liron wrote:
>> This was very hard to discover, but it is real and easy to reproduce. Try running this program:
>> 
>> var finalies = 1
>> var line = 'TEST THIS LINE'
>> try {
>> while ('' !== (line = line.substring(0, line.length - 1))) {
>>  if (line.length % 2 == 0) {
>>   continue
>>  }
>>  java.lang.System.out.println(line)
>> }
>> }
>> catch (x) {
>>  java.lang.System.out.println(x)
>> }
>> finally {
>> java.lang.System.out.println('Finalies ' + (finalies++))
>> }
>> 
>> If you run this code, you'll see that the "finally" block is run every time "continue" is reached, and then the while loop continues after the "finally" block is run. Of course, the "finally" block should only be called once in this example, and the while loop should not continue, and this broken behavior can lead to serious problems.
>> 
>> (I added the "catch" block only to make sure that exceptions are not thrown, and indeed they are not. Sorry about the silly functionality of the program, but it's the result of trying to wrap my head around what was going on...)
>> 
>> Or maybe I'm crazy and am missing something trivial? The same code runs in Rhino without this problem.
>> 
>> The bug appears in the 8u40 release. :(
>> 
>> -Tal
>> 
>> 
> 


From forax at univ-mlv.fr  Mon Mar  9 08:08:39 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 09 Mar 2015 09:08:39 +0100
Subject: RFR 8074671: Nashorn Parser API
In-Reply-To: <54FD3789.2040702@oracle.com>
References: <54FD3789.2040702@oracle.com>
Message-ID: <54FD5507.4070003@univ-mlv.fr>


On 03/09/2015 07:02 AM, A. Sundararajan wrote:
> Please review "Nashorn Parser API". Introduces jdk.nashorn.api.tree 
> package to support parser API for Nashorn.
>
> JEP: http://openjdk.java.net/jeps/236
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074671
> Webrev: http://cr.openjdk.java.net/~sundar/8074671/
>
> Simple examples "evalcheck.js" and "withcheck.js" under samples 
> directory added.
>
> Thanks to Joe Darcy who helped me with extensive specification review.
>
> Thanks,
> -Sundar

Hi Sundar,
nice works !

Nitpicking, there are several occurrences of list.stream.forEach(item -> 
...)
that can be replaced by the simpler list.forEach(item -> ...).

cheers,
R?mi


From sundararajan.athijegannathan at oracle.com  Mon Mar  9 08:16:24 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 09 Mar 2015 13:46:24 +0530
Subject: RFR 8074671: Nashorn Parser API
In-Reply-To: <54FD5507.4070003@univ-mlv.fr>
References: <54FD3789.2040702@oracle.com> <54FD5507.4070003@univ-mlv.fr>
Message-ID: <54FD56D8.50703@oracle.com>

Hi R?mi,

Will fix those forEach calls.

Thanks,
-Sundar

On Monday 09 March 2015 01:38 PM, Remi Forax wrote:
>
> On 03/09/2015 07:02 AM, A. Sundararajan wrote:
>> Please review "Nashorn Parser API". Introduces jdk.nashorn.api.tree 
>> package to support parser API for Nashorn.
>>
>> JEP: http://openjdk.java.net/jeps/236
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074671
>> Webrev: http://cr.openjdk.java.net/~sundar/8074671/
>>
>> Simple examples "evalcheck.js" and "withcheck.js" under samples 
>> directory added.
>>
>> Thanks to Joe Darcy who helped me with extensive specification review.
>>
>> Thanks,
>> -Sundar
>
> Hi Sundar,
> nice works !
>
> Nitpicking, there are several occurrences of list.stream.forEach(item 
> -> ...)
> that can be replaced by the simpler list.forEach(item -> ...).
>
> cheers,
> R?mi
>


From attila.szegedi at oracle.com  Mon Mar  9 08:27:30 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 9 Mar 2015 09:27:30 +0100
Subject: RFR 8074671: Nashorn Parser API
In-Reply-To: <54FD3789.2040702@oracle.com>
References: <54FD3789.2040702@oracle.com>
Message-ID: <B6246BE8-EA41-41A7-BB90-D140F402FAD9@oracle.com>

Amazing work Sundar. I can see this being a very strong point for Nashorn for people writing tools that work with JS source files.

Two typos:
   - JSONWriter: assert "should reach here" should read "should not reach here"
   - withcheck.js: typo: "diganostic"

I'm also very happy that we have synthetic marker on BlockStatement. That's actually something that we could now use for more precise let/const scoping. I think though that we should add the flag on Block, not on BlockStatement. Block already has a flags bitfield, BTW, but that's not the reason. The reason is that we're historically introducing synthetic blocks elsewhere too. "if(...) stmt;" becomes "if(...) { stmt; }" internally as our AST is structured so that IfNode, ForNode, WhileNode, CaseNode etc. do not hold Statement nodes as their bodies, but Block nodes instead. This is strictly speaking incorrect mapping of the ES grammar, but I guess that for now we're stuck with it.

Those blocks are synthetic too, and we aren't distinguishing them on the AST level from explicit blocks present in the source code. It isn't much of a trouble for contexts where only a single statement can be specified without a block (which is most contexts in JS) but it can be a trouble for switch/case, as "case x: stmt1; stmt2; case y: ..." and "case x: { stmt1; stmt2; } case y: ..." have differing semantics in ES6 if stmt1 is a let/const. So I think that if we're finally adding a "synthetic" flag (as we should!) to blocks, it should be marked on Block, not BlockStatement.

Attila.

On Mar 9, 2015, at 7:02 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review "Nashorn Parser API". Introduces jdk.nashorn.api.tree package to support parser API for Nashorn.
> 
> JEP: http://openjdk.java.net/jeps/236
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074671
> Webrev: http://cr.openjdk.java.net/~sundar/8074671/
> 
> Simple examples "evalcheck.js" and "withcheck.js" under samples directory added.
> 
> Thanks to Joe Darcy who helped me with extensive specification review.
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Mon Mar  9 08:50:59 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 09 Mar 2015 09:50:59 +0100
Subject: RFR 8074671: Nashorn Parser API
In-Reply-To: <54FD3789.2040702@oracle.com>
References: <54FD3789.2040702@oracle.com>
Message-ID: <54FD5EF3.1070905@oracle.com>

+1

Great work, Sundar!

Hannes

Am 2015-03-09 um 07:02 schrieb A. Sundararajan:
> Please review "Nashorn Parser API". Introduces jdk.nashorn.api.tree 
> package to support parser API for Nashorn.
>
> JEP: http://openjdk.java.net/jeps/236
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074671
> Webrev: http://cr.openjdk.java.net/~sundar/8074671/
>
> Simple examples "evalcheck.js" and "withcheck.js" under samples 
> directory added.
>
> Thanks to Joe Darcy who helped me with extensive specification review.
>
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Mon Mar  9 10:28:18 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 09 Mar 2015 11:28:18 +0100
Subject: Nashorn bug in Java 8 u40: Cannot parse JSON: { 0: null, 100:
	null }
In-Reply-To: <CAKb=CAqxJMGm5m6E0SiN64k5SLO==breiOPPCtQtS2Ek32YZzQ@mail.gmail.com>
References: <CAKb=CAqxJMGm5m6E0SiN64k5SLO==breiOPPCtQtS2Ek32YZzQ@mail.gmail.com>
Message-ID: <54FD75C2.1070003@oracle.com>

Hi Kaj Magnus,

Thanks for the report. It's unfortunate this bug ended up in 8u40. 
Obviously the fix for the bug you linked was incomplete, and we weren't 
aware of that.

The problem has been fixed in the meantime (together with a rewrite of 
the JSON parser that makes JSON parsing much faster). The fix will be 
part of the 8u60 release. The current 8u60 early access release 
available at https://jdk8.java.net/download.html already contains the fix.

I'm also adding additional tests so this won't happen again:

https://bugs.openjdk.java.net/browse/JDK-8074687

Regards,
Hannes

Am 2015-03-08 um 06:20 schrieb Kaj Magnus Lindberg:
> Hi dear Nashorn developers,
>
> There's an ArrayIndexOutOfBoundsException bug when I try to parse this
> JSON: '{ "0":null, "100": null }'.
>
> Have a look here:
>
> jjs> JSON.parse('{ "0":null, "65503": null }')
> java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 65503
> jjs>
> jjs> JSON.parse('{ "0":null, "100": null }')
> java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 100
> jjs>
> jjs> JSON.parse('{ "0":null, "65": null }')
> java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 65
> jjs>
> jjs> JSON.parse('{ "0":null, "64": null }')  // Works
> [object Object]
> jjs>
> jjs> JSON.parse('{ "_0":null, "_100": null }')  // Works
> [object Object]
> jjs>
> jjs>
>
> I found a bug report that was fixed that made { 0: null, 64: null } work.
> But as you can see above, { 0: null, 65: null } doesn't work.
>    https://bugs.openjdk.java.net/browse/JDK-8048718
>
> Version details:
>
> $ java -version
> java version "1.8.0_40"
> Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
>
> $ uname -a
> Linux kajmagnus-lt-15 3.19.0-031900-generic #201502091451 SMP Mon Feb 9
> 14:52:52 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>
> $ cat /etc/issue
> Linux Mint 17.1 Rebecca \n \l
>
> (This bug wasn't present in an earlier Nashorn version, u20 or u22 or
> something like that.)
>
> Best regards,
> KajMagnus


From tal.liron at threecrickets.com  Mon Mar  9 13:22:16 2015
From: tal.liron at threecrickets.com (Tal Liron)
Date: Mon, 09 Mar 2015 08:22:16 -0500
Subject: Serious bug: "finally" block is run whenever "continue" is reached
In-Reply-To: <8CD3A95C-14E0-4522-9F45-4DD8BD37BDF0@oracle.com>
References: <54FC54D8.2010302@threecrickets.com> <54FC5B17.3000404@gmail.com>
	<8CD3A95C-14E0-4522-9F45-4DD8BD37BDF0@oracle.com>
Message-ID: <54FD9E88.3020802@threecrickets.com>

Could you possibly articulate 1) *exactly* what the issue is, 2) how to 
search for potential issues in my vast amount of JavaScript code, 3) and 
how to work around it?

The problem is that I'm not self-deploying: I am building products that 
run on top of the JVM with JavaScript, and yet I cannot recommend 
Nashorn to anyone in its current state. At the very least, I can make 
sure that my own JavaScript code works with 8u40.

Actually, the "meta" bug here is that Nashorn's release system is 
broken: these kinds of breaking bugs need an immediate notice and a fix 
released to the public. And yet Nashorn is tied to JDK releases, which 
are once every six months. Something is very wrong about this system, 
and I'm sure it must be frustrating to the Nashorn team, too.

Barring the possibility of a bugfix release, there *must* to be a "known 
issues" right there on the JDK download page. You simply cannot release 
a JavaScript engine to the public that does not honor try/finally.

On 03/09/2015 02:48 AM, Attila Szegedi wrote:
> This isn't new to 8u40; I just tested, and it's broken in 8u31 and 
> 8u25 too. If I had to guess, it has been like this since the initial 
> release. I base my guess on the fact that the way Nashorn compiled 
> finally blocks in presence of control flow transfers 
> (break/continue/return) was unfortunately broken, I myself discovered 
> this last December and fixed it early February ? that's indeed the 
> JIRA issue that Anthony pointed out. Unfortunately, it didn't make it 
> in time for 8u40 :-(


From sundararajan.athijegannathan at oracle.com  Mon Mar  9 13:23:43 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 09 Mar 2015 18:53:43 +0530
Subject: RFR 8074671: Nashorn Parser API
In-Reply-To: <B6246BE8-EA41-41A7-BB90-D140F402FAD9@oracle.com>
References: <54FD3789.2040702@oracle.com>
	<B6246BE8-EA41-41A7-BB90-D140F402FAD9@oracle.com>
Message-ID: <54FD9EDF.3000903@oracle.com>

Thanks for the review. Please review the updated webrev:

http://cr.openjdk.java.net/~sundar/8074671/webrev.01/

Changes:

* Fixed JSONWriter.java "should not reach here" string.
* Fixed typo in withcheck.js
* moved synthetic flag to Block.java - added a test case to 
test/script/nosecurity/parservisitor.js test
* changed stream().forEach() as forEach() as Remi suggested 
(SimpleTreeVisitorES5_1.java)

Thanks,
-Sundar

On Monday 09 March 2015 01:57 PM, Attila Szegedi wrote:
> Amazing work Sundar. I can see this being a very strong point for Nashorn for people writing tools that work with JS source files.
>
> Two typos:
>     - JSONWriter: assert "should reach here" should read "should not reach here"
>     - withcheck.js: typo: "diganostic"
>
> I'm also very happy that we have synthetic marker on BlockStatement. That's actually something that we could now use for more precise let/const scoping. I think though that we should add the flag on Block, not on BlockStatement. Block already has a flags bitfield, BTW, but that's not the reason. The reason is that we're historically introducing synthetic blocks elsewhere too. "if(...) stmt;" becomes "if(...) { stmt; }" internally as our AST is structured so that IfNode, ForNode, WhileNode, CaseNode etc. do not hold Statement nodes as their bodies, but Block nodes instead. This is strictly speaking incorrect mapping of the ES grammar, but I guess that for now we're stuck with it.
>
> Those blocks are synthetic too, and we aren't distinguishing them on the AST level from explicit blocks present in the source code. It isn't much of a trouble for contexts where only a single statement can be specified without a block (which is most contexts in JS) but it can be a trouble for switch/case, as "case x: stmt1; stmt2; case y: ..." and "case x: { stmt1; stmt2; } case y: ..." have differing semantics in ES6 if stmt1 is a let/const. So I think that if we're finally adding a "synthetic" flag (as we should!) to blocks, it should be marked on Block, not BlockStatement.
>
> Attila.
>
> On Mar 9, 2015, at 7:02 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
>
>> Please review "Nashorn Parser API". Introduces jdk.nashorn.api.tree package to support parser API for Nashorn.
>>
>> JEP: http://openjdk.java.net/jeps/236
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074671
>> Webrev: http://cr.openjdk.java.net/~sundar/8074671/
>>
>> Simple examples "evalcheck.js" and "withcheck.js" under samples directory added.
>>
>> Thanks to Joe Darcy who helped me with extensive specification review.
>>
>> Thanks,
>> -Sundar


From attila.szegedi at oracle.com  Mon Mar  9 13:49:02 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 9 Mar 2015 14:49:02 +0100
Subject: RFR 8074671: Nashorn Parser API
In-Reply-To: <54FD9EDF.3000903@oracle.com>
References: <54FD3789.2040702@oracle.com>
	<B6246BE8-EA41-41A7-BB90-D140F402FAD9@oracle.com>
	<54FD9EDF.3000903@oracle.com>
Message-ID: <9B5F21FF-C91F-4662-8136-91152280D6D9@oracle.com>

+1

On Mar 9, 2015, at 2:23 PM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Thanks for the review. Please review the updated webrev:
> 
> http://cr.openjdk.java.net/~sundar/8074671/webrev.01/
> 
> Changes:
> 
> * Fixed JSONWriter.java "should not reach here" string.
> * Fixed typo in withcheck.js
> * moved synthetic flag to Block.java - added a test case to test/script/nosecurity/parservisitor.js test
> * changed stream().forEach() as forEach() as Remi suggested (SimpleTreeVisitorES5_1.java)
> 
> Thanks,
> -Sundar
> 
> On Monday 09 March 2015 01:57 PM, Attila Szegedi wrote:
>> Amazing work Sundar. I can see this being a very strong point for Nashorn for people writing tools that work with JS source files.
>> 
>> Two typos:
>>    - JSONWriter: assert "should reach here" should read "should not reach here"
>>    - withcheck.js: typo: "diganostic"
>> 
>> I'm also very happy that we have synthetic marker on BlockStatement. That's actually something that we could now use for more precise let/const scoping. I think though that we should add the flag on Block, not on BlockStatement. Block already has a flags bitfield, BTW, but that's not the reason. The reason is that we're historically introducing synthetic blocks elsewhere too. "if(...) stmt;" becomes "if(...) { stmt; }" internally as our AST is structured so that IfNode, ForNode, WhileNode, CaseNode etc. do not hold Statement nodes as their bodies, but Block nodes instead. This is strictly speaking incorrect mapping of the ES grammar, but I guess that for now we're stuck with it.
>> 
>> Those blocks are synthetic too, and we aren't distinguishing them on the AST level from explicit blocks present in the source code. It isn't much of a trouble for contexts where only a single statement can be specified without a block (which is most contexts in JS) but it can be a trouble for switch/case, as "case x: stmt1; stmt2; case y: ..." and "case x: { stmt1; stmt2; } case y: ..." have differing semantics in ES6 if stmt1 is a let/const. So I think that if we're finally adding a "synthetic" flag (as we should!) to blocks, it should be marked on Block, not BlockStatement.
>> 
>> Attila.
>> 
>> On Mar 9, 2015, at 7:02 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
>> 
>>> Please review "Nashorn Parser API". Introduces jdk.nashorn.api.tree package to support parser API for Nashorn.
>>> 
>>> JEP: http://openjdk.java.net/jeps/236
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074671
>>> Webrev: http://cr.openjdk.java.net/~sundar/8074671/
>>> 
>>> Simple examples "evalcheck.js" and "withcheck.js" under samples directory added.
>>> 
>>> Thanks to Joe Darcy who helped me with extensive specification review.
>>> 
>>> Thanks,
>>> -Sundar
> 


From michael.krause at grawe.at  Mon Mar  9 15:34:04 2015
From: michael.krause at grawe.at (Krause, Michael)
Date: Mon, 9 Mar 2015 15:34:04 +0000
Subject: AW: Serious bug: "finally" block is run whenever "continue" is reached
In-Reply-To: <54FD9E88.3020802@threecrickets.com>
References: <54FC54D8.2010302@threecrickets.com> <54FC5B17.3000404@gmail.com>
	<8CD3A95C-14E0-4522-9F45-4DD8BD37BDF0@oracle.com>,
	<54FD9E88.3020802@threecrickets.com>
Message-ID: <E8515F59548A814D811800C0D441763647D748E6@ATRZEXMBX3.grawe.at>

Absolutely - please consider that Java and the embedded JavaScript Engine is used in production-systems. 
Is Nashorn really ready for production use? Seriously, since I am on the nashorn-dev list
I have read about three bugs that are not mentioned in the official release-notes of Java.

We have no (real) option to use Rhino in Java 8 any more, and Java 7 is near end-of-life. Should I port my scripts to Groovy in order to be safe?
 
________________________________________
Von: nashorn-dev [nashorn-dev-bounces at openjdk.java.net]&quot; im Auftrag von &quot;Tal Liron [tal.liron at threecrickets.com]
Gesendet: Montag, 9. M?rz 2015 14:22
An: nashorn-dev at openjdk.java.net
Betreff: Re: Serious bug: "finally" block is run whenever "continue" is reached

Could you possibly articulate 1) *exactly* what the issue is, 2) how to
search for potential issues in my vast amount of JavaScript code, 3) and
how to work around it?

The problem is that I'm not self-deploying: I am building products that
run on top of the JVM with JavaScript, and yet I cannot recommend
Nashorn to anyone in its current state. At the very least, I can make
sure that my own JavaScript code works with 8u40.

Actually, the "meta" bug here is that Nashorn's release system is
broken: these kinds of breaking bugs need an immediate notice and a fix
released to the public. And yet Nashorn is tied to JDK releases, which
are once every six months. Something is very wrong about this system,
and I'm sure it must be frustrating to the Nashorn team, too.

Barring the possibility of a bugfix release, there *must* to be a "known
issues" right there on the JDK download page. You simply cannot release
a JavaScript engine to the public that does not honor try/finally.

On 03/09/2015 02:48 AM, Attila Szegedi wrote:
> This isn't new to 8u40; I just tested, and it's broken in 8u31 and
> 8u25 too. If I had to guess, it has been like this since the initial
> release. I base my guess on the fact that the way Nashorn compiled
> finally blocks in presence of control flow transfers
> (break/continue/return) was unfortunately broken, I myself discovered
> this last December and fixed it early February ? that's indeed the
> JIRA issue that Anthony pointed out. Unfortunately, it didn't make it
> in time for 8u40 :-(


From marcus.lagergren at oracle.com  Mon Mar  9 15:46:56 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 9 Mar 2015 16:46:56 +0100
Subject: RFR 8074671: Nashorn Parser API
In-Reply-To: <54FD9EDF.3000903@oracle.com>
References: <54FD3789.2040702@oracle.com>
	<B6246BE8-EA41-41A7-BB90-D140F402FAD9@oracle.com>
	<54FD9EDF.3000903@oracle.com>
Message-ID: <57A02950-7564-4C2F-BDAA-54B12DDE4F33@oracle.com>

My congratulations on finishing this, Sundar!

/M

> On 09 Mar 2015, at 14:23, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Thanks for the review. Please review the updated webrev:
> 
> http://cr.openjdk.java.net/~sundar/8074671/webrev.01/
> 
> Changes:
> 
> * Fixed JSONWriter.java "should not reach here" string.
> * Fixed typo in withcheck.js
> * moved synthetic flag to Block.java - added a test case to test/script/nosecurity/parservisitor.js test
> * changed stream().forEach() as forEach() as Remi suggested (SimpleTreeVisitorES5_1.java)
> 
> Thanks,
> -Sundar
> 
> On Monday 09 March 2015 01:57 PM, Attila Szegedi wrote:
>> Amazing work Sundar. I can see this being a very strong point for Nashorn for people writing tools that work with JS source files.
>> 
>> Two typos:
>>    - JSONWriter: assert "should reach here" should read "should not reach here"
>>    - withcheck.js: typo: "diganostic"
>> 
>> I'm also very happy that we have synthetic marker on BlockStatement. That's actually something that we could now use for more precise let/const scoping. I think though that we should add the flag on Block, not on BlockStatement. Block already has a flags bitfield, BTW, but that's not the reason. The reason is that we're historically introducing synthetic blocks elsewhere too. "if(...) stmt;" becomes "if(...) { stmt; }" internally as our AST is structured so that IfNode, ForNode, WhileNode, CaseNode etc. do not hold Statement nodes as their bodies, but Block nodes instead. This is strictly speaking incorrect mapping of the ES grammar, but I guess that for now we're stuck with it.
>> 
>> Those blocks are synthetic too, and we aren't distinguishing them on the AST level from explicit blocks present in the source code. It isn't much of a trouble for contexts where only a single statement can be specified without a block (which is most contexts in JS) but it can be a trouble for switch/case, as "case x: stmt1; stmt2; case y: ..." and "case x: { stmt1; stmt2; } case y: ..." have differing semantics in ES6 if stmt1 is a let/const. So I think that if we're finally adding a "synthetic" flag (as we should!) to blocks, it should be marked on Block, not BlockStatement.
>> 
>> Attila.
>> 
>> On Mar 9, 2015, at 7:02 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
>> 
>>> Please review "Nashorn Parser API". Introduces jdk.nashorn.api.tree package to support parser API for Nashorn.
>>> 
>>> JEP: http://openjdk.java.net/jeps/236
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074671
>>> Webrev: http://cr.openjdk.java.net/~sundar/8074671/
>>> 
>>> Simple examples "evalcheck.js" and "withcheck.js" under samples directory added.
>>> 
>>> Thanks to Joe Darcy who helped me with extensive specification review.
>>> 
>>> Thanks,
>>> -Sundar
> 


From sundararajan.athijegannathan at oracle.com  Mon Mar  9 15:48:54 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 09 Mar 2015 21:18:54 +0530
Subject: RFR 8074671: Nashorn Parser API
In-Reply-To: <57A02950-7564-4C2F-BDAA-54B12DDE4F33@oracle.com>
References: <54FD3789.2040702@oracle.com>
	<B6246BE8-EA41-41A7-BB90-D140F402FAD9@oracle.com>
	<54FD9EDF.3000903@oracle.com>
	<57A02950-7564-4C2F-BDAA-54B12DDE4F33@oracle.com>
Message-ID: <54FDC0E6.4040304@oracle.com>

Thanks Marcus.

Thanks for the review(s) Joe, Remi, Attila and Hannes..

-Sundar

On Monday 09 March 2015 09:16 PM, Marcus Lagergren wrote:
> My congratulations on finishing this, Sundar!
>
> /M
>
>> On 09 Mar 2015, at 14:23, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
>>
>> Thanks for the review. Please review the updated webrev:
>>
>> http://cr.openjdk.java.net/~sundar/8074671/webrev.01/
>>
>> Changes:
>>
>> * Fixed JSONWriter.java "should not reach here" string.
>> * Fixed typo in withcheck.js
>> * moved synthetic flag to Block.java - added a test case to test/script/nosecurity/parservisitor.js test
>> * changed stream().forEach() as forEach() as Remi suggested (SimpleTreeVisitorES5_1.java)
>>
>> Thanks,
>> -Sundar
>>
>> On Monday 09 March 2015 01:57 PM, Attila Szegedi wrote:
>>> Amazing work Sundar. I can see this being a very strong point for Nashorn for people writing tools that work with JS source files.
>>>
>>> Two typos:
>>>     - JSONWriter: assert "should reach here" should read "should not reach here"
>>>     - withcheck.js: typo: "diganostic"
>>>
>>> I'm also very happy that we have synthetic marker on BlockStatement. That's actually something that we could now use for more precise let/const scoping. I think though that we should add the flag on Block, not on BlockStatement. Block already has a flags bitfield, BTW, but that's not the reason. The reason is that we're historically introducing synthetic blocks elsewhere too. "if(...) stmt;" becomes "if(...) { stmt; }" internally as our AST is structured so that IfNode, ForNode, WhileNode, CaseNode etc. do not hold Statement nodes as their bodies, but Block nodes instead. This is strictly speaking incorrect mapping of the ES grammar, but I guess that for now we're stuck with it.
>>>
>>> Those blocks are synthetic too, and we aren't distinguishing them on the AST level from explicit blocks present in the source code. It isn't much of a trouble for contexts where only a single statement can be specified without a block (which is most contexts in JS) but it can be a trouble for switch/case, as "case x: stmt1; stmt2; case y: ..." and "case x: { stmt1; stmt2; } case y: ..." have differing semantics in ES6 if stmt1 is a let/const. So I think that if we're finally adding a "synthetic" flag (as we should!) to blocks, it should be marked on Block, not BlockStatement.
>>>
>>> Attila.
>>>
>>> On Mar 9, 2015, at 7:02 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
>>>
>>>> Please review "Nashorn Parser API". Introduces jdk.nashorn.api.tree package to support parser API for Nashorn.
>>>>
>>>> JEP: http://openjdk.java.net/jeps/236
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074671
>>>> Webrev: http://cr.openjdk.java.net/~sundar/8074671/
>>>>
>>>> Simple examples "evalcheck.js" and "withcheck.js" under samples directory added.
>>>>
>>>> Thanks to Joe Darcy who helped me with extensive specification review.
>>>>
>>>> Thanks,
>>>> -Sundar


From marcus.lagergren at oracle.com  Mon Mar  9 15:53:58 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 9 Mar 2015 16:53:58 +0100
Subject: Nashorn bug in Java 8 u40: Cannot parse JSON: { 0: null,
	100: null }
In-Reply-To: <54FD75C2.1070003@oracle.com>
References: <CAKb=CAqxJMGm5m6E0SiN64k5SLO==breiOPPCtQtS2Ek32YZzQ@mail.gmail.com>
	<54FD75C2.1070003@oracle.com>
Message-ID: <270060D8-DF6C-48AB-AEC0-F0FC5EB3F665@oracle.com>

Hi Kaj Magnus,

We still don?t have a huge user base, but we are working hard on building up our test coverage. Hence, we get some small embarrassments like this from time to time, but they will hopefully get less frequent soon. You will find that most issues will be addressed quicker than new releases come out. You can track the issues in JIRA to see where the fixes are checked in. Should an emergency arise, you can always build the latest Nashorn from source. Being open source, our fixes are visible to the world immediately, even though they are not bundled. Naturally, we will push very hard to get them into as early a release as we can, too.

/M

> On 09 Mar 2015, at 11:28, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Hi Kaj Magnus,
> 
> Thanks for the report. It's unfortunate this bug ended up in 8u40. Obviously the fix for the bug you linked was incomplete, and we weren't aware of that.
> 
> The problem has been fixed in the meantime (together with a rewrite of the JSON parser that makes JSON parsing much faster). The fix will be part of the 8u60 release. The current 8u60 early access release available at https://jdk8.java.net/download.html already contains the fix.
> 
> I'm also adding additional tests so this won't happen again:
> 
> https://bugs.openjdk.java.net/browse/JDK-8074687
> 
> Regards,
> Hannes
> 
> Am 2015-03-08 um 06:20 schrieb Kaj Magnus Lindberg:
>> Hi dear Nashorn developers,
>> 
>> There's an ArrayIndexOutOfBoundsException bug when I try to parse this
>> JSON: '{ "0":null, "100": null }'.
>> 
>> Have a look here:
>> 
>> jjs> JSON.parse('{ "0":null, "65503": null }')
>> java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 65503
>> jjs>
>> jjs> JSON.parse('{ "0":null, "100": null }')
>> java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 100
>> jjs>
>> jjs> JSON.parse('{ "0":null, "65": null }')
>> java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 65
>> jjs>
>> jjs> JSON.parse('{ "0":null, "64": null }')  // Works
>> [object Object]
>> jjs>
>> jjs> JSON.parse('{ "_0":null, "_100": null }')  // Works
>> [object Object]
>> jjs>
>> jjs>
>> 
>> I found a bug report that was fixed that made { 0: null, 64: null } work.
>> But as you can see above, { 0: null, 65: null } doesn't work.
>>   https://bugs.openjdk.java.net/browse/JDK-8048718
>> 
>> Version details:
>> 
>> $ java -version
>> java version "1.8.0_40"
>> Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
>> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
>> 
>> $ uname -a
>> Linux kajmagnus-lt-15 3.19.0-031900-generic #201502091451 SMP Mon Feb 9
>> 14:52:52 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>> 
>> $ cat /etc/issue
>> Linux Mint 17.1 Rebecca \n \l
>> 
>> (This bug wasn't present in an earlier Nashorn version, u20 or u22 or
>> something like that.)
>> 
>> Best regards,
>> KajMagnus
> 


From tal.liron at threecrickets.com  Mon Mar  9 16:17:11 2015
From: tal.liron at threecrickets.com (Tal Liron)
Date: Mon, 09 Mar 2015 11:17:11 -0500
Subject: AW: Serious bug: "finally" block is run whenever "continue" is
	reached
In-Reply-To: <E8515F59548A814D811800C0D441763647D748E6@ATRZEXMBX3.grawe.at>
References: <54FC54D8.2010302@threecrickets.com>
	<54FC5B17.3000404@gmail.com>	<8CD3A95C-14E0-4522-9F45-4DD8BD37BDF0@oracle.com>,
	<54FD9E88.3020802@threecrickets.com>
	<E8515F59548A814D811800C0D441763647D748E6@ATRZEXMBX3.grawe.at>
Message-ID: <54FDC787.8030403@threecrickets.com>

So that I don't sound bitter, let me try to suggest a constructive 
solution to the "meta" bug:

Could Nashorn have its own, separate, "download" page of post-JDK releases?

This would require different versioning, too. Right now, the Nashorn 
version is tied to the JDK -- if I build it from hg, it is always marked 
as version "0.1". Why not have Nashorn have its own internal version 
march, parallel but ultimately separate from the JDK?

That way, instead of telling my users that my product requires 8u40, I 
can specify a Nashorn version. Per JDK release, it can specify which 
Nashorn version is included out of the box. My product could even check 
for that version and provide an error message with instruction on how to 
solve it.

I think it was fine to experiment with tying Nashorn to the JDK. But 
it's also clear, to me at least, that the experiment has failed. It's 
more than a year since Nashorn was released, with so much promise, but I 
still can't recommend it to my users.

On 03/09/2015 10:34 AM, Krause, Michael wrote:
> Absolutely - please consider that Java and the embedded JavaScript Engine is used in production-systems.
> Is Nashorn really ready for production use? Seriously, since I am on the nashorn-dev list
> I have read about three bugs that are not mentioned in the official release-notes of Java.
>
> We have no (real) option to use Rhino in Java 8 any more, and Java 7 is near end-of-life. Should I port my scripts to Groovy in order to be safe?


From swhitemanlistens-software at figureone.com  Mon Mar  9 16:53:40 2015
From: swhitemanlistens-software at figureone.com (Sanford Whiteman)
Date: Mon, 9 Mar 2015 12:53:40 -0400
Subject: Serious bug: "finally" block is run whenever "continue" is reached
In-Reply-To: <54FDC787.8030403@threecrickets.com>
References: <54FC54D8.2010302@threecrickets.com> <54FC5B17.3000404@gmail.com> 
	<8CD3A95C-14E0-4522-9F45-4DD8BD37BDF0@oracle.com>,
	<54FD9E88.3020802@threecrickets.com>
	<E8515F59548A814D811800C0D441763647D748E6@ATRZEXMBX3.grawe.at>
	<54FDC787.8030403@threecrickets.com>
Message-ID: <1773197694.20150309125340@figureone.com>

> if I build it from hg, it is always
> marked  as version "0.1". Why not have Nashorn have its own internal
> version march, parallel but ultimately separate from the JDK?

+1  to  the fullest. I found this very confusing and can't imagine how
it would help testing to have -fv give the same result.

-- Sandy


From kajmagnus79 at gmail.com  Mon Mar  9 21:20:30 2015
From: kajmagnus79 at gmail.com (Kaj Magnus Lindberg)
Date: Mon, 9 Mar 2015 22:20:30 +0100
Subject: Nashorn bug in Java 8 u40: Cannot parse JSON: { 0: null, 100:
	null }
In-Reply-To: <270060D8-DF6C-48AB-AEC0-F0FC5EB3F665@oracle.com>
References: <CAKb=CAqxJMGm5m6E0SiN64k5SLO==breiOPPCtQtS2Ek32YZzQ@mail.gmail.com>
	<54FD75C2.1070003@oracle.com>
	<270060D8-DF6C-48AB-AEC0-F0FC5EB3F665@oracle.com>
Message-ID: <CAKb=CAqQh4YixSpqhb=poYcJXQrwc8-VExsSLR+3GzFxTzK37Q@mail.gmail.com>

Hi Hannes and Marcus,

Thanks for your emails. I'll either give 8u60-early-access a try then, or
continue using the old 8uWhatever version I'm using now.

(B.t.w. I use Nashorn to run React.js server side and it works really
great, I like Scala + Nashorn & React a lot :-)  .)

Best regards,
KajMagnus



On Mon, Mar 9, 2015 at 4:53 PM, Marcus Lagergren <
marcus.lagergren at oracle.com> wrote:

> Hi Kaj Magnus,
>
> We still don?t have a huge user base, but we are working hard on building
> up our test coverage. Hence, we get some small embarrassments like this
> from time to time, but they will hopefully get less frequent soon. You will
> find that most issues will be addressed quicker than new releases come out.
> You can track the issues in JIRA to see where the fixes are checked in.
> Should an emergency arise, you can always build the latest Nashorn from
> source. Being open source, our fixes are visible to the world immediately,
> even though they are not bundled. Naturally, we will push very hard to get
> them into as early a release as we can, too.
>
> /M
>
> > On 09 Mar 2015, at 11:28, Hannes Wallnoefer <
> hannes.wallnoefer at oracle.com> wrote:
> >
> > Hi Kaj Magnus,
> >
> > Thanks for the report. It's unfortunate this bug ended up in 8u40.
> Obviously the fix for the bug you linked was incomplete, and we weren't
> aware of that.
> >
> > The problem has been fixed in the meantime (together with a rewrite of
> the JSON parser that makes JSON parsing much faster). The fix will be part
> of the 8u60 release. The current 8u60 early access release available at
> https://jdk8.java.net/download.html already contains the fix.
> >
> > I'm also adding additional tests so this won't happen again:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8074687
> >
> > Regards,
> > Hannes
> >
> > Am 2015-03-08 um 06:20 schrieb Kaj Magnus Lindberg:
> >> Hi dear Nashorn developers,
> >>
> >> There's an ArrayIndexOutOfBoundsException bug when I try to parse this
> >> JSON: '{ "0":null, "100": null }'.
> >>
> >> Have a look here:
> >>
> >> jjs> JSON.parse('{ "0":null, "65503": null }')
> >> java.lang.ArrayIndexOutOfBoundsException: Array index out of range:
> 65503
> >> jjs>
> >> jjs> JSON.parse('{ "0":null, "100": null }')
> >> java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 100
> >> jjs>
> >> jjs> JSON.parse('{ "0":null, "65": null }')
> >> java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 65
> >> jjs>
> >> jjs> JSON.parse('{ "0":null, "64": null }')  // Works
> >> [object Object]
> >> jjs>
> >> jjs> JSON.parse('{ "_0":null, "_100": null }')  // Works
> >> [object Object]
> >> jjs>
> >> jjs>
> >>
> >> I found a bug report that was fixed that made { 0: null, 64: null }
> work.
> >> But as you can see above, { 0: null, 65: null } doesn't work.
> >>   https://bugs.openjdk.java.net/browse/JDK-8048718
> >>
> >> Version details:
> >>
> >> $ java -version
> >> java version "1.8.0_40"
> >> Java(TM) SE Runtime Environment (build 1.8.0_40-b25)
> >> Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)
> >>
> >> $ uname -a
> >> Linux kajmagnus-lt-15 3.19.0-031900-generic #201502091451 SMP Mon Feb 9
> >> 14:52:52 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> >>
> >> $ cat /etc/issue
> >> Linux Mint 17.1 Rebecca \n \l
> >>
> >> (This bug wasn't present in an earlier Nashorn version, u20 or u22 or
> >> something like that.)
> >>
> >> Best regards,
> >> KajMagnus
> >
>
>

From attila.szegedi at oracle.com  Mon Mar  9 22:58:33 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 9 Mar 2015 23:58:33 +0100
Subject: Serious bug: "finally" block is run whenever "continue" is reached
In-Reply-To: <54FD9E88.3020802@threecrickets.com>
References: <54FC54D8.2010302@threecrickets.com> <54FC5B17.3000404@gmail.com>
	<8CD3A95C-14E0-4522-9F45-4DD8BD37BDF0@oracle.com>
	<54FD9E88.3020802@threecrickets.com>
Message-ID: <A96ADD96-247B-48BD-AF61-57161B7B32CE@oracle.com>

On Mar 9, 2015, at 2:22 PM, Tal Liron <tal.liron at threecrickets.com> wrote:

> Could you possibly articulate 1) *exactly* what the issue is, 

Well, your case is peculiar. My suspicion was originally that the issue only occurred in situations where transfer of control happens to outside the try/finally (e.g. continue/break jumps to outside of try/finally) *and* you had a catch block *and* the finally block also threw an exception. In that case, the catch block that was a sibling to the finally block could have caught the exception erroneously. I'll set up a dev environment with the code before my try/finally compilation rewrite and get back to you when I understand why was this one compiled erroneously.

Mind you, I didn't just do a point fix of that one problem but re-thought how Nashorn compiles try/finally, so I can confirm that my rewrite fixed your issue too.

> 2) how to search for potential issues in my vast amount of JavaScript code, 3) and how to work around it?

I just had an in-the-shower idea. I can take 8u40 code, add some light logging to it (basically add a log for "inlined finally block from line x to line y"; in your example program it'd say "inlined finally block from line 11 to line 5" (that's what the bug is about ? having to inline finally blocks at nonlocal transfer of control points to outside the try block; the bug is that in your case the target of the continue is within the try block, so no inlining should happen). I can add the same logging code to 8u60 codebase. Then I could give you an utility that compiles your source code with both versions, and prints the log diff. As I trust that 8u60 finally-inlining logic is sound, any difference between the two will point out a location in your source code that pre-8u60 was incorrectly inlining.

As for workaround; I don't know; I need to first understand why it happens (see my answer to your point 1).

> The problem is that I'm not self-deploying: I am building products that run on top of the JVM with JavaScript, and yet I cannot recommend Nashorn to anyone in its current state. At the very least, I can make sure that my own JavaScript code works with 8u40.

> Actually, the "meta" bug here is that Nashorn's release system is broken: these kinds of breaking bugs need an immediate notice and a fix released to the public. And yet Nashorn is tied to JDK releases, which are once every six months. Something is very wrong about this system, and I'm sure it must be frustrating to the Nashorn team, too.

Yes, being tied to the release cycle of the JDK can obviously be frustrating in situations like these. I'm very concerned about the pain that this is causing users. FWIW, we also have CPU (Critical Patch Update) releases. Next one (8u45) is coming up in mid-April. I can't promise a fix will get into a CPU release as the decision to include something into a CPU is not mine; I can only nominate a fix it for it.

> Barring the possibility of a bugfix release, there *must* to be a "known issues" right there on the JDK download page. You simply cannot release a JavaScript engine to the public that does not honor try/finally.

I entirely agree with you. I was quite horrified when I realized Nashorn has this problem. (As I said, it's an ancient (in Nashorn time) compiler logic bug, I can track it to before the initial release.) I spent good two weeks understanding the problem and rewriting the relevant compiler pipeline parts to make sure try/finally is correctly compiled under all circumstances. I wish I could've completed it in time for 8u40.

The reason I didn't think it warrants mention (unlike that vararg array issue I wrote an e-mail about upon 8u40 release) was that "it has always been like this", and we sincerely believed it only affects the very specific case I explained above (transfer of control to outside of try block + catch block + finally block itself throws) that felt extremely rare, and hey, nobody complained about it for more than a year. Your case is something else though.

So my action plan for this is: 1. nominate the fix for inclusion into a CPU release 2. whip up a small one-off tool that'd show you the differences in finally inlining between 8u40 and 8u60 code. That should help you find the trouble spots in your code. 3. understand what caused the faulty inlining in your case that will hopefully let me suggest a workaround for the time being.

Attila.

> 
> On 03/09/2015 02:48 AM, Attila Szegedi wrote:
>> This isn't new to 8u40; I just tested, and it's broken in 8u31 and 8u25 too. If I had to guess, it has been like this since the initial release. I base my guess on the fact that the way Nashorn compiled finally blocks in presence of control flow transfers (break/continue/return) was unfortunately broken, I myself discovered this last December and fixed it early February ? that's indeed the JIRA issue that Anthony pointed out. Unfortunately, it didn't make it in time for 8u40 :-(
> 


From tal.liron at threecrickets.com  Tue Mar 10 00:34:02 2015
From: tal.liron at threecrickets.com (Tal Liron)
Date: Mon, 09 Mar 2015 19:34:02 -0500
Subject: Serious bug: "finally" block is run whenever "continue" is reached
In-Reply-To: <A96ADD96-247B-48BD-AF61-57161B7B32CE@oracle.com>
References: <54FC54D8.2010302@threecrickets.com> <54FC5B17.3000404@gmail.com>
	<8CD3A95C-14E0-4522-9F45-4DD8BD37BDF0@oracle.com>
	<54FD9E88.3020802@threecrickets.com>
	<A96ADD96-247B-48BD-AF61-57161B7B32CE@oracle.com>
Message-ID: <54FE3BFA.3000809@threecrickets.com>

Thank you, Atilla, your response does inspire confidence.

I will just add that it's not just me that would need this tool: none of 
us can afford to have a broken try/finally.

On 03/09/2015 05:58 PM, Attila Szegedi wrote:
> So my action plan for this is: 1. nominate the fix for inclusion into 
> a CPU release 2. whip up a small one-off tool that'd show you the 
> differences in finally inlining between 8u40 and 8u60 code. That 
> should help you find the trouble spots in your code. 3. understand 
> what caused the faulty inlining in your case that will hopefully let 
> me suggest a workaround for the time being. Attila.


From attila.szegedi at oracle.com  Tue Mar 10 13:10:19 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 10 Mar 2015 14:10:19 +0100
Subject: Serious bug: "finally" block is run whenever "continue" is reached
In-Reply-To: <54FE3BFA.3000809@threecrickets.com>
References: <54FC54D8.2010302@threecrickets.com> <54FC5B17.3000404@gmail.com>
	<8CD3A95C-14E0-4522-9F45-4DD8BD37BDF0@oracle.com>
	<54FD9E88.3020802@threecrickets.com>
	<A96ADD96-247B-48BD-AF61-57161B7B32CE@oracle.com>
	<54FE3BFA.3000809@threecrickets.com>
Message-ID: <0D890505-1FEB-478B-A244-2FD7E6F8F3BD@oracle.com>

I have understood the extent of the issue, and it is not pretty. Basically, it affects every code shape with a continue or break in a try/finally. I put up a small test here: https://gist.github.com/szegedi/22d634d70d422445be9a It passes with 9 and 8u60 builds, but fails with all released JDK 8 versions up to and including 8u40. I was curious how could this go on for this long undetected. I tallied all of the tests that we run on every build that have the words "finally" and either "break" or "continue" in them, including jquery, sunspider, octane, and test262.ecmascript.org tests. We have 9 own tests, test262 suite has 17, and the rest of the tests (octane etc. combined) have 20 files where these occur. Turns out, even the ~11.500 test262 test suite doesn't test this exact scenario :-( There's some tests with a loop in a try/finally, but they only test exiting those loops with a throw, and don't consider break/continue where the control flow stays within the try finally. Come to think of it, that's actually not even a special case, so I can sort-of understand why it wouldn't be tested separately. I'll definitely be adding that gist as a test to Nashorn.

In light of this, I'm not sure if I need to write a tool for finding occurrences, as the rule is quite simple (unfortunately): every break/continue inside a try/finally is affected. More precisely: every break/continue lexically found in a try/finally within the same function body is affected.

This also gives us a workaround: encapsulating the code surrounding an affected break/continue into a function expression, e.g. in your original example:

var finalies = 1
var line = 'TEST THIS LINE'
try {
    (function(){ // <---
    while ('' !== (line = line.substring(0, line.length - 1))) {
        if (line.length % 2 == 0) {
            continue
        }
        java.lang.System.out.println(line)
    }
    })(); // <---
} finally {
    java.lang.System.out.println('Finalies ' + (finalies++))
}

Of course, it doesn't have to be an immediately-invoked-anonymous-function-expression; you can structure it as a named function you invoke too. It ain't too pretty, but workarounds seldom are. You can also play with passing parameters for better local access performance in the new function body, e.g.

    (function(line){
    ...
    })(line);

Hope this helps until we ship the real fix.
  Attila.

On Mar 10, 2015, at 1:34 AM, Tal Liron <tal.liron at threecrickets.com> wrote:

> Thank you, Atilla, your response does inspire confidence.
> 
> I will just add that it's not just me that would need this tool: none of us can afford to have a broken try/finally.
> 
> On 03/09/2015 05:58 PM, Attila Szegedi wrote:
>> So my action plan for this is: 1. nominate the fix for inclusion into a CPU release 2. whip up a small one-off tool that'd show you the differences in finally inlining between 8u40 and 8u60 code. That should help you find the trouble spots in your code. 3. understand what caused the faulty inlining in your case that will hopefully let me suggest a workaround for the time being. Attila.
> 


From hannes.wallnoefer at oracle.com  Tue Mar 10 14:26:33 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 10 Mar 2015 15:26:33 +0100
Subject: Review request for JDK-8074693: Different instances of same function
	use same allocator map
Message-ID: <54FEFF19.4060909@oracle.com>

Please review JDK-8074693: Different instances of same function use same 
allocator map:

http://cr.openjdk.java.net/~hannesw/8074693/

This delays creation of allocator class name and property map until a 
function is actually invoked as constructor, but also makes sure each 
function instance gets its own allocator map (as it also has its own 
allocator prototype).

Thanks,
Hannes


From hannes.wallnoefer at oracle.com  Tue Mar 10 14:31:06 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 10 Mar 2015 15:31:06 +0100
Subject: Review request for JDK-8074687: Add tests for JSON parsing of numeric
	keys
Message-ID: <54FF002A.4090806@oracle.com>

Please review JDK-8074687: Add tests for JSON parsing of numeric keys:

http://cr.openjdk.java.net/~hannesw/8074687/

Thanks,
Hannes

From sundararajan.athijegannathan at oracle.com  Tue Mar 10 14:31:36 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 10 Mar 2015 20:01:36 +0530
Subject: Review request for JDK-8074687: Add tests for JSON parsing of
	numeric keys
In-Reply-To: <54FF002A.4090806@oracle.com>
References: <54FF002A.4090806@oracle.com>
Message-ID: <54FF0048.1090805@oracle.com>

+1

On Tuesday 10 March 2015 08:01 PM, Hannes Wallnoefer wrote:
> Please review JDK-8074687: Add tests for JSON parsing of numeric keys:
>
> http://cr.openjdk.java.net/~hannesw/8074687/
>
> Thanks,
> Hannes


From tal.liron at threecrickets.com  Tue Mar 10 14:50:42 2015
From: tal.liron at threecrickets.com (Tal Liron)
Date: Tue, 10 Mar 2015 09:50:42 -0500
Subject: Serious bug: "finally" block is run whenever "continue" is reached
In-Reply-To: <0D890505-1FEB-478B-A244-2FD7E6F8F3BD@oracle.com>
References: <54FC54D8.2010302@threecrickets.com> <54FC5B17.3000404@gmail.com>
	<8CD3A95C-14E0-4522-9F45-4DD8BD37BDF0@oracle.com>
	<54FD9E88.3020802@threecrickets.com>
	<A96ADD96-247B-48BD-AF61-57161B7B32CE@oracle.com>
	<54FE3BFA.3000809@threecrickets.com>
	<0D890505-1FEB-478B-A244-2FD7E6F8F3BD@oracle.com>
Message-ID: <54FF04C2.7070500@threecrickets.com>

Thank you. I think this is a good workaround, because it lets us keep 
the try/finally semantics while continuing to function the same in the 
future, when the bug is fixed.

I'll insist that I think you absolutely must make this bug very public 
and prominent, so that all those who download JDK 8 are aware of it. I 
know it won't feel good to admit it publicly, but it is your 
responsibility to users and in the long run will help build trust and 
encourage adoption.

On 03/10/2015 08:10 AM, Attila Szegedi wrote:
> Hope this helps until we ship the real fix.
>   Attila.
>


From attila.szegedi at oracle.com  Tue Mar 10 16:20:13 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 10 Mar 2015 17:20:13 +0100
Subject: Review request for JDK-8074687: Add tests for JSON parsing of
	numeric keys
In-Reply-To: <54FF002A.4090806@oracle.com>
References: <54FF002A.4090806@oracle.com>
Message-ID: <F858974D-A6A2-4607-B688-B1C646616259@oracle.com>

+1

On Mar 10, 2015, at 3:31 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8074687: Add tests for JSON parsing of numeric keys:
> 
> http://cr.openjdk.java.net/~hannesw/8074687/
> 
> Thanks,
> Hannes


From attila.szegedi at oracle.com  Tue Mar 10 16:59:15 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 10 Mar 2015 17:59:15 +0100
Subject: Review request for JDK-8074693: Different instances of same
	function use same allocator map
In-Reply-To: <54FEFF19.4060909@oracle.com>
References: <54FEFF19.4060909@oracle.com>
Message-ID: <83E955A1-7CD0-4EF3-BB08-0EA8D0C4F61D@oracle.com>

+1

On Mar 10, 2015, at 3:26 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8074693: Different instances of same function use same allocator map:
> 
> http://cr.openjdk.java.net/~hannesw/8074693/
> 
> This delays creation of allocator class name and property map until a function is actually invoked as constructor, but also makes sure each function instance gets its own allocator map (as it also has its own allocator prototype).
> 
> Thanks,
> Hannes
> 


From tonyzakula at gmail.com  Tue Mar 10 23:52:36 2015
From: tonyzakula at gmail.com (Tony Zakula)
Date: Tue, 10 Mar 2015 18:52:36 -0500
Subject: Serious bug: "finally" block is run whenever "continue" is reached
In-Reply-To: <54FF04C2.7070500@threecrickets.com>
References: <54FC54D8.2010302@threecrickets.com> <54FC5B17.3000404@gmail.com>
	<8CD3A95C-14E0-4522-9F45-4DD8BD37BDF0@oracle.com>
	<54FD9E88.3020802@threecrickets.com>
	<A96ADD96-247B-48BD-AF61-57161B7B32CE@oracle.com>
	<54FE3BFA.3000809@threecrickets.com>
	<0D890505-1FEB-478B-A244-2FD7E6F8F3BD@oracle.com>
	<54FF04C2.7070500@threecrickets.com>
Message-ID: <CAC_sW-cwhcr_=cLJuONyrat4zbFLQNQ1+NzBzKf_Q6QNbCfMuQ@mail.gmail.com>

Just want to make sure the Nashorn team knows that we all appreciate their
work.  These things happen with a complex project.  Super happy Nashorn is
happening for the Java community.

On Tue, Mar 10, 2015 at 9:50 AM, Tal Liron <tal.liron at threecrickets.com>
wrote:

> Thank you. I think this is a good workaround, because it lets us keep the
> try/finally semantics while continuing to function the same in the future,
> when the bug is fixed.
>
> I'll insist that I think you absolutely must make this bug very public and
> prominent, so that all those who download JDK 8 are aware of it. I know it
> won't feel good to admit it publicly, but it is your responsibility to
> users and in the long run will help build trust and encourage adoption.
>
>
> On 03/10/2015 08:10 AM, Attila Szegedi wrote:
>
>> Hope this helps until we ship the real fix.
>>   Attila.
>>
>>
>

From kcholera at linkedin.com  Wed Mar 11 01:32:01 2015
From: kcholera at linkedin.com (Kunal Cholera)
Date: Wed, 11 Mar 2015 01:32:01 +0000
Subject: Questions about how to use persistent code cache correctly in JDK-8u40
Message-ID: <897090CCBF073241BB0F302E81C704D80100E8DD57@ESV4-MB02.linkedin.biz>

Hello Nahsorn dev team,

Currently I am using -pcc flag using this command ?jjs bench.js -scripting -pcc=true -- 10000? [1] to use the persistent code cache feature. Across different runs using jjs I see the first few javascript executions always take very long. For e.g. the first run execution times(ms) were ?993,149,141,121,102,94,101,86,80...?, second run execution times (ms) were ?796,148,137,135,107,102,96,95,95...?. I was expecting the second run would be much faster and start off at <100ms since the nashorn_code_cache already existed from the first run. Raw data - https://plot.ly/~usckmc/182 (see column with pcc=true for persistent code cache data)

I have three questions around persistent code cache usage -

1. Am I using the persistent code cache feature correctly by just specifying the -pcc=true parameter ?

2. Can these compiled scripts under nashorn_code_cache be used across different machines or different nashorn instances on the same machine? if so how can we specify to Nashorn to reuse an existing code cache folder when it starts up? There is a flag -Dnashorn.persistent.code.cache to specify where the code cache should be generated, but I could not find a way to specify to Nashorn where to pick up existing code cache.

3. Does the compiled code change after many executions because of any optimization? If so how can we reuse this compiled code cache across different machines ?

[1**]
Steps to reproduce these performance numbers -
Download this zip https://drive.google.com/file/d/0B5PpdCJ7YycqMWlVQ0FsNlozcTA/view?usp=sharing which has the following four files
1. bench.js - the benchmarking script
2. hp.js - the javascript we want to execute on Nashorn
3. hp.json - the data we want to use while executing our script hp.js
4. dust-full.js - library needed to execute hp.js script

I am using "1.8.0_40-ea" Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b25 on 8 core redhat linux machine ).

Please advise.

Thanks
Kunal Cholera

From kcholera at linkedin.com  Wed Mar 11 01:42:46 2015
From: kcholera at linkedin.com (Kunal Cholera)
Date: Wed, 11 Mar 2015 01:42:46 +0000
Subject: Question about --lazy-comopilation=false in JDK-8u40-b25
Message-ID: <897090CCBF073241BB0F302E81C704D80100E8DD97@ESV4-MB02.linkedin.biz>

Hello Nahsorn dev team,

Is it a good idea to turn off lazy compilation to get faster warmup and better overall performance over long run ? Execution time on our javascript shows that turning off lazy outperforms persistent code cache and optimistic types. See data with column_name ?lazy=false? in https://plot.ly/~usckmc/182 [1] .Here is the graph comparing8u40 with and without lazy compilation(lazy=false) https://drive.google.com/file/d/0B5PpdCJ7YycqVlhlSnJfTl9ac00/view . Is that expected ?

>From xhelp we got very little information about what lazy-compilation is doing: --lazy-compilation (do not compile the entire script at once, default: true). Can you provide more insights about what this feature does and what scenarios might benefit from its use?

[1]
Steps to reproduce these performance numbers -
Download this ziphttps://drive.google.com/file/d/0B5PpdCJ7YycqMWlVQ0FsNlozcTA/view?usp=sharing which has the following four files
1. bench.js - the benchmarking script
2. hp.js - the javascript we want to execute on Nashorn
3. hp.json - the data we want to use while executing our script hp.js
4. dust-full.js - library needed to execute hp.js script

run jjs bench.js -scripting --lazy-compilation=false -- 10000

I am using "1.8.0_40-ea" Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b25 on 8 core redhat linux machine ).

Please advise.

Thanks
Kunal Cholera

From kcholera at linkedin.com  Wed Mar 11 01:52:13 2015
From: kcholera at linkedin.com (Kunal Cholera)
Date: Wed, 11 Mar 2015 01:52:13 +0000
Subject: Effective warmup strategy for Nashorn - JDK-8u40-b25
Message-ID: <897090CCBF073241BB0F302E81C704D80100E8DDC5@ESV4-MB02.linkedin.biz>

Hello Nahsorn dev team,

Currently our warmup strategy does the following - before our application starts serving request to real users we create 24 Nashorn instances. We are limiting to 24 as we have 24 CPU cores per machine in production. We then load the javascript files into this nashorn instances to setup the context for javascript execution. We then execute each of these javascript 2000 times with mock data to warmup the execution times.

We have observed it takes about 4000 iterations[1] to reach optimal performance. See the graph here that shows 4000 javascript executions on 1 javascript file -
https://drive.google.com/file/d/0B5PpdCJ7YycqbDJBWGRRVjRsYVU/view?usp=sharing

Three questions
1.What is the best way to quickly warm-up to reach optimal performance in fewer iterations ?

2. Is there a better way to warmup using fixture data as opposed to fake data which we have to maintain ?

3. Is there a way to clone 1 nashorn instances that is warmed up so that we can avoid doing the same warmup for other nashorn instances ?

[1]
Steps to reproduce these performance numbers -
Download this ziphttps://drive.google.com/file/d/0B5PpdCJ7YycqMWlVQ0FsNlozcTA/view?usp=sharing which has the following four files
1. bench.js - the benchmarking script
2. hp.js - the javascript we want to execute on Nashorn
3. hp.json - the data we want to use while executing our script hp.js
4. dust-full.js - library needed to execute hp.js script

I am using "1.8.0_40-ea" Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b25 on 8 core redhat linux machine ).

Please advise.

Thanks
Kunal Cholera

From kcholera at linkedin.com  Wed Mar 11 02:05:38 2015
From: kcholera at linkedin.com (Kunal Cholera)
Date: Wed, 11 Mar 2015 02:05:38 +0000
Subject: Effective warmup strategy for Nashorn - JDK-8u40-b25
In-Reply-To: <897090CCBF073241BB0F302E81C704D80100E8DDC5@ESV4-MB02.linkedin.biz>
References: <897090CCBF073241BB0F302E81C704D80100E8DDC5@ESV4-MB02.linkedin.biz>
Message-ID: <897090CCBF073241BB0F302E81C704D80100E8DE33@ESV4-MB02.linkedin.biz>

zip location - https://drive.google.com/file/d/0B5PpdCJ7YycqMWlVQ0FsNlozcTA/view?usp=sharing


________________________________________
From: nashorn-dev [nashorn-dev-bounces at openjdk.java.net] on behalf of Kunal Cholera [kcholera at linkedin.com]
Sent: Tuesday, March 10, 2015 6:52 PM
To: nashorn-dev at openjdk.java.net
Subject: Effective warmup strategy for Nashorn - JDK-8u40-b25

Hello Nahsorn dev team,

Currently our warmup strategy does the following - before our application starts serving request to real users we create 24 Nashorn instances. We are limiting to 24 as we have 24 CPU cores per machine in production. We then load the javascript files into this nashorn instances to setup the context for javascript execution. We then execute each of these javascript 2000 times with mock data to warmup the execution times.

We have observed it takes about 4000 iterations[1] to reach optimal performance. See the graph here that shows 4000 javascript executions on 1 javascript file -
https://drive.google.com/file/d/0B5PpdCJ7YycqbDJBWGRRVjRsYVU/view?usp=sharing

Three questions
1.What is the best way to quickly warm-up to reach optimal performance in fewer iterations ?

2. Is there a better way to warmup using fixture data as opposed to fake data which we have to maintain ?

3. Is there a way to clone 1 nashorn instances that is warmed up so that we can avoid doing the same warmup for other nashorn instances ?

[1]
Steps to reproduce these performance numbers -
Download this zip https://drive.google.com/file/d/0B5PpdCJ7YycqMWlVQ0FsNlozcTA/view?usp=sharing which has the following four files
1. bench.js - the benchmarking script
2. hp.js - the javascript we want to execute on Nashorn
3. hp.json - the data we want to use while executing our script hp.js
4. dust-full.js - library needed to execute hp.js script

I am using "1.8.0_40-ea" Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b25 on 8 core redhat linux machine ).

Please advise.

Thanks
Kunal Cholera

From kcholera at linkedin.com  Wed Mar 11 02:07:20 2015
From: kcholera at linkedin.com (Kunal Cholera)
Date: Wed, 11 Mar 2015 02:07:20 +0000
Subject: Question about --lazy-comopilation=false in JDK-8u40-b25
In-Reply-To: <897090CCBF073241BB0F302E81C704D80100E8DD97@ESV4-MB02.linkedin.biz>
References: <897090CCBF073241BB0F302E81C704D80100E8DD97@ESV4-MB02.linkedin.biz>
Message-ID: <897090CCBF073241BB0F302E81C704D80100E8E04A@ESV4-MB02.linkedin.biz>

zip location - https://drive.google.com/file/d/0B5PpdCJ7YycqMWlVQ0FsNlozcTA/view?usp=sharing

________________________________________
From: nashorn-dev [nashorn-dev-bounces at openjdk.java.net] on behalf of Kunal Cholera [kcholera at linkedin.com]
Sent: Tuesday, March 10, 2015 6:42 PM
To: nashorn-dev at openjdk.java.net
Subject: Question about --lazy-comopilation=false in JDK-8u40-b25

Hello Nahsorn dev team,

Is it a good idea to turn off lazy compilation to get faster warmup and better overall performance over long run ? Execution time on our javascript shows that turning off lazy outperforms persistent code cache and optimistic types. See data with column_name ?lazy=false? in https://plot.ly/~usckmc/182 [1] .Here is the graph comparing8u40 with and without lazy compilation(lazy=false) https://drive.google.com/file/d/0B5PpdCJ7YycqVlhlSnJfTl9ac00/view . Is that expected ?

>From xhelp we got very little information about what lazy-compilation is doing: --lazy-compilation (do not compile the entire script at once, default: true). Can you provide more insights about what this feature does and what scenarios might benefit from its use?

[1]
Steps to reproduce these performance numbers -
Download this zip https://drive.google.com/file/d/0B5PpdCJ7YycqMWlVQ0FsNlozcTA/view?usp=sharing which has the following four files
1. bench.js - the benchmarking script
2. hp.js - the javascript we want to execute on Nashorn
3. hp.json - the data we want to use while executing our script hp.js
4. dust-full.js - library needed to execute hp.js script

run jjs bench.js -scripting --lazy-compilation=false -- 10000

I am using "1.8.0_40-ea" Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b25 on 8 core redhat linux machine ).

Please advise.

Thanks
Kunal Cholera

From sundararajan.athijegannathan at oracle.com  Wed Mar 11 03:40:53 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 11 Mar 2015 09:10:53 +0530
Subject: RFR 8074939: Add few sample scripts to demo nashorn parser API
Message-ID: <54FFB945.7090103@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8074939/

PS. Piggybacking two unrelated, but useful samples as well.

Thanks,
-Sundar

From attila.szegedi at oracle.com  Wed Mar 11 08:23:02 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 11 Mar 2015 09:23:02 +0100
Subject: RFR 8074939: Add few sample scripts to demo nashorn parser API
In-Reply-To: <54FFB945.7090103@oracle.com>
References: <54FFB945.7090103@oracle.com>
Message-ID: <9899DD4F-30F7-49CD-9B90-BE1C593604FF@oracle.com>

+1. I can see myself using the AST viewer while working on Nashorn ? great!

Attila.

On Mar 11, 2015, at 4:40 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8074939/
> 
> PS. Piggybacking two unrelated, but useful samples as well.
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Wed Mar 11 08:42:58 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 11 Mar 2015 09:42:58 +0100
Subject: RFR 8074939: Add few sample scripts to demo nashorn parser API
In-Reply-To: <54FFB945.7090103@oracle.com>
References: <54FFB945.7090103@oracle.com>
Message-ID: <55000012.3070900@oracle.com>

+1

Nice! It would be nice if the scripts would accept a single file as 
argument in addition to a directory as I often find myself working with 
single huge JS files.

Thanks,
Hannes

Am 2015-03-11 um 04:40 schrieb A. Sundararajan:
> Please review http://cr.openjdk.java.net/~sundar/8074939/
>
> PS. Piggybacking two unrelated, but useful samples as well.
>
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Wed Mar 11 08:58:30 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 11 Mar 2015 14:28:30 +0530
Subject: RFR 8074939: Add few sample scripts to demo nashorn parser API
In-Reply-To: <55000012.3070900@oracle.com>
References: <54FFB945.7090103@oracle.com> <55000012.3070900@oracle.com>
Message-ID: <550003B6.9080707@oracle.com>

Fixed it. Uploaded webrev for reference 
http://cr.openjdk.java.net/~sundar/8074939/webrev.01/

PS. Since it is a minor change suggested, I'm going ahead with pushing it..

Thanks,
-Sundar

On Wednesday 11 March 2015 02:12 PM, Hannes Wallnoefer wrote:
> +1
>
> Nice! It would be nice if the scripts would accept a single file as 
> argument in addition to a directory as I often find myself working 
> with single huge JS files.
>
> Thanks,
> Hannes
>
> Am 2015-03-11 um 04:40 schrieb A. Sundararajan:
>> Please review http://cr.openjdk.java.net/~sundar/8074939/
>>
>> PS. Piggybacking two unrelated, but useful samples as well.
>>
>> Thanks,
>> -Sundar
>


From sundararajan.athijegannathan at oracle.com  Wed Mar 11 09:06:28 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 11 Mar 2015 14:36:28 +0530
Subject: Serious bug: "finally" block is run whenever "continue" is reached
In-Reply-To: <CAC_sW-cwhcr_=cLJuONyrat4zbFLQNQ1+NzBzKf_Q6QNbCfMuQ@mail.gmail.com>
References: <54FC54D8.2010302@threecrickets.com>
	<54FC5B17.3000404@gmail.com>	<8CD3A95C-14E0-4522-9F45-4DD8BD37BDF0@oracle.com>	<54FD9E88.3020802@threecrickets.com>	<A96ADD96-247B-48BD-AF61-57161B7B32CE@oracle.com>	<54FE3BFA.3000809@threecrickets.com>	<0D890505-1FEB-478B-A244-2FD7E6F8F3BD@oracle.com>	<54FF04C2.7070500@threecrickets.com>
	<CAC_sW-cwhcr_=cLJuONyrat4zbFLQNQ1+NzBzKf_Q6QNbCfMuQ@mail.gmail.com>
Message-ID: <55000594.2010508@oracle.com>

You can use this script

http://hg.openjdk.java.net/jdk9/dev/nashorn/file/829e3b95b319/samples/breakcontinue_in_tryfinally.js 


to locate all such break/continue in try..finally to apply the workaround.

As this one uses Nashorn parser API in jdk9-dev, you've to follow these 
steps:

$ hg clone http://hg.openjdk.java.net/jdk9/dev/nashorn
$ cd make
$ ant clean jar
$ cd samples
$ jjs -J-Djava.ext.dirs=../dist breakcontinue_in_tryfinally.js  -- 
<your-root-script-dir>

This will report all break/continue within try..finally in every .js of 
your root script dir (recursive scan)

Hope this helps,
-Sundar

On Wednesday 11 March 2015 05:22 AM, Tony Zakula wrote:
> Just want to make sure the Nashorn team knows that we all appreciate their
> work.  These things happen with a complex project.  Super happy Nashorn is
> happening for the Java community.
>
> On Tue, Mar 10, 2015 at 9:50 AM, Tal Liron <tal.liron at threecrickets.com>
> wrote:
>
>> Thank you. I think this is a good workaround, because it lets us keep the
>> try/finally semantics while continuing to function the same in the future,
>> when the bug is fixed.
>>
>> I'll insist that I think you absolutely must make this bug very public and
>> prominent, so that all those who download JDK 8 are aware of it. I know it
>> won't feel good to admit it publicly, but it is your responsibility to
>> users and in the long run will help build trust and encourage adoption.
>>
>>
>> On 03/10/2015 08:10 AM, Attila Szegedi wrote:
>>
>>> Hope this helps until we ship the real fix.
>>>    Attila.
>>>
>>>


From marcus.lagergren at oracle.com  Wed Mar 11 09:08:57 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 11 Mar 2015 10:08:57 +0100
Subject: Review request for JDK-8074693: Different instances of same
	function use same allocator map
In-Reply-To: <54FEFF19.4060909@oracle.com>
References: <54FEFF19.4060909@oracle.com>
Message-ID: <46FA43BB-0FDE-42A7-AEB7-D56B9456802D@oracle.com>

+1

> On 10 Mar 2015, at 15:26, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review JDK-8074693: Different instances of same function use same allocator map:
> 
> http://cr.openjdk.java.net/~hannesw/8074693/
> 
> This delays creation of allocator class name and property map until a function is actually invoked as constructor, but also makes sure each function instance gets its own allocator map (as it also has its own allocator prototype).
> 
> Thanks,
> Hannes
> 


From hannes.wallnoefer at oracle.com  Wed Mar 11 09:18:57 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 11 Mar 2015 10:18:57 +0100
Subject: Review request for JDK-8072426
In-Reply-To: <03102C38-0B8D-49DC-96A8-E1286675D6D6@oracle.com>
References: <A5E06E32-726E-4080-A8CB-696FC191CFD1@oracle.com>	<54E6F4C5.1090402@oracle.com>
	<03102C38-0B8D-49DC-96A8-E1286675D6D6@oracle.com>
Message-ID: <55000881.9050102@oracle.com>

+1

Am 2015-03-08 um 14:29 schrieb Attila Szegedi:
> Thanks for the reviews. In order to backport this to 8u-dev, I had to make some changes. Namely, since we introduced a default method into the JSObject interface, we could not compile this under jdk8u-dev, as for JDK 8 Nashorn is compiled with "-source 7" as the part of the build process is running Nasgen, which is done with the boot JDK, which is a JDK 7 for 8u[*].
>
> For this reason, the 8u backport doesn't add a new getDefaultValue() method to the JSObject interface, as that ? without the default methods' ability ? wouldn't be a binary compatible class change. Instead, AbstractJSObject gains a getDefaultValue(hint) method with the same behavior as well as a static helper getDefaultValue(jsobj, hint) that delegates to AbstractJSObject.getDefaultValue() for AbstractJSObject, and runs the generic algorithm for any other JSObject. (As a separate task, we'll need to forward-port this static helper into JDK 9 codebase so it stays compatible with 8; I'll soon file a JIRA for that.)
>
> With these in mind, please review the backport changeset at <http://cr.openjdk.java.net/~attila/8072426/webrev.8u>
>
> Thanks,
>    Attila.
>
> --
> [*] This raises an interesting further issue, namely that this somewhat peculiar dependency disallows use of any Java 8 syntactic construct in Nashorn code destined for 8. Long term, it'd be great if we could either get 8u to use the previous 8 release as its boot JDK, or if we could rewrite Nasgen so that it reads Nashorn .class files, but doesn't load them into the JVM.
>
> On Feb 20, 2015, at 9:48 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>
>> +1
>>
>> Nice work!
>>
>> Am 2015-02-19 um 18:48 schrieb Attila Szegedi:
>>> Please review JDK-8072426 at <http://cr.openjdk.java.net/~attila/8072426/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8072426>
>>>
>>> This is what basically became an epic yak shaving exercise after we determined that POJOs aren't subjected to ToPrimitive (earlier known as java.math.RoundingMode.UP != "UP" problem). While we originally advocated for throwing TypeError for POJOs [[DefaultValue]] that would've prevented their implicit toString() in string concatenation too. Instead, I opted to fix this once and forever but it turned out that the biggest issue with it is the fact that JSObject was also not handled correctly for ToPrimitive; fixing that turned out to be the most challenging part, introducing a new JSObject.getDefaultValue() method and deprecating JSObject.toNumber() (which isn't used anymore at all).
>>>
>>> As an unexpected boon, JSObjectLinker no longer needs to do any conversions, so its GuardingTypeConverterFactory functionality has been entirely removed. NashornPrimitiveLinker will now automatically take care of converting JSObject instances to various primitive types, as per specification behavior.
>>>
>>> Finally, the ScriptRuntime changes to the equals() and equalDifferentType() are purely refactoring of some common type testing subexpressions and conversions, as well as short-circuiting of some comparisons. They aren't strictly necessary for this issue, but just for clear understanding of what's happening it seemed like a good idea to make them more concise (ScriptRuntime.EQ and .NE, of which the two affected methods are sub-parts are also not invoked terribly often, and I'll soon make them be invoked even less frequently.)
>>>
>>> Thanks,
>>>    Attila.


From ankit.narang at gmail.com  Wed Mar 11 09:29:16 2015
From: ankit.narang at gmail.com (Ankit Narang)
Date: Wed, 11 Mar 2015 14:59:16 +0530
Subject: Pause and Resume
Message-ID: <CAGojj+-MHJ3H7SStztjzso_1hLONebb=LRU7OerSiarDiSOfPA@mail.gmail.com>

Hi all,

I'm migrating to Nashorn from Rhino (v1.7R4). In my use case, I make
asynchronous service calls from Javascript.

I accomplished it in Rhino by:
1. Serializing Scope and Callback Function on S3 (AWS). Send S3 key as a
payload to the service.
2. After getting the response from service (async), de-serializing Scope
and Callback Function from S3 (AWS) using the S3 key (present in service's
response as the payload).
3. Continue script execution by invoking Callback Function with service
response as the argument (with the Scope obtained from step 2).

What's the way to do the same in Nashorn?

Thanks
Ankit

From hannes.wallnoefer at oracle.com  Wed Mar 11 09:30:01 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 11 Mar 2015 10:30:01 +0100
Subject: Review request for JDK-8074484
In-Reply-To: <B874F7CD-1293-425F-B30C-6A958974E20F@oracle.com>
References: <B874F7CD-1293-425F-B30C-6A958974E20F@oracle.com>
Message-ID: <55000B19.1000400@oracle.com>

+1

Am 2015-03-06 um 13:23 schrieb Attila Szegedi:
> Please review JDK-8074484 at <http://cr.openjdk.java.net/~attila/8074484/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8074484>
>
> Thanks,
>    Attila.


From hannes.wallnoefer at oracle.com  Wed Mar 11 10:06:15 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 11 Mar 2015 11:06:15 +0100
Subject: Effective warmup strategy for Nashorn - JDK-8u40-b25
In-Reply-To: <897090CCBF073241BB0F302E81C704D80100E8DDC5@ESV4-MB02.linkedin.biz>
References: <897090CCBF073241BB0F302E81C704D80100E8DDC5@ESV4-MB02.linkedin.biz>
Message-ID: <55001397.3060701@oracle.com>

Hi Kunal,

I'm currently loking at the benchmark scripts you posted.

One approach you should try is to use a single Nashorn ScriptEngine with 
multiple bindings (i.e. JS global objects). This allows Nashorn to share 
compiled classes among multiple threads. It's probably the best 
improvement you can make to startup and warmup time if you're using 
multiple JS environments on multiple threads. On the other hand, it may 
reduce top performance a little bit because of added polymorphism.

I've written about this in my recent Nashorn blog post, it also contains 
demo code for how to set up the script engine for multiple threads:

https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using

I hope this helps. I'll get back to you when I'm done trying your scripts.

Hannes

Am 2015-03-11 um 02:52 schrieb Kunal Cholera:
> Hello Nahsorn dev team,
>
> Currently our warmup strategy does the following - before our application starts serving request to real users we create 24 Nashorn instances. We are limiting to 24 as we have 24 CPU cores per machine in production. We then load the javascript files into this nashorn instances to setup the context for javascript execution. We then execute each of these javascript 2000 times with mock data to warmup the execution times.
>
> We have observed it takes about 4000 iterations[1] to reach optimal performance. See the graph here that shows 4000 javascript executions on 1 javascript file -
> https://drive.google.com/file/d/0B5PpdCJ7YycqbDJBWGRRVjRsYVU/view?usp=sharing
>
> Three questions
> 1.What is the best way to quickly warm-up to reach optimal performance in fewer iterations ?
>
> 2. Is there a better way to warmup using fixture data as opposed to fake data which we have to maintain ?
>
> 3. Is there a way to clone 1 nashorn instances that is warmed up so that we can avoid doing the same warmup for other nashorn instances ?
>
> [1]
> Steps to reproduce these performance numbers -
> Download this ziphttps://drive.google.com/file/d/0B5PpdCJ7YycqMWlVQ0FsNlozcTA/view?usp=sharing which has the following four files
> 1. bench.js - the benchmarking script
> 2. hp.js - the javascript we want to execute on Nashorn
> 3. hp.json - the data we want to use while executing our script hp.js
> 4. dust-full.js - library needed to execute hp.js script
>
> I am using "1.8.0_40-ea" Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b25 on 8 core redhat linux machine ).
>
> Please advise.
>
> Thanks
> Kunal Cholera


From sundararajan.athijegannathan at oracle.com  Wed Mar 11 11:19:11 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 11 Mar 2015 16:49:11 +0530
Subject: RFR 8074972: Unused imports, a missing javadoc and a build warning
Message-ID: <550024AF.6030202@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8074972/

-Sundar

From hannes.wallnoefer at oracle.com  Wed Mar 11 11:23:53 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 11 Mar 2015 12:23:53 +0100
Subject: RFR 8074972: Unused imports, a missing javadoc and a build warning
In-Reply-To: <550024AF.6030202@oracle.com>
References: <550024AF.6030202@oracle.com>
Message-ID: <550025C9.3090102@oracle.com>

+1

Am 2015-03-11 um 12:19 schrieb A. Sundararajan:
> Please review http://cr.openjdk.java.net/~sundar/8074972/
>
> -Sundar


From attila.szegedi at oracle.com  Wed Mar 11 11:54:39 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 11 Mar 2015 12:54:39 +0100
Subject: RFR 8074972: Unused imports, a missing javadoc and a build warning
In-Reply-To: <550024AF.6030202@oracle.com>
References: <550024AF.6030202@oracle.com>
Message-ID: <A02306A4-C4B2-4868-BFEC-09E524E6261D@oracle.com>

+1

On Mar 11, 2015, at 12:19 PM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8074972/
> 
> -Sundar


From sundararajan.athijegannathan at oracle.com  Wed Mar 11 12:47:30 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 11 Mar 2015 18:17:30 +0530
Subject: Pause and Resume
In-Reply-To: <CAGojj+-MHJ3H7SStztjzso_1hLONebb=LRU7OerSiarDiSOfPA@mail.gmail.com>
References: <CAGojj+-MHJ3H7SStztjzso_1hLONebb=LRU7OerSiarDiSOfPA@mail.gmail.com>
Message-ID: <55003962.2030907@oracle.com>

Nashorn script objects, functions are *not* Java Serializable objects. I 
suggest you "serialize" required data (scope or other JS objects) as 
JSON string and also store the associated script string. If script is 
loaded from same URL and persistent code is enabled ( 
https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using 
), when you re-load the script, nashorn would use already compiled 
classes. You can call the desired script function passing JSON.parse'd 
string as argument.

This is the closest things I can think of in nashorn world. Any further 
ideas from anyone else on the list?

Thanks,
-Sundar

On Wednesday 11 March 2015 02:59 PM, Ankit Narang wrote:
> Hi all,
>
> I'm migrating to Nashorn from Rhino (v1.7R4). In my use case, I make
> asynchronous service calls from Javascript.
>
> I accomplished it in Rhino by:
> 1. Serializing Scope and Callback Function on S3 (AWS). Send S3 key as a
> payload to the service.
> 2. After getting the response from service (async), de-serializing Scope
> and Callback Function from S3 (AWS) using the S3 key (present in service's
> response as the payload).
> 3. Continue script execution by invoking Callback Function with service
> response as the argument (with the Scope obtained from step 2).
>
> What's the way to do the same in Nashorn?
>
> Thanks
> Ankit


From attila.szegedi at oracle.com  Wed Mar 11 12:57:42 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 11 Mar 2015 13:57:42 +0100
Subject: Review request for JDK-8074661
Message-ID: <CBE4AFE5-1862-4B1C-8626-05D9C46FA3FE@oracle.com>

Please review JDK-8074661 at <http://cr.openjdk.java.net/~attila/8074661/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8074661>

This change adds the AbstractJSObject.getDefaultValue() method to jdk9 codebase so that it's compatible with the jdk8u backport of JDK-8072426 (which had to introduce it).

Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Wed Mar 11 13:00:41 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 11 Mar 2015 14:00:41 +0100
Subject: Review request for JDK-8074661
In-Reply-To: <CBE4AFE5-1862-4B1C-8626-05D9C46FA3FE@oracle.com>
References: <CBE4AFE5-1862-4B1C-8626-05D9C46FA3FE@oracle.com>
Message-ID: <55003C79.4050204@oracle.com>

+1

Am 2015-03-11 um 13:57 schrieb Attila Szegedi:
> Please review JDK-8074661 at <http://cr.openjdk.java.net/~attila/8074661/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8074661>
>
> This change adds the AbstractJSObject.getDefaultValue() method to jdk9 codebase so that it's compatible with the jdk8u backport of JDK-8072426 (which had to introduce it).
>
> Thanks,
>    Attila.


From sundararajan.athijegannathan at oracle.com  Wed Mar 11 13:05:29 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 11 Mar 2015 18:35:29 +0530
Subject: Review request for JDK-8074661
In-Reply-To: <CBE4AFE5-1862-4B1C-8626-05D9C46FA3FE@oracle.com>
References: <CBE4AFE5-1862-4B1C-8626-05D9C46FA3FE@oracle.com>
Message-ID: <55003D99.9070506@oracle.com>

+1

On Wednesday 11 March 2015 06:27 PM, Attila Szegedi wrote:
> Please review JDK-8074661 at <http://cr.openjdk.java.net/~attila/8074661/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8074661>
>
> This change adds the AbstractJSObject.getDefaultValue() method to jdk9 codebase so that it's compatible with the jdk8u backport of JDK-8072426 (which had to introduce it).
>
> Thanks,
>    Attila.


From attila.szegedi at oracle.com  Wed Mar 11 13:24:53 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 11 Mar 2015 14:24:53 +0100
Subject: Review request for JDK-8073706
Message-ID: <CBBF44C4-2657-4817-8846-27AC6192C0FE@oracle.com>

Please review JDK-8073706 at <http://cr.openjdk.java.net/~attila/8073706/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8073706>

While running test262parallel, it seldom run into this livelock. It's hard to reproduce, and I fail to see how it can happen, so I instead changed the heuristic to make sure the livelock can't happen.

Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Wed Mar 11 14:07:24 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 11 Mar 2015 15:07:24 +0100
Subject: Review request for JDK-8073706
In-Reply-To: <CBBF44C4-2657-4817-8846-27AC6192C0FE@oracle.com>
References: <CBBF44C4-2657-4817-8846-27AC6192C0FE@oracle.com>
Message-ID: <55004C1C.6010006@oracle.com>

+1


Am 2015-03-11 um 14:24 schrieb Attila Szegedi:
> Please review JDK-8073706 at <http://cr.openjdk.java.net/~attila/8073706/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8073706>
>
> While running test262parallel, it seldom run into this livelock. It's hard to reproduce, and I fail to see how it can happen, so I instead changed the heuristic to make sure the livelock can't happen.
>
> Thanks,
>    Attila.


From erik.joelsson at oracle.com  Wed Mar 11 15:47:29 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 11 Mar 2015 16:47:29 +0100
Subject: RFR: JDK-8074988: Reduce boilerplate in Setup* macro definitions
Message-ID: <55006391.7060301@oracle.com>

(including nashorn-dev since a makefile there is touched)

When creating a Setup* macro that takes named parameters, like 
SetupJavaCompilation, there is a lot of copied boilerplate code that 
needs to be written. The code, which is essentially copied for all these 
macro definitions, handles converting the named parameters into local 
variables and some debugging features. Here is SetupJavaCompilation as 
an example:

define SetupJavaCompilation
   $(if $(16),$(error Internal makefile error: Too many arguments to 
SetupJavaCompilation, please update JavaCompilation.gmk))
   $(call EvalDebugWrapper,$(strip $1),$(call 
SetupJavaCompilationInner,$(strip 
$1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15)))
endef

define SetupJavaCompilationInner
   $(foreach i,2 3 4 5 6 7 8 9 10 11 12 13 14 15, $(if $(strip 
$($i)),$1_$(strip $($i)))$(NEWLINE))
   $(call 
LogSetupMacroEntry,SetupJavaCompilation($1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15))
   $(if $(16),$(error Internal makefile error: Too many arguments to 
SetupJavaCompilation, please update JavaCompilation.gmk))
   ...
endef


I have figured out a way to reduce this boilerplate significantly, 
massively reducing the overhead and resistance for creating new macros. 
The logic for converting the named parameters and all the debugging 
features are now defined only once in MakeBase.gmk. The corresponding 
declaration of SetupJavaCompilation is reduced to this:

SetupJavaCompilation = $(NamedParamsMacroTemplate)
define SetupJavaCompilationBody
   ...
endef

Bug: https://bugs.openjdk.java.net/browse/JDK-8074988
Webrev: http://cr.openjdk.java.net/~erikj/8074988/webrev.01/

/Erik

From tim.bell at oracle.com  Wed Mar 11 16:24:03 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 11 Mar 2015 09:24:03 -0700
Subject: RFR: JDK-8074988: Reduce boilerplate in Setup* macro definitions
In-Reply-To: <55006391.7060301@oracle.com>
References: <55006391.7060301@oracle.com>
Message-ID: <55006C23.9050401@oracle.com>

Erik:

> (including nashorn-dev since a makefile there is touched)
>
> When creating a Setup* macro that takes named parameters, like 
> SetupJavaCompilation, there is a lot of copied boilerplate code that 
> needs to be written. The code, which is essentially copied for all 
> these macro definitions, handles converting the named parameters into 
> local variables and some debugging features. Here is 
> SetupJavaCompilation as an example:
>
> define SetupJavaCompilation
>   $(if $(16),$(error Internal makefile error: Too many arguments to 
> SetupJavaCompilation, please update JavaCompilation.gmk))
>   $(call EvalDebugWrapper,$(strip $1),$(call 
> SetupJavaCompilationInner,$(strip 
> $1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15)))
> endef
>
> define SetupJavaCompilationInner
>   $(foreach i,2 3 4 5 6 7 8 9 10 11 12 13 14 15, $(if $(strip 
> $($i)),$1_$(strip $($i)))$(NEWLINE))
>   $(call 
> LogSetupMacroEntry,SetupJavaCompilation($1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15))
>   $(if $(16),$(error Internal makefile error: Too many arguments to 
> SetupJavaCompilation, please update JavaCompilation.gmk))
>   ...
> endef
>
>
> I have figured out a way to reduce this boilerplate significantly, 
> massively reducing the overhead and resistance for creating new 
> macros. The logic for converting the named parameters and all the 
> debugging features are now defined only once in MakeBase.gmk. The 
> corresponding declaration of SetupJavaCompilation is reduced to this:
>
> SetupJavaCompilation = $(NamedParamsMacroTemplate)
> define SetupJavaCompilationBody
>   ...
> endef
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074988
> Webrev: http://cr.openjdk.java.net/~erikj/8074988/webrev.01

Only two minor things to pick on:

make/common/MakeBase.gmk at new line #399:
   'macor' should be 'macro'

test/make/TestJavaCompilation.gmk at line #70
   'DEPSENDENCIES' should be 'DEPENDENCIES'


Otherwise, looks good to me.  No need to respin the webrev for these fixes.

/Tim


From marcus.lagergren at oracle.com  Thu Mar 12 07:43:11 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Thu, 12 Mar 2015 08:43:11 +0100
Subject: Review request for JDK-8073706
In-Reply-To: <CBBF44C4-2657-4817-8846-27AC6192C0FE@oracle.com>
References: <CBBF44C4-2657-4817-8846-27AC6192C0FE@oracle.com>
Message-ID: <71B31880-6178-4FF3-8F83-2992540C76DA@oracle.com>

+1

> On 11 Mar 2015, at 14:24, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Please review JDK-8073706 at <http://cr.openjdk.java.net/~attila/8073706/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8073706>
> 
> While running test262parallel, it seldom run into this livelock. It's hard to reproduce, and I fail to see how it can happen, so I instead changed the heuristic to make sure the livelock can't happen.
> 
> Thanks,
>  Attila.


From magnus.ihse.bursie at oracle.com  Thu Mar 12 10:02:47 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 12 Mar 2015 11:02:47 +0100
Subject: RFR: JDK-8074988: Reduce boilerplate in Setup* macro definitions
In-Reply-To: <55006C23.9050401@oracle.com>
References: <55006391.7060301@oracle.com> <55006C23.9050401@oracle.com>
Message-ID: <55016447.4090705@oracle.com>

On 2015-03-11 17:24, Tim Bell wrote:
> Erik:
>
>> (including nashorn-dev since a makefile there is touched)
>>
>> When creating a Setup* macro that takes named parameters, like 
>> SetupJavaCompilation, there is a lot of copied boilerplate code that 
>> needs to be written. The code, which is essentially copied for all 
>> these macro definitions, handles converting the named parameters into 
>> local variables and some debugging features. Here is 
>> SetupJavaCompilation as an example:
>>
>> define SetupJavaCompilation
>>   $(if $(16),$(error Internal makefile error: Too many arguments to 
>> SetupJavaCompilation, please update JavaCompilation.gmk))
>>   $(call EvalDebugWrapper,$(strip $1),$(call 
>> SetupJavaCompilationInner,$(strip 
>> $1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15)))
>> endef
>>
>> define SetupJavaCompilationInner
>>   $(foreach i,2 3 4 5 6 7 8 9 10 11 12 13 14 15, $(if $(strip 
>> $($i)),$1_$(strip $($i)))$(NEWLINE))
>>   $(call 
>> LogSetupMacroEntry,SetupJavaCompilation($1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15))
>>   $(if $(16),$(error Internal makefile error: Too many arguments to 
>> SetupJavaCompilation, please update JavaCompilation.gmk))
>>   ...
>> endef
>>
>>
>> I have figured out a way to reduce this boilerplate significantly, 
>> massively reducing the overhead and resistance for creating new 
>> macros. The logic for converting the named parameters and all the 
>> debugging features are now defined only once in MakeBase.gmk. The 
>> corresponding declaration of SetupJavaCompilation is reduced to this:
>>
>> SetupJavaCompilation = $(NamedParamsMacroTemplate)
>> define SetupJavaCompilationBody
>>   ...
>> endef
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074988
>> Webrev: http://cr.openjdk.java.net/~erikj/8074988/webrev.01
>
> Only two minor things to pick on:
>
> make/common/MakeBase.gmk at new line #399:
>   'macor' should be 'macro'
>
> test/make/TestJavaCompilation.gmk at line #70
>   'DEPSENDENCIES' should be 'DEPENDENCIES'

Good catch!

Apart from these typos, it looks good to me too.

/Magnus

From erik.joelsson at oracle.com  Thu Mar 12 11:12:27 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 12 Mar 2015 12:12:27 +0100
Subject: RFR: JDK-8074988: Reduce boilerplate in Setup* macro definitions
In-Reply-To: <55016447.4090705@oracle.com>
References: <55006391.7060301@oracle.com> <55006C23.9050401@oracle.com>
	<55016447.4090705@oracle.com>
Message-ID: <5501749B.5000600@oracle.com>

Thanks, I will correct those before pushing.

/Erik

On 2015-03-12 11:02, Magnus Ihse Bursie wrote:
> On 2015-03-11 17:24, Tim Bell wrote:
>> Erik:
>>
>>> (including nashorn-dev since a makefile there is touched)
>>>
>>> When creating a Setup* macro that takes named parameters, like 
>>> SetupJavaCompilation, there is a lot of copied boilerplate code that 
>>> needs to be written. The code, which is essentially copied for all 
>>> these macro definitions, handles converting the named parameters 
>>> into local variables and some debugging features. Here is 
>>> SetupJavaCompilation as an example:
>>>
>>> define SetupJavaCompilation
>>>   $(if $(16),$(error Internal makefile error: Too many arguments to 
>>> SetupJavaCompilation, please update JavaCompilation.gmk))
>>>   $(call EvalDebugWrapper,$(strip $1),$(call 
>>> SetupJavaCompilationInner,$(strip 
>>> $1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15)))
>>> endef
>>>
>>> define SetupJavaCompilationInner
>>>   $(foreach i,2 3 4 5 6 7 8 9 10 11 12 13 14 15, $(if $(strip 
>>> $($i)),$1_$(strip $($i)))$(NEWLINE))
>>>   $(call 
>>> LogSetupMacroEntry,SetupJavaCompilation($1),$2,$3,$4,$5,$6,$7,$8,$9,$(10),$(11),$(12),$(13),$(14),$(15))
>>>   $(if $(16),$(error Internal makefile error: Too many arguments to 
>>> SetupJavaCompilation, please update JavaCompilation.gmk))
>>>   ...
>>> endef
>>>
>>>
>>> I have figured out a way to reduce this boilerplate significantly, 
>>> massively reducing the overhead and resistance for creating new 
>>> macros. The logic for converting the named parameters and all the 
>>> debugging features are now defined only once in MakeBase.gmk. The 
>>> corresponding declaration of SetupJavaCompilation is reduced to this:
>>>
>>> SetupJavaCompilation = $(NamedParamsMacroTemplate)
>>> define SetupJavaCompilationBody
>>>   ...
>>> endef
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074988
>>> Webrev: http://cr.openjdk.java.net/~erikj/8074988/webrev.01
>>
>> Only two minor things to pick on:
>>
>> make/common/MakeBase.gmk at new line #399:
>>   'macor' should be 'macro'
>>
>> test/make/TestJavaCompilation.gmk at line #70
>>   'DEPSENDENCIES' should be 'DEPENDENCIES'
>
> Good catch!
>
> Apart from these typos, it looks good to me too.
>
> /Magnus


From attila.szegedi at oracle.com  Fri Mar 13 11:58:48 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 13 Mar 2015 12:58:48 +0100
Subject: Review request for JDK-8075090
Message-ID: <1C0300B6-BBB2-4B37-9C14-365D091A5722@oracle.com>

Please review JDK-8075090 at <http://cr.openjdk.java.net/~attila/8075090/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8075090>

Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Fri Mar 13 14:00:18 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 13 Mar 2015 15:00:18 +0100
Subject: Review request for JDK-8075006: Threads spinning infinitely in
	WeakHashMap.get running test262parallel
Message-ID: <5502ED72.6040706@oracle.com>

Please review JDK-8075006: Threads spinning infinitely in 
WeakHashMap.get running test262parallel:

http://cr.openjdk.java.net/~hannesw/8075006/

I got the patch from Attila who already had it ready when I assigned the 
bug to myself.

Hannes

From attila.szegedi at oracle.com  Fri Mar 13 14:56:38 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 13 Mar 2015 15:56:38 +0100
Subject: Review request for JDK-8075006: Threads spinning infinitely in
	WeakHashMap.get running test262parallel
In-Reply-To: <5502ED72.6040706@oracle.com>
References: <5502ED72.6040706@oracle.com>
Message-ID: <DAC7E7C2-BF8B-4E89-ABAD-D212A8666438@oracle.com>

+1

On Mar 13, 2015, at 3:00 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8075006: Threads spinning infinitely in WeakHashMap.get running test262parallel:
> 
> http://cr.openjdk.java.net/~hannesw/8075006/
> 
> I got the patch from Attila who already had it ready when I assigned the bug to myself.
> 
> Hannes


From forax at univ-mlv.fr  Sun Mar 15 16:11:43 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 15 Mar 2015 17:11:43 +0100
Subject: Bug in Nashorn Parser API (order of statements)
Message-ID: <5505AF3F.5070705@univ-mlv.fr>

Hi guys, Hi Sundar,
it seems that the parser groups all the function declarations before all 
the statements
instead of following the order of the file.

[forax at localhost jsjs]$ cat bug_parser.js
var File = Java.type("java.io.File");
var Parser = Java.type("jdk.nashorn.api.tree.Parser");
var Tree = Java.type("jdk.nashorn.api.tree.Tree");

// do we have a script file passed? if not, use current script
var sourceName = arguments.length == 0? __FILE__ : arguments[0];

var parser = Parser.create("-scripting");
// parse script to get CompilationUnitTree of it
var ast = parser.parse(new File(sourceName), null);

for each(element in ast.getSourceElements()) {
   print(element.getClass());
}
[forax at localhost jsjs]$ cat test/test5.js
var hello = "hello jsjs";

function print_hello() {
     print(hello);
}

var hello = "hello jsjs 2";


[forax at localhost jsjs]$ jjs bug_parser.js -- test/test5.js
class jdk.nashorn.api.tree.FunctionDeclarationTreeImpl
class jdk.nashorn.api.tree.VariableTreeImpl
class jdk.nashorn.api.tree.VariableTreeImpl

the correct output should be:
class jdk.nashorn.api.tree.VariableTreeImpl
class jdk.nashorn.api.tree.FunctionDeclarationTreeImpl
class jdk.nashorn.api.tree.VariableTreeImpl

regards,
R?mi



From sundararajan.athijegannathan at oracle.com  Mon Mar 16 07:48:05 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 16 Mar 2015 13:18:05 +0530
Subject: Bug in Nashorn Parser API (order of statements)
In-Reply-To: <5505AF3F.5070705@univ-mlv.fr>
References: <5505AF3F.5070705@univ-mlv.fr>
Message-ID: <55068AB5.7010302@oracle.com>

Hi,

Thanks for reporting this issue. I filed a bug 
https://bugs.openjdk.java.net/browse/JDK-8075207

Thanks,
-Sundar

On Sunday 15 March 2015 09:41 PM, Remi Forax wrote:
> Hi guys, Hi Sundar,
> it seems that the parser groups all the function declarations before 
> all the statements
> instead of following the order of the file.
>
> [forax at localhost jsjs]$ cat bug_parser.js
> var File = Java.type("java.io.File");
> var Parser = Java.type("jdk.nashorn.api.tree.Parser");
> var Tree = Java.type("jdk.nashorn.api.tree.Tree");
>
> // do we have a script file passed? if not, use current script
> var sourceName = arguments.length == 0? __FILE__ : arguments[0];
>
> var parser = Parser.create("-scripting");
> // parse script to get CompilationUnitTree of it
> var ast = parser.parse(new File(sourceName), null);
>
> for each(element in ast.getSourceElements()) {
>   print(element.getClass());
> }
> [forax at localhost jsjs]$ cat test/test5.js
> var hello = "hello jsjs";
>
> function print_hello() {
>     print(hello);
> }
>
> var hello = "hello jsjs 2";
>
>
> [forax at localhost jsjs]$ jjs bug_parser.js -- test/test5.js
> class jdk.nashorn.api.tree.FunctionDeclarationTreeImpl
> class jdk.nashorn.api.tree.VariableTreeImpl
> class jdk.nashorn.api.tree.VariableTreeImpl
>
> the correct output should be:
> class jdk.nashorn.api.tree.VariableTreeImpl
> class jdk.nashorn.api.tree.FunctionDeclarationTreeImpl
> class jdk.nashorn.api.tree.VariableTreeImpl
>
> regards,
> R?mi
>
>


From marcus.lagergren at oracle.com  Mon Mar 16 08:25:19 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 16 Mar 2015 09:25:19 +0100
Subject: Review request for JDK-8075090
In-Reply-To: <1C0300B6-BBB2-4B37-9C14-365D091A5722@oracle.com>
References: <1C0300B6-BBB2-4B37-9C14-365D091A5722@oracle.com>
Message-ID: <9B9A9F9A-81B9-4070-BA0B-68AAE3B99F6C@oracle.com>

+1

> On 13 Mar 2015, at 12:58, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Please review JDK-8075090 at <http://cr.openjdk.java.net/~attila/8075090/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8075090>
> 
> Thanks,
>  Attila.


From marcus.lagergren at oracle.com  Mon Mar 16 08:25:25 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 16 Mar 2015 09:25:25 +0100
Subject: Review request for JDK-8075006: Threads spinning infinitely in
	WeakHashMap.get running test262parallel
In-Reply-To: <5502ED72.6040706@oracle.com>
References: <5502ED72.6040706@oracle.com>
Message-ID: <43D73889-BB5E-483F-8C01-06A8895D4ACA@oracle.com>

+1

> On 13 Mar 2015, at 15:00, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review JDK-8075006: Threads spinning infinitely in WeakHashMap.get running test262parallel:
> 
> http://cr.openjdk.java.net/~hannesw/8075006/
> 
> I got the patch from Attila who already had it ready when I assigned the bug to myself.
> 
> Hannes


From sundararajan.athijegannathan at oracle.com  Mon Mar 16 10:21:49 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 16 Mar 2015 15:51:49 +0530
Subject: RFR 8075207: Nashorn parser API returns StatementTree objects in
	out of order
Message-ID: <5506AEBD.4030701@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8075207/ for 
https://bugs.openjdk.java.net/browse/JDK-8075207

PS. Piggybacking few @Override and other clean-ups..

Thanks,
-Sundar

From forax at univ-mlv.fr  Mon Mar 16 10:40:33 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 16 Mar 2015 11:40:33 +0100
Subject: RFR 8075207: Nashorn parser API returns StatementTree objects
	in out of order
In-Reply-To: <5506AEBD.4030701@oracle.com>
References: <5506AEBD.4030701@oracle.com>
Message-ID: <5506B321.9010301@univ-mlv.fr>

Hi Sundar,
Looks good !

just nitpicking, Java 8 introduces a method sort() on List so instead of
Collections.sort(statList, (s1, s2)->(s1.getStart() - s2.getStart()));

one can write
statList.sort((s1, s2)->Integer.compare(s1.getStart(), s2.getStart()));
(Integer.compare() is used avoid the overflow problem)

or with a method reference,
statList.sort(Comparator.comparingInt(Statement::getStart));

cheers,
R?mi


On 03/16/2015 11:21 AM, A. Sundararajan wrote:
> Please review http://cr.openjdk.java.net/~sundar/8075207/ for 
> https://bugs.openjdk.java.net/browse/JDK-8075207
>
> PS. Piggybacking few @Override and other clean-ups..
>
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Mon Mar 16 10:48:40 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 16 Mar 2015 11:48:40 +0100
Subject: RFR 8075207: Nashorn parser API returns StatementTree objects
	in out of order
In-Reply-To: <5506B321.9010301@univ-mlv.fr>
References: <5506AEBD.4030701@oracle.com> <5506B321.9010301@univ-mlv.fr>
Message-ID: <5506B508.8040604@oracle.com>

+1

Am 2015-03-16 um 11:40 schrieb Remi Forax:
> Hi Sundar,
> Looks good !
>
> just nitpicking, Java 8 introduces a method sort() on List so instead of
> Collections.sort(statList, (s1, s2)->(s1.getStart() - s2.getStart()));
>
> one can write
> statList.sort((s1, s2)->Integer.compare(s1.getStart(), s2.getStart()));
> (Integer.compare() is used avoid the overflow problem)
>
> or with a method reference,
> statList.sort(Comparator.comparingInt(Statement::getStart));
>
> cheers,
> R?mi
>
>
> On 03/16/2015 11:21 AM, A. Sundararajan wrote:
>> Please review http://cr.openjdk.java.net/~sundar/8075207/ for 
>> https://bugs.openjdk.java.net/browse/JDK-8075207
>>
>> PS. Piggybacking few @Override and other clean-ups..
>>
>> Thanks,
>> -Sundar
>


From sundararajan.athijegannathan at oracle.com  Mon Mar 16 11:30:06 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 16 Mar 2015 17:00:06 +0530
Subject: RFR 8075207: Nashorn parser API returns StatementTree objects
	in out of order
In-Reply-To: <5506B321.9010301@univ-mlv.fr>
References: <5506AEBD.4030701@oracle.com> <5506B321.9010301@univ-mlv.fr>
Message-ID: <5506BEBE.3070505@oracle.com>

Hi,

Thanks for the review. Fixed to use method reference.

PS. Uploaded updated webrev for reference: 
http://cr.openjdk.java.net/~sundar/8075207/webrev.01/

Thanks,
-Sundar

On Monday 16 March 2015 04:10 PM, Remi Forax wrote:
> Hi Sundar,
> Looks good !
>
> just nitpicking, Java 8 introduces a method sort() on List so instead of
> Collections.sort(statList, (s1, s2)->(s1.getStart() - s2.getStart()));
>
> one can write
> statList.sort((s1, s2)->Integer.compare(s1.getStart(), s2.getStart()));
> (Integer.compare() is used avoid the overflow problem)
>
> or with a method reference,
> statList.sort(Comparator.comparingInt(Statement::getStart));
>
> cheers,
> R?mi
>
>
> On 03/16/2015 11:21 AM, A. Sundararajan wrote:
>> Please review http://cr.openjdk.java.net/~sundar/8075207/ for 
>> https://bugs.openjdk.java.net/browse/JDK-8075207
>>
>> PS. Piggybacking few @Override and other clean-ups..
>>
>> Thanks,
>> -Sundar
>


From marcus.lagergren at oracle.com  Mon Mar 16 12:59:26 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 16 Mar 2015 13:59:26 +0100
Subject: Asciidoctor.js on Nashorn JDK 9 is considerably slower than
	Nashorn JDK 8
In-Reply-To: <CANvh_fbgTn69Lw6qF0jbmfWsO48BjwvhhYW9mWS8u2EQU+ToFQ@mail.gmail.com>
References: <CANvh_fbgTn69Lw6qF0jbmfWsO48BjwvhhYW9mWS8u2EQU+ToFQ@mail.gmail.com>
Message-ID: <8CCBD772-4BB6-4C67-8909-12FF9C74AAFE@oracle.com>

Yes. This probably has to do with optimistic typing being enabled to increase JavaScript runtime performance in 9. We know that 9 is currently slower at startup because we generate more correct code (and throw away too optimistic code that we generate first). 

Try running with ?optimistic-types=false and see if you get back to 8-like performance and startup.

We have plans to cheapen startup time considerably until 9 FC.

You can also try using the code caching feature from 8u40: 

https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using

Regards
Marcus

> On 03 Jan 2015, at 21:01, Guillaume Grossetie <grossetieg at gmail.com> wrote:
> 
> Hello everyone and happy new year!
> 
> Asciidoctor.js is now running on both JDK 8b19 (build 25.40-b23) and JDK
> 9b44 (build 1.9.0-ea-b44).
> We noticed that JDK 9 is considerably slower than JDK 8 Nashorn but at the
> same time running "basic" Javascript seems faster on JDK 9.
> 
> We have a simple Rake task[1] that execute the same examples with the
> latest JDK 8 and JDK 9:
> 
> *Result with JDK 8:*
> 
> Running Nashorn jjs spec/share/basic.js... OK in *909.052 ms*
> Running Nashorn jjs spec/share/asciidoctor-convert.js... OK in *9335.534 ms*
> Running Nashorn java BasicJavascriptWithNashorn... OK in *927.053 ms*
> Running Nashorn java AsciidoctorConvertWithNashorn... OK in *8843.506 ms*
> 
> So less than a second for basic Javascript and around 10 seconds to convert
> AsciiDoc source to HTML5.
> 
> *Result with JDK 9:*
> 
> Running Nashorn jjs spec/share/basic.js... OK in *860.049 ms*
> Running Nashorn jjs spec/share/asciidoctor-convert.js... OK in *31253.788
> ms*
> Running Nashorn java BasicJavascriptWithNashorn... OK in *833.048 ms*
> Running Nashorn java AsciidoctorConvertWithNashorn... OK in *30584.749 ms*
> 
> As you can see basic.js runs a little faster but asciidoctor-convert.js is
> considerably slower (three times slower ~30 seconds).
> 
> The basic.js[2], asciidoctor-convert.js[3] and asciidoctor-all.js[4] are
> available on GitHub.
> Asciidoctor.js is generated from Ruby using Opal[5] as a result the
> file asciidoctor-all.js
> is not easy to read but the entry point is the method $convert[6].
> 
> Let me know if you need more information.
> 
> Cheers,
> Guillaume
> 
> [1] https://github.com/asciidoctor/asciidoctor.js/blob/master/Rakefile#L105
> [2]
> https://github.com/asciidoctor/asciidoctor.js/blob/master/spec/share/basic.js
> [3]
> https://github.com/asciidoctor/asciidoctor.js/blob/master/spec/share/asciidoctor-convert.js
> [4]
> https://github.com/asciidoctor/asciidoctor.js/blob/master/dist/asciidoctor-all.js
> [5] http://opalrb.org/
> [6]
> https://github.com/asciidoctor/asciidoctor.js/blob/master/dist/asciidoctor-all.js#L24419


From marcus.lagergren at oracle.com  Mon Mar 16 15:05:27 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 16 Mar 2015 16:05:27 +0100
Subject: Please review JDK-8066217, constructor behavior for ArrayBuffer
Message-ID: <1228FB9E-866E-4C23-988A-26AB8D2D8DDC@oracle.com>

Webrev: http://cr.openjdk.java.net/~lagergren/8066217/webrev/ <http://cr.openjdk.java.net/~lagergren/8066217/webrev/>
CR: https://bugs.openjdk.java.net/browse/JDK-8066217 <https://bugs.openjdk.java.net/browse/JDK-8066217>

/M


From sundararajan.athijegannathan at oracle.com  Mon Mar 16 15:21:38 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 16 Mar 2015 20:51:38 +0530
Subject: Please review JDK-8066217, constructor behavior for ArrayBuffer
In-Reply-To: <1228FB9E-866E-4C23-988A-26AB8D2D8DDC@oracle.com>
References: <1228FB9E-866E-4C23-988A-26AB8D2D8DDC@oracle.com>
Message-ID: <5506F502.2020804@oracle.com>

+1

If we are not sure of ES6 spec. reference, that comment may be removed.

-Sundar

On Monday 16 March 2015 08:35 PM, Marcus Lagergren wrote:
> Webrev: http://cr.openjdk.java.net/~lagergren/8066217/webrev/ <http://cr.openjdk.java.net/~lagergren/8066217/webrev/>
> CR: https://bugs.openjdk.java.net/browse/JDK-8066217 <https://bugs.openjdk.java.net/browse/JDK-8066217>
>
> /M
>


From hannes.wallnoefer at oracle.com  Mon Mar 16 15:22:55 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 16 Mar 2015 16:22:55 +0100
Subject: Please review JDK-8066217, constructor behavior for ArrayBuffer
In-Reply-To: <1228FB9E-866E-4C23-988A-26AB8D2D8DDC@oracle.com>
References: <1228FB9E-866E-4C23-988A-26AB8D2D8DDC@oracle.com>
Message-ID: <5506F54F.2070104@oracle.com>

+1


Am 2015-03-16 um 16:05 schrieb Marcus Lagergren:
> Webrev: http://cr.openjdk.java.net/~lagergren/8066217/webrev/ <http://cr.openjdk.java.net/~lagergren/8066217/webrev/>
> CR: https://bugs.openjdk.java.net/browse/JDK-8066217 <https://bugs.openjdk.java.net/browse/JDK-8066217>
>
> /M
>


From attila.szegedi at oracle.com  Mon Mar 16 17:12:44 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 16 Mar 2015 18:12:44 +0100
Subject: Review request for JDK-8075223: revert multithreaded deoptimizing
	compilation livelock prevention
Message-ID: <7543D748-272B-4CA0-AD23-46E281896272@oracle.com>

Please review JDK-8075223 "revert multithreaded deoptimizing compilation livelock prevention" at <http://cr.openjdk.java.net/~attila/8075223/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8075223>

Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Mon Mar 16 17:22:43 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 16 Mar 2015 18:22:43 +0100
Subject: Review request for JDK-8075223: revert multithreaded deoptimizing
	compilation livelock prevention
In-Reply-To: <7543D748-272B-4CA0-AD23-46E281896272@oracle.com>
References: <7543D748-272B-4CA0-AD23-46E281896272@oracle.com>
Message-ID: <55071163.3080401@oracle.com>

+1

Am 2015-03-16 um 18:12 schrieb Attila Szegedi:
> Please review JDK-8075223 "revert multithreaded deoptimizing compilation livelock prevention" at <http://cr.openjdk.java.net/~attila/8075223/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8075223>
>
> Thanks,
>    Attila.


From cpettitt at linkedin.com  Mon Mar 16 22:03:02 2015
From: cpettitt at linkedin.com (Chris Pettitt)
Date: Mon, 16 Mar 2015 22:03:02 +0000
Subject: 8u20 with multi-threaded class cache
Message-ID: <8A9DFF013D0EBB439171DAF88E4C7EA9C759A1A7@LCA1-MB01.linkedin.biz>

Hi folks,

We're looking into the possibility of using the class cache in multi-threaded code, as introduced in [1]. We have a few questions related to this feature:

1. The article implies that ScriptEngine can be treated as thread-safe - provided we're not using the default context - though the code doesn't state this explicitly. Is this a safe assumption? Are there any other caveats?

2. As we need to set the Context for each eval, does this lock us out of using Invocable?

3. The code for determining if two Sources are the same ultimately falls back to a comparison of the url / name / content of the scripts. Is there a way to eval with a Source to avoid this fallback? It looks like it is not exposed in a public way.

[1]: https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using

Thanks,
Chris

From kcholera at linkedin.com  Mon Mar 16 22:22:58 2015
From: kcholera at linkedin.com (Kunal Cholera)
Date: Mon, 16 Mar 2015 22:22:58 +0000
Subject: Effective warmup strategy for Nashorn - JDK-8u40-b25
In-Reply-To: <55001397.3060701@oracle.com>
References: <897090CCBF073241BB0F302E81C704D80100E8DDC5@ESV4-MB02.linkedin.biz>,
	<55001397.3060701@oracle.com>
Message-ID: <897090CCBF073241BB0F302E81C704D801018A85BC@LCA1-MB03.linkedin.biz>

Hi Hannes,

Thanks for your reply. We will look into your suggestions, there are few questions as Chris emailed earlier  
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-March/004352.html

Any insights from trying the scripts I sent earlier ?

--
Kunal
________________________________________
From: Hannes Wallnoefer [hannes.wallnoefer at oracle.com]
Sent: Wednesday, March 11, 2015 3:06 AM
To: Kunal Cholera; nashorn-dev at openjdk.java.net
Subject: Re: Effective warmup strategy for Nashorn - JDK-8u40-b25

Hi Kunal,

I'm currently loking at the benchmark scripts you posted.

One approach you should try is to use a single Nashorn ScriptEngine with
multiple bindings (i.e. JS global objects). This allows Nashorn to share
compiled classes among multiple threads. It's probably the best
improvement you can make to startup and warmup time if you're using
multiple JS environments on multiple threads. On the other hand, it may
reduce top performance a little bit because of added polymorphism.

I've written about this in my recent Nashorn blog post, it also contains
demo code for how to set up the script engine for multiple threads:

https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using

I hope this helps. I'll get back to you when I'm done trying your scripts.

Hannes

Am 2015-03-11 um 02:52 schrieb Kunal Cholera:
> Hello Nahsorn dev team,
>
> Currently our warmup strategy does the following - before our application starts serving request to real users we create 24 Nashorn instances. We are limiting to 24 as we have 24 CPU cores per machine in production. We then load the javascript files into this nashorn instances to setup the context for javascript execution. We then execute each of these javascript 2000 times with mock data to warmup the execution times.
>
> We have observed it takes about 4000 iterations[1] to reach optimal performance. See the graph here that shows 4000 javascript executions on 1 javascript file -
> https://drive.google.com/file/d/0B5PpdCJ7YycqbDJBWGRRVjRsYVU/view?usp=sharing
>
> Three questions
> 1.What is the best way to quickly warm-up to reach optimal performance in fewer iterations ?
>
> 2. Is there a better way to warmup using fixture data as opposed to fake data which we have to maintain ?
>
> 3. Is there a way to clone 1 nashorn instances that is warmed up so that we can avoid doing the same warmup for other nashorn instances ?
>
> [1]
> Steps to reproduce these performance numbers -
> Download this ziphttps://drive.google.com/file/d/0B5PpdCJ7YycqMWlVQ0FsNlozcTA/view?usp=sharing which has the following four files
> 1. bench.js - the benchmarking script
> 2. hp.js - the javascript we want to execute on Nashorn
> 3. hp.json - the data we want to use while executing our script hp.js
> 4. dust-full.js - library needed to execute hp.js script
>
> I am using "1.8.0_40-ea" Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b25 on 8 core redhat linux machine ).
>
> Please advise.
>
> Thanks
> Kunal Cholera


From sundararajan.athijegannathan at oracle.com  Tue Mar 17 03:00:41 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Tue, 17 Mar 2015 08:30:41 +0530
Subject: Review request for JDK-8075223: revert multithreaded deoptimizing
	compilation livelock prevention
In-Reply-To: <7543D748-272B-4CA0-AD23-46E281896272@oracle.com>
References: <7543D748-272B-4CA0-AD23-46E281896272@oracle.com>
Message-ID: <550798D9.9090000@oracle.com>

+1

On Monday 16 March 2015 10:42 PM, Attila Szegedi wrote:
> Please review JDK-8075223 "revert multithreaded deoptimizing compilation livelock prevention" at <http://cr.openjdk.java.net/~attila/8075223/webrev.00> for <https://bugs.openjdk.java.net/browse/JDK-8075223>
>
> Thanks,
>    Attila.


From sergey.lugovoy at oracle.com  Tue Mar 17 12:11:27 2015
From: sergey.lugovoy at oracle.com (Sergey Lugovoy)
Date: Tue, 17 Mar 2015 15:11:27 +0300
Subject: RFR 8068306, 8068304, 8068303 : Tests for JEP 236: Parser API for
	Nashorn
Message-ID: <550819EF.4040309@oracle.com>

Hi all,
Please review http://cr.openjdk.java.net/~slugovoy/8068306/webrev.01/ 
for  JEP 236: Parser API for Nashorn

JEP :  https://bugs.openjdk.java.net/browse/JDK-8058809
Test tasks :

  * Tests for Diagnostic listener for Nashorn Parser API -
    https://bugs.openjdk.java.net/browse/JDK-8068304
  * Tests for AST presentation Nashorn Parser API -
    https://bugs.openjdk.java.net/browse/JDK-8068306
  * Create tests for Nashorn Parser API for create Tree from some
    different source and parameters -
    https://bugs.openjdk.java.net/browse/JDK-8068303


-- 
Thanks,
Sergey


From hannes.wallnoefer at oracle.com  Tue Mar 17 17:38:51 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 17 Mar 2015 18:38:51 +0100
Subject: 8u20 with multi-threaded class cache
In-Reply-To: <8A9DFF013D0EBB439171DAF88E4C7EA9C759A1A7@LCA1-MB01.linkedin.biz>
References: <8A9DFF013D0EBB439171DAF88E4C7EA9C759A1A7@LCA1-MB01.linkedin.biz>
Message-ID: <550866AB.5030708@oracle.com>

Hi Chris, Kunal,

Answers are inlined below.

Am 2015-03-16 um 23:03 schrieb Chris Pettitt:
> Hi folks,
>
> We're looking into the possibility of using the class cache in multi-threaded code, as introduced in [1]. We have a few questions related to this feature:
>
> 1. The article implies that ScriptEngine can be treated as thread-safe - provided we're not using the default context - though the code doesn't state this explicitly. Is this a safe assumption? Are there any other caveats?

This is correct as far as Nashorn is concerned. In the original JDK8 
release, using a ScriptEngine with multiple bindings/globals will 
compile each script from scratch. We introduced the class caching in 
8u20 as our best effort to fit code reuse on the existing ScriptEngine 
API. The only caveat I can think of is that code may run slower with 
multiple bindings because of callsite polymorphism. Also bear in mind 
that this is a relatively new feature, but there seemed to be no problem 
using it with your dust scripts (see example below).

> 2. As we need to set the Context for each eval, does this lock us out of using Invocable?

You can actually use this with Invocable.invokeMethod(), passing the 
binding as first argument ("thiz" parameter). I've rewritten the 
threaded class cache example from the blog post to do this with your 
dust benchmark and it seems to work fine:

https://gist.github.com/hns/8f52a620ce36daa3d0ca

I just edited the bench.js file to remove the benchmark loop at the 
bottom, otherwise this will run with the script files you sent me. Feel 
free to use this as a starting point for your own testing.

It could also work with the other Invocable method taking a "thiz" 
parameter, getInterface(Object, Class), but I haven't tested this.

>
> 3. The code for determining if two Sources are the same ultimately falls back to a comparison of the url / name / content of the scripts. Is there a way to eval with a Source to avoid this fallback? It looks like it is not exposed in a public way.

I'm not sure I understand this question. What I use in my example is 
jdk.nashorn.api.scripting.URLReader, which is handy to preserve the 
source URL in error messages.  I believe Nashorn will still load the 
content of the URL to make sure scripts are actually identical.

I hope this helps. Let me know if you have further questions.

Regards,
Hannes

> [1]: https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using
>
> Thanks,
> Chris


From marcus.lagergren at oracle.com  Wed Mar 18 07:26:12 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 18 Mar 2015 08:26:12 +0100
Subject: RFR 8068306, 8068304,
	8068303 : Tests for JEP 236: Parser API for Nashorn
In-Reply-To: <550819EF.4040309@oracle.com>
References: <550819EF.4040309@oracle.com>
Message-ID: <97FC29F1-F9F1-466E-9C85-9EE58186AC23@oracle.com>

+1

> On 17 Mar 2015, at 13:11, Sergey Lugovoy <sergey.lugovoy at oracle.com> wrote:
> 
> Hi all,
> Please review http://cr.openjdk.java.net/~slugovoy/8068306/webrev.01/ <http://cr.openjdk.java.net/~slugovoy/8068306/webrev.01/> for  JEP 236: Parser API for Nashorn
> 
> JEP :  https://bugs.openjdk.java.net/browse/JDK-8058809 <https://bugs.openjdk.java.net/browse/JDK-8058809>
> Test tasks : 
> Tests for Diagnostic listener for Nashorn Parser API - https://bugs.openjdk.java.net/browse/JDK-8068304 <https://bugs.openjdk.java.net/browse/JDK-8068304>
> Tests for AST presentation Nashorn Parser API - https://bugs.openjdk.java.net/browse/JDK-8068306 <https://bugs.openjdk.java.net/browse/JDK-8068306>
> Create tests for Nashorn Parser API for create Tree from some different source and parameters - https://bugs.openjdk.java.net/browse/JDK-8068303 <https://bugs.openjdk.java.net/browse/JDK-8068303>
> 
> -- 
> Thanks,
> Sergey


From sundararajan.athijegannathan at oracle.com  Wed Mar 18 07:38:10 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 18 Mar 2015 13:08:10 +0530
Subject: RFR 8068306, 8068304, 8068303 : Tests for JEP 236: Parser API
	for Nashorn
In-Reply-To: <97FC29F1-F9F1-466E-9C85-9EE58186AC23@oracle.com>
References: <550819EF.4040309@oracle.com>
	<97FC29F1-F9F1-466E-9C85-9EE58186AC23@oracle.com>
Message-ID: <55092B62.8050102@oracle.com>

Hi Sergey,

+1

Nice work! Good coverage!

Nitpick:  class field in JSON may be removed - i.e., filtered out. All 
those IfTreeImpl, LiteralTreeImpl etc. classes are package-private and 
final -- not part of API. So, tests may avoid using those name for 
better stability.

-Sundar

On Wednesday 18 March 2015 12:56 PM, Marcus Lagergren wrote:
> +1
>
>> On 17 Mar 2015, at 13:11, Sergey Lugovoy <sergey.lugovoy at oracle.com> wrote:
>>
>> Hi all,
>> Please review http://cr.openjdk.java.net/~slugovoy/8068306/webrev.01/ <http://cr.openjdk.java.net/~slugovoy/8068306/webrev.01/> for  JEP 236: Parser API for Nashorn
>>
>> JEP :  https://bugs.openjdk.java.net/browse/JDK-8058809 <https://bugs.openjdk.java.net/browse/JDK-8058809>
>> Test tasks :
>> Tests for Diagnostic listener for Nashorn Parser API - https://bugs.openjdk.java.net/browse/JDK-8068304 <https://bugs.openjdk.java.net/browse/JDK-8068304>
>> Tests for AST presentation Nashorn Parser API - https://bugs.openjdk.java.net/browse/JDK-8068306 <https://bugs.openjdk.java.net/browse/JDK-8068306>
>> Create tests for Nashorn Parser API for create Tree from some different source and parameters - https://bugs.openjdk.java.net/browse/JDK-8068303 <https://bugs.openjdk.java.net/browse/JDK-8068303>
>>
>> -- 
>> Thanks,
>> Sergey
>


From grossetieg at gmail.com  Wed Mar 18 12:36:33 2015
From: grossetieg at gmail.com (Guillaume Grossetie)
Date: Wed, 18 Mar 2015 13:36:33 +0100
Subject: Asciidoctor.js on Nashorn JDK 9 is considerably slower than
	Nashorn JDK 8
In-Reply-To: <8CCBD772-4BB6-4C67-8909-12FF9C74AAFE@oracle.com>
References: <CANvh_fbgTn69Lw6qF0jbmfWsO48BjwvhhYW9mWS8u2EQU+ToFQ@mail.gmail.com>
	<8CCBD772-4BB6-4C67-8909-12FF9C74AAFE@oracle.com>
Message-ID: <CANvh_fZjHEPXwAk6GGZvnsTLN0ie-O1aq7Y=-J9FRpYPS6d92g@mail.gmail.com>

Hi Marcus,

Thanks for your reply, I will give it a try and let you know.


Guillaume.

2015-03-16 13:59 GMT+01:00 Marcus Lagergren <marcus.lagergren at oracle.com>:

> Yes. This probably has to do with optimistic typing being enabled to
> increase JavaScript runtime performance in 9. We know that 9 is currently
> slower at startup because we generate more correct code (and throw away too
> optimistic code that we generate first).
>
> Try running with ?optimistic-types=false and see if you get back to 8-like
> performance and startup.
>
> We have plans to cheapen startup time considerably until 9 FC.
>
> You can also try using the code caching feature from 8u40:
>
> https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using
>
> Regards
> Marcus
>
> > On 03 Jan 2015, at 21:01, Guillaume Grossetie <grossetieg at gmail.com>
> wrote:
> >
> > Hello everyone and happy new year!
> >
> > Asciidoctor.js is now running on both JDK 8b19 (build 25.40-b23) and JDK
> > 9b44 (build 1.9.0-ea-b44).
> > We noticed that JDK 9 is considerably slower than JDK 8 Nashorn but at
> the
> > same time running "basic" Javascript seems faster on JDK 9.
> >
> > We have a simple Rake task[1] that execute the same examples with the
> > latest JDK 8 and JDK 9:
> >
> > *Result with JDK 8:*
> >
> > Running Nashorn jjs spec/share/basic.js... OK in *909.052 ms*
> > Running Nashorn jjs spec/share/asciidoctor-convert.js... OK in *9335.534
> ms*
> > Running Nashorn java BasicJavascriptWithNashorn... OK in *927.053 ms*
> > Running Nashorn java AsciidoctorConvertWithNashorn... OK in *8843.506 ms*
> >
> > So less than a second for basic Javascript and around 10 seconds to
> convert
> > AsciiDoc source to HTML5.
> >
> > *Result with JDK 9:*
> >
> > Running Nashorn jjs spec/share/basic.js... OK in *860.049 ms*
> > Running Nashorn jjs spec/share/asciidoctor-convert.js... OK in *31253.788
> > ms*
> > Running Nashorn java BasicJavascriptWithNashorn... OK in *833.048 ms*
> > Running Nashorn java AsciidoctorConvertWithNashorn... OK in *30584.749
> ms*
> >
> > As you can see basic.js runs a little faster but asciidoctor-convert.js
> is
> > considerably slower (three times slower ~30 seconds).
> >
> > The basic.js[2], asciidoctor-convert.js[3] and asciidoctor-all.js[4] are
> > available on GitHub.
> > Asciidoctor.js is generated from Ruby using Opal[5] as a result the
> > file asciidoctor-all.js
> > is not easy to read but the entry point is the method $convert[6].
> >
> > Let me know if you need more information.
> >
> > Cheers,
> > Guillaume
> >
> > [1]
> https://github.com/asciidoctor/asciidoctor.js/blob/master/Rakefile#L105
> > [2]
> >
> https://github.com/asciidoctor/asciidoctor.js/blob/master/spec/share/basic.js
> > [3]
> >
> https://github.com/asciidoctor/asciidoctor.js/blob/master/spec/share/asciidoctor-convert.js
> > [4]
> >
> https://github.com/asciidoctor/asciidoctor.js/blob/master/dist/asciidoctor-all.js
> > [5] http://opalrb.org/
> > [6]
> >
> https://github.com/asciidoctor/asciidoctor.js/blob/master/dist/asciidoctor-all.js#L24419
>
>

From sundararajan.athijegannathan at oracle.com  Wed Mar 18 15:55:31 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 18 Mar 2015 21:25:31 +0530
Subject: RFR 8075448: nashorn parser API returns init variable tree object
	of a for loop after for loop statement tree object
Message-ID: <55099FF3.6050706@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8075448/  for 
https://bugs.openjdk.java.net/browse/JDK-8075448

Thanks,
-Sundar

From hannes.wallnoefer at oracle.com  Wed Mar 18 16:10:26 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 18 Mar 2015 17:10:26 +0100
Subject: RFR 8075448: nashorn parser API returns init variable tree object
	of a for loop after for loop statement tree object
In-Reply-To: <55099FF3.6050706@oracle.com>
References: <55099FF3.6050706@oracle.com>
Message-ID: <5509A372.6090303@oracle.com>

+1

Am 2015-03-18 um 16:55 schrieb A. Sundararajan:
> Please review http://cr.openjdk.java.net/~sundar/8075448/  for 
> https://bugs.openjdk.java.net/browse/JDK-8075448
>
> Thanks,
> -Sundar


From marcus.lagergren at oracle.com  Wed Mar 18 16:12:11 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 18 Mar 2015 17:12:11 +0100
Subject: RFR 8075448: nashorn parser API returns init variable tree object
	of a for loop after for loop statement tree object
In-Reply-To: <55099FF3.6050706@oracle.com>
References: <55099FF3.6050706@oracle.com>
Message-ID: <FB4FC233-D103-42DB-87E3-6768E5831DC4@oracle.com>

+1

> On 18 Mar 2015, at 16:55, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8075448/  for https://bugs.openjdk.java.net/browse/JDK-8075448
> 
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Wed Mar 18 17:27:25 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 18 Mar 2015 22:57:25 +0530
Subject: RFR 8075454: Anonymous functions have internal names exposed via
	parser API
Message-ID: <5509B57D.1000606@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8075454/ for 
https://bugs.openjdk.java.net/browse/JDK-8075454

Thanks,
-Sundar

From marcus.lagergren at oracle.com  Wed Mar 18 17:44:14 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 18 Mar 2015 18:44:14 +0100
Subject: RFR 8075454: Anonymous functions have internal names exposed via
	parser API
In-Reply-To: <5509B57D.1000606@oracle.com>
References: <5509B57D.1000606@oracle.com>
Message-ID: <AF74FB73-AA69-47B7-B562-CB56C0BA991F@oracle.com>

+1

> On 18 Mar 2015, at 18:27, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8075454/ for https://bugs.openjdk.java.net/browse/JDK-8075454
> 
> Thanks,
> -Sundar


From attila.szegedi at oracle.com  Wed Mar 18 18:20:06 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 18 Mar 2015 19:20:06 +0100
Subject: RFR 8075454: Anonymous functions have internal names exposed via
	parser API
In-Reply-To: <AF74FB73-AA69-47B7-B562-CB56C0BA991F@oracle.com>
References: <5509B57D.1000606@oracle.com>
	<AF74FB73-AA69-47B7-B562-CB56C0BA991F@oracle.com>
Message-ID: <CDBF80F2-B218-4746-A80B-B667AF175032@oracle.com>

+1

On Mar 18, 2015, at 6:44 PM, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:

> +1
> 
>> On 18 Mar 2015, at 18:27, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
>> 
>> Please review http://cr.openjdk.java.net/~sundar/8075454/ for https://bugs.openjdk.java.net/browse/JDK-8075454
>> 
>> Thanks,
>> -Sundar
> 


From cpettitt at linkedin.com  Wed Mar 18 22:30:57 2015
From: cpettitt at linkedin.com (Chris Pettitt)
Date: Wed, 18 Mar 2015 22:30:57 +0000
Subject: 8u20 with multi-threaded class cache
In-Reply-To: <550866AB.5030708@oracle.com>
References: <8A9DFF013D0EBB439171DAF88E4C7EA9C759A1A7@LCA1-MB01.linkedin.biz>,
	<550866AB.5030708@oracle.com>
Message-ID: <8A9DFF013D0EBB439171DAF88E4C7EA9C759D0ED@LCA1-MB01.linkedin.biz>

Hannes,

Thanks for the detailed reply - this is very helpful. Your answers clear up my questions for #1 and #2.

For #3, I was hoping we could use some key to retrieve the cached classes that did not involve reloading / re-reading the source scripts on each lookup. jdk.nashorn.internal.runtime.Source is used as the key in jdk.nashorn.internal.objects.Global.findCachedClass. Source tries to avoid the cost of walking the source contents twice, once for hashing (by caching the hash) and once for the equality check by checking the reference. Unfortunately, it *appears* that we're always locked out of this optimization because there is no public way to feed a Source into the NashornScriptEngine.

Thanks,
Chris

________________________________________
From: Hannes Wallnoefer [hannes.wallnoefer at oracle.com]
Sent: Tuesday, March 17, 2015 10:38
To: Chris Pettitt; nashorn-dev at openjdk.java.net; Kunal Cholera
Subject: Re: 8u20 with multi-threaded class cache

Hi Chris, Kunal,

Answers are inlined below.

Am 2015-03-16 um 23:03 schrieb Chris Pettitt:
> Hi folks,
>
> We're looking into the possibility of using the class cache in multi-threaded code, as introduced in [1]. We have a few questions related to this feature:
>
> 1. The article implies that ScriptEngine can be treated as thread-safe - provided we're not using the default context - though the code doesn't state this explicitly. Is this a safe assumption? Are there any other caveats?

This is correct as far as Nashorn is concerned. In the original JDK8
release, using a ScriptEngine with multiple bindings/globals will
compile each script from scratch. We introduced the class caching in
8u20 as our best effort to fit code reuse on the existing ScriptEngine
API. The only caveat I can think of is that code may run slower with
multiple bindings because of callsite polymorphism. Also bear in mind
that this is a relatively new feature, but there seemed to be no problem
using it with your dust scripts (see example below).

> 2. As we need to set the Context for each eval, does this lock us out of using Invocable?

You can actually use this with Invocable.invokeMethod(), passing the
binding as first argument ("thiz" parameter). I've rewritten the
threaded class cache example from the blog post to do this with your
dust benchmark and it seems to work fine:

https://gist.github.com/hns/8f52a620ce36daa3d0ca

I just edited the bench.js file to remove the benchmark loop at the
bottom, otherwise this will run with the script files you sent me. Feel
free to use this as a starting point for your own testing.

It could also work with the other Invocable method taking a "thiz"
parameter, getInterface(Object, Class), but I haven't tested this.

>
> 3. The code for determining if two Sources are the same ultimately falls back to a comparison of the url / name / content of the scripts. Is there a way to eval with a Source to avoid this fallback? It looks like it is not exposed in a public way.

I'm not sure I understand this question. What I use in my example is
jdk.nashorn.api.scripting.URLReader, which is handy to preserve the
source URL in error messages.  I believe Nashorn will still load the
content of the URL to make sure scripts are actually identical.

I hope this helps. Let me know if you have further questions.

Regards,
Hannes

> [1]: https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using
>
> Thanks,
> Chris


From sundararajan.athijegannathan at oracle.com  Thu Mar 19 04:45:11 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 19 Mar 2015 10:15:11 +0530
Subject: RFR 8006996: Add a pretty printer that prints script source in nice
	form
Message-ID: <550A5457.30000@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8006996/ for 
https://bugs.openjdk.java.net/browse/JDK-8006996

Thanks,
-Sundar

From marcus.lagergren at oracle.com  Thu Mar 19 06:00:13 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Thu, 19 Mar 2015 07:00:13 +0100
Subject: RFR 8006996: Add a pretty printer that prints script source in
	nice form
In-Reply-To: <550A5457.30000@oracle.com>
References: <550A5457.30000@oracle.com>
Message-ID: <DA771F7F-0BB7-418E-B705-27D45186985F@oracle.com>

+1

> On 19 Mar 2015, at 05:45, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8006996/ for https://bugs.openjdk.java.net/browse/JDK-8006996
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Thu Mar 19 09:36:18 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 19 Mar 2015 10:36:18 +0100
Subject: RFR 8006996: Add a pretty printer that prints script source in
	nice form
In-Reply-To: <550A5457.30000@oracle.com>
References: <550A5457.30000@oracle.com>
Message-ID: <550A9892.5060807@oracle.com>

+1

I think "intent" should be "indent" for indentation.

This would be a terser representation of operators, although I realize 
it's a matter of taste:

var operators = {
     POSTFIX_INCREMENT : "++",
     POSTFIX_DECREMENT: "--",
     ...
};

operators[Kind.POSTFIX_INCREMENT]    // can use Java enum values as keys


-- Hannes


Am 2015-03-19 um 05:45 schrieb A. Sundararajan:
> Please review http://cr.openjdk.java.net/~sundar/8006996/ for 
> https://bugs.openjdk.java.net/browse/JDK-8006996
>
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Thu Mar 19 09:42:21 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 19 Mar 2015 15:12:21 +0530
Subject: RFR 8006996: Add a pretty printer that prints script source in
	nice form
In-Reply-To: <550A9892.5060807@oracle.com>
References: <550A5457.30000@oracle.com> <550A9892.5060807@oracle.com>
Message-ID: <550A99FD.8070905@oracle.com>

Thanks for the review. Updated and uploaded revised webrev for reference 
: http://cr.openjdk.java.net/~sundar/8006996/webrev.01/

Thanks,
-Sundar

On Thursday 19 March 2015 03:06 PM, Hannes Wallnoefer wrote:
> +1
>
> I think "intent" should be "indent" for indentation.
>
> This would be a terser representation of operators, although I realize 
> it's a matter of taste:
>
> var operators = {
>     POSTFIX_INCREMENT : "++",
>     POSTFIX_DECREMENT: "--",
>     ...
> };
>
> operators[Kind.POSTFIX_INCREMENT]    // can use Java enum values as keys
>
>
> -- Hannes
>
>
> Am 2015-03-19 um 05:45 schrieb A. Sundararajan:
>> Please review http://cr.openjdk.java.net/~sundar/8006996/ for 
>> https://bugs.openjdk.java.net/browse/JDK-8006996
>>
>> Thanks,
>> -Sundar
>


From sundararajan.athijegannathan at oracle.com  Thu Mar 19 13:32:09 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 19 Mar 2015 19:02:09 +0530
Subject: 8u20 with multi-threaded class cache
In-Reply-To: <8A9DFF013D0EBB439171DAF88E4C7EA9C759D0ED@LCA1-MB01.linkedin.biz>
References: <8A9DFF013D0EBB439171DAF88E4C7EA9C759A1A7@LCA1-MB01.linkedin.biz>,
	<550866AB.5030708@oracle.com>
	<8A9DFF013D0EBB439171DAF88E4C7EA9C759D0ED@LCA1-MB01.linkedin.biz>
Message-ID: <550ACFD9.3020809@oracle.com>

Hi Chris,

If you use Nashorn's URLReader ( 
http://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/URLReader.html 
- a Reader wrapping a script URL object), then nashorn's Source would be 
cached against that URL could be re-used (and the compiled Class object 
as well via findCachedClass).

     engine.eval(new URLReader(myScriptURL));

Also, any script loaded via "load(url)" built-in could also be 
compiled/cached and re-used (against that URL + last modified since of 
the same).

Hope this helps,
-Sundar

On Thursday 19 March 2015 04:00 AM, Chris Pettitt wrote:
> Hannes,
>
> Thanks for the detailed reply - this is very helpful. Your answers clear up my questions for #1 and #2.
>
> For #3, I was hoping we could use some key to retrieve the cached classes that did not involve reloading / re-reading the source scripts on each lookup. jdk.nashorn.internal.runtime.Source is used as the key in jdk.nashorn.internal.objects.Global.findCachedClass. Source tries to avoid the cost of walking the source contents twice, once for hashing (by caching the hash) and once for the equality check by checking the reference. Unfortunately, it *appears* that we're always locked out of this optimization because there is no public way to feed a Source into the NashornScriptEngine.
>
> Thanks,
> Chris
>
> ________________________________________
> From: Hannes Wallnoefer [hannes.wallnoefer at oracle.com]
> Sent: Tuesday, March 17, 2015 10:38
> To: Chris Pettitt; nashorn-dev at openjdk.java.net; Kunal Cholera
> Subject: Re: 8u20 with multi-threaded class cache
>
> Hi Chris, Kunal,
>
> Answers are inlined below.
>
> Am 2015-03-16 um 23:03 schrieb Chris Pettitt:
>> Hi folks,
>>
>> We're looking into the possibility of using the class cache in multi-threaded code, as introduced in [1]. We have a few questions related to this feature:
>>
>> 1. The article implies that ScriptEngine can be treated as thread-safe - provided we're not using the default context - though the code doesn't state this explicitly. Is this a safe assumption? Are there any other caveats?
> This is correct as far as Nashorn is concerned. In the original JDK8
> release, using a ScriptEngine with multiple bindings/globals will
> compile each script from scratch. We introduced the class caching in
> 8u20 as our best effort to fit code reuse on the existing ScriptEngine
> API. The only caveat I can think of is that code may run slower with
> multiple bindings because of callsite polymorphism. Also bear in mind
> that this is a relatively new feature, but there seemed to be no problem
> using it with your dust scripts (see example below).
>
>> 2. As we need to set the Context for each eval, does this lock us out of using Invocable?
> You can actually use this with Invocable.invokeMethod(), passing the
> binding as first argument ("thiz" parameter). I've rewritten the
> threaded class cache example from the blog post to do this with your
> dust benchmark and it seems to work fine:
>
> https://gist.github.com/hns/8f52a620ce36daa3d0ca
>
> I just edited the bench.js file to remove the benchmark loop at the
> bottom, otherwise this will run with the script files you sent me. Feel
> free to use this as a starting point for your own testing.
>
> It could also work with the other Invocable method taking a "thiz"
> parameter, getInterface(Object, Class), but I haven't tested this.
>
>> 3. The code for determining if two Sources are the same ultimately falls back to a comparison of the url / name / content of the scripts. Is there a way to eval with a Source to avoid this fallback? It looks like it is not exposed in a public way.
> I'm not sure I understand this question. What I use in my example is
> jdk.nashorn.api.scripting.URLReader, which is handy to preserve the
> source URL in error messages.  I believe Nashorn will still load the
> content of the URL to make sure scripts are actually identical.
>
> I hope this helps. Let me know if you have further questions.
>
> Regards,
> Hannes
>
>> [1]: https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using
>>
>> Thanks,
>> Chris


From cpettitt at linkedin.com  Thu Mar 19 17:35:12 2015
From: cpettitt at linkedin.com (Chris Pettitt)
Date: Thu, 19 Mar 2015 17:35:12 +0000
Subject: 8u20 with multi-threaded class cache
In-Reply-To: <550ACFD9.3020809@oracle.com>
References: <8A9DFF013D0EBB439171DAF88E4C7EA9C759A1A7@LCA1-MB01.linkedin.biz>, 
	<550866AB.5030708@oracle.com>
	<8A9DFF013D0EBB439171DAF88E4C7EA9C759D0ED@LCA1-MB01.linkedin.biz>,
	<550ACFD9.3020809@oracle.com>
Message-ID: <8A9DFF013D0EBB439171DAF88E4C7EA9C759D9E2@LCA1-MB01.linkedin.biz>

Hi Sundar,

Thanks for the follow up. I'm hoping for something along the lines of what you 
described. The code I see seems to suggest different behavior (described
below), but it could be that I'm looking at older code (I'm using [1]) or that
I'm just looking at the wrong code.

Let's assume we'll use the same URLReader for each call to engine.eval. The 
call to engine.eval will then call makeSource:

    @Override
    public Object eval(final Reader reader, final ScriptContext ctxt) throws ScriptException {
        return evalImpl(makeSource(reader, ctxt), ctxt);
    }
    
This in turn creates a new Source - at least in the version I'm looking at:

    private static Source makeSource(final Reader reader, final ScriptContext ctxt) throws ScriptException {
        try {
            if (reader instanceof URLReader) {
                final URL url = ((URLReader)reader).getURL();
                final Charset cs = ((URLReader)reader).getCharset();
                return new Source(url.toString(), url, cs);
            }
            return new Source(getScriptName(ctxt), Source.readFully(reader));
        } catch (final IOException e) {
            throw new ScriptException(e);
        }
    }
    
Since we created a new object for the Source, the reference check in 
Source.equals will return false, and we'll fall back to doing a full array
comparison:

    @Override
    public boolean equals(final Object obj) {
        if (this == obj) {
            return true;
        }

        if (!(obj instanceof Source)) {
            return false;
        }

        final Source src = (Source)obj;
        // Only compare content as a last resort measure
        return length == src.length && Objects.equals(url, src.url) && Objects.equals(name, src.name) && Arrays.equals(content, src.content);
    }
    
Also, by virtue of calling Source(url.toString(), url, cs) we'll end up 
re-reading the entire source each time we call eval:

    public Source(final String name, final URL url, final Charset cs) throws IOException {
        this(name, baseURL(url, null), readFully(url, cs), url);
    }
    
What do you think? Am I looking in the wrong place, out-of-date 
code, or is my understanding flawed?

Thanks again to both you and Hannes for your patience and help.

[1]: http://hg.openjdk.java.net/jdk8u/jdk8u

Best,
Chris

________________________________________
From: nashorn-dev [nashorn-dev-bounces at openjdk.java.net] on behalf of A. Sundararajan [sundararajan.athijegannathan at oracle.com]
Sent: Thursday, March 19, 2015 06:32
To: nashorn-dev at openjdk.java.net
Subject: Re: 8u20 with multi-threaded class cache

Hi Chris,

If you use Nashorn's URLReader (
http://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/URLReader.html
- a Reader wrapping a script URL object), then nashorn's Source would be
cached against that URL could be re-used (and the compiled Class object
as well via findCachedClass).

     engine.eval(new URLReader(myScriptURL));

Also, any script loaded via "load(url)" built-in could also be
compiled/cached and re-used (against that URL + last modified since of
the same).

Hope this helps,
-Sundar

On Thursday 19 March 2015 04:00 AM, Chris Pettitt wrote:
> Hannes,
>
> Thanks for the detailed reply - this is very helpful. Your answers clear up my questions for #1 and #2.
>
> For #3, I was hoping we could use some key to retrieve the cached classes that did not involve reloading / re-reading the source scripts on each lookup. jdk.nashorn.internal.runtime.Source is used as the key in jdk.nashorn.internal.objects.Global.findCachedClass. Source tries to avoid the cost of walking the source contents twice, once for hashing (by caching the hash) and once for the equality check by checking the reference. Unfortunately, it *appears* that we're always locked out of this optimization because there is no public way to feed a Source into the NashornScriptEngine.
>
> Thanks,
> Chris
>
> ________________________________________
> From: Hannes Wallnoefer [hannes.wallnoefer at oracle.com]
> Sent: Tuesday, March 17, 2015 10:38
> To: Chris Pettitt; nashorn-dev at openjdk.java.net; Kunal Cholera
> Subject: Re: 8u20 with multi-threaded class cache
>
> Hi Chris, Kunal,
>
> Answers are inlined below.
>
> Am 2015-03-16 um 23:03 schrieb Chris Pettitt:
>> Hi folks,
>>
>> We're looking into the possibility of using the class cache in multi-threaded code, as introduced in [1]. We have a few questions related to this feature:
>>
>> 1. The article implies that ScriptEngine can be treated as thread-safe - provided we're not using the default context - though the code doesn't state this explicitly. Is this a safe assumption? Are there any other caveats?
> This is correct as far as Nashorn is concerned. In the original JDK8
> release, using a ScriptEngine with multiple bindings/globals will
> compile each script from scratch. We introduced the class caching in
> 8u20 as our best effort to fit code reuse on the existing ScriptEngine
> API. The only caveat I can think of is that code may run slower with
> multiple bindings because of callsite polymorphism. Also bear in mind
> that this is a relatively new feature, but there seemed to be no problem
> using it with your dust scripts (see example below).
>
>> 2. As we need to set the Context for each eval, does this lock us out of using Invocable?
> You can actually use this with Invocable.invokeMethod(), passing the
> binding as first argument ("thiz" parameter). I've rewritten the
> threaded class cache example from the blog post to do this with your
> dust benchmark and it seems to work fine:
>
> https://gist.github.com/hns/8f52a620ce36daa3d0ca
>
> I just edited the bench.js file to remove the benchmark loop at the
> bottom, otherwise this will run with the script files you sent me. Feel
> free to use this as a starting point for your own testing.
>
> It could also work with the other Invocable method taking a "thiz"
> parameter, getInterface(Object, Class), but I haven't tested this.
>
>> 3. The code for determining if two Sources are the same ultimately falls back to a comparison of the url / name / content of the scripts. Is there a way to eval with a Source to avoid this fallback? It looks like it is not exposed in a public way.
> I'm not sure I understand this question. What I use in my example is
> jdk.nashorn.api.scripting.URLReader, which is handy to preserve the
> source URL in error messages.  I believe Nashorn will still load the
> content of the URL to make sure scripts are actually identical.
>
> I hope this helps. Let me know if you have further questions.
>
> Regards,
> Hannes
>
>> [1]: https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using
>>
>> Thanks,
>> Chris


From sundararajan.athijegannathan at oracle.com  Thu Mar 19 18:10:02 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 19 Mar 2015 23:40:02 +0530
Subject: 8u20 with multi-threaded class cache
In-Reply-To: <8A9DFF013D0EBB439171DAF88E4C7EA9C759D9E2@LCA1-MB01.linkedin.biz>
References: <8A9DFF013D0EBB439171DAF88E4C7EA9C759A1A7@LCA1-MB01.linkedin.biz>,
	<550866AB.5030708@oracle.com>	<8A9DFF013D0EBB439171DAF88E4C7EA9C759D0ED@LCA1-MB01.linkedin.biz>,
	<550ACFD9.3020809@oracle.com>
	<8A9DFF013D0EBB439171DAF88E4C7EA9C759D9E2@LCA1-MB01.linkedin.biz>
Message-ID: <550B10FA.2080307@oracle.com>

Hi,

Perhaps repo not sync'ed?

http://hg.openjdk.java.net/jdk8u/jdk8u/nashorn/file/da9741520576/src/jdk/nashorn/api/scripting/NashornScriptEngine.java

You can see Source.sourceFor static helper is called to create Source 
object. And that one has cache logic to choose existing Source - if 
available. And Context.findCachedClass(Source) can check Source->Class 
cache.

BTW, nashorn development checks into this repo for 8 update fixes:

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/

You can check here too:

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/file/e024db176497/src/jdk/nashorn/api/scripting/NashornScriptEngine.java

Hope this helps,
-Sundar


On Thursday 19 March 2015 11:05 PM, Chris Pettitt wrote:
> Hi Sundar,
>
> Thanks for the follow up. I'm hoping for something along the lines of what you
> described. The code I see seems to suggest different behavior (described
> below), but it could be that I'm looking at older code (I'm using [1]) or that
> I'm just looking at the wrong code.
>
> Let's assume we'll use the same URLReader for each call to engine.eval. The
> call to engine.eval will then call makeSource:
>
>      @Override
>      public Object eval(final Reader reader, final ScriptContext ctxt) throws ScriptException {
>          return evalImpl(makeSource(reader, ctxt), ctxt);
>      }
>      
> This in turn creates a new Source - at least in the version I'm looking at:
>
>      private static Source makeSource(final Reader reader, final ScriptContext ctxt) throws ScriptException {
>          try {
>              if (reader instanceof URLReader) {
>                  final URL url = ((URLReader)reader).getURL();
>                  final Charset cs = ((URLReader)reader).getCharset();
>                  return new Source(url.toString(), url, cs);
>              }
>              return new Source(getScriptName(ctxt), Source.readFully(reader));
>          } catch (final IOException e) {
>              throw new ScriptException(e);
>          }
>      }
>      
> Since we created a new object for the Source, the reference check in
> Source.equals will return false, and we'll fall back to doing a full array
> comparison:
>
>      @Override
>      public boolean equals(final Object obj) {
>          if (this == obj) {
>              return true;
>          }
>
>          if (!(obj instanceof Source)) {
>              return false;
>          }
>
>          final Source src = (Source)obj;
>          // Only compare content as a last resort measure
>          return length == src.length && Objects.equals(url, src.url) && Objects.equals(name, src.name) && Arrays.equals(content, src.content);
>      }
>      
> Also, by virtue of calling Source(url.toString(), url, cs) we'll end up
> re-reading the entire source each time we call eval:
>
>      public Source(final String name, final URL url, final Charset cs) throws IOException {
>          this(name, baseURL(url, null), readFully(url, cs), url);
>      }
>      
> What do you think? Am I looking in the wrong place, out-of-date
> code, or is my understanding flawed?
>
> Thanks again to both you and Hannes for your patience and help.
>
> [1]: http://hg.openjdk.java.net/jdk8u/jdk8u
>
> Best,
> Chris
>
> ________________________________________
> From: nashorn-dev [nashorn-dev-bounces at openjdk.java.net] on behalf of A. Sundararajan [sundararajan.athijegannathan at oracle.com]
> Sent: Thursday, March 19, 2015 06:32
> To: nashorn-dev at openjdk.java.net
> Subject: Re: 8u20 with multi-threaded class cache
>
> Hi Chris,
>
> If you use Nashorn's URLReader (
> http://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/URLReader.html
> - a Reader wrapping a script URL object), then nashorn's Source would be
> cached against that URL could be re-used (and the compiled Class object
> as well via findCachedClass).
>
>       engine.eval(new URLReader(myScriptURL));
>
> Also, any script loaded via "load(url)" built-in could also be
> compiled/cached and re-used (against that URL + last modified since of
> the same).
>
> Hope this helps,
> -Sundar
>
> On Thursday 19 March 2015 04:00 AM, Chris Pettitt wrote:
>> Hannes,
>>
>> Thanks for the detailed reply - this is very helpful. Your answers clear up my questions for #1 and #2.
>>
>> For #3, I was hoping we could use some key to retrieve the cached classes that did not involve reloading / re-reading the source scripts on each lookup. jdk.nashorn.internal.runtime.Source is used as the key in jdk.nashorn.internal.objects.Global.findCachedClass. Source tries to avoid the cost of walking the source contents twice, once for hashing (by caching the hash) and once for the equality check by checking the reference. Unfortunately, it *appears* that we're always locked out of this optimization because there is no public way to feed a Source into the NashornScriptEngine.
>>
>> Thanks,
>> Chris
>>
>> ________________________________________
>> From: Hannes Wallnoefer [hannes.wallnoefer at oracle.com]
>> Sent: Tuesday, March 17, 2015 10:38
>> To: Chris Pettitt; nashorn-dev at openjdk.java.net; Kunal Cholera
>> Subject: Re: 8u20 with multi-threaded class cache
>>
>> Hi Chris, Kunal,
>>
>> Answers are inlined below.
>>
>> Am 2015-03-16 um 23:03 schrieb Chris Pettitt:
>>> Hi folks,
>>>
>>> We're looking into the possibility of using the class cache in multi-threaded code, as introduced in [1]. We have a few questions related to this feature:
>>>
>>> 1. The article implies that ScriptEngine can be treated as thread-safe - provided we're not using the default context - though the code doesn't state this explicitly. Is this a safe assumption? Are there any other caveats?
>> This is correct as far as Nashorn is concerned. In the original JDK8
>> release, using a ScriptEngine with multiple bindings/globals will
>> compile each script from scratch. We introduced the class caching in
>> 8u20 as our best effort to fit code reuse on the existing ScriptEngine
>> API. The only caveat I can think of is that code may run slower with
>> multiple bindings because of callsite polymorphism. Also bear in mind
>> that this is a relatively new feature, but there seemed to be no problem
>> using it with your dust scripts (see example below).
>>
>>> 2. As we need to set the Context for each eval, does this lock us out of using Invocable?
>> You can actually use this with Invocable.invokeMethod(), passing the
>> binding as first argument ("thiz" parameter). I've rewritten the
>> threaded class cache example from the blog post to do this with your
>> dust benchmark and it seems to work fine:
>>
>> https://gist.github.com/hns/8f52a620ce36daa3d0ca
>>
>> I just edited the bench.js file to remove the benchmark loop at the
>> bottom, otherwise this will run with the script files you sent me. Feel
>> free to use this as a starting point for your own testing.
>>
>> It could also work with the other Invocable method taking a "thiz"
>> parameter, getInterface(Object, Class), but I haven't tested this.
>>
>>> 3. The code for determining if two Sources are the same ultimately falls back to a comparison of the url / name / content of the scripts. Is there a way to eval with a Source to avoid this fallback? It looks like it is not exposed in a public way.
>> I'm not sure I understand this question. What I use in my example is
>> jdk.nashorn.api.scripting.URLReader, which is handy to preserve the
>> source URL in error messages.  I believe Nashorn will still load the
>> content of the URL to make sure scripts are actually identical.
>>
>> I hope this helps. Let me know if you have further questions.
>>
>> Regards,
>> Hannes
>>
>>> [1]: https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using
>>>
>>> Thanks,
>>> Chris


From cpettitt at linkedin.com  Thu Mar 19 21:22:22 2015
From: cpettitt at linkedin.com (Chris Pettitt)
Date: Thu, 19 Mar 2015 21:22:22 +0000
Subject: 8u20 with multi-threaded class cache
In-Reply-To: <550B10FA.2080307@oracle.com>
References: <8A9DFF013D0EBB439171DAF88E4C7EA9C759A1A7@LCA1-MB01.linkedin.biz>, 
	<550866AB.5030708@oracle.com>
	<8A9DFF013D0EBB439171DAF88E4C7EA9C759D0ED@LCA1-MB01.linkedin.biz>,
	<550ACFD9.3020809@oracle.com>
	<8A9DFF013D0EBB439171DAF88E4C7EA9C759D9E2@LCA1-MB01.linkedin.biz>,
	<550B10FA.2080307@oracle.com>
Message-ID: <8A9DFF013D0EBB439171DAF88E4C7EA9C759E553@LCA1-MB01.linkedin.biz>

Hi Sundar,

Thanks again for all of the help. The code looks good when I pulled from jdk8u-dev.

Thanks,
Chris

________________________________________
From: A. Sundararajan [sundararajan.athijegannathan at oracle.com]
Sent: Thursday, March 19, 2015 11:10
To: Chris Pettitt; nashorn-dev at openjdk.java.net
Subject: Re: 8u20 with multi-threaded class cache

Hi,

Perhaps repo not sync'ed?

http://hg.openjdk.java.net/jdk8u/jdk8u/nashorn/file/da9741520576/src/jdk/nashorn/api/scripting/NashornScriptEngine.java

You can see Source.sourceFor static helper is called to create Source
object. And that one has cache logic to choose existing Source - if
available. And Context.findCachedClass(Source) can check Source->Class
cache.

BTW, nashorn development checks into this repo for 8 update fixes:

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/

You can check here too:

http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/file/e024db176497/src/jdk/nashorn/api/scripting/NashornScriptEngine.java

Hope this helps,
-Sundar


On Thursday 19 March 2015 11:05 PM, Chris Pettitt wrote:
> Hi Sundar,
>
> Thanks for the follow up. I'm hoping for something along the lines of what you
> described. The code I see seems to suggest different behavior (described
> below), but it could be that I'm looking at older code (I'm using [1]) or that
> I'm just looking at the wrong code.
>
> Let's assume we'll use the same URLReader for each call to engine.eval. The
> call to engine.eval will then call makeSource:
>
>      @Override
>      public Object eval(final Reader reader, final ScriptContext ctxt) throws ScriptException {
>          return evalImpl(makeSource(reader, ctxt), ctxt);
>      }
>
> This in turn creates a new Source - at least in the version I'm looking at:
>
>      private static Source makeSource(final Reader reader, final ScriptContext ctxt) throws ScriptException {
>          try {
>              if (reader instanceof URLReader) {
>                  final URL url = ((URLReader)reader).getURL();
>                  final Charset cs = ((URLReader)reader).getCharset();
>                  return new Source(url.toString(), url, cs);
>              }
>              return new Source(getScriptName(ctxt), Source.readFully(reader));
>          } catch (final IOException e) {
>              throw new ScriptException(e);
>          }
>      }
>
> Since we created a new object for the Source, the reference check in
> Source.equals will return false, and we'll fall back to doing a full array
> comparison:
>
>      @Override
>      public boolean equals(final Object obj) {
>          if (this == obj) {
>              return true;
>          }
>
>          if (!(obj instanceof Source)) {
>              return false;
>          }
>
>          final Source src = (Source)obj;
>          // Only compare content as a last resort measure
>          return length == src.length && Objects.equals(url, src.url) && Objects.equals(name, src.name) && Arrays.equals(content, src.content);
>      }
>
> Also, by virtue of calling Source(url.toString(), url, cs) we'll end up
> re-reading the entire source each time we call eval:
>
>      public Source(final String name, final URL url, final Charset cs) throws IOException {
>          this(name, baseURL(url, null), readFully(url, cs), url);
>      }
>
> What do you think? Am I looking in the wrong place, out-of-date
> code, or is my understanding flawed?
>
> Thanks again to both you and Hannes for your patience and help.
>
> [1]: http://hg.openjdk.java.net/jdk8u/jdk8u
>
> Best,
> Chris
>
> ________________________________________
> From: nashorn-dev [nashorn-dev-bounces at openjdk.java.net] on behalf of A. Sundararajan [sundararajan.athijegannathan at oracle.com]
> Sent: Thursday, March 19, 2015 06:32
> To: nashorn-dev at openjdk.java.net
> Subject: Re: 8u20 with multi-threaded class cache
>
> Hi Chris,
>
> If you use Nashorn's URLReader (
> http://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/URLReader.html
> - a Reader wrapping a script URL object), then nashorn's Source would be
> cached against that URL could be re-used (and the compiled Class object
> as well via findCachedClass).
>
>       engine.eval(new URLReader(myScriptURL));
>
> Also, any script loaded via "load(url)" built-in could also be
> compiled/cached and re-used (against that URL + last modified since of
> the same).
>
> Hope this helps,
> -Sundar
>
> On Thursday 19 March 2015 04:00 AM, Chris Pettitt wrote:
>> Hannes,
>>
>> Thanks for the detailed reply - this is very helpful. Your answers clear up my questions for #1 and #2.
>>
>> For #3, I was hoping we could use some key to retrieve the cached classes that did not involve reloading / re-reading the source scripts on each lookup. jdk.nashorn.internal.runtime.Source is used as the key in jdk.nashorn.internal.objects.Global.findCachedClass. Source tries to avoid the cost of walking the source contents twice, once for hashing (by caching the hash) and once for the equality check by checking the reference. Unfortunately, it *appears* that we're always locked out of this optimization because there is no public way to feed a Source into the NashornScriptEngine.
>>
>> Thanks,
>> Chris
>>
>> ________________________________________
>> From: Hannes Wallnoefer [hannes.wallnoefer at oracle.com]
>> Sent: Tuesday, March 17, 2015 10:38
>> To: Chris Pettitt; nashorn-dev at openjdk.java.net; Kunal Cholera
>> Subject: Re: 8u20 with multi-threaded class cache
>>
>> Hi Chris, Kunal,
>>
>> Answers are inlined below.
>>
>> Am 2015-03-16 um 23:03 schrieb Chris Pettitt:
>>> Hi folks,
>>>
>>> We're looking into the possibility of using the class cache in multi-threaded code, as introduced in [1]. We have a few questions related to this feature:
>>>
>>> 1. The article implies that ScriptEngine can be treated as thread-safe - provided we're not using the default context - though the code doesn't state this explicitly. Is this a safe assumption? Are there any other caveats?
>> This is correct as far as Nashorn is concerned. In the original JDK8
>> release, using a ScriptEngine with multiple bindings/globals will
>> compile each script from scratch. We introduced the class caching in
>> 8u20 as our best effort to fit code reuse on the existing ScriptEngine
>> API. The only caveat I can think of is that code may run slower with
>> multiple bindings because of callsite polymorphism. Also bear in mind
>> that this is a relatively new feature, but there seemed to be no problem
>> using it with your dust scripts (see example below).
>>
>>> 2. As we need to set the Context for each eval, does this lock us out of using Invocable?
>> You can actually use this with Invocable.invokeMethod(), passing the
>> binding as first argument ("thiz" parameter). I've rewritten the
>> threaded class cache example from the blog post to do this with your
>> dust benchmark and it seems to work fine:
>>
>> https://gist.github.com/hns/8f52a620ce36daa3d0ca
>>
>> I just edited the bench.js file to remove the benchmark loop at the
>> bottom, otherwise this will run with the script files you sent me. Feel
>> free to use this as a starting point for your own testing.
>>
>> It could also work with the other Invocable method taking a "thiz"
>> parameter, getInterface(Object, Class), but I haven't tested this.
>>
>>> 3. The code for determining if two Sources are the same ultimately falls back to a comparison of the url / name / content of the scripts. Is there a way to eval with a Source to avoid this fallback? It looks like it is not exposed in a public way.
>> I'm not sure I understand this question. What I use in my example is
>> jdk.nashorn.api.scripting.URLReader, which is handy to preserve the
>> source URL in error messages.  I believe Nashorn will still load the
>> content of the URL to make sure scripts are actually identical.
>>
>> I hope this helps. Let me know if you have further questions.
>>
>> Regards,
>> Hannes
>>
>>> [1]: https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using
>>>
>>> Thanks,
>>> Chris


From sundararajan.athijegannathan at oracle.com  Fri Mar 20 03:31:21 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 20 Mar 2015 09:01:21 +0530
Subject: 8u20 with multi-threaded class cache
In-Reply-To: <8A9DFF013D0EBB439171DAF88E4C7EA9C759E553@LCA1-MB01.linkedin.biz>
References: <8A9DFF013D0EBB439171DAF88E4C7EA9C759A1A7@LCA1-MB01.linkedin.biz>,
	<550866AB.5030708@oracle.com>	<8A9DFF013D0EBB439171DAF88E4C7EA9C759D0ED@LCA1-MB01.linkedin.biz>,
	<550ACFD9.3020809@oracle.com>
	<8A9DFF013D0EBB439171DAF88E4C7EA9C759D9E2@LCA1-MB01.linkedin.biz>,
	<550B10FA.2080307@oracle.com>
	<8A9DFF013D0EBB439171DAF88E4C7EA9C759E553@LCA1-MB01.linkedin.biz>
Message-ID: <550B9489.6030207@oracle.com>

Hi Chris,

You're welcome!

Thanks,
-Sundar

On Friday 20 March 2015 02:52 AM, Chris Pettitt wrote:
> Hi Sundar,
>
> Thanks again for all of the help. The code looks good when I pulled from jdk8u-dev.
>
> Thanks,
> Chris
>
> ________________________________________
> From: A. Sundararajan [sundararajan.athijegannathan at oracle.com]
> Sent: Thursday, March 19, 2015 11:10
> To: Chris Pettitt; nashorn-dev at openjdk.java.net
> Subject: Re: 8u20 with multi-threaded class cache
>
> Hi,
>
> Perhaps repo not sync'ed?
>
> http://hg.openjdk.java.net/jdk8u/jdk8u/nashorn/file/da9741520576/src/jdk/nashorn/api/scripting/NashornScriptEngine.java
>
> You can see Source.sourceFor static helper is called to create Source
> object. And that one has cache logic to choose existing Source - if
> available. And Context.findCachedClass(Source) can check Source->Class
> cache.
>
> BTW, nashorn development checks into this repo for 8 update fixes:
>
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/
>
> You can check here too:
>
> http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn/file/e024db176497/src/jdk/nashorn/api/scripting/NashornScriptEngine.java
>
> Hope this helps,
> -Sundar
>
>
> On Thursday 19 March 2015 11:05 PM, Chris Pettitt wrote:
>> Hi Sundar,
>>
>> Thanks for the follow up. I'm hoping for something along the lines of what you
>> described. The code I see seems to suggest different behavior (described
>> below), but it could be that I'm looking at older code (I'm using [1]) or that
>> I'm just looking at the wrong code.
>>
>> Let's assume we'll use the same URLReader for each call to engine.eval. The
>> call to engine.eval will then call makeSource:
>>
>>       @Override
>>       public Object eval(final Reader reader, final ScriptContext ctxt) throws ScriptException {
>>           return evalImpl(makeSource(reader, ctxt), ctxt);
>>       }
>>
>> This in turn creates a new Source - at least in the version I'm looking at:
>>
>>       private static Source makeSource(final Reader reader, final ScriptContext ctxt) throws ScriptException {
>>           try {
>>               if (reader instanceof URLReader) {
>>                   final URL url = ((URLReader)reader).getURL();
>>                   final Charset cs = ((URLReader)reader).getCharset();
>>                   return new Source(url.toString(), url, cs);
>>               }
>>               return new Source(getScriptName(ctxt), Source.readFully(reader));
>>           } catch (final IOException e) {
>>               throw new ScriptException(e);
>>           }
>>       }
>>
>> Since we created a new object for the Source, the reference check in
>> Source.equals will return false, and we'll fall back to doing a full array
>> comparison:
>>
>>       @Override
>>       public boolean equals(final Object obj) {
>>           if (this == obj) {
>>               return true;
>>           }
>>
>>           if (!(obj instanceof Source)) {
>>               return false;
>>           }
>>
>>           final Source src = (Source)obj;
>>           // Only compare content as a last resort measure
>>           return length == src.length && Objects.equals(url, src.url) && Objects.equals(name, src.name) && Arrays.equals(content, src.content);
>>       }
>>
>> Also, by virtue of calling Source(url.toString(), url, cs) we'll end up
>> re-reading the entire source each time we call eval:
>>
>>       public Source(final String name, final URL url, final Charset cs) throws IOException {
>>           this(name, baseURL(url, null), readFully(url, cs), url);
>>       }
>>
>> What do you think? Am I looking in the wrong place, out-of-date
>> code, or is my understanding flawed?
>>
>> Thanks again to both you and Hannes for your patience and help.
>>
>> [1]: http://hg.openjdk.java.net/jdk8u/jdk8u
>>
>> Best,
>> Chris
>>
>> ________________________________________
>> From: nashorn-dev [nashorn-dev-bounces at openjdk.java.net] on behalf of A. Sundararajan [sundararajan.athijegannathan at oracle.com]
>> Sent: Thursday, March 19, 2015 06:32
>> To: nashorn-dev at openjdk.java.net
>> Subject: Re: 8u20 with multi-threaded class cache
>>
>> Hi Chris,
>>
>> If you use Nashorn's URLReader (
>> http://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/URLReader.html
>> - a Reader wrapping a script URL object), then nashorn's Source would be
>> cached against that URL could be re-used (and the compiled Class object
>> as well via findCachedClass).
>>
>>        engine.eval(new URLReader(myScriptURL));
>>
>> Also, any script loaded via "load(url)" built-in could also be
>> compiled/cached and re-used (against that URL + last modified since of
>> the same).
>>
>> Hope this helps,
>> -Sundar
>>
>> On Thursday 19 March 2015 04:00 AM, Chris Pettitt wrote:
>>> Hannes,
>>>
>>> Thanks for the detailed reply - this is very helpful. Your answers clear up my questions for #1 and #2.
>>>
>>> For #3, I was hoping we could use some key to retrieve the cached classes that did not involve reloading / re-reading the source scripts on each lookup. jdk.nashorn.internal.runtime.Source is used as the key in jdk.nashorn.internal.objects.Global.findCachedClass. Source tries to avoid the cost of walking the source contents twice, once for hashing (by caching the hash) and once for the equality check by checking the reference. Unfortunately, it *appears* that we're always locked out of this optimization because there is no public way to feed a Source into the NashornScriptEngine.
>>>
>>> Thanks,
>>> Chris
>>>
>>> ________________________________________
>>> From: Hannes Wallnoefer [hannes.wallnoefer at oracle.com]
>>> Sent: Tuesday, March 17, 2015 10:38
>>> To: Chris Pettitt; nashorn-dev at openjdk.java.net; Kunal Cholera
>>> Subject: Re: 8u20 with multi-threaded class cache
>>>
>>> Hi Chris, Kunal,
>>>
>>> Answers are inlined below.
>>>
>>> Am 2015-03-16 um 23:03 schrieb Chris Pettitt:
>>>> Hi folks,
>>>>
>>>> We're looking into the possibility of using the class cache in multi-threaded code, as introduced in [1]. We have a few questions related to this feature:
>>>>
>>>> 1. The article implies that ScriptEngine can be treated as thread-safe - provided we're not using the default context - though the code doesn't state this explicitly. Is this a safe assumption? Are there any other caveats?
>>> This is correct as far as Nashorn is concerned. In the original JDK8
>>> release, using a ScriptEngine with multiple bindings/globals will
>>> compile each script from scratch. We introduced the class caching in
>>> 8u20 as our best effort to fit code reuse on the existing ScriptEngine
>>> API. The only caveat I can think of is that code may run slower with
>>> multiple bindings because of callsite polymorphism. Also bear in mind
>>> that this is a relatively new feature, but there seemed to be no problem
>>> using it with your dust scripts (see example below).
>>>
>>>> 2. As we need to set the Context for each eval, does this lock us out of using Invocable?
>>> You can actually use this with Invocable.invokeMethod(), passing the
>>> binding as first argument ("thiz" parameter). I've rewritten the
>>> threaded class cache example from the blog post to do this with your
>>> dust benchmark and it seems to work fine:
>>>
>>> https://gist.github.com/hns/8f52a620ce36daa3d0ca
>>>
>>> I just edited the bench.js file to remove the benchmark loop at the
>>> bottom, otherwise this will run with the script files you sent me. Feel
>>> free to use this as a starting point for your own testing.
>>>
>>> It could also work with the other Invocable method taking a "thiz"
>>> parameter, getInterface(Object, Class), but I haven't tested this.
>>>
>>>> 3. The code for determining if two Sources are the same ultimately falls back to a comparison of the url / name / content of the scripts. Is there a way to eval with a Source to avoid this fallback? It looks like it is not exposed in a public way.
>>> I'm not sure I understand this question. What I use in my example is
>>> jdk.nashorn.api.scripting.URLReader, which is handy to preserve the
>>> source URL in error messages.  I believe Nashorn will still load the
>>> content of the URL to make sure scripts are actually identical.
>>>
>>> I hope this helps. Let me know if you have further questions.
>>>
>>> Regards,
>>> Hannes
>>>
>>>> [1]: https://blogs.oracle.com/nashorn/entry/improving_nashorn_startup_time_using
>>>>
>>>> Thanks,
>>>> Chris


From sundararajan.athijegannathan at oracle.com  Fri Mar 20 13:39:43 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 20 Mar 2015 19:09:43 +0530
Subject: RFR 8075604: jjs exits even when non-daemon threads are still active
Message-ID: <550C231F.8020400@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8075604/ for 
https://bugs.openjdk.java.net/browse/JDK-8075604

Thanks,
-Sundar

From attila.szegedi at oracle.com  Fri Mar 20 13:43:07 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 20 Mar 2015 14:43:07 +0100
Subject: RFR 8075604: jjs exits even when non-daemon threads are still
	active
In-Reply-To: <550C231F.8020400@oracle.com>
References: <550C231F.8020400@oracle.com>
Message-ID: <31444F08-E4B8-4C62-AE55-C6C7CF273E46@oracle.com>

+1

On Mar 20, 2015, at 2:39 PM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:

> Please review http://cr.openjdk.java.net/~sundar/8075604/ for https://bugs.openjdk.java.net/browse/JDK-8075604
> 
> Thanks,
> -Sundar


From james.laskey at oracle.com  Fri Mar 20 13:53:25 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 20 Mar 2015 10:53:25 -0300
Subject: RFR 8075604: jjs exits even when non-daemon threads are still
	active
In-Reply-To: <550C231F.8020400@oracle.com>
References: <550C231F.8020400@oracle.com>
Message-ID: <DAE3BF35-B5BB-4273-99FE-C1AA93EF5137@oracle.com>

+1

> On Mar 20, 2015, at 10:39 AM, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8075604/ for https://bugs.openjdk.java.net/browse/JDK-8075604
> 
> Thanks,
> -Sundar


From james.laskey at oracle.com  Fri Mar 20 17:54:29 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 20 Mar 2015 14:54:29 -0300
Subject: RFR: JDK-8075623 - Temporary patch to get fx imports working interim
Message-ID: <D3B8A225-918D-4EF9-BBF1-229D5FE7C95E@oracle.com>

http://cr.openjdk.java.net/~jlaskey/8075623/webrev/index.html

From marcus.lagergren at oracle.com  Sat Mar 21 14:17:43 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Sat, 21 Mar 2015 15:17:43 +0100
Subject: RFR: JDK-8075623 - Temporary patch to get fx imports working
	interim
In-Reply-To: <D3B8A225-918D-4EF9-BBF1-229D5FE7C95E@oracle.com>
References: <D3B8A225-918D-4EF9-BBF1-229D5FE7C95E@oracle.com>
Message-ID: <509CB7F8-E544-42EA-9BBD-3E681A188CD5@oracle.com>

+1

> On 20 Mar 2015, at 18:54, Jim Laskey (Oracle) <james.laskey at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~jlaskey/8075623/webrev/index.html


From sundararajan.athijegannathan at oracle.com  Mon Mar 23 02:57:20 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 23 Mar 2015 08:27:20 +0530
Subject: RFR: JDK-8075623 - Temporary patch to get fx imports working
	interim
In-Reply-To: <D3B8A225-918D-4EF9-BBF1-229D5FE7C95E@oracle.com>
References: <D3B8A225-918D-4EF9-BBF1-229D5FE7C95E@oracle.com>
Message-ID: <550F8110.6080400@oracle.com>

+1

On Friday 20 March 2015 11:24 PM, Jim Laskey (Oracle) wrote:
> http://cr.openjdk.java.net/~jlaskey/8075623/webrev/index.html


From sergey.lugovoy at oracle.com  Mon Mar 23 10:52:22 2015
From: sergey.lugovoy at oracle.com (Sergey Lugovoy)
Date: Mon, 23 Mar 2015 13:52:22 +0300
Subject: RFR 8075240: Output of some tests contains platform specific line
	break
Message-ID: <550FF066.5060903@oracle.com>

Please review http://cr.openjdk.java.net/~slugovoy/8075240/webrev.00  
for https://bugs.openjdk.java.net/browse/JDK-8075240

-- 
Thanks,
Sergey


From sundararajan.athijegannathan at oracle.com  Mon Mar 23 12:31:38 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 23 Mar 2015 18:01:38 +0530
Subject: RFR 8075240: Output of some tests contains platform specific
	line break
In-Reply-To: <550FF066.5060903@oracle.com>
References: <550FF066.5060903@oracle.com>
Message-ID: <551007AA.4050709@oracle.com>

+1

On Monday 23 March 2015 04:22 PM, Sergey Lugovoy wrote:
> Please review http://cr.openjdk.java.net/~slugovoy/8075240/webrev.00  
> for https://bugs.openjdk.java.net/browse/JDK-8075240
>


From Thomas.BURRIS at 3ds.com  Mon Mar 23 13:06:37 2015
From: Thomas.BURRIS at 3ds.com (BURRIS Thomas)
Date: Mon, 23 Mar 2015 13:06:37 +0000
Subject: Adding js functionality to existing ScriptObjectMirror
Message-ID: <97CDD3EBF3AA0B4AB4F20B16975E85D9EC9A70C1@AG-DCC-MBX11.dsone.3ds.com>

Hi ... I have a cache of ScriptObjectMirrors (SOM) that wrap some compiled javascript and -- at runtime -- I need to inject an additional function into the SOMs. Something like this

     ScriptObjectMirror som = SOMPool.get();
     som.setMember("someFn", <WHAT-HERE?>);

     // so that I am now enabled to do this:
     som.callMember("someFn", "arg1", "arg2");


Possible? I've tried a bunch of approaches, none have worked.

thanks!

This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email and all attachments,

(iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.

For other languages, go to http://www.3ds.com/terms/email-disclaimer

From sundararajan.athijegannathan at oracle.com  Mon Mar 23 14:26:01 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 23 Mar 2015 19:56:01 +0530
Subject: Adding js functionality to existing ScriptObjectMirror
In-Reply-To: <97CDD3EBF3AA0B4AB4F20B16975E85D9EC9A70C1@AG-DCC-MBX11.dsone.3ds.com>
References: <97CDD3EBF3AA0B4AB4F20B16975E85D9EC9A70C1@AG-DCC-MBX11.dsone.3ds.com>
Message-ID: <55102279.5010608@oracle.com>

You could implement additional function in Java as given below..

import javax.script.*;
import jdk.nashorn.api.scripting.*;

public class Main {
   public static void main(String[] a) throws Exception {
     ScriptEngineManager m = new ScriptEngineManager();
     ScriptEngine e = m.getEngineByName("nashorn");
     ScriptObjectMirror obj  = (ScriptObjectMirror)
               e.eval("var obj = ({ foo: 33 }); obj");

     // implement a function object in Java using AbstractJavaObject
     obj.setMember("func", new AbstractJSObject() {
         @Override
         // hook for actual call of "func"
         public Object call(Object thiz, Object... args) {
             return args[0].toString().toUpperCase();
         }

         @Override
         // yes, I am a function!
         public boolean isFunction() { return true; }
     });

     // call it from script
     System.out.println(e.eval("obj.func('hello')"));
     // call it from java
     System.out.println(obj.callMember("func", "hello"));
   }
}

Thanks
-Sundar

On Monday 23 March 2015 06:36 PM, BURRIS Thomas wrote:
> Hi ... I have a cache of ScriptObjectMirrors (SOM) that wrap some compiled javascript and -- at runtime -- I need to inject an additional function into the SOMs. Something like this
>
>       ScriptObjectMirror som = SOMPool.get();
>       som.setMember("someFn", <WHAT-HERE?>);
>
>       // so that I am now enabled to do this:
>       som.callMember("someFn", "arg1", "arg2");
>
>
> Possible? I've tried a bunch of approaches, none have worked.
>
> thanks!
>
> This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
>
> If you are not one of the named recipients or have received this email in error,
>
> (i) you should not read, disclose, or copy it,
>
> (ii) please notify sender of your receipt by reply email and delete this email and all attachments,
>
> (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.
>
> For other languages, go to http://www.3ds.com/terms/email-disclaimer


From attila.szegedi at oracle.com  Mon Mar 23 15:48:51 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 23 Mar 2015 16:48:51 +0100
Subject: Adding js functionality to existing ScriptObjectMirror
In-Reply-To: <97CDD3EBF3AA0B4AB4F20B16975E85D9EC9A70C1@AG-DCC-MBX11.dsone.3ds.com>
References: <97CDD3EBF3AA0B4AB4F20B16975E85D9EC9A70C1@AG-DCC-MBX11.dsone.3ds.com>
Message-ID: <95C80822-4EA2-43D0-90DA-A75227FE2E9D@oracle.com>

As a minor point, type safety wise, I'd suggest you program for the JSObject interface whenever you can instead of for the ScriptObjectMirror concrete type. Just future-proofing it :-)

Attila.

On Mar 23, 2015, at 2:06 PM, BURRIS Thomas <Thomas.BURRIS at 3ds.com> wrote:

> Hi ... I have a cache of ScriptObjectMirrors (SOM) that wrap some compiled javascript and -- at runtime -- I need to inject an additional function into the SOMs. Something like this
> 
>     ScriptObjectMirror som = SOMPool.get();
>     som.setMember("someFn", <WHAT-HERE?>);
> 
>     // so that I am now enabled to do this:
>     som.callMember("someFn", "arg1", "arg2");
> 
> 
> Possible? I've tried a bunch of approaches, none have worked.
> 
> thanks!
> 
> This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
> 
> If you are not one of the named recipients or have received this email in error,
> 
> (i) you should not read, disclose, or copy it,
> 
> (ii) please notify sender of your receipt by reply email and delete this email and all attachments,
> 
> (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email.
> 
> For other languages, go to http://www.3ds.com/terms/email-disclaimer


From sundararajan.athijegannathan at oracle.com  Mon Mar 23 17:11:49 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 23 Mar 2015 22:41:49 +0530
Subject: RFR 8074410: Startup time: Port shell.js to Java
Message-ID: <55104955.8020906@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8074410/ for 
https://bugs.openjdk.java.net/browse/JDK-8074410

Thanks,
-Sundar

From marcus.lagergren at oracle.com  Mon Mar 23 17:42:38 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Mon, 23 Mar 2015 18:42:38 +0100
Subject: RFR 8074410: Startup time: Port shell.js to Java
In-Reply-To: <55104955.8020906@oracle.com>
References: <55104955.8020906@oracle.com>
Message-ID: <0191B0A6-6603-4597-95CB-E51D121D4D74@oracle.com>

+1. Good startup time improvement for jjs!

/M

> On 23 Mar 2015, at 18:11, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8074410/ for https://bugs.openjdk.java.net/browse/JDK-8074410
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Tue Mar 24 08:14:28 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 24 Mar 2015 09:14:28 +0100
Subject: RFR 8074410: Startup time: Port shell.js to Java
In-Reply-To: <55104955.8020906@oracle.com>
References: <55104955.8020906@oracle.com>
Message-ID: <55111CE4.60503@oracle.com>

+1

Am 2015-03-23 um 18:11 schrieb A. Sundararajan:
> Please review http://cr.openjdk.java.net/~sundar/8074410/ for 
> https://bugs.openjdk.java.net/browse/JDK-8074410
>
> Thanks,
> -Sundar


From tal.liron at threecrickets.com  Wed Mar 25 00:40:26 2015
From: tal.liron at threecrickets.com (Tal Liron)
Date: Tue, 24 Mar 2015 19:40:26 -0500
Subject: !isNaN(value - 0)
Message-ID: <551203FA.1070600@threecrickets.com>

In most JavaScript engines, this would return true if value is fully 
numerical:

!isNaN(value - 0)

But in Nashorn, it returns true if even if value is a string that begins 
with a number. It seems that arithmetic with strings is working 
non-standardly in Nashorn.

From tal.liron at threecrickets.com  Wed Mar 25 00:48:42 2015
From: tal.liron at threecrickets.com (Tal Liron)
Date: Tue, 24 Mar 2015 19:48:42 -0500
Subject: !isNaN(value - 0)
In-Reply-To: <551203FA.1070600@threecrickets.com>
References: <551203FA.1070600@threecrickets.com>
Message-ID: <551205EA.304@threecrickets.com>

Hm, actually, something weirder is going on:

isNaN('1.5x') -> true
isNaN('1.5d') -> false

What is it about "d"? Is it some kind of numerical literal? Again, this 
is not standard behavior for JavaScript.

On 03/24/2015 07:40 PM, Tal Liron wrote:
> In most JavaScript engines, this would return true if value is fully 
> numerical:
>
> !isNaN(value - 0)
>
> But in Nashorn, it returns true if even if value is a string that 
> begins with a number. It seems that arithmetic with strings is working 
> non-standardly in Nashorn.


From sundararajan.athijegannathan at oracle.com  Wed Mar 25 06:21:06 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 25 Mar 2015 11:51:06 +0530
Subject: RFR 8012190: Global scope should be initialized lazily
Message-ID: <551253D2.3080504@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8012190/webrev.00/ for 
https://bugs.openjdk.java.net/browse/JDK-8012190

Except for mostly used/needed objects such as Object, Function, Number 
etc. other constructors, objects are lazily initialized via @Getter 
(Math, RegExp, Date, Java, JavaImporter, EvalError, URIError, typed 
array constructors).

~200 classes are not loaded at startup when jjs is started in 
interactive mode. Should help in startup - both interactive mode and in 
scenarios when many globals are created and thrown away after simple 
code evaluation.

Thanks,
-Sundar

From marcus.lagergren at oracle.com  Wed Mar 25 07:50:59 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 25 Mar 2015 08:50:59 +0100
Subject: RFR 8012190: Global scope should be initialized lazily
In-Reply-To: <551253D2.3080504@oracle.com>
References: <551253D2.3080504@oracle.com>
Message-ID: <07D4D6FD-98F0-4C37-8CE7-2234D242E172@oracle.com>

+1

> On 25 Mar 2015, at 07:21, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8012190/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8012190
> 
> Except for mostly used/needed objects such as Object, Function, Number etc. other constructors, objects are lazily initialized via @Getter (Math, RegExp, Date, Java, JavaImporter, EvalError, URIError, typed array constructors).
> 
> ~200 classes are not loaded at startup when jjs is started in interactive mode. Should help in startup - both interactive mode and in scenarios when many globals are created and thrown away after simple code evaluation.
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Wed Mar 25 08:20:43 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 25 Mar 2015 09:20:43 +0100
Subject: RFR 8012190: Global scope should be initialized lazily
In-Reply-To: <551253D2.3080504@oracle.com>
References: <551253D2.3080504@oracle.com>
Message-ID: <55126FDB.1080706@oracle.com>

+1, nice.

Maybe leave Math eagerly initialized as it is often used in hot numeric 
code?

Hannes

Am 2015-03-25 um 07:21 schrieb A. Sundararajan:
> Please review http://cr.openjdk.java.net/~sundar/8012190/webrev.00/ 
> for https://bugs.openjdk.java.net/browse/JDK-8012190
>
> Except for mostly used/needed objects such as Object, Function, Number 
> etc. other constructors, objects are lazily initialized via @Getter 
> (Math, RegExp, Date, Java, JavaImporter, EvalError, URIError, typed 
> array constructors).
>
> ~200 classes are not loaded at startup when jjs is started in 
> interactive mode. Should help in startup - both interactive mode and 
> in scenarios when many globals are created and thrown away after 
> simple code evaluation.
>
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Wed Mar 25 08:49:53 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 25 Mar 2015 09:49:53 +0100
Subject: !isNaN(value - 0)
In-Reply-To: <551205EA.304@threecrickets.com>
References: <551203FA.1070600@threecrickets.com>
	<551205EA.304@threecrickets.com>
Message-ID: <551276B1.9030408@oracle.com>

Hi Tal,

Thanks for letting us know. There seems to be a problem with 
toNumber(String). I'm investigating the issue.

Regards,
Hannes

Am 2015-03-25 um 01:48 schrieb Tal Liron:
> Hm, actually, something weirder is going on:
>
> isNaN('1.5x') -> true
> isNaN('1.5d') -> false
>
> What is it about "d"? Is it some kind of numerical literal? Again, 
> this is not standard behavior for JavaScript.
>
> On 03/24/2015 07:40 PM, Tal Liron wrote:
>> In most JavaScript engines, this would return true if value is fully 
>> numerical:
>>
>> !isNaN(value - 0)
>>
>> But in Nashorn, it returns true if even if value is a string that 
>> begins with a number. It seems that arithmetic with strings is 
>> working non-standardly in Nashorn.
>


From sundararajan.athijegannathan at oracle.com  Wed Mar 25 09:05:54 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 25 Mar 2015 14:35:54 +0530
Subject: RFR 8012190: Global scope should be initialized lazily
In-Reply-To: <55126FDB.1080706@oracle.com>
References: <551253D2.3080504@oracle.com> <55126FDB.1080706@oracle.com>
Message-ID: <55127A72.7070408@oracle.com>

Made Math as eagerly initialized property again. Uploaded updated webrev 
for reference here:
http://cr.openjdk.java.net/~sundar/8012190/webrev.01/

thanks for the review,
-Sundar

On Wednesday 25 March 2015 01:50 PM, Hannes Wallnoefer wrote:
> +1, nice.
>
> Maybe leave Math eagerly initialized as it is often used in hot 
> numeric code?
>
> Hannes
>
> Am 2015-03-25 um 07:21 schrieb A. Sundararajan:
>> Please review http://cr.openjdk.java.net/~sundar/8012190/webrev.00/ 
>> for https://bugs.openjdk.java.net/browse/JDK-8012190
>>
>> Except for mostly used/needed objects such as Object, Function, 
>> Number etc. other constructors, objects are lazily initialized via 
>> @Getter (Math, RegExp, Date, Java, JavaImporter, EvalError, URIError, 
>> typed array constructors).
>>
>> ~200 classes are not loaded at startup when jjs is started in 
>> interactive mode. Should help in startup - both interactive mode and 
>> in scenarios when many globals are created and thrown away after 
>> simple code evaluation.
>>
>> Thanks,
>> -Sundar
>


From hannes.wallnoefer at oracle.com  Wed Mar 25 10:41:01 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 25 Mar 2015 11:41:01 +0100
Subject: Review request for JDK-8073868: Regex matching causes
	java.lang.ArrayIndexOutOfBoundsException: 64
Message-ID: <551290BD.6090105@oracle.com>

Please review JDK-8073868: Regex matching causes 
java.lang.ArrayIndexOutOfBoundsException: 64:

http://cr.openjdk.java.net/~hannesw/8073868/

This is different from the fix in JRuby Joni since ECMAScript seems to 
require different semantics from Ruby.

The patch also removes methods for features that are not used in JavaScript.

Thanks,
Hannes

From attila.szegedi at oracle.com  Wed Mar 25 11:28:27 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 25 Mar 2015 12:28:27 +0100
Subject: Review request for JDK-8073868: Regex matching causes
	java.lang.ArrayIndexOutOfBoundsException: 64
In-Reply-To: <551290BD.6090105@oracle.com>
References: <551290BD.6090105@oracle.com>
Message-ID: <BE5121A2-AAFA-49D5-B91F-6CDCCBDD7927@oracle.com>

+1

On Mar 25, 2015, at 11:41 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8073868: Regex matching causes java.lang.ArrayIndexOutOfBoundsException: 64:
> 
> http://cr.openjdk.java.net/~hannesw/8073868/
> 
> This is different from the fix in JRuby Joni since ECMAScript seems to require different semantics from Ruby.
> 
> The patch also removes methods for features that are not used in JavaScript.
> 
> Thanks,
> Hannes


From hannes.wallnoefer at oracle.com  Wed Mar 25 12:50:12 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 25 Mar 2015 13:50:12 +0100
Subject: Review request for JDK-8075927: toNumber(String) accepts illegal
	characters
Message-ID: <5512AF04.6090703@oracle.com>

Please review JDK-8075927: toNumber(String) accepts illegal characters:

http://cr.openjdk.java.net/~hannesw/8075927/

Thanks,
Hannes

From attila.szegedi at oracle.com  Wed Mar 25 13:03:03 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 25 Mar 2015 14:03:03 +0100
Subject: Review request for JDK-8075927: toNumber(String) accepts illegal
	characters
In-Reply-To: <5512AF04.6090703@oracle.com>
References: <5512AF04.6090703@oracle.com>
Message-ID: <DFB21673-CF17-4865-8704-3C6E2B0820C4@oracle.com>

+1

On Mar 25, 2015, at 1:50 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8075927: toNumber(String) accepts illegal characters:
> 
> http://cr.openjdk.java.net/~hannesw/8075927/
> 
> Thanks,
> Hannes


From sundararajan.athijegannathan at oracle.com  Wed Mar 25 13:22:23 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Wed, 25 Mar 2015 18:52:23 +0530
Subject: Review request for JDK-8075927: toNumber(String) accepts illegal
	characters
In-Reply-To: <5512AF04.6090703@oracle.com>
References: <5512AF04.6090703@oracle.com>
Message-ID: <5512B68F.4030103@oracle.com>

+1

On Wednesday 25 March 2015 06:20 PM, Hannes Wallnoefer wrote:
> Please review JDK-8075927: toNumber(String) accepts illegal characters:
>
> http://cr.openjdk.java.net/~hannesw/8075927/
>
> Thanks,
> Hannes


From marcus.lagergren at oracle.com  Wed Mar 25 16:49:53 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 25 Mar 2015 17:49:53 +0100
Subject: RFR 8012190: Global scope should be initialized lazily
In-Reply-To: <55127A72.7070408@oracle.com>
References: <551253D2.3080504@oracle.com> <55126FDB.1080706@oracle.com>
	<55127A72.7070408@oracle.com>
Message-ID: <B90E03D6-71B4-4DFF-98C6-5EF00B3DEC5A@oracle.com>

+1

> On 25 Mar 2015, at 10:05, A. Sundararajan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Made Math as eagerly initialized property again. Uploaded updated webrev for reference here:
> http://cr.openjdk.java.net/~sundar/8012190/webrev.01/
> 
> thanks for the review,
> -Sundar
> 
> On Wednesday 25 March 2015 01:50 PM, Hannes Wallnoefer wrote:
>> +1, nice.
>> 
>> Maybe leave Math eagerly initialized as it is often used in hot numeric code?
>> 
>> Hannes
>> 
>> Am 2015-03-25 um 07:21 schrieb A. Sundararajan:
>>> Please review http://cr.openjdk.java.net/~sundar/8012190/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8012190
>>> 
>>> Except for mostly used/needed objects such as Object, Function, Number etc. other constructors, objects are lazily initialized via @Getter (Math, RegExp, Date, Java, JavaImporter, EvalError, URIError, typed array constructors).
>>> 
>>> ~200 classes are not loaded at startup when jjs is started in interactive mode. Should help in startup - both interactive mode and in scenarios when many globals are created and thrown away after simple code evaluation.
>>> 
>>> Thanks,
>>> -Sundar
>> 
> 


From marcus.lagergren at oracle.com  Wed Mar 25 16:50:00 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Wed, 25 Mar 2015 17:50:00 +0100
Subject: Review request for JDK-8073868: Regex matching causes
	java.lang.ArrayIndexOutOfBoundsException: 64
In-Reply-To: <551290BD.6090105@oracle.com>
References: <551290BD.6090105@oracle.com>
Message-ID: <B70B9988-2BF5-4DDE-B5AF-CD9C1C25C881@oracle.com>

+1

> On 25 Mar 2015, at 11:41, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review JDK-8073868: Regex matching causes java.lang.ArrayIndexOutOfBoundsException: 64:
> 
> http://cr.openjdk.java.net/~hannesw/8073868/
> 
> This is different from the fix in JRuby Joni since ECMAScript seems to require different semantics from Ruby.
> 
> The patch also removes methods for features that are not used in JavaScript.
> 
> Thanks,
> Hannes


From hannes.wallnoefer at oracle.com  Thu Mar 26 12:08:20 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 26 Mar 2015 13:08:20 +0100
Subject: Review requests for JDK-8075366: Slow scope access to global let/const
	does not work
Message-ID: <5513F6B4.2020802@oracle.com>

Please review JDK-8075366: Slow scope access to global let/const does 
not work:

http://cr.openjdk.java.net/~hannesw/8075366/

Thanks,
Hannes

From hannes.wallnoefer at oracle.com  Thu Mar 26 12:08:57 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 26 Mar 2015 13:08:57 +0100
Subject: Review request for JDK-8075231: Typed array setters are very slow
	when index exceeds capacity
Message-ID: <5513F6D9.8010808@oracle.com>

Please review JDK-8075231: Typed array setters are very slow when index 
exceeds capacity:

http://cr.openjdk.java.net/~hannesw/8075231/

Thanks,
Hannes

From hannes.wallnoefer at oracle.com  Thu Mar 26 14:21:28 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 26 Mar 2015 15:21:28 +0100
Subject: Review requests for JDK-8075366: Slow scope access to global
	let/const does not work
In-Reply-To: <5513F6B4.2020802@oracle.com>
References: <5513F6B4.2020802@oracle.com>
Message-ID: <551415E8.70709@oracle.com>

Sorry, I forgot to upload the actual webrev. It's up there now.

Hannes

Am 2015-03-26 um 13:08 schrieb Hannes Wallnoefer:
> Please review JDK-8075366: Slow scope access to global let/const does 
> not work:
>
> http://cr.openjdk.java.net/~hannesw/8075366/
>
> Thanks,
> Hannes


From sundararajan.athijegannathan at oracle.com  Thu Mar 26 15:41:06 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Thu, 26 Mar 2015 21:11:06 +0530
Subject: Review requests for JDK-8075366: Slow scope access to global
	let/const does not work
In-Reply-To: <5514279F.6050202@oracle.com>
References: <5513F6B4.2020802@oracle.com> <5514279F.6050202@oracle.com>
Message-ID: <55142892.2080303@oracle.com>

+1

On Thursday 26 March 2015 09:07 PM, Hannes Wallnoefer wrote:
> Please review JDK-8075366: Slow scope access to global let/const does 
> not work:
>
> http://cr.openjdk.java.net/~hannesw/8075366/
>
> Thanks,
> Hannes
>
>


From attila.szegedi at oracle.com  Thu Mar 26 16:07:31 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 26 Mar 2015 17:07:31 +0100
Subject: Review request for JDK-8075231: Typed array setters are very slow
	when index exceeds capacity
In-Reply-To: <5513F6D9.8010808@oracle.com>
References: <5513F6D9.8010808@oracle.com>
Message-ID: <D8D89A12-2FA5-43DC-A2A6-4D135C730BAE@oracle.com>

+1

On Mar 26, 2015, at 1:08 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8075231: Typed array setters are very slow when index exceeds capacity:
> 
> http://cr.openjdk.java.net/~hannesw/8075231/
> 
> Thanks,
> Hannes


From attila.szegedi at oracle.com  Thu Mar 26 16:10:20 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 26 Mar 2015 17:10:20 +0100
Subject: Review requests for JDK-8075366: Slow scope access to global
	let/const does not work
In-Reply-To: <5513F6B4.2020802@oracle.com>
References: <5513F6B4.2020802@oracle.com>
Message-ID: <24635CEF-A705-4B11-9245-E32CE8C6CD2E@oracle.com>

+1

On Mar 26, 2015, at 1:08 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:

> Please review JDK-8075366: Slow scope access to global let/const does not work:
> 
> http://cr.openjdk.java.net/~hannesw/8075366/
> 
> Thanks,
> Hannes


From marcus.lagergren at oracle.com  Thu Mar 26 17:45:17 2015
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Thu, 26 Mar 2015 18:45:17 +0100
Subject: Review request for JDK-8075231: Typed array setters are very slow
	when index exceeds capacity
In-Reply-To: <5513F6D9.8010808@oracle.com>
References: <5513F6D9.8010808@oracle.com>
Message-ID: <1542BA77-48D7-48EE-AB02-140C35C5CC5F@oracle.com>

+1 if no octane regressions

> On 26 Mar 2015, at 13:08, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review JDK-8075231: Typed array setters are very slow when index exceeds capacity:
> 
> http://cr.openjdk.java.net/~hannesw/8075231/
> 
> Thanks,
> Hannes


From david at code.davidpcaldwell.com  Fri Mar 27 11:11:43 2015
From: david at code.davidpcaldwell.com (David P. Caldwell)
Date: Fri, 27 Mar 2015 07:11:43 -0400
Subject: Problem with interoperability with JavaFX WebEngine
Message-ID: <CABBxOKkEzX15p0q+SQZgeGFop1FD0VpHqE3+S-hH_g4fg0SvDA@mail.gmail.com>

So it's very cool, and unexpected, that JavaScript objects obtained
from a JavaFX WebEngine show up as something like ordinary Nashorn
objects in Nashorn scripts. That's an unexpected bonus (I was planning
on using .setMember() and all that stuff from
netscape.javascript.JSObject).

The objects behave a bit strangely, though. So I've got a couple of
bug reports, I guess.

Here's a script that demonstrates the ones I've found so far:

var WebEngine = Java.type("javafx.scene.web.WebEngine");
var engine = new WebEngine();

var window = engine.executeScript("window");

print("foo = " + window.foo);
print("typeof(window.foo) = " + typeof(window.foo));
if (window.foo) {
    print("window.foo is truthy");
}

Output:
$ /usr/lib/jvm/jdk1.8.0_40/bin/jjs -fx nashorn.js
foo = undefined
typeof(window.foo) = string
window.foo is truthy

I actually am using a much more complicated embedding that is done
from Java, so I can tell you the problem is not in the implementation
of the -fx flag.

Other than that, I can't see much; I haven't delved into the Nashorn
code, let alone whatever magic enables this.

-- David.

From james.laskey at oracle.com  Fri Mar 27 12:16:43 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 27 Mar 2015 09:16:43 -0300
Subject: Problem with interoperability with JavaFX WebEngine
In-Reply-To: <CABBxOKkEzX15p0q+SQZgeGFop1FD0VpHqE3+S-hH_g4fg0SvDA@mail.gmail.com>
References: <CABBxOKkEzX15p0q+SQZgeGFop1FD0VpHqE3+S-hH_g4fg0SvDA@mail.gmail.com>
Message-ID: <18F41A0D-6A23-4344-A673-4F452652D8B9@oracle.com>

David,

At issue is the fact that WebEngine JS objects come from WebJS (not Nashorn) and are really Java objects from Nashorn's perspective (including undefined.)  In order for them to be treated like Nashorn JavaScript objects you need to wrap these objects in something like a JSAdaptor.  See https://blogs.oracle.com/nashorn/entry/porting_from_the_browser_to for starting points.

Cheers,

-- Jim




> On Mar 27, 2015, at 8:11 AM, David P. Caldwell <david at code.davidpcaldwell.com> wrote:
> 
> So it's very cool, and unexpected, that JavaScript objects obtained
> from a JavaFX WebEngine show up as something like ordinary Nashorn
> objects in Nashorn scripts. That's an unexpected bonus (I was planning
> on using .setMember() and all that stuff from
> netscape.javascript.JSObject).
> 
> The objects behave a bit strangely, though. So I've got a couple of
> bug reports, I guess.
> 
> Here's a script that demonstrates the ones I've found so far:
> 
> var WebEngine = Java.type("javafx.scene.web.WebEngine");
> var engine = new WebEngine();
> 
> var window = engine.executeScript("window");
> 
> print("foo = " + window.foo);
> print("typeof(window.foo) = " + typeof(window.foo));
> if (window.foo) {
>    print("window.foo is truthy");
> }
> 
> Output:
> $ /usr/lib/jvm/jdk1.8.0_40/bin/jjs -fx nashorn.js
> foo = undefined
> typeof(window.foo) = string
> window.foo is truthy
> 
> I actually am using a much more complicated embedding that is done
> from Java, so I can tell you the problem is not in the implementation
> of the -fx flag.
> 
> Other than that, I can't see much; I haven't delved into the Nashorn
> code, let alone whatever magic enables this.
> 
> -- David.


From sundararajan.athijegannathan at oracle.com  Fri Mar 27 12:52:25 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 27 Mar 2015 18:22:25 +0530
Subject: Problem with interoperability with JavaFX WebEngine
In-Reply-To: <CABBxOKkEzX15p0q+SQZgeGFop1FD0VpHqE3+S-hH_g4fg0SvDA@mail.gmail.com>
References: <CABBxOKkEzX15p0q+SQZgeGFop1FD0VpHqE3+S-hH_g4fg0SvDA@mail.gmail.com>
Message-ID: <55155289.2000905@oracle.com>

Browser's DOM objects (like WebEngine's) implement 
netscape.javascript.JSObject interface. Such objects are treated 
specially by nashorn's linker.

http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ca150ddd536e/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java

is the dynalink linker that handles such objects. JSObject.getMember, 
putMember, call are used to provide property, call access seamlessly.

Please check out this example:

http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ca150ddd536e/samples/browser_dom.js

So, what you're seeing is a bug in the way that linker works.  Let me 
check out and file a bug.

Thanks,
-Sundar


On Friday 27 March 2015 04:41 PM, David P. Caldwell wrote:
> So it's very cool, and unexpected, that JavaScript objects obtained
> from a JavaFX WebEngine show up as something like ordinary Nashorn
> objects in Nashorn scripts. That's an unexpected bonus (I was planning
> on using .setMember() and all that stuff from
> netscape.javascript.JSObject).
>
> The objects behave a bit strangely, though. So I've got a couple of
> bug reports, I guess.
>
> Here's a script that demonstrates the ones I've found so far:
>
> var WebEngine = Java.type("javafx.scene.web.WebEngine");
> var engine = new WebEngine();
>
> var window = engine.executeScript("window");
>
> print("foo = " + window.foo);
> print("typeof(window.foo) = " + typeof(window.foo));
> if (window.foo) {
>      print("window.foo is truthy");
> }
>
> Output:
> $ /usr/lib/jvm/jdk1.8.0_40/bin/jjs -fx nashorn.js
> foo = undefined
> typeof(window.foo) = string
> window.foo is truthy
>
> I actually am using a much more complicated embedding that is done
> from Java, so I can tell you the problem is not in the implementation
> of the -fx flag.
>
> Other than that, I can't see much; I haven't delved into the Nashorn
> code, let alone whatever magic enables this.
>
> -- David.


From sundararajan.athijegannathan at oracle.com  Fri Mar 27 13:48:49 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 27 Mar 2015 19:18:49 +0530
Subject: Problem with interoperability with JavaFX WebEngine
In-Reply-To: <55155289.2000905@oracle.com>
References: <CABBxOKkEzX15p0q+SQZgeGFop1FD0VpHqE3+S-hH_g4fg0SvDA@mail.gmail.com>
	<55155289.2000905@oracle.com>
Message-ID: <55155FC1.7000104@oracle.com>

I think I found the issue with this modified script.

var WebEngine = Java.type("javafx.scene.web.WebEngine");
var engine = new WebEngine();

var window = engine.executeScript("window");

print(Debug.getClass(window.foo));
print("typeof(window.foo) = " + typeof(window.foo));
if (window.foo) {
     print("window.foo is truthy");
}

We need to run with -J-Dnashorn.debug to enable nashorn debug mode. 
Debug.getClass gets the Java class of the value. Apparently, browser's 
JSObject impl. returns a string with the value "undefined" for undefined 
values! And not a special value or null for undefined...

I think nashorn's BrowserJSObjectLinker has to probably call 
JSObject.hasMember to check existence of a member before calling 
JSObject.getMember. That appears to be the only way to find out if 
"undefined" string is due to missing property or not.

-Sundar

On Friday 27 March 2015 06:22 PM, A. Sundararajan wrote:
> Browser's DOM objects (like WebEngine's) implement 
> netscape.javascript.JSObject interface. Such objects are treated 
> specially by nashorn's linker.
>
> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ca150ddd536e/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java 
>
>
> is the dynalink linker that handles such objects. JSObject.getMember, 
> putMember, call are used to provide property, call access seamlessly.
>
> Please check out this example:
>
> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ca150ddd536e/samples/browser_dom.js 
>
>
> So, what you're seeing is a bug in the way that linker works.  Let me 
> check out and file a bug.
>
> Thanks,
> -Sundar
>
>
> On Friday 27 March 2015 04:41 PM, David P. Caldwell wrote:
>> So it's very cool, and unexpected, that JavaScript objects obtained
>> from a JavaFX WebEngine show up as something like ordinary Nashorn
>> objects in Nashorn scripts. That's an unexpected bonus (I was planning
>> on using .setMember() and all that stuff from
>> netscape.javascript.JSObject).
>>
>> The objects behave a bit strangely, though. So I've got a couple of
>> bug reports, I guess.
>>
>> Here's a script that demonstrates the ones I've found so far:
>>
>> var WebEngine = Java.type("javafx.scene.web.WebEngine");
>> var engine = new WebEngine();
>>
>> var window = engine.executeScript("window");
>>
>> print("foo = " + window.foo);
>> print("typeof(window.foo) = " + typeof(window.foo));
>> if (window.foo) {
>>      print("window.foo is truthy");
>> }
>>
>> Output:
>> $ /usr/lib/jvm/jdk1.8.0_40/bin/jjs -fx nashorn.js
>> foo = undefined
>> typeof(window.foo) = string
>> window.foo is truthy
>>
>> I actually am using a much more complicated embedding that is done
>> from Java, so I can tell you the problem is not in the implementation
>> of the -fx flag.
>>
>> Other than that, I can't see much; I haven't delved into the Nashorn
>> code, let alone whatever magic enables this.
>>
>> -- David.
>


From sundararajan.athijegannathan at oracle.com  Fri Mar 27 14:02:14 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Fri, 27 Mar 2015 19:32:14 +0530
Subject: Problem with interoperability with JavaFX WebEngine
In-Reply-To: <55155FC1.7000104@oracle.com>
References: <CABBxOKkEzX15p0q+SQZgeGFop1FD0VpHqE3+S-hH_g4fg0SvDA@mail.gmail.com>	<55155289.2000905@oracle.com>
	<55155FC1.7000104@oracle.com>
Message-ID: <551562E6.3040009@oracle.com>

Oops. Actually, there is no JSObject.hasMember/hasSlot to check if a 
named property or an indexed property exists in a browser JSObject! 
Unlike Nashorn's own JSObject interface 
(jdk.nashorn.api.scripting.JSObject) which has hasMember, hasSlot!

So, workaround is to modify the script as follows:

var WebEngine = Java.type("javafx.scene.web.WebEngine");
var engine = new WebEngine();

var window = engine.executeScript("window");

// check if property foo exists by "eval" on browser's JS engine!
var type = window.eval("typeof this.foo");

if (type == 'undefined') {
     print("no 'foo' on Window");
} else {
     print("there is 'foo' of type " + type);
}

Hope this helps,
-Sundar

On Friday 27 March 2015 07:18 PM, A. Sundararajan wrote:
> I think I found the issue with this modified script.
>
> var WebEngine = Java.type("javafx.scene.web.WebEngine");
> var engine = new WebEngine();
>
> var window = engine.executeScript("window");
>
> print(Debug.getClass(window.foo));
> print("typeof(window.foo) = " + typeof(window.foo));
> if (window.foo) {
>     print("window.foo is truthy");
> }
>
> We need to run with -J-Dnashorn.debug to enable nashorn debug mode. 
> Debug.getClass gets the Java class of the value. Apparently, browser's 
> JSObject impl. returns a string with the value "undefined" for 
> undefined values! And not a special value or null for undefined...
>
> I think nashorn's BrowserJSObjectLinker has to probably call 
> JSObject.hasMember to check existence of a member before calling 
> JSObject.getMember. That appears to be the only way to find out if 
> "undefined" string is due to missing property or not.
>
> -Sundar
>
> On Friday 27 March 2015 06:22 PM, A. Sundararajan wrote:
>> Browser's DOM objects (like WebEngine's) implement 
>> netscape.javascript.JSObject interface. Such objects are treated 
>> specially by nashorn's linker.
>>
>> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ca150ddd536e/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java 
>>
>>
>> is the dynalink linker that handles such objects. JSObject.getMember, 
>> putMember, call are used to provide property, call access seamlessly.
>>
>> Please check out this example:
>>
>> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ca150ddd536e/samples/browser_dom.js 
>>
>>
>> So, what you're seeing is a bug in the way that linker works. Let me 
>> check out and file a bug.
>>
>> Thanks,
>> -Sundar
>>
>>
>> On Friday 27 March 2015 04:41 PM, David P. Caldwell wrote:
>>> So it's very cool, and unexpected, that JavaScript objects obtained
>>> from a JavaFX WebEngine show up as something like ordinary Nashorn
>>> objects in Nashorn scripts. That's an unexpected bonus (I was planning
>>> on using .setMember() and all that stuff from
>>> netscape.javascript.JSObject).
>>>
>>> The objects behave a bit strangely, though. So I've got a couple of
>>> bug reports, I guess.
>>>
>>> Here's a script that demonstrates the ones I've found so far:
>>>
>>> var WebEngine = Java.type("javafx.scene.web.WebEngine");
>>> var engine = new WebEngine();
>>>
>>> var window = engine.executeScript("window");
>>>
>>> print("foo = " + window.foo);
>>> print("typeof(window.foo) = " + typeof(window.foo));
>>> if (window.foo) {
>>>      print("window.foo is truthy");
>>> }
>>>
>>> Output:
>>> $ /usr/lib/jvm/jdk1.8.0_40/bin/jjs -fx nashorn.js
>>> foo = undefined
>>> typeof(window.foo) = string
>>> window.foo is truthy
>>>
>>> I actually am using a much more complicated embedding that is done
>>> from Java, so I can tell you the problem is not in the implementation
>>> of the -fx flag.
>>>
>>> Other than that, I can't see much; I haven't delved into the Nashorn
>>> code, let alone whatever magic enables this.
>>>
>>> -- David.
>>
>


From david at code.davidpcaldwell.com  Fri Mar 27 16:51:17 2015
From: david at code.davidpcaldwell.com (David P. Caldwell)
Date: Fri, 27 Mar 2015 12:51:17 -0400
Subject: Problem with interoperability with JavaFX WebEngine
In-Reply-To: <551562E6.3040009@oracle.com>
References: <CABBxOKkEzX15p0q+SQZgeGFop1FD0VpHqE3+S-hH_g4fg0SvDA@mail.gmail.com>
	<55155289.2000905@oracle.com> <55155FC1.7000104@oracle.com>
	<551562E6.3040009@oracle.com>
Message-ID: <CABBxOKnDk12Z2znm7yE+ToMEE7egzvBwJ0rZ78C0XF3FJ1ywLA@mail.gmail.com>

Thanks for the pointer to the linker code, which I skimmed, and to
some ideas for a workaround. I'll do some exploring. My guess is that
with some kind of meta-object programming (if I used a Nashorn class)
I could wrap the browser object inside something that encapsulated the
logic that Sundar mentioned. Perhaps it's the Nashorn JSObject to
which you allude, or perhaps some other object, but presumably I can
wrap the Nashorn-linked quasi-object inside a JSObject that fixes the
mistakes in the browser JSObject Java implementation. This is coming
from a low-level API of mine so I can wrap it inside something ugly if
needed to make it work in a more-expected way outside it.

But alternatively, could the jdk.nashorn.internal.runtime.linker class
be modified to work around this issue? I ask without attempting to do
any understanding of the code, but it appears at a glance that the
linker class is already doing a bunch of this stuff. Since it's
already JSObject-specific, it seems like it would make sense to insert
the code in there if JSObject has known bugs. And interoperability of
the two JavaScript implementations is a big win if it works well
(which I presume motivated the development of this special-case linker
to begin with).

On Fri, Mar 27, 2015 at 10:02 AM, A. Sundararajan
<sundararajan.athijegannathan at oracle.com> wrote:
> Oops. Actually, there is no JSObject.hasMember/hasSlot to check if a named
> property or an indexed property exists in a browser JSObject! Unlike
> Nashorn's own JSObject interface (jdk.nashorn.api.scripting.JSObject) which
> has hasMember, hasSlot!
>
> So, workaround is to modify the script as follows:
>
> var WebEngine = Java.type("javafx.scene.web.WebEngine");
> var engine = new WebEngine();
>
> var window = engine.executeScript("window");
>
> // check if property foo exists by "eval" on browser's JS engine!
> var type = window.eval("typeof this.foo");
>
> if (type == 'undefined') {
>     print("no 'foo' on Window");
> } else {
>     print("there is 'foo' of type " + type);
> }
>
> Hope this helps,
> -Sundar
>
>
> On Friday 27 March 2015 07:18 PM, A. Sundararajan wrote:
>>
>> I think I found the issue with this modified script.
>>
>> var WebEngine = Java.type("javafx.scene.web.WebEngine");
>> var engine = new WebEngine();
>>
>> var window = engine.executeScript("window");
>>
>> print(Debug.getClass(window.foo));
>> print("typeof(window.foo) = " + typeof(window.foo));
>> if (window.foo) {
>>     print("window.foo is truthy");
>> }
>>
>> We need to run with -J-Dnashorn.debug to enable nashorn debug mode.
>> Debug.getClass gets the Java class of the value. Apparently, browser's
>> JSObject impl. returns a string with the value "undefined" for undefined
>> values! And not a special value or null for undefined...
>>
>> I think nashorn's BrowserJSObjectLinker has to probably call
>> JSObject.hasMember to check existence of a member before calling
>> JSObject.getMember. That appears to be the only way to find out if
>> "undefined" string is due to missing property or not.
>>
>> -Sundar
>>
>> On Friday 27 March 2015 06:22 PM, A. Sundararajan wrote:
>>>
>>> Browser's DOM objects (like WebEngine's) implement
>>> netscape.javascript.JSObject interface. Such objects are treated specially
>>> by nashorn's linker.
>>>
>>>
>>> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ca150ddd536e/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java
>>>
>>> is the dynalink linker that handles such objects. JSObject.getMember,
>>> putMember, call are used to provide property, call access seamlessly.
>>>
>>> Please check out this example:
>>>
>>>
>>> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ca150ddd536e/samples/browser_dom.js
>>>
>>> So, what you're seeing is a bug in the way that linker works. Let me
>>> check out and file a bug.
>>>
>>> Thanks,
>>> -Sundar
>>>
>>>
>>> On Friday 27 March 2015 04:41 PM, David P. Caldwell wrote:
>>>>
>>>> So it's very cool, and unexpected, that JavaScript objects obtained
>>>> from a JavaFX WebEngine show up as something like ordinary Nashorn
>>>> objects in Nashorn scripts. That's an unexpected bonus (I was planning
>>>> on using .setMember() and all that stuff from
>>>> netscape.javascript.JSObject).
>>>>
>>>> The objects behave a bit strangely, though. So I've got a couple of
>>>> bug reports, I guess.
>>>>
>>>> Here's a script that demonstrates the ones I've found so far:
>>>>
>>>> var WebEngine = Java.type("javafx.scene.web.WebEngine");
>>>> var engine = new WebEngine();
>>>>
>>>> var window = engine.executeScript("window");
>>>>
>>>> print("foo = " + window.foo);
>>>> print("typeof(window.foo) = " + typeof(window.foo));
>>>> if (window.foo) {
>>>>      print("window.foo is truthy");
>>>> }
>>>>
>>>> Output:
>>>> $ /usr/lib/jvm/jdk1.8.0_40/bin/jjs -fx nashorn.js
>>>> foo = undefined
>>>> typeof(window.foo) = string
>>>> window.foo is truthy
>>>>
>>>> I actually am using a much more complicated embedding that is done
>>>> from Java, so I can tell you the problem is not in the implementation
>>>> of the -fx flag.
>>>>
>>>> Other than that, I can't see much; I haven't delved into the Nashorn
>>>> code, let alone whatever magic enables this.
>>>>
>>>> -- David.
>>>
>>>
>>
>

From viktor.gamov at gmail.com  Sun Mar 29 03:59:57 2015
From: viktor.gamov at gmail.com (Viktor Gamov)
Date: Sat, 28 Mar 2015 23:59:57 -0400
Subject: Workaround for java.io.NotSerializableException:
	jdk.nashorn.internal.objects.Global
Message-ID: <CAD0N6pwzUU9-hsOAawEeBYZpJrHE05kEnE5nDvGfx8SFrPjACg@mail.gmail.com>

Hello Nashorn-team,

In my sample project I'm integrating different Hazelcast API with Nashorn.
It's on GH https://github.com/gAmUssA/hazelcast-nashorn
One thing that I'm trying to do is EntryProcessor (
http://docs.hazelcast.org/docs/latest/manual/html/entryprocessor.html).
EntryProcessor is executing on Hazelcast cluster member node. For that
purpose, Hazelcast client serializes it and sends it member node.

?I'm getting exception

Caused by: java.io.NotSerializableException:
jdk.nashorn.internal.objects.Global?
(hazelcastClient.js, line 40, commented)

?Thanks to Sundar? (
https://twitter.com/sundararajan_a/status/581651315920515072), I learn that
Global object is not serializable to security reasons.

?Please, let me know if there is a workaround of? this problem?

?Thank you?

-- 
With Best Regards,
Vik Gamov

From sundararajan.athijegannathan at oracle.com  Mon Mar 30 02:49:40 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 30 Mar 2015 08:19:40 +0530
Subject: Problem with interoperability with JavaFX WebEngine
In-Reply-To: <CABBxOKnDk12Z2znm7yE+ToMEE7egzvBwJ0rZ78C0XF3FJ1ywLA@mail.gmail.com>
References: <CABBxOKkEzX15p0q+SQZgeGFop1FD0VpHqE3+S-hH_g4fg0SvDA@mail.gmail.com>
	<55155289.2000905@oracle.com> <55155FC1.7000104@oracle.com>
	<551562E6.3040009@oracle.com>
	<CABBxOKnDk12Z2znm7yE+ToMEE7egzvBwJ0rZ78C0XF3FJ1ywLA@mail.gmail.com>
Message-ID: <5518B9C4.3090504@oracle.com>

Hi,

Without doing another "eval" call on browser's JS engine, I can''t think 
of a way to know if a property is missing in the browser's object or 
not. Making an "eval" call before every property "get", appears 
overkill! I think client code mostly would access "properties know to 
exist" - in which case the current scheme is fine. For border cases, 
client code has to do the check (by 'eval') before doing property get.

Thanks,
-Sundar

On Friday 27 March 2015 10:21 PM, David P. Caldwell wrote:
> Thanks for the pointer to the linker code, which I skimmed, and to
> some ideas for a workaround. I'll do some exploring. My guess is that
> with some kind of meta-object programming (if I used a Nashorn class)
> I could wrap the browser object inside something that encapsulated the
> logic that Sundar mentioned. Perhaps it's the Nashorn JSObject to
> which you allude, or perhaps some other object, but presumably I can
> wrap the Nashorn-linked quasi-object inside a JSObject that fixes the
> mistakes in the browser JSObject Java implementation. This is coming
> from a low-level API of mine so I can wrap it inside something ugly if
> needed to make it work in a more-expected way outside it.
>
> But alternatively, could the jdk.nashorn.internal.runtime.linker class
> be modified to work around this issue? I ask without attempting to do
> any understanding of the code, but it appears at a glance that the
> linker class is already doing a bunch of this stuff. Since it's
> already JSObject-specific, it seems like it would make sense to insert
> the code in there if JSObject has known bugs. And interoperability of
> the two JavaScript implementations is a big win if it works well
> (which I presume motivated the development of this special-case linker
> to begin with).
>
> On Fri, Mar 27, 2015 at 10:02 AM, A. Sundararajan
> <sundararajan.athijegannathan at oracle.com> wrote:
>> Oops. Actually, there is no JSObject.hasMember/hasSlot to check if a named
>> property or an indexed property exists in a browser JSObject! Unlike
>> Nashorn's own JSObject interface (jdk.nashorn.api.scripting.JSObject) which
>> has hasMember, hasSlot!
>>
>> So, workaround is to modify the script as follows:
>>
>> var WebEngine = Java.type("javafx.scene.web.WebEngine");
>> var engine = new WebEngine();
>>
>> var window = engine.executeScript("window");
>>
>> // check if property foo exists by "eval" on browser's JS engine!
>> var type = window.eval("typeof this.foo");
>>
>> if (type == 'undefined') {
>>      print("no 'foo' on Window");
>> } else {
>>      print("there is 'foo' of type " + type);
>> }
>>
>> Hope this helps,
>> -Sundar
>>
>>
>> On Friday 27 March 2015 07:18 PM, A. Sundararajan wrote:
>>> I think I found the issue with this modified script.
>>>
>>> var WebEngine = Java.type("javafx.scene.web.WebEngine");
>>> var engine = new WebEngine();
>>>
>>> var window = engine.executeScript("window");
>>>
>>> print(Debug.getClass(window.foo));
>>> print("typeof(window.foo) = " + typeof(window.foo));
>>> if (window.foo) {
>>>      print("window.foo is truthy");
>>> }
>>>
>>> We need to run with -J-Dnashorn.debug to enable nashorn debug mode.
>>> Debug.getClass gets the Java class of the value. Apparently, browser's
>>> JSObject impl. returns a string with the value "undefined" for undefined
>>> values! And not a special value or null for undefined...
>>>
>>> I think nashorn's BrowserJSObjectLinker has to probably call
>>> JSObject.hasMember to check existence of a member before calling
>>> JSObject.getMember. That appears to be the only way to find out if
>>> "undefined" string is due to missing property or not.
>>>
>>> -Sundar
>>>
>>> On Friday 27 March 2015 06:22 PM, A. Sundararajan wrote:
>>>> Browser's DOM objects (like WebEngine's) implement
>>>> netscape.javascript.JSObject interface. Such objects are treated specially
>>>> by nashorn's linker.
>>>>
>>>>
>>>> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ca150ddd536e/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/BrowserJSObjectLinker.java
>>>>
>>>> is the dynalink linker that handles such objects. JSObject.getMember,
>>>> putMember, call are used to provide property, call access seamlessly.
>>>>
>>>> Please check out this example:
>>>>
>>>>
>>>> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/ca150ddd536e/samples/browser_dom.js
>>>>
>>>> So, what you're seeing is a bug in the way that linker works. Let me
>>>> check out and file a bug.
>>>>
>>>> Thanks,
>>>> -Sundar
>>>>
>>>>
>>>> On Friday 27 March 2015 04:41 PM, David P. Caldwell wrote:
>>>>> So it's very cool, and unexpected, that JavaScript objects obtained
>>>>> from a JavaFX WebEngine show up as something like ordinary Nashorn
>>>>> objects in Nashorn scripts. That's an unexpected bonus (I was planning
>>>>> on using .setMember() and all that stuff from
>>>>> netscape.javascript.JSObject).
>>>>>
>>>>> The objects behave a bit strangely, though. So I've got a couple of
>>>>> bug reports, I guess.
>>>>>
>>>>> Here's a script that demonstrates the ones I've found so far:
>>>>>
>>>>> var WebEngine = Java.type("javafx.scene.web.WebEngine");
>>>>> var engine = new WebEngine();
>>>>>
>>>>> var window = engine.executeScript("window");
>>>>>
>>>>> print("foo = " + window.foo);
>>>>> print("typeof(window.foo) = " + typeof(window.foo));
>>>>> if (window.foo) {
>>>>>       print("window.foo is truthy");
>>>>> }
>>>>>
>>>>> Output:
>>>>> $ /usr/lib/jvm/jdk1.8.0_40/bin/jjs -fx nashorn.js
>>>>> foo = undefined
>>>>> typeof(window.foo) = string
>>>>> window.foo is truthy
>>>>>
>>>>> I actually am using a much more complicated embedding that is done
>>>>> from Java, so I can tell you the problem is not in the implementation
>>>>> of the -fx flag.
>>>>>
>>>>> Other than that, I can't see much; I haven't delved into the Nashorn
>>>>> code, let alone whatever magic enables this.
>>>>>
>>>>> -- David.
>>>>


From gamussa at gmail.com  Sat Mar 28 14:16:12 2015
From: gamussa at gmail.com (Viktor Gamov)
Date: Sat, 28 Mar 2015 10:16:12 -0400
Subject: Workaround for java.io.NotSerializableException:
	jdk.nashorn.internal.objects.Global
Message-ID: <CAD0N6pyFJ3FbZQYyv5aCzUgcHGJasTXeeQt75_Qh1XatnrZdrg@mail.gmail.com>

Hello Nashorn-team,

In my sample project I'm integrating different Hazelcast API with Nashorn.
It's on GH https://github.com/gAmUssA/hazelcast-nashorn
One thing that I'm trying to do is EntryProcessor (
http://docs.hazelcast.org/docs/latest/manual/html/entryprocessor.html).
EntryProcessor is executing on Hazelcast cluster member node. For that
purpose, Hazelcast client serializes it and sends it member node.

?I'm getting exception

Caused by: java.io.NotSerializableException:
jdk.nashorn.internal.objects.Global?
(hazelcastClient.js, line 40, commented)

?Thanks to Sundar? (
https://twitter.com/sundararajan_a/status/581651315920515072), I learn that
Global object is not serializable to security reasons.

?Please, let me know if there is a workaround of? this problem?

?Thank you?

-- 
With best regards,
Viktor Gamov

From gamussa at gmail.com  Sun Mar 29 03:58:44 2015
From: gamussa at gmail.com (Viktor Gamov)
Date: Sat, 28 Mar 2015 23:58:44 -0400
Subject: Workaround for java.io.NotSerializableException:
	jdk.nashorn.internal.objects.Global
Message-ID: <CAD0N6pzZhd6bLneUs-u52yXQ1UxF4DmikA4hK237v7XQD+KGXQ@mail.gmail.com>

Hello Nashorn-team,

In my sample project I'm integrating different Hazelcast API with Nashorn.
It's on GH https://github.com/gAmUssA/hazelcast-nashorn
One thing that I'm trying to do is EntryProcessor (
http://docs.hazelcast.org/docs/latest/manual/html/entryprocessor.html).
EntryProcessor is executing on Hazelcast cluster member node. For that
purpose, Hazelcast client serializes it and sends it member node.

?I'm getting exception

Caused by: java.io.NotSerializableException:
jdk.nashorn.internal.objects.Global?
(hazelcastClient.js, line 40, commented)

?Thanks to Sundar? (
https://twitter.com/sundararajan_a/status/581651315920515072), I learn that
Global object is not serializable to security reasons.

?Please, let me know if there is a workaround of? this problem?

?Thank you?

-- 
With best regards,
Viktor Gamov

From sundararajan.athijegannathan at oracle.com  Mon Mar 30 13:24:31 2015
From: sundararajan.athijegannathan at oracle.com (A. Sundararajan)
Date: Mon, 30 Mar 2015 18:54:31 +0530
Subject: Workaround for java.io.NotSerializableException:
	jdk.nashorn.internal.objects.Global
In-Reply-To: <CAD0N6pwzUU9-hsOAawEeBYZpJrHE05kEnE5nDvGfx8SFrPjACg@mail.gmail.com>
References: <CAD0N6pwzUU9-hsOAawEeBYZpJrHE05kEnE5nDvGfx8SFrPjACg@mail.gmail.com>
Message-ID: <55194E8F.5050505@oracle.com>

As mentioned, serialization is not supported for script objects to avoid 
security, versioning issues (i.e,freely evolving internal implementation 
data structures). But, it should be possible to "serialize" a required 
global variables as a JSON document (JSON.stringify accepts "replacer" 
function which can be used to customize - for example, java serializable 
object values of global vars can be serialized and encoded as needed). 
JSON.parse can be used to "deserialize" - again "reviver" function can 
be used customize deserialization of particular values.

Hope this helps,
-Sundar

On Sunday 29 March 2015 09:29 AM, Viktor Gamov wrote:
> Hello Nashorn-team,
>
> In my sample project I'm integrating different Hazelcast API with Nashorn.
> It's on GH https://github.com/gAmUssA/hazelcast-nashorn
> One thing that I'm trying to do is EntryProcessor (
> http://docs.hazelcast.org/docs/latest/manual/html/entryprocessor.html).
> EntryProcessor is executing on Hazelcast cluster member node. For that
> purpose, Hazelcast client serializes it and sends it member node.
>
> ?I'm getting exception
>
> Caused by: java.io.NotSerializableException:
> jdk.nashorn.internal.objects.Global?
> (hazelcastClient.js, line 40, commented)
>
> ?Thanks to Sundar? (
> https://twitter.com/sundararajan_a/status/581651315920515072), I learn that
> Global object is not serializable to security reasons.
>
> ?Please, let me know if there is a workaround of? this problem?
>
> ?Thank you?
>