Re: RFR: 8193567: Conversion of comparison nodes affects local slots in optimistic continuation

[Jim Laskey (Oracle)]

+1


> On Dec 21, 2017, at 11:36 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193567
> Webrev: http://cr.openjdk.java.net/~hannesw/8193567/webrev.00/
> 
> I’ve tried finding a smaller fix like just tagging the child nodes of all 
> comparisons as non-optimistic, but that didn't fix the problem as those nodes 
> could still have optimistic children.
> 
> Hannes

Re: RFR: 8193508: Expressions in split literals must never be optimistic

[Jim Laskey (Oracle)]

+1


> On Dec 14, 2017, at 1:38 PM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193508
> Webrev: http://cr.openjdk.java.net/~hannesw/8193508/webrev.00/
> 
> The actual fix is quite simple: stop visiting when we encounter a split 
> object or array literal in OptimisticTypesCalculator.
> 
> There are a few non-essential changes:
> - rename methods and fields in CodeGeneratorLexicalContext from *SplitNode to 
> *SplitLiteral as the former is misleading (no actual SplitNodes around)
> - make sure we don’t have optimistic operations unless we generate optimistic 
> code to avoid the situation that enabled this bug
> - add logging for split array and object nodes in Splitter
> - add some @Ignore annotations to make nodes behave in IR printer
> 
> Thanks,
> Hannes

Re: RFR:8193491:JavaImporter fails to resolve method elements within functions, that contain too many statements

[Jim Laskey (Oracle)]

+1


> On Dec 20, 2017, at 10:01 AM, Priya Lakshmi Muthuswamy 
>  wrote:
> 
>  Removed __noSuchProperty__ methods in NativeJavaImporter
> 
>  updated webrev : http://cr.openjdk.java.net/~pmuthuswamy/8193491/webrev.01/
> 
> Thanks,
> Priya
> On 12/20/2017 11:41 AM, Priya Lakshmi Muthuswamy wrote:
>> Hi,
>> 
>> Please review JDK-8193491 : JavaImporter fails to resolve method elements 
>> within functions, that contain too many statements
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8193491
>> webrev: http://cr.openjdk.java.net/~pmuthuswamy/8193491/webrev.00/
>> 
>> This issue address both method and property lookup in JavaImporter when the 
>> function is split .
>> 
>> Thanks,
>> Priya
> 

Re: Review request for JDK-8192970: Element getters/setters with fixed key fail to link properly

[Jim Laskey (Oracle)]

Please wait for Sundar

> On Dec 6, 2017, at 3:52 PM, Attila Szegedi  wrote:
> 
> Is it okay to commit this with one +1 or should I wait for another approval?
> 
> Thanks,
>  Attila.
> 
>> On 2017. Dec 4., at 16:36, Hannes Wallnöfer  
>> wrote:
>> 
>> Took me some time to spot the difference in behaviour (adaptation of method 
>> type in Binder)!
>> 
>> +1
>> 
>> Hannes
>> 
>>> Am 04.12.2017 um 13:40 schrieb Attila Szegedi :
>>> 
>>> Please review JDK-8192970 "Element getters/setters with fixed key fail to 
>>> link properly" at  
>>> for 
>>> 
>>> Note that this is unrelated to the previous refactoring (8191878), it is 
>>> present even before that and also in JDK9, I’ll have to separately produce 
>>> a backport fix for it. I discovered this while trying to expand the test 
>>> coverage (and good thing that I did, too…)
>>> 
>>> The gist of the problem is that convertArgToNumber as it was before will 
>>> fail with IndexOutOfBoundsException invoking parameterType(1) on method 
>>> type for fixed-key getters, as they only have one parameter at index 0. 
>>> 
>>> The fix is to move the logic into the Binder and use the methodType it 
>>> manages, not the call site method type. This works because Binder always 
>>> works with a method type as if the getter/setter were variable-key (it adds 
>>> back the parameter type in its constructor if the operation is for a fixed 
>>> key).
>>> 
>>> Thanks,
>>> Attila.
>> 
> 

Re: RFR: 8191891: Update minumum Ant version in Nashorn build.xml

[Jim Laskey (Oracle)]

+1


> On Nov 28, 2017, at 10:26 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191891
> Webrev: http://cr.openjdk.java.net/~hannesw/8191891/webrev.00/
> 
> Thanks,
> Hannes

Re: RFR: 8059835: Optimistic splitting doesn't work with let and const

[Jim Laskey (Oracle)]

+1


> On Nov 28, 2017, at 10:03 AM, Hannes Wallnöfer  
> wrote:
> 

Re: RFR 8191771: nashorn ant makefile uses javadoc -link which may fail

[Jim Laskey (Oracle)]

+1


> On Nov 22, 2017, at 12:43 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191771
> Webrev: http://cr.openjdk.java.net/~sundar/8191771/webrev.00/
> 
> Thanks,
> -Sundar

Re: RFR 8191468: jdk.scripting.nashorn.shell (jjs) module should use optional dependency for java.compiler module

[Jim Laskey (Oracle)]

+1


> On Nov 17, 2017, at 5:16 AM, Hannes Wallnöfer  
> wrote:
> 
> Looks good!
> 
> Hannes
> 
>> Am 17.11.2017 um 07:30 schrieb Sundararajan Athijegannathan 
>> :
>> 
>> Please review.
>> 
>> Bug:  https://bugs.openjdk.java.net/browse/JDK-8191468
>> Webrev: http://cr.openjdk.java.net/~sundar/8191468/webrev.00/index.html
>> 
>> Thanks,
>> -Sundar
> 

Re: RFR 8191306: Math.abs corner case with optimistic typing

[Jim Laskey (Oracle)]

+1


> On Nov 15, 2017, at 9:22 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191306
> Webrev: http://cr.openjdk.java.net/~sundar/8191306/webrev.00/index.html
> 
> Thanks
> -Sundar

Re: RFR: 8191133: Ant task to fetch underscore.js requires gzip decoding option

[Jim Laskey (Oracle)]

+1

> On Nov 14, 2017, at 5:28 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191133
> Webrev: http://cr.openjdk.java.net/~hannesw/8191133/webrev/
> 
> Thanks,
> Hannes

Re: RFR: 8185119: Uninitialized const when using multiple threads

[Jim Laskey (Oracle)]

+1


> On Nov 13, 2017, at 1:25 PM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8185119
> Webrev: http://cr.openjdk.java.net/~hannesw/8185119/webrev/
> 
> Thanks,
> Hannes

Re: RFR: 8191131: Nashorn test comparator breaks comparator contract

[Jim Laskey (Oracle)]

+1

> On Nov 13, 2017, at 12:49 PM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191131
> Webrev: http://cr.openjdk.java.net/~hannesw/8191131/webrev/
> 
> Thanks,
> Hannes

Re: RFR: 8190427 : Test for JDK-8165198 fails intermittently because of GC

[Jim Laskey (Oracle)]

+1

> On Nov 7, 2017, at 8:45 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190427
> Webrev: http://cr.openjdk.java.net/~hannesw/8190427/webrev.02/
> 
> This started as simple bug fix but turned into a full refactoring of the code 
> that manages property switch points. However, I do think it is actually the 
> only reasonable way too fix this bug, with the side benefit that the code 
> becomes simpler.
> 
> The gist of this change is that PropertyMap no longer acts as property change 
> listener of parent maps. Instead, the switch points are managed and 
> invalidated directly in the PropertySwitchPoints class (renamed from 
> PropertyListeners). Thus, we no longer depend on PropertyMaps being kept 
> around, which was the root of the bug, and there’s one less level of 
> indirection. 
> 
> I also replaced the property change callback methods in PropertyMap with a 
> single propertyChanged method because it’s now the same code for all types of 
> property change.
> 
> I spent quite some time testing behaviour of the new code, and it’s actually 
> as good or slightly better than the old one in terms of switch points created 
> and invalidated. I’m a bit embarrassed I made this more complex than it had 
> to be the first time around.
> 
> Hannes

Re: RFR 8190795: jjs should show javadoc for java methods on shift-tab

[Jim Laskey (Oracle)]

+1


> On Nov 6, 2017, at 10:37 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190795
> Webrev: http://cr.openjdk.java.net/~sundar/8190795/webrev.00/
> 
> Piggybacking refactoring of other functions implemented in script (browse, 
> load etc.) so that we can avoid multi-line hard coded string in java sources.
> 
> -Sundar

Re: RFR 8190698: jjs tool of jdk.scripting.nashorn.shell module should not statically depend on java.desktop

[Jim Laskey (Oracle)]

+1

Does jshell have similar dependencies?

> On Nov 3, 2017, at 6:10 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190698
> Webrev: http://cr.openjdk.java.net/~sundar/8190698/webrev.00
> 
> Thanks,
> -Sundar

Re: RFR: 8189617: Remove undocumented --print-mem-usage option

[Jim Laskey (Oracle)]

+1


> On Oct 19, 2017, at 7:32 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189617
> Webrev: http://cr.openjdk.java.net/~hannesw/8189617/webrev.00/
> 
> Thanks,
> Hannes

Re: RFR: 8068513: Adding elements to a javascript 'object' (a map) is slow

[Jim Laskey (Oracle)]

+1


> On Oct 13, 2017, at 11:25 AM, Hannes Wallnöfer  
> wrote:
> 
> I uploaded a new webrev, please review:
> 
> http://cr.openjdk.java.net/~hannesw/8068513/webrev.02/
> 
> Changes to previous webrev:
> 
> - updated to consolidated repository layout
> - fixed typos and improved/added some comments
> - improved test
> 
> Thanks,
> Hannes
> 
> 
>> Am 11.09.2017 um 16:18 schrieb Hannes Wallnöfer 
>> :
>> 
>> Unfortunately I rushed the first webrev a bit, and a couple of bugs slipped 
>> in.
>> 
>> - PropertyHashMap(MapBuilder) constructor checks its own bins field instead 
>> of MapBuilder’s for calculating threshold
>> - ElementQueue.cloneAndMerge() updates the queue field in PropertyHashMap 
>> instead of just returning cloned and merged bins
>> 
>> I uploaded a new webrev that fixes these problems, everything I wrote in my 
>> original RFR still applies.
>> 
>> http://cr.openjdk.java.net/~hannesw/8068513/webrev.01/
>> 
>> Thanks,
>> Hannes
>> 
>> 
>>> Am 05.09.2017 um 19:57 schrieb Hannes Wallnöfer 
>>> :
>>> 
>>> Please review 8068513: Adding elements to a javascript 'object' (a map) is 
>>> slow:
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8068513
>>> Webrev: http://cr.openjdk.java.net/~hannesw/8068513/webrev.00/
>>> 
>>> This adds a new singly linked list called ‚ElementQueue‘ to PropertyHashMap 
>>> that is used above a certain map size to store newly inserted elements 
>>> without having to hash them (and therefore clone the bins array) 
>>> immediately. Instead, The queue is merged into the hash bins at certain 
>>> intervals, either every 512th insertions, or when a map's queue is searched 
>>> for properties more than a few times.
>>> 
>>> Merging the queue every 512 insertions proved to be the best balance 
>>> between keeping the list searchable (we still need to check it for 
>>> duplicates when adding elements) and avoiding too frequent cloning.
>>> 
>>> In order to merge the queue to optimise query performance, the queue field 
>>> needs to be non-final. To preserve thread safety, ElementQueue bundles both 
>>> the bins and queue components, so it can replace both with the update of a 
>>> single reference in PropertyHashMap. The old and new ElementQueue instances 
>>> logically contain the same elements, so it is safe for other threads to 
>>> keep using the old instance. I was thinking of maybe making the queue field 
>>> volatile, but I don’t think this should be an issue.
>>> 
>>> As part of this change I also added a new MapBuilder class that helps 
>>> derive new maps from the existing ones by adding, replacing, or removing 
>>> elements. The code is a bit more complex now with three possible storage 
>>> data structures (list, bins, queue), but it’s still not too bad.
>>> 
>>> I made sure that the code used for maps beneath the queue threshold is 
>>> largely the same as before. Performance of the new combined behaveior is 
>>> very close to before. The queued implementation itself performs pretty 
>>> close to the normal implementation (apart from insertion on large maps of 
>>> course) - I tested much lower thresholds during development, and it was 
>>> still very good. 
>>> 
>>> Of course, all tests pass and performance is comparable or maybe slightly 
>>> faster for some code.
>>> 
>>> Thanks,
>>> Hannes
>> 
> 

Re: RFR: 8027302: Identifiers containing unicode escapes are not recognized as reserved words

[Jim Laskey (Oracle)]

+1


> On Oct 13, 2017, at 5:36 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review: 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8027302
> Webrev: http://cr.openjdk.java.net/~hannesw/8027302/webrev.01
> 
> ES6 and ES5 require different handling regarding unencoding Unicode escapes 
> in keywords and identifiers. This patch makes handling more compliant and 
> more efficient in ES6 mode (previously we didn’t cover all cases, and checked 
> every identifier instead of just those containing escapes).
> 
> About the removal of Lexer.isEscapeCharacter: this method always returns true 
> in Lexer, and it’s only purpose was to be overridden in JSON parser, but JSON 
> parser doesn’t extend Lexer/Parser anymore.
> 
> Thanks,
> Hannes

Re: RFR:8147076(LinkerCallSite.ARGLIMIT is used incorrectly)

[Jim Laskey (Oracle)]

+1

> On Sep 29, 2017, at 11:33 AM, Srinivas Dama  wrote:
> 
> Hi Hannes,
> 
> Thank you for the comments
> 
> -Modified test case already covers both > ARGLIMIT and  with double).
> I have added a new test case for double arguments.anyway,I will modify the 
> test as you suggested.
> -Yes,eval()in the test is meant for the same purpose as you mentioned. I will 
> add comments.
> 
> Regards,
> Srinivas
> 
> - Original Message -
> From: hannes.wallnoe...@oracle.com
> To: srinivas.d...@oracle.com
> Cc: nashorn-dev@openjdk.java.net
> Sent: Friday, September 29, 2017 7:33:18 PM GMT +05:30 Chennai, Kolkata, 
> Mumbai, New Delhi
> Subject: Re: RFR:8147076(LinkerCallSite.ARGLIMIT is used incorrectly)
> 
> Hi Srini, 
> 
> a few notes:
> 
> - Shouldn’t the new test include an invocation with >  ARGLIMIT double 
> arguments to test it works?
> - No need to use Number(1.1), a number with a fractional part will result in 
> a double.
> - I assume eval() in the test is to force this-object and callee to be sent, 
> maybe add a comment about that?
> - there’s a typo in the test: arguements
> 
> Hannes
> 
> 
>> Am 29.09.2017 um 15:34 schrieb Srinivas Dama :
>> 
>> Hi,
>> 
>> Please review http://cr.openjdk.java.net/~sdama/8147076/webrev.00/ 
>> for https://bugs.openjdk.java.net/browse/JDK-8147076
>> 
>> Regards,
>> Srinivas
> 

Re: RFR 8180274: Fix links in nashorn documentation

[Jim Laskey (Oracle)]

+1

> On Sep 29, 2017, at 1:56 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180274
> Webrev: http://cr.openjdk.java.net/~sundar/8180274/webrev.00/
> 
> Thanks,
> -Sundar

Re: RFR 8188098: NPE in SimpleTreeVisitorES6 visitor when parsing a tagged template literal

[Jim Laskey (Oracle)]

+1

> On Sep 28, 2017, at 1:38 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8188098
> Webrev: http://cr.openjdk.java.net/~sundar/8188098/webrev.00/
> 
> Thanks,
> -Sundar

Re: RFR 8188082: autoimports.js sample is broken

[Jim Laskey (Oracle)]

+1

> On Sep 28, 2017, at 2:37 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8188082
> Webrev: http://cr.openjdk.java.net/~sundar/8188082/webrev.00/
> 
> PS. Piggybacking to push another sample to demonstrate the use of es6 tagged 
> template literal to create a java object
> 
> Thanks,
> -Sundar

Re: RFR: 8186815: Java.from has a bug, when element is ScriptObject

[Jim Laskey (Oracle)]

+1

> On Sep 27, 2017, at 11:44 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8186815
> Webrev: http://cr.openjdk.java.net/~hannesw/8186815/webrev/
> 
> Thanks,
> Hannes

Re: RFR 8188023: Avoid -source and -target javac options in nashorn ant compilation

[Jim Laskey (Oracle)]

+1

> On Sep 27, 2017, at 8:59 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8188023
> Webrev: http://cr.openjdk.java.net/~sundar/8188023/webrev.00/index.html
> 
> Piggybacking to take care of few javac warnings as well.
> 
> Thanks,
> -Sundar

Re: RFR 8187965: dynalink samples under $jdk10/src/sample/nashorn/dynalink are broken

[Jim Laskey (Oracle)]

+1 nicer too


> On Sep 26, 2017, at 10:58 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187965
> 
> Webrev: http://cr.openjdk.java.net/~sundar/8187965/webrev.00/
> 
> Dynalink samples are broken because of wildcard usage in jar command.
> 
> PS. Piggybacking another sample script base64.js
> 
> Thanks,
> -Sundar

Re: RFR 8187934: dropping a shebang script in src/sample/nashorn directory results in test failure

[Jim Laskey (Oracle)]

+1

> On Sep 25, 2017, at 11:15 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187934
> Webrev: http://cr.openjdk.java.net/~sundar/8187934/webrev.00/
> 
> PS. Piggybacking a sample script (psgrep.js)
> 
> Thanks,
> -Sundar

Re: RFR: 8186646: Nashorn: "duplicate code" assertion when binding a vararg function that just passes arguments along

[Jim Laskey (Oracle)]

+1

> On Sep 21, 2017, at 7:22 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review 8186646: Nashorn: "duplicate code" assertion when binding a 
> vararg function that just passes arguments along
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8186646
> Webrev: http://cr.openjdk.java.net/~hannesw/8186646/webrev/
> 
> Thanks,
> Hannes

Re: RFR 8187782: no ant build artifact should be produced under make/nashorn directory

[Jim Laskey (Oracle)]

+1

Too bad there isn’t any refactoring tools for this sort of thing.

> On Sep 21, 2017, at 9:06 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187782
> Webrev: http://cr.openjdk.java.net/~sundar/8187782/webrev.00/
> 
> Thanks,
> -Sundar

Re: RFR 8187773: nashorn ant javadoc, nashornapi, dynalinkapi, run, debug, octane, sunspider targets fail

[Jim Laskey (Oracle)]

+1

> On Sep 21, 2017, at 4:19 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187773
> Webrev: http://cr.openjdk.java.net/~sundar/8187773/webrev.00/
> 
> Thanks,
> -Sundar

Re: RFR:8181792:nashorn samples/exec.js has some incorrect examples

[Jim Laskey (Oracle)]

+1

> On Sep 8, 2017, at 6:42 AM, Priya Lakshmi Muthuswamy 
>  wrote:
> 
> Removed the redundant example(ls -l -a).
> 
> Updated patch : http://cr.openjdk.java.net/~pmuthuswamy/8181792/webrev.01/
> 
> Thanks,
> Priya
> 
> On 9/8/2017 2:25 PM, Priya Lakshmi Muthuswamy wrote:
>> Hi,
>> 
>> Please review JDK-8181792 : nashorn samples/exec.js has some incorrect 
>> examples.
>> 
>> JBS : https://bugs.openjdk.java.net/browse/JDK-8181792
>> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8181792/webrev.00/
>> 
>> Thanks,
>> Priya
>> 
>> 
>> 
> 

Re: RFR:8169233:LengthNotWritableFilter extraElements.remove(index) has no effect

[Jim Laskey (Oracle)]

+1

> On Sep 1, 2017, at 1:32 AM, Priya Lakshmi Muthuswamy 
>  wrote:
> 
> Hi,
> 
> Please review JDK-8169233 : LengthNotWritableFilter: 
> extraElements.remove(index) has no effect
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8169233
> webrev : http://cr.openjdk.java.net/~pmuthuswamy/8169233/webrev.00/
> 
> Thanks,
> Priya

Re: RFR:8177691:Labeled break in catch and finally works wrongly, when invoked through nashorn

[Jim Laskey (Oracle)]

+1

> On Aug 29, 2017, at 10:55 AM, Srinivas Dama  wrote:
> 
> Hi,
> 
> 
> 
> Please review http://cr.openjdk.java.net/~sdama/8177691/webrev.00/ 
> 
> for  https://bugs.openjdk.java.net/browse/JDK-8177691 
> 
> 
> 
> Regards,
> 
> Srinivas

Re: RFR:8073640:Nashorn scripting: here document with only whitespace gives error

[Jim Laskey (Oracle)]

+1

> On Aug 31, 2017, at 8:01 AM, Hannes Wallnöfer  
> wrote:
> 
> +1
> 
> Does this change behaviour for non-empty strings?
> 
> Hannes
> 
>> Am 31.08.2017 um 10:51 schrieb Srinivas Dama :
>> 
>> Hi,
>> 
>> Please review http://cr.openjdk.java.net/~sdama/8073640/webrev.00/
>> for https://bugs.openjdk.java.net/browse/JDK-8073640 
>> 
>> Regards,
>> srinivas
> 

Re: [10] RFR: 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks

[Jim Laskey (Oracle)]

+1


> On Jul 25, 2017, at 10:44 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review 8184893: jdk8u152 b06 : issues with nashorn when running kraken 
> benchmarks
> 
> Kraken benchmark contains some files that invokes the Array constructor with 
> lots of number literal arguments. We assume too low code footprint for these 
> number literals in WeighNodes.java, resulting in the function not being split.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8184893
> Webrev: http://cr.openjdk.java.net/~hannesw/8184893/webrev/
> 
> Thanks,
> Hannes

Re: RFR: 8180727(Use jdk.editpad to replace jdk.nashorn.tools.jjs.EditPad duplicated class)

[Jim Laskey (Oracle)]

+1

> On Jul 25, 2017, at 10:54 AM, Srinivas Dama  wrote:
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~sdama/8180727/webrev.00/ 
> 
> for https://bugs.openjdk.java.net/browse/JDK-8180727 
> 
> 
> 
> Regards,
> 
> Srinivas

Re: RFR: 8184241(Fix nashorn/samples/filebrowser.js)

[Jim Laskey (Oracle)]

Forgot. +1

> On Jul 19, 2017, at 5:45 AM, Srinivas Dama  wrote:
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~sdama/8184241/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8184241.
> 
> Regards,
> Srinivas

Re: RFR: 8184239(Fix broken nashorn/samples)

[Jim Laskey (Oracle)]

+1

> On Jul 12, 2017, at 3:41 PM, Srinivas Dama <srinivas.d...@oracle.com> wrote:
> 
> Hi,
> 
> Please review the updated patch. Sorry I missed one sample earlier.
> http://cr.openjdk.java.net/~sdama/8184239/webrev.01/ 
> 
> Regards,
> Srinivas
> 
> -Original Message-
> From: Jim Laskey (Oracle) 
> Sent: Wednesday, July 12, 2017 5:34 PM
> To: Srinivas Dama
> Cc: Nashorn-Dev
> Subject: Re: RFR: 8184239(Fix broken nashorn/samples)
> 
> +1
> 
>> On Jul 12, 2017, at 6:00 AM, Srinivas Dama <srinivas.d...@oracle.com> wrote:
>> 
>> Hi,
>> 
>> Please review http://cr.openjdk.java.net/~sdama/8184239/webrev.00/ for 
>> https://bugs.openjdk.java.net/browse/JDK-8184239 
>> 
>> Regards,
>> Srinivas
> 

Re: RFR: 8184239(Fix broken nashorn/samples)

[Jim Laskey (Oracle)]

+1

> On Jul 12, 2017, at 6:00 AM, Srinivas Dama  wrote:
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~sdama/8184239/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8184239 
> 
> Regards,
> Srinivas

Re: RFR: 8182996: Incorrect mapping Long type to JavaScript equivalent

[Jim Laskey (Oracle)]

+1

> On Jun 28, 2017, at 10:34 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review 8182996: Incorrect mapping Long type to JavaScript equivalent:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8182996
> Webrev: http://cr.openjdk.java.net/~hannesw/8182996/webrev/
> 
> Thanks,
> Hannes

Re: RFR: 8181105: Nashorn file descriptor leaks

[Jim Laskey (Oracle)]

+1

> On Jun 21, 2017, at 10:13 PM, Andrey Nazarov  
> wrote:
> 
> Hi,
> 
> Please review fix for 8181105
> Webrev: http://cr.openjdk.java.net/~anazarov/JDK-8181105/webrev.00/webrev/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8181105
> 
> 
> —Andrei

Re: RFR (10): JDK-8181191: getUint32 returning Long

[Jim Laskey (Oracle)]

+1

> On Jun 13, 2017, at 12:51 PM, Hannes Wallnöfer  
> wrote:
> 
> Please review: 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181191
> Webrev: http://cr.openjdk.java.net/~hannesw/8181191/webrev/
> 
> Thanks,
> Hannes

Re: Pass js array to a Java method pointer

[Jim Laskey (Oracle)]

Others are more expert than I but I believe the difference is that f1/f2 
invokes are using hard Java Objects and f3/f4 invokes are using MethodHandles 
with generic arguments.

> On May 16, 2017, at 3:36 PM, xu qingyi <bphan...@live.com> wrote:
> 
> thx, Jim, I hava  tried your solution and  it  works. but  it  needs  to 
> invoke java method so  it's more  complex. After all, what's the different 
> between  f1, f2 and  f4.
> 
> 2017年5月17日 上午2:28，"Jim Laskey (Oracle)" <james.las...@oracle.com>写道：
> It could have inferred that you meant to pass in a single element object 
> array. Nashorn needs a bit more to determine that you wanted to convert to an 
> java object array.
> 
> System.out.println(nashorn.eval("var ObjectArray = 
> Java.type('java.lang.Object[]'); f4(Java.to([1,2], ObjectArray))"));
> 
> or more simply
> 
> System.out.println(nashorn.eval("f4(Java.to([1,2]))"));
> 
> Generally, Nashorn only automatically converts primitive types.
> 
> 
> — Jim
> 
> 
> 
> 
> > On May 16, 2017, at 3:03 PM, qiyi <bphan...@gmail.com> wrote:
> > 
> > Hi, all, I'am trying to add a function to nashorn engine's bindings, and
> > these methods I have tried:
> > 
> > public class MyFunction implements Function<Object[], Object> {
> > 
> >@Override
> >public Object apply(Object[] objects) {
> >return Arrays.toString(objects);
> >}
> > 
> >public Object f2(Object[] objects) {
> >return Arrays.toString(objects);
> >}
> > 
> >public Object f3(Object object) {
> >return object;
> >}
> > 
> >public Object f4(Object[] objects) {
> >return Arrays.toString(objects);
> >}
> > 
> > 
> >public static void main(String[] args) throws ScriptException {
> >MyFunction myFunction = new MyFunction();
> > 
> >ScriptEngineManager manager = new ScriptEngineManager();
> >ScriptEngine nashorn = manager.getEngineByName("nashorn");
> >Bindings bindings = nashorn.getBindings(ScriptContext.ENGINE_SCOPE);
> > 
> >bindings.put("f1", myFunction);
> >bindings.put("f", myFunction);
> >bindings.put("f3", (Function<Object, Object>) myFunction::f3);
> >bindings.put("f4", (Function<Object[], Object>) myFunction::f4);
> > 
> >System.out.println(nashorn.eval("f1([1,2])")); // run ok, ret: [1,2]
> >System.out.println(nashorn.eval("f.f2([1,2])")); // run ok, ret: [1, 
> > 2]
> >System.out.println(nashorn.eval("f3(\"f3\")")); // run ok, ret: f3
> >System.out.println(nashorn.eval("f4([1,2])")); // run fail,
> > ClassCastException: ScriptObjectMirror cannot be cast to
> > [Ljava.lang.Object
> >}
> > }
> > 
> > 
> > The problem is the f4 function, this method pointer receive Object[]
> > parameter and nashorn will throw exception with ClassCastException.
> > 
> > But why nashorn could not infer the parameter type and auto convert
> > the js array to java array, will it be a bug of nashorn
> 
> 

Re: Pass js array to a Java method pointer

[Jim Laskey (Oracle)]

It could have inferred that you meant to pass in a single element object array. 
Nashorn needs a bit more to determine that you wanted to convert to an java 
object array.

System.out.println(nashorn.eval("var ObjectArray = 
Java.type('java.lang.Object[]'); f4(Java.to([1,2], ObjectArray))"));

or more simply

System.out.println(nashorn.eval("f4(Java.to([1,2]))"));

Generally, Nashorn only automatically converts primitive types.


— Jim




> On May 16, 2017, at 3:03 PM, qiyi  wrote:
> 
> Hi, all, I'am trying to add a function to nashorn engine's bindings, and
> these methods I have tried:
> 
> public class MyFunction implements Function {
> 
>@Override
>public Object apply(Object[] objects) {
>return Arrays.toString(objects);
>}
> 
>public Object f2(Object[] objects) {
>return Arrays.toString(objects);
>}
> 
>public Object f3(Object object) {
>return object;
>}
> 
>public Object f4(Object[] objects) {
>return Arrays.toString(objects);
>}
> 
> 
>public static void main(String[] args) throws ScriptException {
>MyFunction myFunction = new MyFunction();
> 
>ScriptEngineManager manager = new ScriptEngineManager();
>ScriptEngine nashorn = manager.getEngineByName("nashorn");
>Bindings bindings = nashorn.getBindings(ScriptContext.ENGINE_SCOPE);
> 
>bindings.put("f1", myFunction);
>bindings.put("f", myFunction);
>bindings.put("f3", (Function) myFunction::f3);
>bindings.put("f4", (Function) myFunction::f4);
> 
>System.out.println(nashorn.eval("f1([1,2])")); // run ok, ret: [1,2]
>System.out.println(nashorn.eval("f.f2([1,2])")); // run ok, ret: [1, 2]
>System.out.println(nashorn.eval("f3(\"f3\")")); // run ok, ret: f3
>System.out.println(nashorn.eval("f4([1,2])")); // run fail,
> ClassCastException: ScriptObjectMirror cannot be cast to
> [Ljava.lang.Object
>}
> }
> 
> 
> The problem is the f4 function, this method pointer receive Object[]
> parameter and nashorn will throw exception with ClassCastException.
> 
> But why nashorn could not infer the parameter type and auto convert
> the js array to java array, will it be a bug of nashorn

Re: RFR: 8179891: JavaDoc for for..in is incorrect

[Jim Laskey (Oracle)]

+1

> On May 11, 2017, at 6:00 AM, Srinivas Dama  wrote:
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~sdama/8179891/webrev.00/index.html 
> for 
> https://bugs.openjdk.java.net/browse/JDK-8179891
> 
> Regards,
> Srinivas

Re: Nashorn Parser API Javadoc

[Jim Laskey (Oracle)]

Will file a bug.

— Jim


> On May 8, 2017, at 4:01 AM, Dai Conrad  wrote:
> 
> I was looking at the parser API and I noticed that in the class
> ForOfLoopTree, the methods getStatement() and getVariable()
> have the following javadoc, respectively:
> 
>The statement contained in this for..in statement.
> 
>The for..in left hand side expression.
> 
> In both cases "for..in" should read "for..of".

Running JS code on a server

[Jim Laskey (Oracle)]

From: Eliezer Julian >
Subject: Running JS code on a server
Date: May 1, 2017 at 6:28:05 AM ADT
To: "nashorn-dev@openjdk.java.net " 
>
Cc: Elior Apelbaum >, Moshe Robinov >, Chen Malka >


Hi,
 
I am developing a server side application and would like to add a feature that 
allows a user to submit JS code to be executed via Nashorn. My concern is that 
a user may submit malicious code that may compromise the server. I have already 
limited the script’s access to the bare minimum of Java classes, and have 
implemented a mechanize to kill the script if execution time runs over a 
certain limit. I have also manually removed many of the special methods such as 
print, echo, exit and quit from the Bindings object. However, this is extremely 
limited in scope compared to the damage a willfully malicious user may be able 
to effect via this feature (such as allocating too much memory, try to access 
the file system via the script, etc.). I was wondering if the Nashorn 
development team had any recommendations as far as security is concerned, and 
whether there are any plans to add additional security features in the future.
 
Thanks,
 
Eli Julian
Software Developer
Decision Division

Email: eliezer.jul...@sapiens.com 
Office: +972-3-7902155
Mobile: +972-50-3697238
Skype handle: eli_julian
Visit us at: www.sapiens.com 

Re: how to help with ES6 features

[Jim Laskey (Oracle)]

If we can get more people involved, maybe I should come up with some scheme of 
free Nashorn t-shirts for those people that contribute code. :-) 


> On Apr 27, 2017, at 9:07 AM, Paulo Lopes  wrote:
> 
> I can make it work with nashorn. Currently it does run on nashorn jdk8 plus
> I need a executor impl for the async part. Of course I'm using vert.x for
> this ;) However this could be a runtime configuration and by default use a
> simple ThreadPool as it exists on the JDK itself and allow (say with some
> runtime config) to provide a custom executor.
> 
> The executor is basically the equivalent of the not yet standard:
> 
> setImmediate(function);
> 
> Or node's:
> 
> nextTick(function);
> 
> So in nashorn it can be just a java.lang.Runnable and a ThreadPoolExecutor.
> 
> Cheers,
> Paulo
> 
> 
> On Thu, Apr 27, 2017 at 1:49 PM, Hannes Wallnöfer <
> hannes.wallnoe...@oracle.com> wrote:
> 
>> Hi Paulo,
>> 
>> Excellent! I’d be happy to help you and sponsor this work.
>> 
>> Do you think your existing code would work in Nashorn, or would it be a
>> reimplementation based on that prototype? In any case, a link to the code
>> would be nice to get an idea of what’s involved.
>> 
>> Also, before contributing to OpenJDK you have to sign and send in the
>> committer agreement as described in http://openjdk.java.net/contribute/ .
>> If you aren’t a committer already we can help you with this.
>> 
>> Hannes
>> 
>> 
>>> Am 27.04.2017 um 13:16 schrieb Paulo Lopes :
>>> 
>>> Hi,
>>> 
>>> For Vert.x javascript support I've prototyped the Promise API as per:
>>> 
>>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/
>> Reference/Global_Objects/Promise
>>> http://www.ecma-international.org/ecma-262/6.0/#sec-promise-objects
>>> 
>>> I see that it is not in the complete list, If someone would "mentor" me
>> with how to get it in nashorn, I'd gladly contribute the code.
>>> 
>>> As an example here's some demo:
>>> 
>>> https://gist.github.com/pmlopes/3d86f67943b3ffd9dd9aff73067de0a2
>>> 
>>> And it has been tested to work with babel.js to allow transpiling
>> `async` `await` to Promise API.
>>> 
>>> Cheers,
>>> Paulo
>>> 
>>> 
>>> On Wed, Apr 26, 2017 at 4:38 PM, Hannes Wallnöfer <
>> hannes.wallnoe...@oracle.com> wrote:
>>> Here’s a list of things we have working and things we don’t:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8066046
>>> 
>>> ES6 support in the parser is pretty much complete, so some features are
>> arrow functions are ‚almost‘ working, and others may not require too much
>> effort.
>>> 
>>> Hannes
>>> 
>>> 
 Am 26.04.2017 um 16:18 schrieb Karl Pietrzak :
 
 On Wed, Apr 26, 2017 at 10:14 AM, Hannes Wallnöfer <
 hannes.wallnoe...@oracle.com> wrote:
 
> ES6 support is still work in progress, we only support some of it, so
> making it the default wouldn’t be a good idea.
> 
 
 
 Is there a feature I can help with?   If someone points me in the right
 direction, I can submit a patch.  I don't see anything in JIRA, really.
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Paulo Lopes
>>> www.jetdrone.com
>> 
>> 
> 
> 
> -- 
> Paulo Lopes
> www.jetdrone.com

Re: Exception while using ES6 features (template strings) with Nashorn on JDK 9

[Jim Laskey (Oracle)]

You need to specify --language=es6 on the command line

> On Apr 26, 2017, at 10:25 AM, Mohammed Sanaulla  wrote:
> 
> Hello All,
> 
> I am using build b166 of JDK 9.
> 
> And I tried to run the following code:
> 
> ScriptEngineManager engineManager = new ScriptEngineManager();
> ScriptEngine engine = engineManager.getEngineByName("nashorn");
> engine.eval("function sum(a, b) { return a + b; }");
> System.out.println(engine.eval("sum(1, 2);"));
> engine.eval("var name = 'Sanaulla'");
> System.out.println(engine.eval("print(`Hello Mr. ${name}`)"));
> 
> The sum(1,2) works fine by printing 3. But the other part i.e using
> template strings throws the following exception:
> 
> Exception in thread "main" javax.script.ScriptException: :1:6
> Expected an operand but found error
> print(`Hello Mr. ${name}`)
>  ^ in  at line number 1 at column number 6
>at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:469)
>at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:536)
>at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:523)
>at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:401)
>at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:154)
>at
> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
>at
> nashorn.demo/com.packt.JavascriptCodeFromJavaDemo.main(JavascriptCodeFromJavaDemo.java:13)
> Caused by: jdk.nashorn.internal.runtime.ParserException: :1:6
> Expected an operand but found error
> print(`Hello Mr. ${name}`)
>  ^
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:297)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:282)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:4443)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4601)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.conditionalExpression(Parser.java:4753)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:4692)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.argumentList(Parser.java:3706)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.leftHandSideExpression(Parser.java:3389)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.unaryExpression(Parser.java:4421)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4601)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.conditionalExpression(Parser.java:4753)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.assignmentExpression(Parser.java:4692)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4570)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expression(Parser.java:4566)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.expressionStatement(Parser.java:1847)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.statement(Parser.java:1155)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.sourceElements(Parser.java:909)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.program(Parser.java:844)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.parse(Parser.java:325)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.parser.Parser.parse(Parser.java:285)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.compile(Context.java:1500)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.compileScript(Context.java:1467)
>at
> jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.compileScript(Context.java:750)
>at
> jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(NashornScriptEngine.java:534)
>... 5 more
> 
> I even tried running template strings from jjs console, but I am facing
> same issue.
> 
> Can someone please guide me in using the ES6 features in Nashorn on JDK9?
> 
> Regards,
> Sanaulla

Re: RFR 8179304: Please review minor changes to doc comments

[Jim Laskey (Oracle)]

+1

> On Apr 25, 2017, at 10:32 PM, Jonathan Gibbons  
> wrote:
> 
> Please review these minor changes to make the doc comments HTML5 compliant.
> 
> Mostly, the changes are about changing  to  or {@code} tags.
> 
> There is one minor adjustment to the text content -- in TreeVisitor.java,
> I adjusted the name visitXYZ to visitXyz in line with similar usage elsewhere.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179304
> Webrev: http://cr.openjdk.java.net/~jjg/8179304/webrev/
> 
> -- Jon

Re: RFR 8178954: jjs uses wrong javadoc base URL

[Jim Laskey (Oracle)]

+1

> On Apr 19, 2017, at 1:43 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8178954/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8178954
> 
> Thanks,
> -Sundar

Re: Can we define a method name alias when using a Java object/class form Nashorn?

[Jim Laskey (Oracle)]

You might consider using an ordinary JS object to wrap the Java Promise Object. 
 Even though the wrapper exists, the indirection should eventually optimize out 
(more so than for JSObject.)  As far as having more objects about, I think it’s 
small relative to other objects in the background (MethodHandles.)  This will 
also give you the advantage of having Promise be a real JS Object.  Who knows 
what kinds of things users hang off of the promise.

Cheers,

— Jim




> On Mar 9, 2017, at 8:20 AM, Paulo Lopes  wrote:
> 
> Hi,
> 
> For the Vert.x project I've created a simple Promise implementation as
> available in a Browser.
> 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise
> 
> I've then played with babel to transpile the ES7 async - await to Promises
> and I must say that it works fine under Nashorn.
> 
> Now my concern is that since this code is always in the hot-path I'd like
> to translate it to Java so it could be executed/jitted faster, however the
> Promise API has a small issue with that, it defines a method named: "catch"
> 
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/catch
> 
> This is forbidden name for a java method since according to the JLS "catch"
> is a reserved word and Java is way more strict than JS. My question is, now:
> 
> Do I need to implement this using the JSObject interface where I can react
> to a "getMember" to return a Function and then handle it on the "call"
> method, or is there some "magic" where I can keep it all under a single
> Java object and make an alias?
> 
> I expect that if I implement the JSObject that I'll start making to many
> small lived objects and the performance improvements would be lost with the
> GC pressure...

Re: Efficiency of context-per-thread on shared engine vs. engine + context per thread?

[Jim Laskey (Oracle)]

From basic experience I found that using a single engine, using JavaScript code 
to create the new threads and using loadWithNewGlobal to start each thread gave 
the best overall performance.

- Jim


> On Feb 27, 2017, at 7:58 AM, Frantzius, Jörg  
> wrote:
> 
> Hi,
> 
> for our application we’re about to implement a global-per-thread on single 
> engine approach, and I’d be very thankful if someone in the know could share 
> some insights on whether this is worth the effort when compared to engine-per 
> thread (as the latter seems much more easy to implement for us).
> 
> More precisely the question is whether a single engine with multiple 
> ScriptContexts is substantially more resource-efficient than multiple engines 
> (each with their own ScriptContext)? Does Nashorn e.g. share 
> code-optimization between engines? Or does it share code-optimization between 
> ScriptContexts on a single engine in the first place?
> 
> Also it would be great to know about the memory-footprint of the engine, e.g. 
> http://stackoverflow.com/questions/24116672/how-much-memory-does-a-nashorn-scriptengine-use
>  seems to say that an empty engine is ~324KB, but I’d expect that to be 
> higher when it is actually executing code.
> 
> Thanks for any insights + regards,
> Jörg
> 
> 
> ---
> 
> Dipl. Inf. Jörg von Frantzius, Technical Director
> 
> E-Mail joerg.frantz...@aperto.com
> 
> Phone +49 30 283921-318
> Fax +49 30 283921-29
> 
> Aperto GmbH – An IBM Company
> Chausseestraße 5, D-10115 Berlin
> http://www.aperto.com
> http://www.facebook.com/aperto
> https://www.xing.com/companies/apertoag
> 
> HRB 77049 B, AG Berlin Charlottenburg
> Geschäftsführer: Dirk Buddensiek, Kai Großmann, Stephan Haagen, Daniel Simon
> 

Re: Getting Input From User

[Jim Laskey (Oracle)]

>> jjs -scripting
jjs> var name = readLine("Your name >> ");
Your name >> Jim
jjs> print(name)
Jim

That sort of thing?

— Jim


> On Feb 25, 2017, at 5:24 AM, Koray  wrote:
> 
> Hello,
> 
> I apologize if this is not the place to ask, but I couldn't get a
> satisfying answer from anywhere else so this is kind of my last
> resort.
> 
> Is there any built-in function to get input from a user when using
> NashornScriptEngine? print() method allows us to utilize both the
> default OutputStreamWriter (System.out) and any writers that we set
> using ScriptContext, but how can I make use of the reader which is
> used by the engine?
> 
> Thank you,
> Burak

Re: RFR of JDK-8174699: Fix @since in module-info.java in dev/nashorn repo

[Jim Laskey (Oracle)]

+1 Go ahead and push.


> On Feb 9, 2017, at 11:43 PM, Hamlin Li  wrote:
> 
> Would you please review the below patch?
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8174699
> 
> webrev: http://cr.openjdk.java.net/~mli/8174699/webrev.00/
> 
> 
> Thank you
> 
> -Hamlin
> 

Re: RFR: 8173888: Test for JDK-8169481 causes stack overflows in parser tests

[Jim Laskey (Oracle)]

+1

> On Feb 3, 2017, at 7:37 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173888
> Webrev: http://cr.openjdk.java.net/~hannesw/8173888/webrev.00/
> 
> Note that the bug that introduced the problematic test is confidential, the 
> changeset contained adjustments to the splitter weight calculation:
> 
> http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/ea1d4ecf5862
> 
> Thanks,
> Hannes

Re: RFR: 8173480: in operator should work on java objects and classes

[Jim Laskey (Oracle)]

+1

> On Jan 30, 2017, at 6:22 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review 8173480: in operator should work on java objects and classes.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173480
> Webrev: http://cr.openjdk.java.net/~hannesw/8173480/webrev.00/nashorn.patch
> 
> Thanks,
> Hannes
> 

Re: RFR: 8172006: Nashorn JavaScript engine fails to call @FunctionalInterface with a java.util.List argument

[Jim Laskey (Oracle)]

+1

> On Jan 25, 2017, at 12:45 PM, Hannes Wallnöfer  
> wrote:
> 
> 
>> Am 25.01.2017 um 17:39 schrieb Attila Szegedi :
>> 
>> Well, filterInternalObjects itself doesn’t change the method handle type. I 
>> guess what happens is that the delegate BeansLinker.getGuardedInvocation 
>> returned a handle that it already adapted to the call site type. But you’re 
>> right that the filterInternalObjects here was both redundant and harmful; 
>> BeanLinker calls it where necessary.
>> 
> 
> Yes, I realised that after I sent the message. I added a note to the issue as 
> well:
> 
> https://bugs.openjdk.java.net/browse/JDK-8172006?focusedCommentId=14044057=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14044057
> 
> Thanks a lot!
> 
> Hannes
> 
>> +1.
>> 
>> Glad you got to the bottom of this, it felt really scary how the original 
>> reproducer seemingly depended on the shape of not-yet-evaluated expressions 
>> (I completely forgot about shared scope…)
>> 
>> Attila.
>> 
>>> On 25 Jan 2017, at 17:32, Hannes Wallnöfer  
>>> wrote:
>>> 
>>> The problem is that the first invocation of filtertInternalObjects (that 
>>> happens closer to the target handle) changes the method handle’s parameter 
>>> type from java.util.List to java.lang.Object, so the outer 
>>> filtertInternalObjects invocation did not see the List target type.
>>> 
>>> Hannes
>>> 
 Am 25.01.2017 um 17:21 schrieb Attila Szegedi :
 
 Oh, great. I was just starting at this for a bit (after I saw you updated 
 the JIRA), and was definitely starting to suspect the 
 filterInternalObjects call in NashornBeansLinker. It still worries me that 
 filtering would add a script object mirror wrapper – the method handle’s 
 parameter is typed as List, isn’t it? DefaultInternalObjectFilter should 
 only operate on parameters declared as Object.
 
 Attila.
 
> On 25 Jan 2017, at 17:05, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8172006
> Webrev: http://cr.openjdk.java.net/~hannesw/8172006/webrev.00/
> 
> The final invocation of linkerServices.filterInternalObjects was 
> redundant, and in fact caused the argument to be converted to 
> ScripObjectMirror when the actual target type was java.util.List. As far 
> as I can tell, linkerServices.filterInternalObjects is called elsewhere 
> for all types of invocations. Existing tests pass, and I added a few more.
> 
> Thanks,
> Hannes
 
>>> 
>> 
> 

Re: RFR 8173257: test/script/trusted/JDK-8021189.js and test/script/trusted/JDK-8021129.js fail in nashorn nightly

[Jim Laskey (Oracle)]

+1

> On Jan 24, 2017, at 4:56 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8173257/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8173257
> 
> Thanks,
> -Sundar

Re: RFR: 8166187: Regression: NPE during reparse when using persistent code cache and optimistic types

[Jim Laskey (Oracle)]

+1

> On Jan 10, 2017, at 10:50 AM, Hannes Wallnöfer  
> wrote:
> 
> I just realized I used the wrong bug id for the second webrev linked below. 
> Here’s the webrev again, with the correct id:
> 
> http://cr.openjdk.java.net/~hannesw/8166187/webrev.01/
> 
> Hannes
> 
>> Am 23.12.2016 um 12:20 schrieb Hannes Wallnöfer 
>> :
>> 
>> Thanks Attila, I had forgotten cached AST is not just a performance feature.
>> 
>> I uploaded a new webrev. It pretty much follows your suggestions, except I 
>> used a slightly different approach to conditional serialization of cachedAst 
>> - I left the field transient and serialize it explicitly if it is an 
>> instance of SerializedAst, otherwise write out null. I also added a test 
>> case for split stored functions.
>> 
>> http://cr.openjdk.java.net/~hannesw/8170977/webrev.01/ 
>> 
>> Hannes
>> 
>> 
>>> Am 22.12.2016 um 16:48 schrieb Attila Szegedi :
>>> 
>>> Hm… cachedAst is essential for split functions; specifically if it contains 
>>> a SerializedAst, then its "byte[] serializedAst" field is essential. If 
>>> cachedAst is lost, we can reparse an unsplit function from source, but we 
>>> can’t reparse fragments of split functions.
>>> 
>>> I’d suggest instead of making cachedAst transient, we should:
>>> 1. make SerializedAst Serializable, and have SerializedAst.cachedAst within 
>>> it transient (reference objects aren’t serializable, and we can afford to 
>>> lose it anyway).
>>> 2. introduce RecompilableScriptFunctionData.writeObject and make sure that 
>>> if serializedAst contains a reference (instead of a SerializedAst object) 
>>> then we don’t attempt to serialize it — write null instead (this can be 
>>> accomplished by just setting serializedAst = null, and maybe re-setting it 
>>> back to what it was after defaultWriteObject)
>>> 3. make sure there’s a null check on SerializedAst.cachedAst read in 
>>> getCachedAst() (as now it can actually be null on deserialization, it was 
>>> an invariant that it was never null before)
>>> 
>>> Attila.
>>> 
 On 22 Dec 2016, at 16:18, Hannes Wallnöfer  
 wrote:
 
 Please review: 
 
 Bug: https://bugs.openjdk.java.net/browse/JDK-8166187
 Webrev: http://cr.openjdk.java.net/~hannesw/8166187/webrev/
 
 It was actually the combination of having a non-serialisable AST reference 
 and not initialising the transient fields of nested functions that caused 
 this error.
 
 Thanks,
 Hannes
>>> 
>> 
> 

Re: RFR 8172493: Nashorn FX example 3-4 using load for fx: scripts fails to run with latest jdk9 ea build

[Jim Laskey (Oracle)]

+1

> On Jan 10, 2017, at 4:45 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8172493/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8172493
> 
> PS. I've not added an automated test because of javafx dependency [and the 
> tests need to be run on openjdk builds as well]. I manually tested the fix 
> using --patch-module option to replace build's nashorn classes with those of 
> nashorn repo with the fix. The test shows the javafx window with a button as 
> expected.
> 
> Thanks,
> -Sundar

Re: Minor discepancy for multiline regexps

[Jim Laskey (Oracle)]

Bug filed on your behalf.  https://bugs.openjdk.java.net/browse/JDK-8172353 


— Jim




> On Jan 6, 2017, at 7:27 AM, Esben Andreasen  wrote:
> 
> Hi
> 
> I stumbled upon a minor discrepancy between Nashorn and other
> JavaScript engines when doing regexp matching with the multiline flag
> enabled.
> 
> Nashorn
> ```
> $ jjs -version
> nashorn 1.8.0_111
> jjs> String.prototype.replace.apply("a\nb\rc\n\rd\r\ne", [/^(.*)/gm,"*$1"]);
> *a
> *c
> **
> *e
> ```
> 
> Notice that the characters 'b' and 'd' are gone from the output.
> 
> Node:
> ```
> $ node --version
> v5.5.0
> $ node
>> String.prototype.replace.apply("a\nb\rc\n\rd\r\ne", [/^(.*)/gm,"*$1"]);
> '*a\n*b\r*c\n*\r*d\r*\n*e'
> ```
> 
> Firefox & Chrome console:
> ```
>> String.prototype.replace.apply("a\nb\rc\n\rd\r\ne", [/^(.*)/gm,"*$1"]);
> "*a
> *b
> *c
> *
> *d
> *
> *e"
> ```
> 
> Notice that the characters 'b' and 'd' are in the output.
> 
> -
> 
> I suspect the cause is that nashorn does treat the character after
> '\r' as being at the start of a line.
> 
> -
> Esben

Re: RFR 8164391: Provide a javadoc description for jdk.scripting.nashorn

[Jim Laskey (Oracle)]

+1

> On Jan 4, 2017, at 7:25 AM, Attila Szegedi  wrote:
> 
> +1
> 
>> On 04 Jan 2017, at 11:40, Sundararajan Athijegannathan 
>>  wrote:
>> 
>> Please review http://cr.openjdk.java.net/~sundar/8164391/webrev.00/ for 
>> https://bugs.openjdk.java.net/browse/JDK-8164391
>> 
>> Thanks,
>> -Sundar
> 

Re: RFR 8172183: Provide a javadoc description for jdk.dynalink module

[Jim Laskey (Oracle)]

+1

> On Jan 3, 2017, at 1:17 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8172183/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8172183
> 
> Piggybacking couple of README cleanups in nashorn repo.
> 
> Thanks,
> -Sundar

Re: Review request for JDK-8171849: Collection and Queue conversions not prioritized for Arrays

[Jim Laskey (Oracle)]

+1

> On Dec 22, 2016, at 12:32 PM, Attila Szegedi  wrote:
> 
> Please review JDK-8171849 "Collection and Queue conversions not prioritized 
> for Arrays" at  for 
> 
> 
> Thanks,
>  Attila.

Re: RFR: 8166187: Regression: NPE during reparse when using persistent code cache and optimistic types

[Jim Laskey (Oracle)]

+1

> On Dec 22, 2016, at 11:18 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review: 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166187
> Webrev: http://cr.openjdk.java.net/~hannesw/8166187/webrev/
> 
> It was actually the combination of having a non-serialisable AST reference 
> and not initialising the transient fields of nested functions that caused 
> this error.
> 
> Thanks,
> Hannes

Re: RFR: 8170977: SparseArrayData should not grow its underlying dense array data

[Jim Laskey (Oracle)]

+1

> On Dec 22, 2016, at 11:15 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170977
> Webrev: http://cr.openjdk.java.net/~hannesw/8170977/webrev/
> 
> With this we keep whatever is already allocated as dense array but do not 
> grow it up to the dense array length limit internally. I also reduced the max 
> dense array length as with 1 million dense elements we still risk to be very 
> wasteful with memory.
> 
> Thanks,
> Hannes

Re: RFR 8171503: Nashorn build, test failures with the latest jdk9-dev forest - javadoc target and test target fail

[Jim Laskey (Oracle)]

+1

> On Dec 20, 2016, at 9:36 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8171503/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8171503
> 
> Thanks,
> -Sundar

Re: RFR: 8171219: Missing checks in sparse array shift() implementation

[Jim Laskey (Oracle)]

+1

> On Dec 15, 2016, at 6:48 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8171219
> Webrev: http://cr.openjdk.java.net/~hannesw/8171219/webrev/
> 
> This fixes a number of bugs around the Array.prototype.shift on sparse array 
> data (and its underlying dense data). Unlikely as it may seem, all these 
> issues where exposed by the short test script included in this webrev:
> 
> - UntouchedArrayData did not convert to a real ArrayData instance when 
> ensuring place for first element (index 0)
> - Dense array data did not check their size before trying System.arraycopy in 
> shiftLeft
> - Dense array data did not set the new length in shiftLeft, thereby leaving 
> empty slots
> - Sparse array data did not ensure space in the underlying dense array when 
> moving elements from sparse to dense in shiftLeft
> - Sparse array data did not delete new in-between elements when moving 
> elements from sparse to dense in shiftLeft
> - Sparse array data did not set the length after shrinking underlying dense 
> data in shiftRight, thereby creating new empty slots
> - DeletedRangeArrayData could not return the underlying data if it turned 
> empty in shiftLeft, causing problems later on.
> 
> I also moved the invocation of ensure() on the underlying dense array from 
> SparseArrayData.ensure() to where it is actually required, which is cleaner 
> and safe since underlying is a private field.
> 
> Thanks,
> Hannes

Re: Can't get Multithreaded Nashorn uses to Scale

[Jim Laskey (Oracle)]

\"profileIconId\": 950,\n" +
> "\"level\": 30,\n" +
> "\"expPoints\": 139,\n" +
> "\"infPoints\": 208789,\n" +
> "\"revisionDate\": 1480804396000\n" +
> "  },\n" +
> "  {\n" +
> "\"id\": 1373229,\n" +
> "\"accountId\": 1358441,\n" +
> "\"name\": \"AbsoluteDeath\",\n" +
> "\"profileIconId\": 7,\n" +
> "\"level\": 30,\n" +
> "\"expPoints\": 34,\n" +
> "\"infPoints\": 223655,\n" +
> "\"revisionDate\": 1471867646000\n" +
> "  },\n" +
> "  {\n" +
> "\"id\": 7694972,\n" +
> "\"accountId\": 204803668,\n" +
> "\"name\": \"ac pnp\",\n" +
> "\"profileIconId\": 937,\n" +
> "\"level\": 30,\n" +
> "\"expPoints\": 161,\n" +
> "\"infPoints\": 249681,\n" +
> "\"revisionDate\": 1480801507000\n" +
> "  },\n" +
> "  {\n" +
> "\"id\": 1373524,\n" +
> "\"accountId\": 1350474,\n" +
> "\"name\": \"Abdüü\",\n" +
> "\"profileIconId\": 1301,\n" +
> "\"level\": 30,\n" +
> "\"expPoints\": 103,\n" +
> "\"infPoints\": 286803,\n" +
> "\"revisionDate\": 1476621827000\n" +
> "  },\n" +
> "  {\n" +
> "\"id\": 1650227,\n" +
> "\"accountId\": 20503,\n" +
> "\"name\": \"AD Ambrosia\",\n" +
> "\"profileIconId\": 1152,\n" +
> "\"level\": 30,\n" +
> "\"expPoints\": 139,\n" +
> "\"infPoints\": 156333,\n" +
> "\"revisionDate\": 148080532\n" +
> "  },\n" +
> "  {\n" +
> "\"id\": 8331358,\n" +
> "\"accountId\": 205073925,\n" +
> "\"name\": \"acarmanyust2\",\n" +
> "\"profileIconId\": 0,\n" +
> "\"level\": 2,\n" +
> "\"expPoints\": 43,\n" +
> "\"infPoints\": 318,\n" +
> "\"revisionDate\": 1423915139000\n" +
> "  },\n" +
> "  {\n" +
> "\"id\": 1862106,\n" +
> "\"accountId\": 200139838,\n" +
> "\"name\": \"aboU\",\n" +
> "\"profileIconId\": 1155,\n" +
> "\"level\": 30,\n" +
> "\"expPoints\": 0,\n" +
> "\"infPoints\": 412616,\n" +
> "\"revisionDate\": 1480771055000\n" +
> "  },\n" +
> "  {\n" +
> "\"id\": 2362628,\n" +
> "\"accountId\": 685649,\n" +
> "\"name\": \"AcıFısTık\",\n" +
> "\"profileIconId\": 1074,\n" +
> "\"level\": 30,\n" +
> "\"expPoints\": 48,\n" +
> "\"infPoints\": 233882,\n" +
> "\"revisionDate\": 1480786233000\n" +
> "  },\n" +
> "  {\n" +
> "\"id\": 4323909,\n" +
> "\"accountId\": 2019

Re: Can't get Multithreaded Nashorn uses to Scale

[Jim Laskey (Oracle)]

Intersting.  The example you posted demonstrates this behaviour?  If so I’ll 
file a bug and dig in.  It sounds like an object is being reused across 
invocations and accumulating changes to the property map.

— Jim


> On Dec 6, 2016, at 5:12 PM, Jesus Luzon <jlu...@riotgames.com> wrote:
> 
> With more threads you are impacting the same 8 cores, so it will taper off 
> after 8 threads.  If it’s a 2x4 core machine then I can see 4 being a 
> threshold depending on System performance.  Transport: I meant if you were 
> using sockets to provide the script.  
> This makes sense. This one's on me then. 
>  
> So you are using the same invocable instance for all threads?  If so, then 
> you are probably good to go.  As far as leaks are concerned, not sure how you 
> would get leaks from Nashorn.  The JSON object is written in Java, and little 
> JavaScript involved.
>  
> In your example, pull up Invocable invocable = generateInvocable(script); out 
> of the loop and use the same invocable for all threads. 
> 
> We were using one invocable across all threads and we were getting slowdowns 
> on execution, high CPU Usage and memory leaks that led to OutOfMemory errors. 
> I could trace the leak to 
> jdk.nashorn.internal.objects.Global -> objectSpill Object[8] -> 
> jdk.nashorn.internal.scripts.JO4 -> arrayData 
> jdk.nashorn.internal.runtime.arrays.SparseArraysData -> underlying 
> jdk.nashorn.internal.runtime.arrays.DeletedArrayFilter
> which just keeps growing forever.
> 
> On Tue, Dec 6, 2016 at 6:30 AM, Jim Laskey (Oracle) <james.las...@oracle.com 
> <mailto:james.las...@oracle.com>> wrote:
> 
>> On Dec 6, 2016, at 9:56 AM, Jesus Luzon <jlu...@riotgames.com 
>> <mailto:jlu...@riotgames.com>> wrote:
>> 
>> The cost of creating a new engine is significant.  So share an engine across 
>> threads but use eval 
>> <https://docs.oracle.com/javase/7/docs/api/javax/script/ScriptEngine.html#eval(java.lang.String,%20javax.script.ScriptContext)>(String
>>  <https://docs.oracle.com/javase/7/docs/api/java/lang/String.html> script, 
>> ScriptContext 
>> <https://docs.oracle.com/javase/7/docs/api/javax/script/ScriptContext.html> 
>> context) instead, separate context per execution.  If your JavaScript code 
>> does not modify globals you can get away with using the same engine, same 
>> compiled script on each thread.
>> 
>> I guess there's a few things here I don't understand. One thing I'm trying 
>> to do is sharing a CompiledScript (which is why I'm using invocable). Also, 
>> what exactly does modify globals mean? All our filters do the same thing, 
>> make a function that takes a JSON String, turns it into a JSON, modifies it 
>> and then stringifies it back. No state is changed of anything else but there 
>> are temporary vars created inside the scope of the function. When we run 
>> this multithreaded, running invokeFunction slows down significantly and we 
>> get crazy memory leaks. 
> 
> So you are using the same invocable instance for all threads?  If so, then 
> you are probably good to go.  As far as leaks are concerned, not sure how you 
> would get leaks from Nashorn.  The JSON object is written in Java, and little 
> JavaScript involved.
> 
>> 
>> Of course there are many factors involved n performance.  How many cores do 
>> you have on the test machine?  How much memory in the process?  What 
>> transport are you using between threads?  That sort of thing.  Other than 
>> constructing then engine and context Nashorn performance should scale. 
>> I'm using an 8 core machine to test with 2.5Gs of RAM allocated to the 
>> process. Not sure what transports between threads means, but this is the 
>> code I'm benchmarking with. Increasing the number of threads actually makes 
>> it go faster until about 4 threads, then adding more threads takes the same 
>> amount to get to 1000 and and after a certain point it is just slower to get 
>> to 1000 counts. Some of our filters need to be able to run over 1000 times a 
>> second (across all threads) and the fastest time I could actually get with 
>> this was about 2.4 seconds for a 1000 counts.
>> ExecutorService executor = Executors.newFixedThreadPool(50);
>> AtomicLong count = new AtomicLong();
>> for (int i = 0; i < 50; i++) {
>> executor.submit(new Runnable() {
>> @Override
>> public void run() {
>> 
>> try {
>> Invocable invocable = generateInvocable(script);
>> while(true) {
&

Re: Can't get Multithreaded Nashorn uses to Scale

[Jim Laskey (Oracle)]

> On Dec 6, 2016, at 9:56 AM, Jesus Luzon <jlu...@riotgames.com> wrote:
> 
> The cost of creating a new engine is significant.  So share an engine across 
> threads but use eval 
> <https://docs.oracle.com/javase/7/docs/api/javax/script/ScriptEngine.html#eval(java.lang.String,%20javax.script.ScriptContext)>(String
>  <https://docs.oracle.com/javase/7/docs/api/java/lang/String.html> script, 
> ScriptContext 
> <https://docs.oracle.com/javase/7/docs/api/javax/script/ScriptContext.html> 
> context) instead, separate context per execution.  If your JavaScript code 
> does not modify globals you can get away with using the same engine, same 
> compiled script on each thread.
> 
> I guess there's a few things here I don't understand. One thing I'm trying to 
> do is sharing a CompiledScript (which is why I'm using invocable). Also, what 
> exactly does modify globals mean? All our filters do the same thing, make a 
> function that takes a JSON String, turns it into a JSON, modifies it and then 
> stringifies it back. No state is changed of anything else but there are 
> temporary vars created inside the scope of the function. When we run this 
> multithreaded, running invokeFunction slows down significantly and we get 
> crazy memory leaks. 

So you are using the same invocable instance for all threads?  If so, then you 
are probably good to go.  As far as leaks are concerned, not sure how you would 
get leaks from Nashorn.  The JSON object is written in Java, and little 
JavaScript involved.

> 
> Of course there are many factors involved n performance.  How many cores do 
> you have on the test machine?  How much memory in the process?  What 
> transport are you using between threads?  That sort of thing.  Other than 
> constructing then engine and context Nashorn performance should scale. 
> I'm using an 8 core machine to test with 2.5Gs of RAM allocated to the 
> process. Not sure what transports between threads means, but this is the code 
> I'm benchmarking with. Increasing the number of threads actually makes it go 
> faster until about 4 threads, then adding more threads takes the same amount 
> to get to 1000 and and after a certain point it is just slower to get to 1000 
> counts. Some of our filters need to be able to run over 1000 times a second 
> (across all threads) and the fastest time I could actually get with this was 
> about 2.4 seconds for a 1000 counts.
> ExecutorService executor = Executors.newFixedThreadPool(50);
> AtomicLong count = new AtomicLong();
> for (int i = 0; i < 50; i++) {
> executor.submit(new Runnable() {
> @Override
> public void run() {
> 
> try {
> Invocable invocable = generateInvocable(script);
> while(true) {
> invocable.invokeFunction("transform", 
> something);
> count.incrementAndGet();
> }
> } catch (NoSuchMethodException | ScriptException e) {
> e.printStackTrace();
> }
> }
> });
> }
> long lastTimestamp = System.currentTimeMillis();
> while(true) {
> 
> if (count.get() > 1000) {
> count.getAndAdd(-1000);
> System.out.println((System.currentTimeMillis() - 
> lastTimestamp)/1000.0);
> lastTimestamp = System.currentTimeMillis();
> }
> }

With more threads you are impacting the same 8 cores, so it will taper off 
after 8 threads.  If it’s a 2x4 core machine then I can see 4 being a threshold 
depending on System performance.  Transport: I meant if you were using sockets 
to provide the script.  

In your example, pull up Invocable invocable = generateInvocable(script); out 
of the loop and use the same invocable for all threads.

- Jim



> 
> On Tue, Dec 6, 2016 at 5:31 AM, Jim Laskey (Oracle) <james.las...@oracle.com 
> <mailto:james.las...@oracle.com>> wrote:
> 
>> On Dec 6, 2016, at 9:19 AM, Jesus Luzon <jlu...@riotgames.com 
>> <mailto:jlu...@riotgames.com>> wrote:
>> 
>> Hey Jim,
>> 
>> I looked at it and I will look into loadWithNewGlobal to see what exactly it 
>> does since it could be relevant. As for the rest, for my use case having 
>> threads in the JS would not help. We're using Nashorn to build JSON filters 
>> in a Dynamic Proxy Service and need any of the threads processing a request 
>> to be able to execute the script to filter.
> 
> The cost of creating a new engine is signif

Re: Can't get Multithreaded Nashorn uses to Scale

[Jim Laskey (Oracle)]

> On Dec 6, 2016, at 9:19 AM, Jesus Luzon <jlu...@riotgames.com> wrote:
> 
> Hey Jim,
> 
> I looked at it and I will look into loadWithNewGlobal to see what exactly it 
> does since it could be relevant. As for the rest, for my use case having 
> threads in the JS would not help. We're using Nashorn to build JSON filters 
> in a Dynamic Proxy Service and need any of the threads processing a request 
> to be able to execute the script to filter.

The cost of creating a new engine is significant.  So share an engine across 
threads but use eval 
<https://docs.oracle.com/javase/7/docs/api/javax/script/ScriptEngine.html#eval(java.lang.String,%20javax.script.ScriptContext)>(String
 <https://docs.oracle.com/javase/7/docs/api/java/lang/String.html> script, 
ScriptContext 
<https://docs.oracle.com/javase/7/docs/api/javax/script/ScriptContext.html> 
context) instead, separate context per execution.  If your JavaScript code does 
not modify globals you can get away with using the same engine, same compiled 
script on each thread.

> 
> Also, when you say a new engine per threads is the worst case what exactly do 
> you mean? I would expect an initial cost of compiling the script on each 
> thread and then each engine should be able to do its own thing, but what I'm 
> seeing is that when running with more than 10 threads all my engines get slow 
> at executing code, even though they are all completely separate from each 
> other.

Of course there are many factors involved n performance.  How many cores do you 
have on the test machine?  How much memory in the process?  What transport are 
you using between threads?  That sort of thing.  Other than constructing then 
engine and context Nashorn performance should scale. 

> 
> On Tue, Dec 6, 2016 at 5:07 AM, Jim Laskey (Oracle) <james.las...@oracle.com 
> <mailto:james.las...@oracle.com>> wrote:
> Jesus,
> 
> Probably the most informative information is in this blog.
> 
> https://blogs.oracle.com/nashorn/entry/nashorn_multi_threading_and_mt 
> <https://blogs.oracle.com/nashorn/entry/nashorn_multi_threading_and_mt>
> 
> This example uses Executors but threads would work as well.
> 
> I did a talk that looked at different methods to max out multithreading 
> performance.  A new engine per thread is the worst case.  A new context per 
> thread does much better.  A new global per thread is the best while remaining 
> thread safe.
> 
> Cheers,
> 
> — Jim
> 
> 
> 
> 
> 
>> On Dec 6, 2016, at 8:45 AM, Jesus Luzon <jlu...@riotgames.com 
>> <mailto:jlu...@riotgames.com>> wrote:
>> 
>> Hey folks,
>> 
>> I've tried many different ways of using Nashorn multithreaded based on what
>> I've found on the internet and I still can't get a single one to scale.
>> Even the most naive method of making many script engines with my script
>> tends to bottleneck itself when I have more than 10 threads invoking
>> functions.
>> 
>> I'm using the following code to compile my script and
>> invocable.invokeFunction("transform", input) to execute:
>> 
>>>static Invocable generateInvocable(String script) throws
>>> ScriptException {
>>>ScriptEngineManager manager = new ScriptEngineManager();
>>>ScriptEngine engine =
>>> manager.getEngineByName(JAVASCRIPT_ENGINE_NAME);
>>>Compilable compilable = (Compilable) engine;
>>>final CompiledScript compiled = compilable.compile(script);
>>>compiled.eval();
>>>return (Invocable) engine;
>>>}
>> 
>> 
>> The script I'm compiling is:
>> 
>>>String script = "function transform(input) {" +
>>>"var result = JSON.parse(input);" +
>>>"response = {};\n" +
>>>"for (var i = 0; i < result.length; i++) {\n" +
>>>"var summoner = {};\n" +
>>>"summoner.id <http://summoner.id/> = result[i].id;\n" +
>>>"summoner.name <http://summoner.name/> = 
>>> result[i].name;\n" +
>>>"summoner.profileIconId = result[i].profileIconId;\n" +
>>>"summoner.revisionDate = result[i].revisionDate;\n" +
>>>"summoner.summonerLevel = result[i].level;\n" +
>>>"response[summoner.id <http://summoner.id/>] = 
>>> summoner;\n" +
>>>"}\n" +
>>>"result = response;" +
>>>"return JSON.stringify(result);" +
>>>"};";
>> 
>> 
>> I've also tried other more scaleable ways to work with scripts
>> concurrently, but given that this is the most naive method where everything
>> is brand new and I still get slowness calling them concurrently I fear that
>> maybe I'm overlooking something extremely basic on my code.
>> 
>> Thanks.
>> -Jesus Luzon

Re: Can't get Multithreaded Nashorn uses to Scale

[Jim Laskey (Oracle)]

Jesus,

Probably the most informative information is in this blog.

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


This example uses Executors but threads would work as well.

I did a talk that looked at different methods to max out multithreading 
performance.  A new engine per thread is the worst case.  A new context per 
thread does much better.  A new global per thread is the best while remaining 
thread safe.

Cheers,

— Jim





> On Dec 6, 2016, at 8:45 AM, Jesus Luzon  wrote:
> 
> Hey folks,
> 
> I've tried many different ways of using Nashorn multithreaded based on what
> I've found on the internet and I still can't get a single one to scale.
> Even the most naive method of making many script engines with my script
> tends to bottleneck itself when I have more than 10 threads invoking
> functions.
> 
> I'm using the following code to compile my script and
> invocable.invokeFunction("transform", input) to execute:
> 
>>static Invocable generateInvocable(String script) throws
>> ScriptException {
>>ScriptEngineManager manager = new ScriptEngineManager();
>>ScriptEngine engine =
>> manager.getEngineByName(JAVASCRIPT_ENGINE_NAME);
>>Compilable compilable = (Compilable) engine;
>>final CompiledScript compiled = compilable.compile(script);
>>compiled.eval();
>>return (Invocable) engine;
>>}
> 
> 
> The script I'm compiling is:
> 
>>String script = "function transform(input) {" +
>>"var result = JSON.parse(input);" +
>>"response = {};\n" +
>>"for (var i = 0; i < result.length; i++) {\n" +
>>"var summoner = {};\n" +
>>"summoner.id = result[i].id;\n" +
>>"summoner.name = result[i].name;\n" +
>>"summoner.profileIconId = result[i].profileIconId;\n" +
>>"summoner.revisionDate = result[i].revisionDate;\n" +
>>"summoner.summonerLevel = result[i].level;\n" +
>>"response[summoner.id] = summoner;\n" +
>>"}\n" +
>>"result = response;" +
>>"return JSON.stringify(result);" +
>>"};";
> 
> 
> I've also tried other more scaleable ways to work with scripts
> concurrently, but given that this is the most naive method where everything
> is brand new and I still get slowness calling them concurrently I fear that
> maybe I'm overlooking something extremely basic on my code.
> 
> Thanks.
> -Jesus Luzon

Re: Review request for JDK-8170594: >>>=0 generates invalid bytecode for BaseNode LHS

[Jim Laskey (Oracle)]

+1

> On Dec 1, 2016, at 9:19 AM, Attila Szegedi  wrote:
> 
> Please review JDK-8170594 ">>>=0 generates invalid bytecode for BaseNode LHS" 
> at  for 
> 
> 
> Thanks,
>  Attila.

Re: RFR 8170565: JSObject call() is passed undefined for the argument 'thiz'

[Jim Laskey (Oracle)]

+1

> On Dec 1, 2016, at 8:48 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Good catch Hannes! Please review the updated webrev : 
> http://cr.openjdk.java.net/~sundar/8170565/webrev.01/
> 
> PS. Had to use Function.prototype.call.call to pass undefined this explicitly 
> (as JSObject.call can't be called from script).
> 
> -Sundar
> 
> On 01/12/16, 3:13 PM, Hannes Wallnöfer wrote:
>> Hi Sundar,
>> 
>> The problem with this approach is that it will replace any occurrence of 
>> undefined this with the global object. However, this should only occur for 
>> scope calls. For example, the following call would see undefined replaced 
>> with global:
>> 
>> func.call(undefined)
>> 
>> This is probably not a problem that will occur very often, but ideally I 
>> think we should do the check and replacement on the linking side, i.e. in 
>> JSObjectLinker.findCallMethod.
>> 
>> On the other hand we can’t check for function strictness that way. Maybe do 
>> it your way but add a boolean isScope parameter and bind that at link time?
>> 
>> Hannes
>> 
>> 
>>> Am 01.12.2016 um 07:21 schrieb Sundararajan 
>>> Athijegannathan:
>>> 
>>> Please review http://cr.openjdk.java.net/~sundar/8170565/webrev.00/ for 
>>> https://bugs.openjdk.java.net/browse/JDK-8170565
>>> 
>>> Thanks,
>>> -Sundar

Re: 8130351: JDK-8130127.js fails under cygwin: cygwin path pased to Java

[Jim Laskey (Oracle)]

+1

> On Nov 30, 2016, at 2:11 PM, Srinivas Dama  wrote:
> 
> Hi,
> 
> Please review http://cr.openjdk.java.net/~sdama/8130351/webrev.02/ 
> for https://bugs.openjdk.java.net/browse/JDK-8130351 
> 
> Note: I cannot reproduce the errors mentioned in the bug. But I do see some 
> other kind of issue related to $EXEC.
> Moved test files from currently-failing directory to nosecurity directory to 
> include them in test run and added fix for $EXEC issue.
> Fix is adding '\n' to interactive input as jline used by jjs expects it.
> 
> Regards,
> Srinivas

Re: RFR 8170402: Compilation warning with NashornException

[Jim Laskey (Oracle)]

+1

> On Nov 28, 2016, at 11:17 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8170402/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8170402
> 
> Thanks,
> -Sundar
> 

Re: RFR: 8161579: Array-like AbstractJSObject-based instance not treated as array by native array functions

[Jim Laskey (Oracle)]

+1

> On Nov 25, 2016, at 11:19 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review: 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8161579
> Webrev: http://cr.openjdk.java.net/~hannesw/8161579/webrev/
> 
> Thanks,
> Hannes

Re: RFR: 8170322: Specialized functions convert booleans to numbers

[Jim Laskey (Oracle)]

+1

> On Nov 25, 2016, at 7:52 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review: 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170322
> Webrev: http://cr.openjdk.java.net/~hannesw/8170322/webrev/
> 
> This adds a new „convertsNumericArgs“ property to the SpecializedFunction 
> annotation that defines whether it is safe to convert non-numeric arguments 
> for this function to numbers. This is used at link time to decide whether the 
> specialised function can be used with a boolean parameter. I also removed a 
> few specialised functions with long parameters which are no longer in use.
> 
> Thanks,
> Hannes

Re: RFR 8170099: Nashorn test failures with stricter reflection access checks in jake forest

[Jim Laskey (Oracle)]

+1

> On Nov 21, 2016, at 10:14 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8170099/webrev.00/ for 
> https://bugs.openjdk.java.net/browse/JDK-8170099
> 
> Thanks,
> -Sundar

Re: RFR: 8162839: JavaAdapters do not work with ScriptObjectMirror objects

[Jim Laskey (Oracle)]

+1

> On Nov 17, 2016, at 7:11 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Looks good!
> 
> PS. Would be nice if we have with security manager test (perhaps .js
> test?) that exercises ScriptObjectMirror to adapter conversion. But, no
> biggie..
> 
> -Sundar
> 
> 
> On 11/16/2016 8:43 PM, Hannes Wallnöfer wrote:
>> Please review:
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8162839
>> Webrev: http://cr.openjdk.java.net/~hannesw/8162839/webrev.00/
>> 
>> This makes JavaAdapters work with ScriptObjectMirrors in addition to 
>> ScriptObjects and ScriptFunctions.
>> 
>> A few notes:
>> - NashornLinker.getSamTypeConverter now gets the constructor with 
>> Object.class extra parameter if sourceType is more generic than 
>> ScriptFunction.class. However, this really is an OverloadedMethod 
>> constructor, so the ScriptFunction constructor will be called if the 
>> argument happens to be a ScriptFunction.
>> - Unfortunately the only way to get at the ScriptObject and Global of a 
>> ScriptObjectMirror is to use reflection, making the fields accessible. Since 
>> ScriptObjectMirror is in a package that’s exported to the world we can’t add 
>> public getters. Field accessors are created lazily and cached in 
>> JavaAdapterServices.MirrorFieldHolder.
>> - When writing the test for this I noticed that some of our java tests are 
>> not run in „ant run“. I added the missing test packages to build.xml.
>> - This contains cleanup for indentation in 
>> JavaAdapterByteCodeGenerator.java. That class had wrong indentation in 
>> various places.
>> 
>> Thanks,
>> Hannes
> 

Re: RFR 8169050: underscore_linker.js sample fails after dynalink changes for JDK-8168005

[Jim Laskey (Oracle)]

+1

> On Nov 2, 2016, at 9:38 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8169050/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8169050
> 
> PS. The failing sample exposed a bug in nashorn's
> NashornCallSiteDescriptor.  I converted that sample as a test.
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR: 8148924: Inconsistent "this" context in JSAdapter adaptee function calls

[Jim Laskey (Oracle)]

+1

> On Oct 25, 2016, at 11:45 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8148924
> Webrev: http://cr.openjdk.java.net/~hannesw/8148924/webrev/
> 
> Thanks,
> Hannes

Re: RFR 8071678: javax.script.ScriptContext setAttribute method should clarify behavior when GLOBAL_SCOPE is used and global scope object is null

[Jim Laskey (Oracle)]

+1

> On Oct 18, 2016, at 8:36 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8071678/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8071678
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

[Jim Laskey (Oracle)]

+1

> On Oct 12, 2016, at 12:11 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167614
> 
> jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/
> 
> nashorn webrev:
> http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8167018: Nashorn and jjs should support --module-path and --add-modules options

[Jim Laskey (Oracle)]

+1

> On Oct 7, 2016, at 10:16 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8167018
> Nashorn webrev: http://cr.openjdk.java.net/~sundar/8167018/nashorn/webrev.00/
> JDK webrev (jjs tests): 
> http://cr.openjdk.java.net/~sundar/8167018/jdk/webrev.00/
> 
> Thanks,
> -Sundar

Re: Review request for JDK-8167117: insert missing final keywords

[Jim Laskey (Oracle)]

+1

> On Oct 4, 2016, at 3:36 PM, Attila Szegedi  wrote:
> 
> Please review JDK-8167117 "insert missing final keywords" at 
>  for 
> 
> 
> Every year or so, this is done once as a kind of anti-entropy task :-)
> It’s a big patch, but it’s just mechanical addition of missing “final” 
> keywords everywhere (and organizing imports in only few files); tests were 
> run afterwards.
> 
> I have few other things in the pipeline, but my diffs were getting noisy 
> because of my IDE inserting all the missing “final” keywords in the files I 
> touched, so wanted to get this out of the way in one swoop.
> 
> Thanks,
>  Attila.

Re: RFR: 8077149: __noSuchProperty__ and __noSuchMethod__ invocations are not properly guarded

[Jim Laskey (Oracle)]

+1


> On Sep 7, 2016, at 12:58 PM, Hannes Wallnöfer  
> wrote:
> 
> Please review 8077149: __noSuchProperty__ and __noSuchMethod__ invocations 
> are not properly guarded.
> 
> Webrev: http://cr.openjdk.java.net/~hannesw/8077149/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8077149
> 
> Thanks,
> Hannes

Re: ZBB List for our group

[Jim Laskey (Oracle)]

Try 

(assignee = jlaskey OR assignee = sundar OR assignee = hannesw OR assignee = 
mhaupt OR assignee = sdama) AND project = JDK AND issuetype = Bug AND status in 
(Open, "In Progress", New) AND priority in (P1, P2, P3) AND (fixVersion in (9) 
OR fixVersion is EMPTY AND affectedVersion in (9) AND affectedVersion not in 
regexVersion("8.*", "7.*", "6.*")) AND (labels is EMPTY OR labels not in 
(jdk9-defer-request, noreg-demo, noreg-doc, noreg-self)) AND component not in 
(docs, globalization, infrastructure) ORDER BY status DESC, assignee DESC, 
priority, component, subcomponent





> On Sep 6, 2016, at 11:20 AM, Jim Laskey (Oracle) <james.las...@oracle.com> 
> wrote:
> 
> https://bugs.openjdk.java.net/issues/?filter=28851=(assignee%20%3D%20jlaskey%20OR%20assignee%20%3D%20sundar%20OR%20assignee%20%3D%20hannesw%20OR%20assignee%20%3D%20mhaupt%20OR%20assignee%20%3D%20sdama)%20AND%20project%20%3D%20JDK%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20New)%20AND%20priority%20in%20(P1%2C%20P2%2C%20P3)%20AND%20(fixVersion%20in%20(9)%20OR%20fixVersion%20is%20EMPTY%20AND%20affectedVersion%20in%20(9)%20AND%20affectedVersion%20not%20in%20regexVersion(%228.*%22%2C%20%227.*%22%2C%20%226.*%22))%20AND%20(labels%20is%20EMPTY%20OR%20labels%20not%20in%20(jdk9-defer-request%2C%20noreg-demo%2C%20noreg-doc%2C%20noreg-self))%20AND%20component%20not%20in%20(docs%2C%20globalization%2C%20infrastructure)%20ORDER%20BY%20status%20DESC%2C%20assignee%20DESC%2C%20priority%2C%20component%2C%20subcomponent
> 

Re: RFR 8164748: Edit pad crashes when calling function

[Jim Laskey (Oracle)]

+1

> On Aug 25, 2016, at 1:43 PM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8164748/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8164748
> 
> Thanks,
> 
> -Sundar
> 

Re: Type specialization / recompilation of functions using "arguments"

[Jim Laskey (Oracle)]

Axel,

I’ve created a bug to track.  May be slow to process because of vacations and 
JDK9 long march.

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

Cheers,

— Jim


> On Aug 19, 2016, at 11:41 AM, Axel Faust  wrote:
> 
> Hello,
> 
> in my ongoing project to implement an alternative scripting integration to
> the ECM platform Alfresco using Nashorn, I recently ran into a performance
> issue due to constructor / function recompilation due to type
> specialization, particularly if the constructor / function in question is
> accessing the "arguments" object.
> 
> I have tried to simplify this with a test and used "jjs
> --log=recompile:finest" to run it.
> 
> Consider the following script:
> 
> function testArguments() { print(JSON.stringify(arguments)); }
> // simple call tests
> testArguments('test1'); // first access => 2x "parameter type
> specialization"
> testArguments('test1'); // identical parameter => no recompilation
> testArguments('test2'); // identical param type, different value =>
> "parameter type specialization"
> testArguments('test3'); // identical param type, different value =>
> "parameter type specialization"
> // iterative call test
> for (var i = 0; i < 1000; i++) { testArguments('test' + i); } // identical
> param type, different values => only one "parameter type specialization"
> 
> 
> Now I don't quite understand why script function "testArguments" needs to
> be recompiled on each call with the same parameter type but different
> value, and how this is not required when executed within a loop structure.
> The latter is interesting on another level, since a test script for my
> Alfresco-Nashorn integration is running an array-forEach loop where the
> called function is being recompiled on every iteration, while replacing the
> for-loop in the test script above with an array-forEach (pre-filled)
> behaves exactly the same as the for-loop with only a single recompilation.
> Additionally, in the integration test script I even see recompilations for
> identical values (in subsequent runs of the same script).
> 
> Now having a single recompilation wouldn't be so bad, but continous
> recompilation hurts quite a bit. Unfortunately this affects quite a central
> piece in my integration project and thus causes significant overhead via
> ClassLoader.defineClass, Class.getDeclaredFields and method handle / call
> site handling operations that result from the recompilation. Each run of my
> integration-specific test script adds ~10 CompiledFunction instances to the
> ScriptFunctionData.code list for the same function (all with apparently
> identical call site types and invokers, at least judging from
> toString-representations). The persistent code cache doesn't seem to be
> used at all as RecompilableScriptFunctionData.getBest calls
> compileTypeSpecialization in a way that disables its use.
> 
> Is this behaviour something that should be considered "expected" or is it a
> "real" performance bug? If it is expected, is there a general
> recommendation not to use functions that access arguments for
> performance-critical code?
> (I tested with JDK 8u71 and JDK 9 ea+125 - behaviour is the same except JDK
> 9 provides deoptimization log output on 1st call)
> 
> Regards
> Axel Faust

Re: RFR 8164260: readLine does not echo characters

[Jim Laskey (Oracle)]

+1

> On Aug 18, 2016, at 6:04 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8164260/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8164260
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR 8164216: Netbeans makefile for nashorn should use JDK_9 as platform

[Jim Laskey (Oracle)]

+1

> On Aug 17, 2016, at 10:45 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8164216/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8164216
> 
> -Sundar
> 

Re: RFR: 8068972: Array.splice should follow the ES6 specification

[Jim Laskey (Oracle)]

+1

> On Jul 21, 2016, at 12:19 PM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Webrev: http://cr.openjdk.java.net/~hannesw/8068972/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8068972
> 
> This updates the implementation of Array.prototype.splice to conform with ES6 
> when called with a single argument.
> 
> Hannes

Re: RFR: 8073653: Secondary heredoc eating wrong lines.

[Jim Laskey (Oracle)]

+1

> On Jun 24, 2016, at 8:23 AM, Hannes Wallnöfer  
> wrote:
> 
> Please review:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8073653
> Webrev: http://cr.openjdk.java.net/~hannesw/8073653/webrev.00/
> 
> I don’t think there is a formal spec for heredoc out there, so I used 
> documentation from other scripting languages as a guide.
> 
> Hannes

Re: Share context/JS bindings

[Jim Laskey (Oracle)]

Tony,

We will keep this general issue open as 
https://bugs.openjdk.java.net/browse/JDK-8160103 and revisit later on.

— Jim



> On Jun 21, 2016, at 11:41 PM, Tony Zakula  wrote:
> 
> Thank you for looking into this.  Much appreciated.  We are working on a
> large Nashorn project we hope to share soon.
> On Jun 21, 2016 8:33 AM, "Hannes Wallnöfer" 
> wrote:
> 
>> Unfortunately, there is a problem with invalidation of callsites that
>> Sundar brought up in the review thread for the issue I filed.
>> 
>> I’ve thought about it, but there isn’t any easy way to do this without
>> giving up significant benefits on the other side. I’m closing the issue as
>> „won’t fix“, but I’ll continue thinking about a solution for quicker
>> creation of global objects.
>> 
>> Hannes
>> 
>> 
>>> Am 16.06.2016 um 21:11 schrieb Tony Zakula :
>>> 
>>> Thank you Hannes.  That would be great.  We have tried using clear
>> before too.
>>> 
>>> @Axel - Thank you for the stats.  Interesting to see that.  One thing we
>> did was use strict mode and use Immediate Functions.  This would keep
>> variables going to global scope I think.
>>> 
>>> Thanks,
>>> 
>>> Tony
>>> 
>>> On Wed, Jun 15, 2016 at 8:02 AM, Hannes Wallnöfer <
>> hannes.wallnoe...@oracle.com> wrote:
>>> I prototyped the proposed change to the clear() method. It seems to work
>> well and makes a lot of sense to me, so I filed a bug for it:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8159589
>>> 
>>> I haven’t discussed this with the other team members yet, so let’s see
>> what they think.
>>> 
>>> Hannes
>>> 
>>> 
 Am 15.06.2016 um 11:24 schrieb Axel Dörfler :
 
 Am 14.06.2016 um 22:09 schrieb Tony Zakula:
> Interesting.  We use on global context and create a new engine context
> with each run.  The initial compile of several scripts is over 100ms,
> but then we see that drop to under 10ms.  The context creation seems
>> to
> have very little overhead.  We have not timed that specifically
>> though,
> just total process time.
 
 In my special use case which was a very short JavaScript that was used
>> as Comparator, actual execution time was very short, so the impact of the
>> optimizations were pretty obvious.
 Sorting about 15000 entries took way over 10 minutes before any
>> optimization. IIRC after using a single global engine this dropped to about
>> 2 minutes. After also reusing the JS context, it went down to 10 seconds.
 
 Bye,
  Axel.
 
>>> 
>>> 
>> 
>> 

Re: RFR 8159034: 4 nashorn ant tests fail with latest jdk9-dev build with IncompatibleClassChangeError

[Jim Laskey (Oracle)]

+1

> On Jun 8, 2016, at 9:01 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8159034/webrev.00/ for
> https://bugs.openjdk.java.net/browse/JDK-8159034
> 
> No new regression test added as there are already tests cover calling
> inherited default methods on interfaces.
> 
> Thanks,
> 
> -Sundar
> 

Re: RFR:DK-8148457(Remove jdk.nashorn.tools.FXShell class and associated build.xml cruft)

[Jim Laskey (Oracle)]

+1

> On Jun 3, 2016, at 9:39 AM, Srinivas Dama  wrote:
> 
> Hi,
> 
> Please review:
> http://cr.openjdk.java.net/~sdama/8148457/webrev.00/ 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8148457 
> 
> I have verified all debug logs generated out of make targets for jdk9 forest 
> build and 
> nashorn ant targets.
> 
> Regards,
> Srinivas

Re: RFR(S) 8158338: Nashorn's ScriptLoader split delegation has to adjusted

[Jim Laskey (Oracle)]

+1

> On Jun 1, 2016, at 6:14 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> I had to update webrev to handle the case of appLoader being null in
> ScriptLoader. I had used Class.forName(String, boolean, ClassLoader).
> But that methods introduces a security check when caller is not
> bootstrap (like nashorn) and ClassLoader is null! In any case,
> bootloader delegation has already happened via parent delegation. So,
> I'm checking and handling appLoader null case by throwing
> ClassNotFoundException.
> 
> Updated webrev: http://cr.openjdk.java.net/~sundar/8158338/webrev.01/
> 
> -Sundar
> 
> On 6/1/2016 12:59 PM, Sundararajan Athijegannathan wrote:
>> Hi,
>> 
>> Thanks for the review.
>> 
>> We have an existing test that depends on "split" delegation implemented
>> in the ScriptLoader.
>> 
>> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/7fb2bf00347b/test/script/basic/JDK-8024619.js
>> 
>> The current code adjustment is about which loader is "parent" and which
>> one "side" delegatee. Previously, parent was Context's appLoader and
>> side-delegatee was the structure loader.
>> Now, it is other way around. But, the behavior seen from scripts should
>> remain same in either case. The aforementioned test (along with other
>> nashorn tests) passes with the adjusted
>> delegation setup as well.
>> 
>> -Sundar
>> 
>> On 6/1/2016 12:49 PM, Marcus Lagergren wrote:
>>> This looks good. Is it possible to test it?
>>> 
>>> /M
>>> 
 On 01 Jun 2016, at 08:46, Sundararajan Athijegannathan 
  wrote:
 
 Please review http://cr.openjdk.java.net/~sundar/8158338/webrev.00/ for
 https://bugs.openjdk.java.net/browse/JDK-8158338
 
 Thanks,
 
 -Sundar
 
> 

Re: [8u] approval request for 8157160: JSON.stringify does not work on ScriptObjectMirror objects

[Jim Laskey (Oracle)]

+1

> On May 20, 2016, at 11:51 AM, Sundararajan Athijegannathan 
>  wrote:
> 
> Please approve.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8157160
> 
> 9 review thread:
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-May/006179.html
> 
> 8u webrev: http://cr.openjdk.java.net/~sundar/8157160/8u/webrev.00/
> 
> The patch wouldn't apply "as is" because of slight difference in
> dynalink/Bootstrap code. I'm CC'ing this email to nashorn-dev as well
> for backport review.
> 
> Thanks,
> 
> -Sundar
> 
>