From lagergren at gmail.com  Tue Sep  1 07:14:09 2015
From: lagergren at gmail.com (Marcus Lagergren)
Date: Tue, 1 Sep 2015 09:14:09 +0200
Subject: Review request for JDK-8133300: Ensure symbol table immutability
	in Nashorn AST
In-Reply-To: <C96FE3F0-0910-4CBB-B7C6-617D77DEF62A@oracle.com>
References: <1FF60D9D-02BC-45C1-A949-2947C5B03C01@oracle.com>
	<D63C61AD-E5E4-4E11-A7DE-35DB4968F7EC@lagergren.net>
	<9799463A-0862-4FCE-9C4E-D1C3E36B1665@oracle.com>
	<C96FE3F0-0910-4CBB-B7C6-617D77DEF62A@oracle.com>
Message-ID: <DFFE9620-6089-4B51-90E4-4C96B96380F5@lagergren.net>

Reviewed new webrev. Happy +1

/M

> On 31 Aug 2015, at 12:09, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> I posted another webrev, can you please review: http://cr.openjdk.java.net/~attila/8133300/webrev.01.jdk9 <http://cr.openjdk.java.net/~attila/8133300/webrev.01.jdk9>
> The only changes are:
> - added JavaDoc comments explaining SerializedAst class, as per Marcus? suggestion
> - external symbols? re-marking as global now only happens for non-cached split functions (previously, it happened for all non-cached functions). Other functions will already have external symbols marked as globals, as they?re coming from a lazy compilation.
> 
> Thanks,
>  Attila.
> 
>> On Aug 31, 2015, at 10:58 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>> 
>> if the FunctionNode object is set as the cached representation of a RecompilableScriptFunctionData using its setCached method, its IS_CACHED flag is set to true. The flag is used in recompilation to determine the necessary compilation phases: if the function is cached, it means phases in Compiler.COMPILE_UPTO_CACHED were already run on it, so they don't need to be repeated. Otherwise the function is freshly reparsed, so the full compiler pipeline needs to be re-run.
>> 
>> There?s also the issue of re-marking external symbols as globals in RecompilableScriptFunctionData.cloneSymbols(). We normally don?t have to do that ? I implemented that back when I was caching pre-pass ASTs. Now that we're only caching AST resulting from lazy compilation, we don't really need it except for split functions, which are incidentally cached from the eager pass :-)
>> 
>> When we lazily compile a function from scratch, all symbols outside of it are considered global (since AssignSymbols won't find them in the enclosing lexical scope, as the enclosing source text is not reparsed). OTOH, if we cache a FunctionNode resulting from the eager first pass, it will have the full lexical scope, so those symbols won't be marked as "global" (which is rather a misnomer at the moment and should be instead considered ?external? instead). We need the cached AST and a lazily parsed AST to be identical though, otherwise things break down further down the line.
>> 
>> Split functions are cached from eager pre-pass (and before they were serialized from eager pre-pass). They didn't suffer from this problem though as AssignSymbols was re-run every time after deserialization. Now however, I moved AssignSymbols to be a pre-cache phase.
>> 
>> I'll modify the code though so that this marking of external symbols only happens when we cache a split function.
>> 
>> Attila.
>> 
>>> On Aug 30, 2015, at 3:07 PM, Marcus Lagergren <marcus at lagergren.net> wrote:
>>> 
>>> Can you elaborate a bit on the isCached mechanism in FunctionNode?
>>> 
>>> /M
>>> 
>>>> On 26 Aug 2015, at 14:18, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>>> 
>>>> Please review JDK-8133300 "Ensure symbol table immutability in Nashorn AST" at <http://cr.openjdk.java.net/~attila/8133300/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8133300>
>>>> 
>>>> Implementation notes for reviewers are here: <https://bugs.openjdk.java.net/browse/JDK-8133300?focusedCommentId=13837384&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837384 <https://bugs.openjdk.java.net/browse/JDK-8133300?focusedCommentId=13837384&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837384>>
>>>> 
>>>> Thanks,
>>>> Attila.
>>> 
>> 
> 


From lagergren at gmail.com  Tue Sep  1 07:15:13 2015
From: lagergren at gmail.com (Marcus Lagergren)
Date: Tue, 1 Sep 2015 09:15:13 +0200
Subject: RFR 8134731: `Function.prototype.apply` interacts incorrectly
	with `arguments`
In-Reply-To: <55E43BFC.6080204@oracle.com>
References: <55E43BFC.6080204@oracle.com>
Message-ID: <50682D61-B4E9-4AAB-A5C0-C83C30544FB0@lagergren.net>

+1. Any regression on raytrace, though?

/M

> On 31 Aug 2015, at 13:35, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8134731/ for https://bugs.openjdk.java.net/browse/JDK-8134731
> 
> Thanks
> -Sundar


From attila.szegedi at oracle.com  Tue Sep  1 08:21:43 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 1 Sep 2015 10:21:43 +0200
Subject: RFR 8134731: `Function.prototype.apply` interacts incorrectly
	with `arguments`
In-Reply-To: <50682D61-B4E9-4AAB-A5C0-C83C30544FB0@lagergren.net>
References: <55E43BFC.6080204@oracle.com>
	<50682D61-B4E9-4AAB-A5C0-C83C30544FB0@lagergren.net>
Message-ID: <83B46E93-A9CB-436B-A83E-0A0E0575482D@oracle.com>

It can?t regress on raytrace, since raytrace uses:

    return function() {
      this.initialize.apply(this, arguments);
    }

that is, the function containing the transform declares no arguments.

Attila.

> On Sep 1, 2015, at 9:15 AM, Marcus Lagergren <lagergren at gmail.com> wrote:
> 
> +1. Any regression on raytrace, though?
> 
> /M
> 
>> On 31 Aug 2015, at 13:35, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>> 
>> Please review http://cr.openjdk.java.net/~sundar/8134731/ for https://bugs.openjdk.java.net/browse/JDK-8134731
>> 
>> Thanks
>> -Sundar
> 


From sundararajan.athijegannathan at oracle.com  Tue Sep  1 08:57:48 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 1 Sep 2015 14:27:48 +0530
Subject: RFR 8134731: `Function.prototype.apply` interacts incorrectly
	with `arguments`
In-Reply-To: <83B46E93-A9CB-436B-A83E-0A0E0575482D@oracle.com>
References: <55E43BFC.6080204@oracle.com>
	<50682D61-B4E9-4AAB-A5C0-C83C30544FB0@lagergren.net>
	<83B46E93-A9CB-436B-A83E-0A0E0575482D@oracle.com>
Message-ID: <55E5688C.70209@oracle.com>

Yes. And I manually inspected generated bytecode to make sure 
no-declared-param function case is handled by apply2call opt.

-Sundar

On 9/1/2015 1:51 PM, Attila Szegedi wrote:
> It can?t regress on raytrace, since raytrace uses:
>
>      return function() {
>        this.initialize.apply(this, arguments);
>      }
>
> that is, the function containing the transform declares no arguments.
>
> Attila.
>
>> On Sep 1, 2015, at 9:15 AM, Marcus Lagergren <lagergren at gmail.com> wrote:
>>
>> +1. Any regression on raytrace, though?
>>
>> /M
>>
>>> On 31 Aug 2015, at 13:35, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>>
>>> Please review http://cr.openjdk.java.net/~sundar/8134731/ for https://bugs.openjdk.java.net/browse/JDK-8134731
>>>
>>> Thanks
>>> -Sundar


From lagergren at gmail.com  Tue Sep  1 10:21:41 2015
From: lagergren at gmail.com (Marcus Lagergren)
Date: Tue, 1 Sep 2015 12:21:41 +0200
Subject: RFR 8134731: `Function.prototype.apply` interacts incorrectly
	with `arguments`
In-Reply-To: <55E5688C.70209@oracle.com>
References: <55E43BFC.6080204@oracle.com>
	<50682D61-B4E9-4AAB-A5C0-C83C30544FB0@lagergren.net>
	<83B46E93-A9CB-436B-A83E-0A0E0575482D@oracle.com>
	<55E5688C.70209@oracle.com>
Message-ID: <B30574B7-9B41-467F-80CA-EDFFF0B6E42B@gmail.com>

Awesome. Good diagnosis, Sundar! +1

/M

> On 01 Sep 2015, at 10:57, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Yes. And I manually inspected generated bytecode to make sure no-declared-param function case is handled by apply2call opt.
> 
> -Sundar
> 
> On 9/1/2015 1:51 PM, Attila Szegedi wrote:
>> It can?t regress on raytrace, since raytrace uses:
>> 
>>     return function() {
>>       this.initialize.apply(this, arguments);
>>     }
>> 
>> that is, the function containing the transform declares no arguments.
>> 
>> Attila.
>> 
>>> On Sep 1, 2015, at 9:15 AM, Marcus Lagergren <lagergren at gmail.com> wrote:
>>> 
>>> +1. Any regression on raytrace, though?
>>> 
>>> /M
>>> 
>>>> On 31 Aug 2015, at 13:35, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>>> 
>>>> Please review http://cr.openjdk.java.net/~sundar/8134731/ for https://bugs.openjdk.java.net/browse/JDK-8134731
>>>> 
>>>> Thanks
>>>> -Sundar
> 


From sundararajan.athijegannathan at oracle.com  Tue Sep  1 11:00:52 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 1 Sep 2015 16:30:52 +0530
Subject: RFR 8068901: Surprising behavior with more than one functional
	interface on a class , 8068903: Can't invoke vararg @FunctionalInterface
	methods
Message-ID: <55E58564.7060508@oracle.com>

Please review http://cr.openjdk.java.net/~sundar/8068901_8068903/ for 
https://bugs.openjdk.java.net/browse/JDK-8068901 and 
https://bugs.openjdk.java.net/browse/JDK-8068903

Thanks,
-Sundar

From attila.szegedi at oracle.com  Tue Sep  1 11:25:27 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 1 Sep 2015 13:25:27 +0200
Subject: RFR 8068901: Surprising behavior with more than one functional
	interface on a class ,
	8068903: Can't invoke vararg @FunctionalInterface methods
In-Reply-To: <55E58564.7060508@oracle.com>
References: <55E58564.7060508@oracle.com>
Message-ID: <C92D41CF-FFB7-439E-8CEC-A884FC140EC2@oracle.com>

Elegant small solution with use of dyn:callMethod.

One small thing:
  ClassValue<Method> FUNCTIONAL_IFACE_METHOD
could now be
  ClassValue<String> FUNCTIONAL_IFACE_METHOD_NAME
instead.

> On Sep 1, 2015, at 1:00 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8068901_8068903/ for https://bugs.openjdk.java.net/browse/JDK-8068901 and https://bugs.openjdk.java.net/browse/JDK-8068903
> 
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Tue Sep  1 11:50:28 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 1 Sep 2015 17:20:28 +0530
Subject: RFR 8068901: Surprising behavior with more than one functional
	interface on a class , 8068903: Can't invoke vararg @FunctionalInterface
	methods
In-Reply-To: <C92D41CF-FFB7-439E-8CEC-A884FC140EC2@oracle.com>
References: <55E58564.7060508@oracle.com>
	<C92D41CF-FFB7-439E-8CEC-A884FC140EC2@oracle.com>
Message-ID: <55E59104.7000209@oracle.com>

Thanks for the review. Updated: 
http://cr.openjdk.java.net/~sundar/8068901_8068903/webrev.01/

Thanks,
-Sundar

On 9/1/2015 4:55 PM, Attila Szegedi wrote:
> Elegant small solution with use of dyn:callMethod.
>
> One small thing:
>    ClassValue<Method> FUNCTIONAL_IFACE_METHOD
> could now be
>    ClassValue<String> FUNCTIONAL_IFACE_METHOD_NAME
> instead.
>
>> On Sep 1, 2015, at 1:00 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>
>> Please review http://cr.openjdk.java.net/~sundar/8068901_8068903/ for https://bugs.openjdk.java.net/browse/JDK-8068901 and https://bugs.openjdk.java.net/browse/JDK-8068903
>>
>> Thanks,
>> -Sundar


From sundararajan.athijegannathan at oracle.com  Tue Sep  1 12:06:50 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 1 Sep 2015 17:36:50 +0530
Subject: RFR 8068901: Surprising behavior with more than one functional
	interface on a class , 8068903: Can't invoke vararg @FunctionalInterface
	methods
In-Reply-To: <55E59104.7000209@oracle.com>
References: <55E58564.7060508@oracle.com>
	<C92D41CF-FFB7-439E-8CEC-A884FC140EC2@oracle.com>
	<55E59104.7000209@oracle.com>
Message-ID: <55E594DA.4090106@oracle.com>

Updated further: (method names changed to state "MethodName") 
http://cr.openjdk.java.net/~sundar/8068901_8068903/webrev.02/

Thanks,
-Sundar

On 9/1/2015 5:20 PM, Sundararajan Athijegannathan wrote:
> Thanks for the review. Updated: 
> http://cr.openjdk.java.net/~sundar/8068901_8068903/webrev.01/
>
> Thanks,
> -Sundar
>
> On 9/1/2015 4:55 PM, Attila Szegedi wrote:
>> Elegant small solution with use of dyn:callMethod.
>>
>> One small thing:
>>    ClassValue<Method> FUNCTIONAL_IFACE_METHOD
>> could now be
>>    ClassValue<String> FUNCTIONAL_IFACE_METHOD_NAME
>> instead.
>>
>>> On Sep 1, 2015, at 1:00 PM, Sundararajan Athijegannathan 
>>> <sundararajan.athijegannathan at oracle.com> wrote:
>>>
>>> Please review http://cr.openjdk.java.net/~sundar/8068901_8068903/ 
>>> for https://bugs.openjdk.java.net/browse/JDK-8068901 and 
>>> https://bugs.openjdk.java.net/browse/JDK-8068903
>>>
>>> Thanks,
>>> -Sundar
>


From andreas.woess at oracle.com  Tue Sep  1 12:31:12 2015
From: andreas.woess at oracle.com (Andreas Woess)
Date: Tue, 1 Sep 2015 14:31:12 +0200
Subject: RFR 8134865: Need to restore for container block from lexical context
	in finally
Message-ID: <55E59A90.60906@oracle.com>

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

In forStatement(), restoreBlock() was not called on exception in ES6 
language mode, which lead to an AssertionError. I've added some minor 
cleanups on top.

Thanks,
Andreas

From attila.szegedi at oracle.com  Tue Sep  1 12:32:46 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 1 Sep 2015 14:32:46 +0200
Subject: RFR 8068901: Surprising behavior with more than one functional
	interface on a class ,
	8068903: Can't invoke vararg @FunctionalInterface methods
In-Reply-To: <55E594DA.4090106@oracle.com>
References: <55E58564.7060508@oracle.com>
	<C92D41CF-FFB7-439E-8CEC-A884FC140EC2@oracle.com>
	<55E59104.7000209@oracle.com> <55E594DA.4090106@oracle.com>
Message-ID: <9FCDD01E-4885-4AA9-A45C-6FC45E7C6475@oracle.com>

+1

> On Sep 1, 2015, at 2:06 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Updated further: (method names changed to state "MethodName") http://cr.openjdk.java.net/~sundar/8068901_8068903/webrev.02/
> 
> Thanks,
> -Sundar
> 
> On 9/1/2015 5:20 PM, Sundararajan Athijegannathan wrote:
>> Thanks for the review. Updated: http://cr.openjdk.java.net/~sundar/8068901_8068903/webrev.01/
>> 
>> Thanks,
>> -Sundar
>> 
>> On 9/1/2015 4:55 PM, Attila Szegedi wrote:
>>> Elegant small solution with use of dyn:callMethod.
>>> 
>>> One small thing:
>>>   ClassValue<Method> FUNCTIONAL_IFACE_METHOD
>>> could now be
>>>   ClassValue<String> FUNCTIONAL_IFACE_METHOD_NAME
>>> instead.
>>> 
>>>> On Sep 1, 2015, at 1:00 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>>> 
>>>> Please review http://cr.openjdk.java.net/~sundar/8068901_8068903/ for https://bugs.openjdk.java.net/browse/JDK-8068901 and https://bugs.openjdk.java.net/browse/JDK-8068903
>>>> 
>>>> Thanks,
>>>> -Sundar
>> 
> 


From hannes.wallnoefer at oracle.com  Tue Sep  1 12:47:00 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 1 Sep 2015 14:47:00 +0200
Subject: RFR 8068901: Surprising behavior with more than one functional
	interface on a class , 8068903: Can't invoke vararg @FunctionalInterface
	methods
In-Reply-To: <55E594DA.4090106@oracle.com>
References: <55E58564.7060508@oracle.com>
	<C92D41CF-FFB7-439E-8CEC-A884FC140EC2@oracle.com>
	<55E59104.7000209@oracle.com> <55E594DA.4090106@oracle.com>
Message-ID: <55E59E44.5060408@oracle.com>

+1

Am 2015-09-01 um 14:06 schrieb Sundararajan Athijegannathan:
> Updated further: (method names changed to state "MethodName") 
> http://cr.openjdk.java.net/~sundar/8068901_8068903/webrev.02/
>
> Thanks,
> -Sundar
>
> On 9/1/2015 5:20 PM, Sundararajan Athijegannathan wrote:
>> Thanks for the review. Updated: 
>> http://cr.openjdk.java.net/~sundar/8068901_8068903/webrev.01/
>>
>> Thanks,
>> -Sundar
>>
>> On 9/1/2015 4:55 PM, Attila Szegedi wrote:
>>> Elegant small solution with use of dyn:callMethod.
>>>
>>> One small thing:
>>>    ClassValue<Method> FUNCTIONAL_IFACE_METHOD
>>> could now be
>>>    ClassValue<String> FUNCTIONAL_IFACE_METHOD_NAME
>>> instead.
>>>
>>>> On Sep 1, 2015, at 1:00 PM, Sundararajan Athijegannathan 
>>>> <sundararajan.athijegannathan at oracle.com> wrote:
>>>>
>>>> Please review http://cr.openjdk.java.net/~sundar/8068901_8068903/ 
>>>> for https://bugs.openjdk.java.net/browse/JDK-8068901 and 
>>>> https://bugs.openjdk.java.net/browse/JDK-8068903
>>>>
>>>> Thanks,
>>>> -Sundar
>>
>


From attila.szegedi at oracle.com  Tue Sep  1 13:08:09 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 1 Sep 2015 15:08:09 +0200
Subject: RFR 8134865: Need to restore for container block from lexical
	context in finally
In-Reply-To: <55E59A90.60906@oracle.com>
References: <55E59A90.60906@oracle.com>
Message-ID: <1E0AF5E9-0408-4452-9370-2D5B3673ECA7@oracle.com>

Looks good; +1

> On Sep 1, 2015, at 2:31 PM, Andreas Woess <andreas.woess at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~aw/8134865/ for https://bugs.openjdk.java.net/browse/JDK-8134865
> 
> In forStatement(), restoreBlock() was not called on exception in ES6 language mode, which lead to an AssertionError. I've added some minor cleanups on top.
> 
> Thanks,
> Andreas


From michael.haupt at oracle.com  Tue Sep  1 13:15:39 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Tue, 1 Sep 2015 15:15:39 +0200
Subject: RFR 8134865: Need to restore for container block from lexical
	context in finally
In-Reply-To: <1E0AF5E9-0408-4452-9370-2D5B3673ECA7@oracle.com>
References: <55E59A90.60906@oracle.com>
	<1E0AF5E9-0408-4452-9370-2D5B3673ECA7@oracle.com>
Message-ID: <B2F71ECB-9D6C-4ADE-821D-D32374C329A9@oracle.com>

Hi,

lower-case thumbs up from me. I'll sponsor this.

Thanks,

Michael

> Am 01.09.2015 um 15:08 schrieb Attila Szegedi <attila.szegedi at oracle.com>:
> 
> Looks good; +1
> 
>> On Sep 1, 2015, at 2:31 PM, Andreas Woess <andreas.woess at oracle.com> wrote:
>> 
>> Please review http://cr.openjdk.java.net/~aw/8134865/ for https://bugs.openjdk.java.net/browse/JDK-8134865
>> 
>> In forStatement(), restoreBlock() was not called on exception in ES6 language mode, which lead to an AssertionError. I've added some minor cleanups on top.
>> 
>> Thanks,
>> Andreas
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From andreas.woess at oracle.com  Tue Sep  1 14:30:22 2015
From: andreas.woess at oracle.com (Andreas Woess)
Date: Tue, 1 Sep 2015 16:30:22 +0200
Subject: RFR 8134873: Implement support for ES6 numeric literals
Message-ID: <55E5B67E.9050709@oracle.com>

Please reviewhttp://cr.openjdk.java.net/~aw/8134873/  forhttps://bugs.openjdk.java.net/browse/JDK-8134873

Implements Lexer/Parser support for ECMAScript 6 binary (0b) and octal (0o) literals. I've renamed OCTAL (legacy octal literal, e.g. 0777) to OCTAL_LEGACY and added OCTAL and BINARY_LITERAL token types (the _LITERAL suffix is to disambiguate with TokenKind.BINARY).

Thanks,
Andreas


From sundararajan.athijegannathan at oracle.com  Tue Sep  1 14:40:26 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 1 Sep 2015 20:10:26 +0530
Subject: RFR 8134873: Implement support for ES6 numeric literals
In-Reply-To: <55E5B67E.9050709@oracle.com>
References: <55E5B67E.9050709@oracle.com>
Message-ID: <55E5B8DA.9080603@oracle.com>

Do you want to pass a flag to Lexer for ES6 and control these ES6 
specific stuff only under that flag? Much like -scripting is handled?

-Sundar

On 9/1/2015 8:00 PM, Andreas Woess wrote:
> Please reviewhttp://cr.openjdk.java.net/~aw/8134873/ 
> forhttps://bugs.openjdk.java.net/browse/JDK-8134873
>
> Implements Lexer/Parser support for ECMAScript 6 binary (0b) and octal 
> (0o) literals. I've renamed OCTAL (legacy octal literal, e.g. 0777) to 
> OCTAL_LEGACY and added OCTAL and BINARY_LITERAL token types (the 
> _LITERAL suffix is to disambiguate with TokenKind.BINARY).
>
> Thanks,
> Andreas
>


From attila.szegedi at oracle.com  Tue Sep  1 14:42:45 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 1 Sep 2015 16:42:45 +0200
Subject: RFR 8134873: Implement support for ES6 numeric literals
In-Reply-To: <55E5B67E.9050709@oracle.com>
References: <55E5B67E.9050709@oracle.com>
Message-ID: <CF59D617-3270-4158-B51E-CAF4C64A2C9B@oracle.com>

- How about we use BINARY_NUMBER instead of BINARY_LITERAL? I know this is bikeshedding? It?s still more consisent with other literal token types (e.g. NULL and STRING) that don?t have the _LITERAL suffix. If we made it consistent the other way round, we?d have to have NULL_LITERAL, STRING_LITERAL, etc. Of course, we can just choose to live with the inconsistency and leave it as it is.

- These literals should only be recognized with --language=es6, shouldn?t they? In the current form, it seems like the code will recognize them with es5 language too, won?t it?

Attila.

> On Sep 1, 2015, at 4:30 PM, Andreas Woess <andreas.woess at oracle.com> wrote:
> 
> Please reviewhttp://cr.openjdk.java.net/~aw/8134873/  forhttps://bugs.openjdk.java.net/browse/JDK-8134873
> 
> Implements Lexer/Parser support for ECMAScript 6 binary (0b) and octal (0o) literals. I've renamed OCTAL (legacy octal literal, e.g. 0777) to OCTAL_LEGACY and added OCTAL and BINARY_LITERAL token types (the _LITERAL suffix is to disambiguate with TokenKind.BINARY).
> 
> Thanks,
> Andreas
> 


From andreas.woess at oracle.com  Tue Sep  1 15:05:45 2015
From: andreas.woess at oracle.com (Andreas Woess)
Date: Tue, 1 Sep 2015 17:05:45 +0200
Subject: RFR 8134873: Implement support for ES6 numeric literals
In-Reply-To: <CF59D617-3270-4158-B51E-CAF4C64A2C9B@oracle.com>
References: <55E5B67E.9050709@oracle.com>
	<CF59D617-3270-4158-B51E-CAF4C64A2C9B@oracle.com>
Message-ID: <55E5BEC9.9040305@oracle.com>

Bikeshedding is welcomed :) I've uploaded a new webrev[1] with 
s/BINARY_LITERAL/BINARY_NUMBER/ and an es6 flag in Lexer as suggested by 
Sundar.

[1] http://cr.openjdk.java.net/~aw/8134873/webrev.01/

Thanks,
Andreas

On 01/09/15 16:42, Attila Szegedi wrote:
> - How about we use BINARY_NUMBER instead of BINARY_LITERAL? I know this is bikeshedding? It?s still more consisent with other literal token types (e.g. NULL and STRING) that don?t have the _LITERAL suffix. If we made it consistent the other way round, we?d have to have NULL_LITERAL, STRING_LITERAL, etc. Of course, we can just choose to live with the inconsistency and leave it as it is.
>
> - These literals should only be recognized with --language=es6, shouldn?t they? In the current form, it seems like the code will recognize them with es5 language too, won?t it?
>
> Attila.
>
>> On Sep 1, 2015, at 4:30 PM, Andreas Woess <andreas.woess at oracle.com> wrote:
>>
>> Please reviewhttp://cr.openjdk.java.net/~aw/8134873/  forhttps://bugs.openjdk.java.net/browse/JDK-8134873
>>
>> Implements Lexer/Parser support for ECMAScript 6 binary (0b) and octal (0o) literals. I've renamed OCTAL (legacy octal literal, e.g. 0777) to OCTAL_LEGACY and added OCTAL and BINARY_LITERAL token types (the _LITERAL suffix is to disambiguate with TokenKind.BINARY).
>>
>> Thanks,
>> Andreas
>>


From sundararajan.athijegannathan at oracle.com  Tue Sep  1 17:13:33 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 1 Sep 2015 22:43:33 +0530
Subject: RFR 8134887: nashorn ant test configuration should disable assertion
	for LamdaFormEditor class
Message-ID: <55E5DCBD.6020400@oracle.com>

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

Thanks,
-Sundar

From james.laskey at oracle.com  Tue Sep  1 17:27:22 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Tue, 1 Sep 2015 14:27:22 -0300
Subject: RFR 8134887: nashorn ant test configuration should disable
	assertion for LamdaFormEditor class
In-Reply-To: <55E5DCBD.6020400@oracle.com>
References: <55E5DCBD.6020400@oracle.com>
Message-ID: <E5EC85DC-4DE5-46E4-BA0F-A324B59955C2@oracle.com>

+1

> On Sep 1, 2015, at 2:13 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8134887/ for https://bugs.openjdk.java.net/browse/JDK-8134887
> 
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Wed Sep  2 03:48:40 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 2 Sep 2015 09:18:40 +0530
Subject: RFR 8134873: Implement support for ES6 numeric literals
In-Reply-To: <55E5BEC9.9040305@oracle.com>
References: <55E5B67E.9050709@oracle.com>
	<CF59D617-3270-4158-B51E-CAF4C64A2C9B@oracle.com>
	<55E5BEC9.9040305@oracle.com>
Message-ID: <55E67198.9040808@oracle.com>

+1

PS. After few more changesets are done, perhaps we should perhaps have 
"negative es6" tests. i.e., attempt es6 constructs in default es5 mode 
and expect syntax errors.

-Sundar

On 9/1/2015 8:35 PM, Andreas Woess wrote:
> Bikeshedding is welcomed :) I've uploaded a new webrev[1] with 
> s/BINARY_LITERAL/BINARY_NUMBER/ and an es6 flag in Lexer as suggested 
> by Sundar.
>
> [1] http://cr.openjdk.java.net/~aw/8134873/webrev.01/
>
> Thanks,
> Andreas
>
> On 01/09/15 16:42, Attila Szegedi wrote:
>> - How about we use BINARY_NUMBER instead of BINARY_LITERAL? I know 
>> this is bikeshedding? It?s still more consisent with other literal 
>> token types (e.g. NULL and STRING) that don?t have the _LITERAL 
>> suffix. If we made it consistent the other way round, we?d have to 
>> have NULL_LITERAL, STRING_LITERAL, etc. Of course, we can just choose 
>> to live with the inconsistency and leave it as it is.
>>
>> - These literals should only be recognized with --language=es6, 
>> shouldn?t they? In the current form, it seems like the code will 
>> recognize them with es5 language too, won?t it?
>>
>> Attila.
>>
>>> On Sep 1, 2015, at 4:30 PM, Andreas Woess <andreas.woess at oracle.com> 
>>> wrote:
>>>
>>> Please reviewhttp://cr.openjdk.java.net/~aw/8134873/ 
>>> forhttps://bugs.openjdk.java.net/browse/JDK-8134873
>>>
>>> Implements Lexer/Parser support for ECMAScript 6 binary (0b) and 
>>> octal (0o) literals. I've renamed OCTAL (legacy octal literal, e.g. 
>>> 0777) to OCTAL_LEGACY and added OCTAL and BINARY_LITERAL token types 
>>> (the _LITERAL suffix is to disambiguate with TokenKind.BINARY).
>>>
>>> Thanks,
>>> Andreas
>>>
>


From attila.szegedi at oracle.com  Wed Sep  2 09:16:16 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 2 Sep 2015 11:16:16 +0200
Subject: RFR 8134873: Implement support for ES6 numeric literals
In-Reply-To: <55E5BEC9.9040305@oracle.com>
References: <55E5B67E.9050709@oracle.com>
	<CF59D617-3270-4158-B51E-CAF4C64A2C9B@oracle.com>
	<55E5BEC9.9040305@oracle.com>
Message-ID: <8F3FF935-E464-4532-94F3-171B79D183C5@oracle.com>

+1

> On Sep 1, 2015, at 5:05 PM, Andreas Woess <andreas.woess at oracle.com> wrote:
> 
> Bikeshedding is welcomed :) I've uploaded a new webrev[1] with s/BINARY_LITERAL/BINARY_NUMBER/ and an es6 flag in Lexer as suggested by Sundar.
> 
> [1] http://cr.openjdk.java.net/~aw/8134873/webrev.01/
> 
> Thanks,
> Andreas
> 
> On 01/09/15 16:42, Attila Szegedi wrote:
>> - How about we use BINARY_NUMBER instead of BINARY_LITERAL? I know this is bikeshedding? It?s still more consisent with other literal token types (e.g. NULL and STRING) that don?t have the _LITERAL suffix. If we made it consistent the other way round, we?d have to have NULL_LITERAL, STRING_LITERAL, etc. Of course, we can just choose to live with the inconsistency and leave it as it is.
>> 
>> - These literals should only be recognized with --language=es6, shouldn?t they? In the current form, it seems like the code will recognize them with es5 language too, won?t it?
>> 
>> Attila.
>> 
>>> On Sep 1, 2015, at 4:30 PM, Andreas Woess <andreas.woess at oracle.com> wrote:
>>> 
>>> Please reviewhttp://cr.openjdk.java.net/~aw/8134873/  forhttps://bugs.openjdk.java.net/browse/JDK-8134873
>>> 
>>> Implements Lexer/Parser support for ECMAScript 6 binary (0b) and octal (0o) literals. I've renamed OCTAL (legacy octal literal, e.g. 0777) to OCTAL_LEGACY and added OCTAL and BINARY_LITERAL token types (the _LITERAL suffix is to disambiguate with TokenKind.BINARY).
>>> 
>>> Thanks,
>>> Andreas
>>> 
> 


From attila.szegedi at oracle.com  Wed Sep  2 10:37:47 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 2 Sep 2015 12:37:47 +0200
Subject: Review request for JDK-8134930: Defer stack trace walking of
	NashornException for extracting line number and file name
Message-ID: <A9ACC345-42FB-4A0E-A93C-4C51F722821B@oracle.com>

Please review JDK-8134930 "Defer stack trace walking of NashornException for extracting line number and file name" at <http://cr.openjdk.java.net/~attila/8134930/webrev.01.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134930>

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Wed Sep  2 10:52:47 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 2 Sep 2015 16:22:47 +0530
Subject: Review request for JDK-8134930: Defer stack trace walking of
	NashornException for extracting line number and file name
In-Reply-To: <A9ACC345-42FB-4A0E-A93C-4C51F722821B@oracle.com>
References: <A9ACC345-42FB-4A0E-A93C-4C51F722821B@oracle.com>
Message-ID: <55E6D4FF.6010305@oracle.com>

+1

-Sundar

On 9/2/2015 4:07 PM, Attila Szegedi wrote:
> Please review JDK-8134930 "Defer stack trace walking of NashornException for extracting line number and file name" at <http://cr.openjdk.java.net/~attila/8134930/webrev.01.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134930>
>
> Thanks,
>    Attila.


From sundararajan.athijegannathan at oracle.com  Wed Sep  2 11:00:39 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 2 Sep 2015 16:30:39 +0530
Subject: RFR 8134931: jdk.nashorn.internal.codegen.TypeMap should not use Map
Message-ID: <55E6D6D7.6070002@oracle.com>

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

Thanks,
-Sundar

From michael.haupt at oracle.com  Wed Sep  2 11:15:51 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Wed, 2 Sep 2015 13:15:51 +0200
Subject: RFR 8134931: jdk.nashorn.internal.codegen.TypeMap should not use
	Map
In-Reply-To: <55E6D6D7.6070002@oracle.com>
References: <55E6D6D7.6070002@oracle.com>
Message-ID: <B11C5D0E-D559-429C-9D8E-CE419EBBA8DC@oracle.com>

Hi Sundar,

with any particular TypeMap instance hanging off of a node, and all of its members constant, I think some of the logic throughout the class can be reduced by means of constant folding. For instance, getCallSiteType() doesn't really have to do the appendParameterTypes() sequence every time. The result could be computed once and cached. Likewise for other methods.

Best,

Michael

> Am 02.09.2015 um 13:00 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Please review http://cr.openjdk.java.net/~sundar/8134931/ for https://bugs.openjdk.java.net/browse/JDK-8134931
> 
> Thanks,
> -Sundar

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From attila.szegedi at oracle.com  Wed Sep  2 11:26:40 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 2 Sep 2015 13:26:40 +0200
Subject: RFR 8134931: jdk.nashorn.internal.codegen.TypeMap should not use
	Map
In-Reply-To: <55E6D6D7.6070002@oracle.com>
References: <55E6D6D7.6070002@oracle.com>
Message-ID: <B3AD64A2-4C4A-4883-92EB-9EBBF300770E@oracle.com>

+1

> On Sep 2, 2015, at 1:00 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8134931/ for https://bugs.openjdk.java.net/browse/JDK-8134931
> 
> Thanks,
> -Sundar


From michael.haupt at oracle.com  Wed Sep  2 11:35:42 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Wed, 2 Sep 2015 13:35:42 +0200
Subject: RFR 8134931: jdk.nashorn.internal.codegen.TypeMap should not use
	Map
In-Reply-To: <B11C5D0E-D559-429C-9D8E-CE419EBBA8DC@oracle.com>
References: <55E6D6D7.6070002@oracle.com>
	<B11C5D0E-D559-429C-9D8E-CE419EBBA8DC@oracle.com>
Message-ID: <3B132092-9036-4626-84AC-730A8F56DB89@oracle.com>

... oh, other than that: lower-case thumbs up.

Michael

> Am 02.09.2015 um 13:15 schrieb Michael Haupt <michael.haupt at oracle.com>:
> 
> Hi Sundar,
> 
> with any particular TypeMap instance hanging off of a node, and all of its members constant, I think some of the logic throughout the class can be reduced by means of constant folding. For instance, getCallSiteType() doesn't really have to do the appendParameterTypes() sequence every time. The result could be computed once and cached. Likewise for other methods.
> 
> Best,
> 
> Michael
> 
>> Am 02.09.2015 um 13:00 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
>> 
>> Please review http://cr.openjdk.java.net/~sundar/8134931/ for https://bugs.openjdk.java.net/browse/JDK-8134931
>> 
>> Thanks,
>> -Sundar

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From attila.szegedi at oracle.com  Wed Sep  2 14:00:00 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 2 Sep 2015 16:00:00 +0200
Subject: Review request for JDK-8134939: Improve toString method of Dynalink
	DynamicMethod objects
Message-ID: <8D9F775C-4584-49F2-A2BB-C8E9B039079B@oracle.com>

Please review JDK-8134939 "Improve toString method of Dynalink DynamicMethod objects" at <http://cr.openjdk.java.net/~attila/8134939/webrev.01.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134939>

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Wed Sep  2 14:19:22 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 2 Sep 2015 19:49:22 +0530
Subject: Review request for JDK-8134939: Improve toString method of
	Dynalink DynamicMethod objects
In-Reply-To: <8D9F775C-4584-49F2-A2BB-C8E9B039079B@oracle.com>
References: <8D9F775C-4584-49F2-A2BB-C8E9B039079B@oracle.com>
Message-ID: <55E7056A.6080009@oracle.com>

+1

-Sundar

On 9/2/2015 7:30 PM, Attila Szegedi wrote:
> Please review JDK-8134939 "Improve toString method of Dynalink DynamicMethod objects" at <http://cr.openjdk.java.net/~attila/8134939/webrev.01.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134939>
>
> Thanks,
>    Attila.


From hannes.wallnoefer at oracle.com  Wed Sep  2 14:25:36 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 2 Sep 2015 16:25:36 +0200
Subject: Review request for JDK-8134939: Improve toString method of
	Dynalink DynamicMethod objects
In-Reply-To: <8D9F775C-4584-49F2-A2BB-C8E9B039079B@oracle.com>
References: <8D9F775C-4584-49F2-A2BB-C8E9B039079B@oracle.com>
Message-ID: <55E706E0.3070701@oracle.com>

+1

Am 2015-09-02 um 16:00 schrieb Attila Szegedi:
> Please review JDK-8134939 "Improve toString method of Dynalink DynamicMethod objects" at <http://cr.openjdk.java.net/~attila/8134939/webrev.01.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134939>
>
> Thanks,
>    Attila.


From sundararajan.athijegannathan at oracle.com  Wed Sep  2 16:42:37 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 2 Sep 2015 22:12:37 +0530
Subject: RFR 8134973: Control flow exceptions should avoid filling stack trace
Message-ID: <55E726FD.3030204@oracle.com>

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

PS. Piggybacking to remove an unused exception class.

Thanks,
-Sundar

From attila.szegedi at oracle.com  Wed Sep  2 16:44:50 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 2 Sep 2015 18:44:50 +0200
Subject: RFR 8134973: Control flow exceptions should avoid filling stack
	trace
In-Reply-To: <55E726FD.3030204@oracle.com>
References: <55E726FD.3030204@oracle.com>
Message-ID: <19F29475-6DCD-4159-944B-412C77FADBA5@oracle.com>

+1

> On Sep 2, 2015, at 6:42 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8134973/ for https://bugs.openjdk.java.net/browse/JDK-8134973
> 
> PS. Piggybacking to remove an unused exception class.
> 
> Thanks,
> -Sundar


From james.laskey at oracle.com  Wed Sep  2 16:50:00 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Wed, 2 Sep 2015 13:50:00 -0300
Subject: RFR 8134973: Control flow exceptions should avoid filling stack
	trace
In-Reply-To: <55E726FD.3030204@oracle.com>
References: <55E726FD.3030204@oracle.com>
Message-ID: <C6911C47-E274-46E7-B9E5-F4AE1552BAA8@oracle.com>

+1

> On Sep 2, 2015, at 1:42 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8134973/ for https://bugs.openjdk.java.net/browse/JDK-8134973
> 
> PS. Piggybacking to remove an unused exception class.
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Wed Sep  2 16:50:39 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 2 Sep 2015 18:50:39 +0200
Subject: RFR 8134973: Control flow exceptions should avoid filling stack
	trace
In-Reply-To: <55E726FD.3030204@oracle.com>
References: <55E726FD.3030204@oracle.com>
Message-ID: <55E728DF.10405@oracle.com>

+1

Am 2015-09-02 um 18:42 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8134973/ for 
> https://bugs.openjdk.java.net/browse/JDK-8134973
>
> PS. Piggybacking to remove an unused exception class.
>
> Thanks,
> -Sundar


From esben at esbena.dk  Wed Sep  2 21:59:30 2015
From: esben at esbena.dk (Esben Andreasen)
Date: Wed, 2 Sep 2015 23:59:30 +0200
Subject: Bug in Number.prototype.toFixed for 0.5 and -0.5
Message-ID: <CAE_ENxXHioX9eR02CBCNz-pXUAMCcJTYZihqS0LjY6131i3n3w@mail.gmail.com>

The implementation of Number.prototype.toFixed seems to be wrong in
two cases. Can you confirm this, and/or report it on an issue tracker?

Observed behaviour:

> $ jjs -version
> nashorn 1.8.0_60
> jjs> 0.5.toFixed()
> 0
> jjs> -0.5.toFixed()
> 0

Expected behaviour:

The two results should be 1 and -1 respectively.

I expect this behaviour because that is how I interpret ES5 and ES6
specifications for Number.prototype.toFixed, and because that is the
behaviour that I can observe in Chrome and Firefox.



Extra comments on possible cause of bug:

The interesting part of the ES6 specification is

20.1.3.3 - 10. - a.:

> Let n be an integer for which the exact mathematical value of n /
  10^f ? x is as close to zero as possible. If there are two such n,
  pick the larger n.

In the case of `0.5.toFixed()` the expression above becomes:

> n / 10^0 - 0.5 = n / 1 - 0.5 = n - 0.5

which solves to `n = 0` or `n = 1`.  It seems that Nashorn picks the
`n = 0` case instead of the `n = 1` case.



---
Esben Andreasen

From sundararajan.athijegannathan at oracle.com  Thu Sep  3 04:12:16 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 3 Sep 2015 09:42:16 +0530
Subject: Bug in Number.prototype.toFixed for 0.5 and -0.5
In-Reply-To: <CAE_ENxXHioX9eR02CBCNz-pXUAMCcJTYZihqS0LjY6131i3n3w@mail.gmail.com>
References: <CAE_ENxXHioX9eR02CBCNz-pXUAMCcJTYZihqS0LjY6131i3n3w@mail.gmail.com>
Message-ID: <55E7C8A0.3080302@oracle.com>

Yes, your interpretation seems right and I confirm that nashorn has a bug.

https://es5.github.io/#x15.7.4.5

Else, /x/ < 10^21

 1. Let /n/ be an integer for which the exact mathematical value of /n/
    ? 10^f ? /x/ is as close to zero as possible. If there are two such
    /n/, pick the larger /n/.

I filed https://bugs.openjdk.java.net/browse/JDK-8135000

Thanks for reporting this issue.
-Sundar


On 9/3/2015 3:29 AM, Esben Andreasen wrote:
> The implementation of Number.prototype.toFixed seems to be wrong in
> two cases. Can you confirm this, and/or report it on an issue tracker?
>
> Observed behaviour:
>
>> $ jjs -version
>> nashorn 1.8.0_60
>> jjs> 0.5.toFixed()
>> 0
>> jjs> -0.5.toFixed()
>> 0
> Expected behaviour:
>
> The two results should be 1 and -1 respectively.
>
> I expect this behaviour because that is how I interpret ES5 and ES6
> specifications for Number.prototype.toFixed, and because that is the
> behaviour that I can observe in Chrome and Firefox.
>
>
>
> Extra comments on possible cause of bug:
>
> The interesting part of the ES6 specification is
>
> 20.1.3.3 - 10. - a.:
>
>> Let n be an integer for which the exact mathematical value of n /
>    10^f ? x is as close to zero as possible. If there are two such n,
>    pick the larger n.
>
> In the case of `0.5.toFixed()` the expression above becomes:
>
>> n / 10^0 - 0.5 = n / 1 - 0.5 = n - 0.5
> which solves to `n = 0` or `n = 1`.  It seems that Nashorn picks the
> `n = 0` case instead of the `n = 1` case.
>
>
>
> ---
> Esben Andreasen


From sundararajan.athijegannathan at oracle.com  Thu Sep  3 13:33:29 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 3 Sep 2015 19:03:29 +0530
Subject: RFR 8087292: nashorn should have a "fail-fast" option for scripting, 
	analog to bash "set -e"
Message-ID: <55E84C29.6010708@oracle.com>

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

Thanks,
-Sundar

From hannes.wallnoefer at oracle.com  Thu Sep  3 13:37:32 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 3 Sep 2015 15:37:32 +0200
Subject: RFR 8087292: nashorn should have a "fail-fast" option for
	scripting, analog to bash "set -e"
In-Reply-To: <55E84C29.6010708@oracle.com>
References: <55E84C29.6010708@oracle.com>
Message-ID: <55E84D1C.6060303@oracle.com>

Two suggestions:

The return code is just the "messenger" and we don't know what went 
wrong, so I would prefer to use plain Error instead of RangeError.
And maybe we could set $EXEC.throwOnError = false by default so this 
feature was easier to discover.

Hannes

Am 2015-09-03 um 15:33 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8087292/ for 
> https://bugs.openjdk.java.net/browse/JDK-8087292
>
> Thanks,
> -Sundar


From james.laskey at oracle.com  Thu Sep  3 13:55:16 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Thu, 3 Sep 2015 10:55:16 -0300
Subject: RFR 8087292: nashorn should have a "fail-fast" option for
	scripting, analog to bash "set -e"
In-Reply-To: <55E84C29.6010708@oracle.com>
References: <55E84C29.6010708@oracle.com>
Message-ID: <32E4AEB6-EB1D-42BA-A267-313912B6C174@oracle.com>

+1

> On Sep 3, 2015, at 10:33 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8087292/ for https://bugs.openjdk.java.net/browse/JDK-8087292
> 
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Thu Sep  3 15:44:17 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 3 Sep 2015 21:14:17 +0530
Subject: RFR 8087292: nashorn should have a "fail-fast" option for
	scripting, analog to bash "set -e"
In-Reply-To: <55E84D1C.6060303@oracle.com>
References: <55E84C29.6010708@oracle.com> <55E84D1C.6060303@oracle.com>
Message-ID: <55E86AD1.7080203@oracle.com>

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

Updates:

* Added throwOnError property (false default) to $EXEC function object
* Added a test case (suggested by Michael offline)

On RangeError: I interpreted as { 0 } as only "expected" set of exit 
code values. Anything outside that is a "range error" as /RangeError/ 
object indicates an error when a value is not in the set or range of 
allowed values

Thanks,
-Sundar

On 9/3/2015 7:07 PM, Hannes Wallnoefer wrote:
> Two suggestions:
>
> The return code is just the "messenger" and we don't know what went 
> wrong, so I would prefer to use plain Error instead of RangeError.
> And maybe we could set $EXEC.throwOnError = false by default so this 
> feature was easier to discover.
>
> Hannes
>
> Am 2015-09-03 um 15:33 schrieb Sundararajan Athijegannathan:
>> Please review http://cr.openjdk.java.net/~sundar/8087292/ for 
>> https://bugs.openjdk.java.net/browse/JDK-8087292
>>
>> Thanks,
>> -Sundar
>


From michael.haupt at oracle.com  Thu Sep  3 15:55:09 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Thu, 3 Sep 2015 17:55:09 +0200
Subject: RFR 8087292: nashorn should have a "fail-fast" option for
	scripting, analog to bash "set -e"
In-Reply-To: <55E86AD1.7080203@oracle.com>
References: <55E84C29.6010708@oracle.com> <55E84D1C.6060303@oracle.com>
	<55E86AD1.7080203@oracle.com>
Message-ID: <3D2A1F30-C575-45B2-8B23-EE2BAC44BBAC@oracle.com>

Hi Sundar,

lower-case thumbs up!

Best,

Michael

> Am 03.09.2015 um 17:44 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Updated webrev: http://cr.openjdk.java.net/~sundar/8087292/webrev.01/
> 
> Updates:
> 
> * Added throwOnError property (false default) to $EXEC function object
> * Added a test case (suggested by Michael offline)
> 
> On RangeError: I interpreted as { 0 } as only "expected" set of exit code values. Anything outside that is a "range error" as /RangeError/ object indicates an error when a value is not in the set or range of allowed values
> 
> Thanks,
> -Sundar
> 
> On 9/3/2015 7:07 PM, Hannes Wallnoefer wrote:
>> Two suggestions:
>> 
>> The return code is just the "messenger" and we don't know what went wrong, so I would prefer to use plain Error instead of RangeError.
>> And maybe we could set $EXEC.throwOnError = false by default so this feature was easier to discover.
>> 
>> Hannes
>> 
>> Am 2015-09-03 um 15:33 schrieb Sundararajan Athijegannathan:
>>> Please review http://cr.openjdk.java.net/~sundar/8087292/ for https://bugs.openjdk.java.net/browse/JDK-8087292
>>> 
>>> Thanks,
>>> -Sundar
>> 
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From sundararajan.athijegannathan at oracle.com  Thu Sep  3 16:13:20 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 3 Sep 2015 21:43:20 +0530
Subject: RFR 8087292: nashorn should have a "fail-fast" option for
	scripting, analog to bash "set -e"
In-Reply-To: <3D2A1F30-C575-45B2-8B23-EE2BAC44BBAC@oracle.com>
References: <55E84C29.6010708@oracle.com> <55E84D1C.6060303@oracle.com>
	<55E86AD1.7080203@oracle.com>
	<3D2A1F30-C575-45B2-8B23-EE2BAC44BBAC@oracle.com>
Message-ID: <55E871A0.4020708@oracle.com>

Hi,

Thanks. Updated to check EXIT code is indeed non-zero in all the three 
calls of tryExec in test case.

http://cr.openjdk.java.net/~sundar/8087292/webrev.02/

-Sundar

On 9/3/2015 9:25 PM, Michael Haupt wrote:
> Hi Sundar,
>
> lower-case thumbs up!
>
> Best,
>
> Michael
>
>> Am 03.09.2015 um 17:44 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
>>
>> Updated webrev: http://cr.openjdk.java.net/~sundar/8087292/webrev.01/
>>
>> Updates:
>>
>> * Added throwOnError property (false default) to $EXEC function object
>> * Added a test case (suggested by Michael offline)
>>
>> On RangeError: I interpreted as { 0 } as only "expected" set of exit code values. Anything outside that is a "range error" as /RangeError/ object indicates an error when a value is not in the set or range of allowed values
>>
>> Thanks,
>> -Sundar
>>
>> On 9/3/2015 7:07 PM, Hannes Wallnoefer wrote:
>>> Two suggestions:
>>>
>>> The return code is just the "messenger" and we don't know what went wrong, so I would prefer to use plain Error instead of RangeError.
>>> And maybe we could set $EXEC.throwOnError = false by default so this feature was easier to discover.
>>>
>>> Hannes
>>>
>>> Am 2015-09-03 um 15:33 schrieb Sundararajan Athijegannathan:
>>>> Please review http://cr.openjdk.java.net/~sundar/8087292/ for https://bugs.openjdk.java.net/browse/JDK-8087292
>>>>
>>>> Thanks,
>>>> -Sundar


From hannes.wallnoefer at oracle.com  Thu Sep  3 16:29:14 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 3 Sep 2015 18:29:14 +0200
Subject: RFR 8087292: nashorn should have a "fail-fast" option for
	scripting, analog to bash "set -e"
In-Reply-To: <55E871A0.4020708@oracle.com>
References: <55E84C29.6010708@oracle.com> <55E84D1C.6060303@oracle.com>
	<55E86AD1.7080203@oracle.com>
	<3D2A1F30-C575-45B2-8B23-EE2BAC44BBAC@oracle.com>
	<55E871A0.4020708@oracle.com>
Message-ID: <55E8755A.8040103@oracle.com>

+1

Your rationale for using RangeError makes sense.

Hannes

Am 2015-09-03 um 18:13 schrieb Sundararajan Athijegannathan:
> Hi,
>
> Thanks. Updated to check EXIT code is indeed non-zero in all the three 
> calls of tryExec in test case.
>
> http://cr.openjdk.java.net/~sundar/8087292/webrev.02/
>
> -Sundar
>
> On 9/3/2015 9:25 PM, Michael Haupt wrote:
>> Hi Sundar,
>>
>> lower-case thumbs up!
>>
>> Best,
>>
>> Michael
>>
>>> Am 03.09.2015 um 17:44 schrieb Sundararajan Athijegannathan 
>>> <sundararajan.athijegannathan at oracle.com>:
>>>
>>> Updated webrev: http://cr.openjdk.java.net/~sundar/8087292/webrev.01/
>>>
>>> Updates:
>>>
>>> * Added throwOnError property (false default) to $EXEC function object
>>> * Added a test case (suggested by Michael offline)
>>>
>>> On RangeError: I interpreted as { 0 } as only "expected" set of exit 
>>> code values. Anything outside that is a "range error" as 
>>> /RangeError/ object indicates an error when a value is not in the 
>>> set or range of allowed values
>>>
>>> Thanks,
>>> -Sundar
>>>
>>> On 9/3/2015 7:07 PM, Hannes Wallnoefer wrote:
>>>> Two suggestions:
>>>>
>>>> The return code is just the "messenger" and we don't know what went 
>>>> wrong, so I would prefer to use plain Error instead of RangeError.
>>>> And maybe we could set $EXEC.throwOnError = false by default so 
>>>> this feature was easier to discover.
>>>>
>>>> Hannes
>>>>
>>>> Am 2015-09-03 um 15:33 schrieb Sundararajan Athijegannathan:
>>>>> Please review http://cr.openjdk.java.net/~sundar/8087292/ for 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8087292
>>>>>
>>>>> Thanks,
>>>>> -Sundar
>


From andreas.woess at oracle.com  Thu Sep  3 16:49:17 2015
From: andreas.woess at oracle.com (Andreas Woess)
Date: Thu, 3 Sep 2015 18:49:17 +0200
Subject: RFR 8134941: Implement ES6 template literal support
Message-ID: <55E87A0D.8020608@oracle.com>

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

This change adds support for ES6 template literals (both untagged and 
tagged). This is rather heavy patch, so let me walk you through it.

Instead of using the existing EditStringLexer, I took a somewhat 
different approach. I've added 4 lexer tokens for the different template 
string portions cf. 11.8.6 and let the parser decide what to do with it. 
These are then treated different depending on whether the literal is tagged:
* untagged: desugared to a string concatenation using +
* tagged: desugared to function call (cf. 12.2.9.2) tag( 
RuntimeCall(GET_TEMPLATE_OBJECT, [...rawStrings], [...cookedStrings]), 
...evaluatedExpressions ), where rawStrings and cookedStrings are the 
unescaped and escaped string portions, respectively. CR and CRLF in the 
strings are always converted to LF.

The EditStringLexer did not correctly count quoted braces in embedded 
expressions (e.g., `${ "}" }` would error), so I've hooked an open brace 
counter into Lexer#lexify() directly that is context-aware. It's purpose 
is to break out of the nested Lexer at the closing RBRACE, and then 
continue with scanning the rest of the literal.
Template literals are always scanned as a whole, quote-to-quote (as with 
EditStringLexer). This turned out to be a problem with embedded 
functions in expressions and lazy/optimistic compilation on: 
Parser#skipFunctionBody would skip over the body and restart lexing at 
the RBRACE, forgetting about the embedding string context. I've worked 
around this in skipFunctionBody by skipping over to the RBRACE directly 
if it is already in the token stream (which it is because we've already 
scanned to the end quote).

Template strings use the same quotes (`) as exec strings in -scripting 
mode; if mixed, --language=es6 takes precedence over -scripting, 
ES5+scripting is unaffected.

Outstanding correctness issues not dealt with:
* 12.2.9.3 GetTemplateObject stipulates that the returned template 
object be cached and unique. I don't know why you'd want the spec to 
demand caching rather than allow it (functionally it does not make a 
difference, but you could observe it not being cached in a test).
* 12.2.9.5 Evaluation: string concatenation using + is slightly 
off-spec. There are two way to solve this: (a) wrap the expressions in a 
ToString UnaryExpression (or RuntimeCall) or (b) generate a call to 
concat with interleaved string and expression arguments.

Testing: ant -f make/build.xml test-pessimistic test-optimistic

Thanks,
Andreas

From sundararajan.athijegannathan at oracle.com  Fri Sep  4 06:15:46 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 4 Sep 2015 11:45:46 +0530
Subject: RFR 8135054:Add more samples to nashorn samples directory
Message-ID: <55E93712.50201@oracle.com>

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

Thanks,
-Sundar

From michael.haupt at oracle.com  Fri Sep  4 11:25:09 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Fri, 4 Sep 2015 13:25:09 +0200
Subject: RFR 8135054:Add more samples to nashorn samples directory
In-Reply-To: <55E93712.50201@oracle.com>
References: <55E93712.50201@oracle.com>
Message-ID: <CF6FDB40-3532-4B44-8545-768708659C2B@oracle.com>

Hi Sundar,

lower-case thumbs up for an awesome collection of very instructive snippets!

Best,

Michael

> Am 04.09.2015 um 08:15 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Please review http://cr.openjdk.java.net/~sundar/8135054/ for https://bugs.openjdk.java.net/browse/JDK-8135054
> 
> Thanks,
> -Sundar

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From hannes.wallnoefer at oracle.com  Fri Sep  4 11:28:42 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 4 Sep 2015 13:28:42 +0200
Subject: RFR 8135054:Add more samples to nashorn samples directory
In-Reply-To: <55E93712.50201@oracle.com>
References: <55E93712.50201@oracle.com>
Message-ID: <55E9806A.703@oracle.com>

+1

Am 2015-09-04 um 08:15 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8135054/ for 
> https://bugs.openjdk.java.net/browse/JDK-8135054
>
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Fri Sep  4 11:56:12 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 4 Sep 2015 17:26:12 +0530
Subject: [8u] approval request for 8135054:Add more samples to nashorn samples
	directory
Message-ID: <55E986DC.3020207@oracle.com>

Please approve.

Bug: https://bugs.openjdk.java.net/browse/JDK-8135054
jdk9 review thread: 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005152.html
jdk8u webrev: http://cr.openjdk.java.net/~sundar/8135054/8u/webrev.00/

Backporting all samples "as is" except for two jdk9 specific samples - 
jrtlist.js (requires jrt file system), java_completion.js (requires jshell).
CC'ing nashorn-dev.

Thanks,
-Sundar

From sean.coffey at oracle.com  Fri Sep  4 12:29:09 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Fri, 04 Sep 2015 13:29:09 +0100
Subject: [8u] approval request for 8135054:Add more samples to nashorn
	samples directory
In-Reply-To: <55E986DC.3020207@oracle.com>
References: <55E986DC.3020207@oracle.com>
Message-ID: <55E98E95.5060109@oracle.com>

Approved but subject to peer code review.

Regards,
Sean.

On 04/09/15 12:56, Sundararajan Athijegannathan wrote:
> Please approve.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8135054
> jdk9 review thread: 
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005152.html
> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8135054/8u/webrev.00/
>
> Backporting all samples "as is" except for two jdk9 specific samples - 
> jrtlist.js (requires jrt file system), java_completion.js (requires 
> jshell).
> CC'ing nashorn-dev.
>
> Thanks,
> -Sundar


From michael.haupt at oracle.com  Fri Sep  4 12:47:33 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Fri, 4 Sep 2015 14:47:33 +0200
Subject: [8u] approval request for 8135054:Add more samples to nashorn
	samples directory
In-Reply-To: <55E98E95.5060109@oracle.com>
References: <55E986DC.3020207@oracle.com> <55E98E95.5060109@oracle.com>
Message-ID: <D8DA78D7-5C73-42BC-A1D2-B2B14B04B4CD@oracle.com>

... lower-case thumbs up.

Michael

> Am 04.09.2015 um 14:29 schrieb Se?n Coffey <sean.coffey at oracle.com>:
> 
> Approved but subject to peer code review.
> 
> Regards,
> Sean.
> 
> On 04/09/15 12:56, Sundararajan Athijegannathan wrote:
>> Please approve.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135054
>> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005152.html
>> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8135054/8u/webrev.00/
>> 
>> Backporting all samples "as is" except for two jdk9 specific samples - jrtlist.js (requires jrt file system), java_completion.js (requires jshell).
>> CC'ing nashorn-dev.
>> 
>> Thanks,
>> -Sundar
> 

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From attila.szegedi at oracle.com  Fri Sep  4 15:10:58 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 4 Sep 2015 17:10:58 +0200
Subject: Review request for JDK-8135075: Reorder short-circuit tests in
	ApplySpecialization to run cheapest first
Message-ID: <CFFFF182-EBE2-4B26-9AC7-AF8C831DB810@oracle.com>

Please review JDK-8135075 "Reorder short-circuit tests in ApplySpecialization to run cheapest first" at <http://cr.openjdk.java.net/~attila/8135075/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135075>

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Fri Sep  4 15:18:23 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 4 Sep 2015 20:48:23 +0530
Subject: Review request for JDK-8135075: Reorder short-circuit tests in
	ApplySpecialization to run cheapest first
In-Reply-To: <CFFFF182-EBE2-4B26-9AC7-AF8C831DB810@oracle.com>
References: <CFFFF182-EBE2-4B26-9AC7-AF8C831DB810@oracle.com>
Message-ID: <55E9B63F.1090100@oracle.com>

+1

-Sundar

On 9/4/2015 8:40 PM, Attila Szegedi wrote:
> Please review JDK-8135075 "Reorder short-circuit tests in ApplySpecialization to run cheapest first" at <http://cr.openjdk.java.net/~attila/8135075/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135075>
>
> Thanks,
>    Attila.


From michael.haupt at oracle.com  Mon Sep  7 07:11:33 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Mon, 7 Sep 2015 09:11:33 +0200
Subject: Review request for JDK-8135075: Reorder short-circuit tests in
	ApplySpecialization to run cheapest first
In-Reply-To: <CFFFF182-EBE2-4B26-9AC7-AF8C831DB810@oracle.com>
References: <CFFFF182-EBE2-4B26-9AC7-AF8C831DB810@oracle.com>
Message-ID: <7EA5C258-98FF-44C1-BC02-362C6BE0BF49@oracle.com>

Hi Attila,

lower-case thumbs up!

Best,

Michael

> Am 04.09.2015 um 17:10 schrieb Attila Szegedi <attila.szegedi at oracle.com>:
> 
> Please review JDK-8135075 "Reorder short-circuit tests in ApplySpecialization to run cheapest first" at <http://cr.openjdk.java.net/~attila/8135075/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135075>
> 
> Thanks,
>  Attila.

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From hannes.wallnoefer at oracle.com  Mon Sep  7 08:58:48 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 7 Sep 2015 10:58:48 +0200
Subject: Review request for JDK-8135075: Reorder short-circuit tests in
	ApplySpecialization to run cheapest first
In-Reply-To: <CFFFF182-EBE2-4B26-9AC7-AF8C831DB810@oracle.com>
References: <CFFFF182-EBE2-4B26-9AC7-AF8C831DB810@oracle.com>
Message-ID: <55ED51C8.2020905@oracle.com>

+1

Am 2015-09-04 um 17:10 schrieb Attila Szegedi:
> Please review JDK-8135075 "Reorder short-circuit tests in ApplySpecialization to run cheapest first" at <http://cr.openjdk.java.net/~attila/8135075/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135075>
>
> Thanks,
>    Attila.


From sundararajan.athijegannathan at oracle.com  Mon Sep  7 14:12:09 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 7 Sep 2015 19:42:09 +0530
Subject: RFR 8135151: jjs should work in cygwin environment
Message-ID: <55ED9B39.7020303@oracle.com>

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

Thanks,
-Sundar

From attila.szegedi at oracle.com  Mon Sep  7 14:14:01 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 7 Sep 2015 16:14:01 +0200
Subject: RFR 8135151: jjs should work in cygwin environment
In-Reply-To: <55ED9B39.7020303@oracle.com>
References: <55ED9B39.7020303@oracle.com>
Message-ID: <7010771F-ACA4-4146-9A21-B05F18E5E11B@oracle.com>

+1

> On Sep 7, 2015, at 4:12 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8135151/ for https://bugs.openjdk.java.net/browse/JDK-8135151
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Mon Sep  7 14:35:51 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 7 Sep 2015 16:35:51 +0200
Subject: RFR 8135151: jjs should work in cygwin environment
In-Reply-To: <55ED9B39.7020303@oracle.com>
References: <55ED9B39.7020303@oracle.com>
Message-ID: <55EDA0C7.9010101@oracle.com>

+1

Am 2015-09-07 um 16:12 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8135151/ for 
> https://bugs.openjdk.java.net/browse/JDK-8135151
>
> Thanks,
> -Sundar


From sdeleuze at pivotal.io  Tue Sep  8 13:40:23 2015
From: sdeleuze at pivotal.io (Sebastien Deleuze)
Date: Tue, 8 Sep 2015 15:40:23 +0200
Subject: Review request for JDK-8134403: Nashorn react.js benchmark
	performance regression
In-Reply-To: <CABMnHOffGh_phTtYrtOc9df0vgw45AnqGL-PmHH3WTNhiErttg@mail.gmail.com>
References: <A14A9011-094D-4FC3-9EBB-FA4B6CB872AD@oracle.com>
	<CABMnHOeGxRiKpdZzDP6k=vZsXAv7oZ-2aw5VSFLw=jKU-5M9Bg@mail.gmail.com>
	<EE2133B8-92B6-40A1-8490-0142B8E0BDA5@oracle.com>
	<CABMnHOffGh_phTtYrtOc9df0vgw45AnqGL-PmHH3WTNhiErttg@mail.gmail.com>
Message-ID: <CAF_xPQLSSyxMk4WbqnO8cqCy1Xyw1nEtQt2khPDijCwGiz_BGw@mail.gmail.com>

Hi,

In my upcoming Nashorn + Spring talk next week, I would like to give people
a feedback about Nashorn performances with real figures.
I am going to bench my sample Nashorn + React.js application [1] and in
order to show Nashorn as performant as it is, I need to use a build that
contains JDK-8134403 fix.

Sadly, only Java 8u66 seems to be available [3] for download.
Any idea about how I could download a Java 8u72 MacOS build that contains
JDK-8134403 fix or any news about backporting JDK-8134403 to Java 8u66 ?

Thanks in advance for your feedback,
S?bastien Deleuze

[1] https://github.com/sdeleuze/spring-react-isomorphic
[2] https://bugs.openjdk.java.net/browse/JDK-8134403
[3] https://jdk8.java.net/download.html


On Thu, Aug 27, 2015 at 10:03 PM, Martin Solli <msolli at gmail.com> wrote:

> Much obliged!
>
> -martin
>
> tor. 27. aug. 2015 kl. 09.04 skrev Attila Szegedi <
> attila.szegedi at oracle.com
> >:
>
> > I have just backported it to 8u-dev repository, which means that it
> should
> > definitely appear in 8u72 [1]. 8u66 [2] is already in RampDown 2 phase,
> > meaning it only accepts critical updates at this time. I will file a
> > critical update request for it, but it?s out of my hands whether it gets
> > accepted for inclusion there.
> >
> > Attila.
> >
> > [1] http://openjdk.java.net/projects/jdk8u/releases/8u72.html
> > [2] http://openjdk.java.net/projects/jdk8u/releases/8u66.html
> >
> >
> >
> > On Aug 27, 2015, at 8:56 AM, Martin Solli <msolli at gmail.com> wrote:
> >
> > Awesome! Any chance of getting this into a future Java 8 update?
> > Performance is pretty dismal on u60 - can't get a medium-sized React
> > component tree to render under 50 ms, whereas on u31 it renders in 1 ms
> > (after ~7000 iterations).
> >
> > Thanks for all of your great work on Nashorn!
> >
> > -martin
> >
> > ons. 26. aug. 2015 kl. 15.41 skrev Attila Szegedi <
> > attila.szegedi at oracle.com
> >
> > :
> >
> >
> > Please review JDK-8134403 "Nashorn react.js benchmark performance
> > regression" at <http://cr.openjdk.java.net/~attila/8134403/webrev.jdk9>
> > for <https://bugs.openjdk.java.net/browse/JDK-8134403>
> >
> > Thanks,
> >  Attila.
> >
> >
> >
>

From sundararajan.athijegannathan at oracle.com  Wed Sep  9 08:19:13 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 9 Sep 2015 13:49:13 +0530
Subject: RFR 8027137: Merge ScriptFunction and ScriptFunctionImpl
Message-ID: <55EFEB81.7060404@oracle.com>

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

Thanks,
-Sundar

From michael.haupt at oracle.com  Wed Sep  9 08:36:36 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Wed, 9 Sep 2015 10:36:36 +0200
Subject: RFR 8027137: Merge ScriptFunction and ScriptFunctionImpl
In-Reply-To: <55EFEB81.7060404@oracle.com>
References: <55EFEB81.7060404@oracle.com>
Message-ID: <CF6DFADE-F439-44A5-BC81-5ECD7A16E072@oracle.com>

Hi Sundar,

lower-case thumbs up!

Best,

Michael

> Am 09.09.2015 um 10:19 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Please review http://cr.openjdk.java.net/~sundar/8027137/ for https://bugs.openjdk.java.net/browse/JDK-8027137
> 
> Thanks,
> -Sundar

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From hannes.wallnoefer at oracle.com  Wed Sep  9 09:10:06 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 9 Sep 2015 11:10:06 +0200
Subject: RFR 8027137: Merge ScriptFunction and ScriptFunctionImpl
In-Reply-To: <55EFEB81.7060404@oracle.com>
References: <55EFEB81.7060404@oracle.com>
Message-ID: <55EFF76E.50304@oracle.com>

  The javadoc comment in ScriptFunctionData#makeBoundFunctionData refers 
to {@link ScriptFunction#makeBoundFunction(Object, Object[])} which is 
now called createBound.

Apart than that +1. Nice!

Hannes

Am 2015-09-09 um 10:19 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8027137/ for 
> https://bugs.openjdk.java.net/browse/JDK-8027137
>
> Thanks,
> -Sundar


From sdeleuze at pivotal.io  Wed Sep  9 09:13:42 2015
From: sdeleuze at pivotal.io (Sebastien Deleuze)
Date: Wed, 9 Sep 2015 11:13:42 +0200
Subject: Data corruption with Nashorn + Handlebars and concurrent requests
In-Reply-To: <55AC6666.3040807@oracle.com>
References: <CAF6YWN0e73cwLXmvYFOVQX4AZVRJeGSZ__eYNAFLKaSL2=NNPg@mail.gmail.com>
	<CAF_xPQ+ae5iD4rOeBo3RHpewYdL9fJDYxL65vBxM+grgRcfv2g@mail.gmail.com>
	<CAF6YWN1fc6xDc_TZ8Mpvk_d5J7h1Z4i7VN5ftDXbjrErEakcOg@mail.gmail.com>
	<55AC6666.3040807@oracle.com>
Message-ID: <CAF_xPQLkd9b=aN4eH8j+NAHVXnY44nqS3agqavHEz4abFHxu_g@mail.gmail.com>

I am updating my Spring + Nashorn talk and the related sample applications,
and I am wondering if in the Nashorn version provided with java 8u60 there
is a better/easier way to convert a Java Map<String, Object> instance into
a real JSON Object (with Iterable elements being converted to real JSON
arrays)?

Currently I am doing that:

    // Create a real JSON Object from the model Map
    var data = {};
    for (var k in model) {
        // Convert Java Iterable and List to real JSON arrays
        if (model[k] instanceof Java.type("java.lang.Iterable")) {
            data[k] = Java.from(model[k]);
        } else {
            data[k] = model[k];
        }
    }

Any thoughts?

On Mon, Jul 20, 2015 at 5:09 AM, A. Sundararajan <
sundararajan.athijegannathan at oracle.com> wrote:

> By "reset",  if you mean "throw all the stuff in global to get a blank
> global", then you can do this:
>
>     ScriptContext sc  = engine.getContext();
>     sc.setBindings(engine.createBindings(), ScriptContext.ENGINE_SCOPE);
>
> This will create fresh (ECMAScript) global and makes it as ENGINE_SCOPE of
> the default context.
>
> -Sundar
>
>
> On Sunday 19 July 2015 02:37 AM, Matt Kime wrote:
>
>> thanks, this is very helpful.
>>
>> one issue remains for me - is there a good way to reset the script engines
>> in a development environment without restarting the whole app?
>>
>> --matt
>>
>> On Wed, Jul 15, 2015 at 1:02 PM, Sebastien Deleuze <sdeleuze at pivotal.io>
>> wrote:
>>
>> Hi,
>>>
>>> We ended up to use thread-local script engines [1] in Spring 4.2 for
>>> Javascript libraries not designed for concurrency like React or
>>> Handlebars.
>>> Based on my initial tests, it works pretty well. The main remaining open
>>> question is about the memory consumption, since it creates one
>>> ScriptEngine
>>> instance by thread.
>>> If we see some blocking issues regarding this topic, we may eventually
>>> experiment with a synchronized ScriptEngine pool, but I hope the
>>> thread-local approach will be fine.
>>>
>>> Regards,
>>> S?bastien Deleuze
>>>
>>> [1] https://jira.spring.io/browse/SPR-13034
>>>
>>> On Fri, Jun 5, 2015 at 5:08 PM, Matt Kime <mattk at meetup.com> wrote:
>>>
>>> I'm curious if any progress has been made on isolating whatever isn't
>>>> thread safe about handlebars template execution.
>>>>
>>>> I'm also working on using Handlebars.js inside nashorn however i'm
>>>> doing a
>>>> number of things different. i'm precompiling my templates using
>>>> https://github.com/gruntjs/grunt-contrib-handlebars and then compile
>>>> the
>>>> js
>>>> functions into cached bytecode.
>>>>
>>>> I haven't checked for threading issues yet but I'm glad i found this
>>>> discussion so i know that i should.
>>>>
>>>>
>>>
>

From attila.szegedi at oracle.com  Wed Sep  9 09:27:01 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 9 Sep 2015 11:27:01 +0200
Subject: RFR 8027137: Merge ScriptFunction and ScriptFunctionImpl
In-Reply-To: <55EFEB81.7060404@oracle.com>
References: <55EFEB81.7060404@oracle.com>
Message-ID: <D1E4FF8B-CA74-47F5-82C7-C2BCFEE8AF7E@oracle.com>

Great work! I?m very happy that ScriptFunctionImpl is going away.

Some implementation remarks:

- The newly public methods in Global.java, getFunctionPrototype and getTypeErrorThrower don?t have Javadoc.
- The newly public two constructors of PrototypeObject also don?t hava Javadoc.
-  while you're at it, how about we replace ScriptFunction.constructorCount/invokes/allocations fields with LongAdder objects? We should gradually be replacing all such static counters.
- can we create an explicit subclass for bound functions? It can be declared as "private static class Bound extends ScriptFunction { ... }" within the ScriptFunction class. When we debug, we'll then see its name as ScriptFunction$Bound instead of ScriptFunction$1.

Attila.

> On Sep 9, 2015, at 10:19 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8027137/ for https://bugs.openjdk.java.net/browse/JDK-8027137
> 
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Wed Sep  9 11:22:09 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 9 Sep 2015 16:52:09 +0530
Subject: RFR 8027137: Merge ScriptFunction and ScriptFunctionImpl
In-Reply-To: <D1E4FF8B-CA74-47F5-82C7-C2BCFEE8AF7E@oracle.com>
References: <55EFEB81.7060404@oracle.com>
	<D1E4FF8B-CA74-47F5-82C7-C2BCFEE8AF7E@oracle.com>
Message-ID: <55F01661.4050000@oracle.com>

Thanks for the reviews Hannes & Attila.

I've incorporated the changes suggested. Updated webrev: 
http://cr.openjdk.java.net/~sundar/8027137/webrev.01/

PS. I've changed all counters (used from NativeDebug) to use LongAdder.

-Sundar

On 9/9/2015 2:57 PM, Attila Szegedi wrote:
> Great work! I?m very happy that ScriptFunctionImpl is going away.
>
> Some implementation remarks:
>
> - The newly public methods in Global.java, getFunctionPrototype and getTypeErrorThrower don?t have Javadoc.
> - The newly public two constructors of PrototypeObject also don?t hava Javadoc.
> -  while you're at it, how about we replace ScriptFunction.constructorCount/invokes/allocations fields with LongAdder objects? We should gradually be replacing all such static counters.
> - can we create an explicit subclass for bound functions? It can be declared as "private static class Bound extends ScriptFunction { ... }" within the ScriptFunction class. When we debug, we'll then see its name as ScriptFunction$Bound instead of ScriptFunction$1.
>
> Attila.
>
>> On Sep 9, 2015, at 10:19 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>
>> Please review http://cr.openjdk.java.net/~sundar/8027137/ for https://bugs.openjdk.java.net/browse/JDK-8027137
>>
>> Thanks,
>> -Sundar


From sundararajan.athijegannathan at oracle.com  Wed Sep  9 11:28:52 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 9 Sep 2015 16:58:52 +0530
Subject: Data corruption with Nashorn + Handlebars and concurrent requests
In-Reply-To: <CAF_xPQLkd9b=aN4eH8j+NAHVXnY44nqS3agqavHEz4abFHxu_g@mail.gmail.com>
References: <CAF6YWN0e73cwLXmvYFOVQX4AZVRJeGSZ__eYNAFLKaSL2=NNPg@mail.gmail.com>
	<CAF_xPQ+ae5iD4rOeBo3RHpewYdL9fJDYxL65vBxM+grgRcfv2g@mail.gmail.com>
	<CAF6YWN1fc6xDc_TZ8Mpvk_d5J7h1Z4i7VN5ftDXbjrErEakcOg@mail.gmail.com>
	<55AC6666.3040807@oracle.com>
	<CAF_xPQLkd9b=aN4eH8j+NAHVXnY44nqS3agqavHEz4abFHxu_g@mail.gmail.com>
Message-ID: <55F017F4.9060208@oracle.com>

Hi,

No, there is no direct way to convert a Java Map to a real JSON object. 
You've to do conversion as you hinted.

-Sundar

On 9/9/2015 2:43 PM, Sebastien Deleuze wrote:
> I am updating my Spring + Nashorn talk and the related sample 
> applications, and I am wondering if in the Nashorn version provided 
> with java 8u60 there is a better/easier way to convert a Java 
> Map<String, Object> instance into a real JSON Object (with Iterable 
> elements being converted to real JSON arrays)?
>
> Currently I am doing that:
>
>     // Create a real JSON Object from the model Map

>     var data = {};
>     for (var k in model) {
>         // Convert Java Iterable and List to real JSON arrays

>         if (model[k] instanceof Java.type("java.lang.Iterable")) {
>             data[k] = Java.from(model[k]);
>         } else {
>             data[k] = model[k];
>         }
>     }
>
> Any thoughts?
>
> On Mon, Jul 20, 2015 at 5:09 AM, A. Sundararajan 
> <sundararajan.athijegannathan at oracle.com 
> <mailto:sundararajan.athijegannathan at oracle.com>> wrote:
>
>     By "reset",  if you mean "throw all the stuff in global to get a
>     blank global", then you can do this:
>
>         ScriptContext sc  = engine.getContext();
>         sc.setBindings(engine.createBindings(),
>     ScriptContext.ENGINE_SCOPE);
>
>     This will create fresh (ECMAScript) global and makes it as
>     ENGINE_SCOPE of the default context.
>
>     -Sundar
>
>
>     On Sunday 19 July 2015 02:37 AM, Matt Kime wrote:
>
>         thanks, this is very helpful.
>
>         one issue remains for me - is there a good way to reset the
>         script engines
>         in a development environment without restarting the whole app?
>
>         --matt
>
>         On Wed, Jul 15, 2015 at 1:02 PM, Sebastien Deleuze
>         <sdeleuze at pivotal.io <mailto:sdeleuze at pivotal.io>>
>         wrote:
>
>             Hi,
>
>             We ended up to use thread-local script engines [1] in
>             Spring 4.2 for
>             Javascript libraries not designed for concurrency like
>             React or Handlebars.
>             Based on my initial tests, it works pretty well. The main
>             remaining open
>             question is about the memory consumption, since it creates
>             one ScriptEngine
>             instance by thread.
>             If we see some blocking issues regarding this topic, we
>             may eventually
>             experiment with a synchronized ScriptEngine pool, but I
>             hope the
>             thread-local approach will be fine.
>
>             Regards,
>             S?bastien Deleuze
>
>             [1] https://jira.spring.io/browse/SPR-13034
>
>             On Fri, Jun 5, 2015 at 5:08 PM, Matt Kime
>             <mattk at meetup.com <mailto:mattk at meetup.com>> wrote:
>
>                 I'm curious if any progress has been made on isolating
>                 whatever isn't
>                 thread safe about handlebars template execution.
>
>                 I'm also working on using Handlebars.js inside nashorn
>                 however i'm doing a
>                 number of things different. i'm precompiling my
>                 templates using
>                 https://github.com/gruntjs/grunt-contrib-handlebars
>                 and then compile the
>                 js
>                 functions into cached bytecode.
>
>                 I haven't checked for threading issues yet but I'm
>                 glad i found this
>                 discussion so i know that i should.
>
>
>
>


From sundararajan.athijegannathan at oracle.com  Wed Sep  9 11:33:31 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 9 Sep 2015 17:03:31 +0530
Subject: Review request for JDK-8134403: Nashorn react.js benchmark
	performance regression
In-Reply-To: <CAF_xPQLSSyxMk4WbqnO8cqCy1Xyw1nEtQt2khPDijCwGiz_BGw@mail.gmail.com>
References: <A14A9011-094D-4FC3-9EBB-FA4B6CB872AD@oracle.com>
	<CABMnHOeGxRiKpdZzDP6k=vZsXAv7oZ-2aw5VSFLw=jKU-5M9Bg@mail.gmail.com>
	<EE2133B8-92B6-40A1-8490-0142B8E0BDA5@oracle.com>
	<CABMnHOffGh_phTtYrtOc9df0vgw45AnqGL-PmHH3WTNhiErttg@mail.gmail.com>
	<CAF_xPQLSSyxMk4WbqnO8cqCy1Xyw1nEtQt2khPDijCwGiz_BGw@mail.gmail.com>
Message-ID: <55F0190B.6000402@oracle.com>

Hi,

You could check out jdk8u-dev forest and build nashorn using "ant". You 
can get jdk8u forest from

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

If you've complete jdk8u forest in directory $jdk8u

     cd $jdk8u/nashorn/make
     export JAVA_HOME=<recent_jdk8u_installation_home>
     ant clean jar

The resulting jar is produced @ $jdk8u/nashorn/dist directory. You can 
use that jar with jjs as

     jjs -J-Djava.ext.dirs=$jdk8u/nashorn/dist

NOTE: This is just a workaround for demonstration/talk purpose only. I 
don't recommend this as a production/deployment option - mixing binaries 
from local build + released version is problematic!

Hope this helps,
-Sundar

On 9/8/2015 7:10 PM, Sebastien Deleuze wrote:
> Hi,
>
> In my upcoming Nashorn + Spring talk next week, I would like to give people
> a feedback about Nashorn performances with real figures.
> I am going to bench my sample Nashorn + React.js application [1] and in
> order to show Nashorn as performant as it is, I need to use a build that
> contains JDK-8134403 fix.
>
> Sadly, only Java 8u66 seems to be available [3] for download.
> Any idea about how I could download a Java 8u72 MacOS build that contains
> JDK-8134403 fix or any news about backporting JDK-8134403 to Java 8u66 ?
>
> Thanks in advance for your feedback,
> S?bastien Deleuze
>
> [1] https://github.com/sdeleuze/spring-react-isomorphic
> [2] https://bugs.openjdk.java.net/browse/JDK-8134403
> [3] https://jdk8.java.net/download.html
>
>
> On Thu, Aug 27, 2015 at 10:03 PM, Martin Solli <msolli at gmail.com> wrote:
>
>> Much obliged!
>>
>> -martin
>>
>> tor. 27. aug. 2015 kl. 09.04 skrev Attila Szegedi <
>> attila.szegedi at oracle.com
>>> :
>>> I have just backported it to 8u-dev repository, which means that it
>> should
>>> definitely appear in 8u72 [1]. 8u66 [2] is already in RampDown 2 phase,
>>> meaning it only accepts critical updates at this time. I will file a
>>> critical update request for it, but it?s out of my hands whether it gets
>>> accepted for inclusion there.
>>>
>>> Attila.
>>>
>>> [1] http://openjdk.java.net/projects/jdk8u/releases/8u72.html
>>> [2] http://openjdk.java.net/projects/jdk8u/releases/8u66.html
>>>
>>>
>>>
>>> On Aug 27, 2015, at 8:56 AM, Martin Solli <msolli at gmail.com> wrote:
>>>
>>> Awesome! Any chance of getting this into a future Java 8 update?
>>> Performance is pretty dismal on u60 - can't get a medium-sized React
>>> component tree to render under 50 ms, whereas on u31 it renders in 1 ms
>>> (after ~7000 iterations).
>>>
>>> Thanks for all of your great work on Nashorn!
>>>
>>> -martin
>>>
>>> ons. 26. aug. 2015 kl. 15.41 skrev Attila Szegedi <
>>> attila.szegedi at oracle.com
>>>
>>> :
>>>
>>>
>>> Please review JDK-8134403 "Nashorn react.js benchmark performance
>>> regression" at <http://cr.openjdk.java.net/~attila/8134403/webrev.jdk9>
>>> for <https://bugs.openjdk.java.net/browse/JDK-8134403>
>>>
>>> Thanks,
>>>   Attila.
>>>
>>>
>>>


From attila.szegedi at oracle.com  Wed Sep  9 11:37:32 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 9 Sep 2015 13:37:32 +0200
Subject: RFR 8027137: Merge ScriptFunction and ScriptFunctionImpl
In-Reply-To: <55F01661.4050000@oracle.com>
References: <55EFEB81.7060404@oracle.com>
	<D1E4FF8B-CA74-47F5-82C7-C2BCFEE8AF7E@oracle.com>
	<55F01661.4050000@oracle.com>
Message-ID: <E7E7A30D-09B1-4609-A183-2D2F4B9476DD@oracle.com>

Excellent, +1.

> On Sep 9, 2015, at 1:22 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Thanks for the reviews Hannes & Attila.
> 
> I've incorporated the changes suggested. Updated webrev: http://cr.openjdk.java.net/~sundar/8027137/webrev.01/
> 
> PS. I've changed all counters (used from NativeDebug) to use LongAdder.
> 
> -Sundar
> 
> On 9/9/2015 2:57 PM, Attila Szegedi wrote:
>> Great work! I?m very happy that ScriptFunctionImpl is going away.
>> 
>> Some implementation remarks:
>> 
>> - The newly public methods in Global.java, getFunctionPrototype and getTypeErrorThrower don?t have Javadoc.
>> - The newly public two constructors of PrototypeObject also don?t hava Javadoc.
>> -  while you're at it, how about we replace ScriptFunction.constructorCount/invokes/allocations fields with LongAdder objects? We should gradually be replacing all such static counters.
>> - can we create an explicit subclass for bound functions? It can be declared as "private static class Bound extends ScriptFunction { ... }" within the ScriptFunction class. When we debug, we'll then see its name as ScriptFunction$Bound instead of ScriptFunction$1.
>> 
>> Attila.
>> 
>>> On Sep 9, 2015, at 10:19 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>> 
>>> Please review http://cr.openjdk.java.net/~sundar/8027137/ for https://bugs.openjdk.java.net/browse/JDK-8027137
>>> 
>>> Thanks,
>>> -Sundar
> 


From hannes.wallnoefer at oracle.com  Wed Sep  9 11:39:17 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 9 Sep 2015 13:39:17 +0200
Subject: RFR 8027137: Merge ScriptFunction and ScriptFunctionImpl
In-Reply-To: <55F01661.4050000@oracle.com>
References: <55EFEB81.7060404@oracle.com>
	<D1E4FF8B-CA74-47F5-82C7-C2BCFEE8AF7E@oracle.com>
	<55F01661.4050000@oracle.com>
Message-ID: <55F01A65.9080107@oracle.com>

Looks good!

Am 2015-09-09 um 13:22 schrieb Sundararajan Athijegannathan:
> Thanks for the reviews Hannes & Attila.
>
> I've incorporated the changes suggested. Updated webrev: 
> http://cr.openjdk.java.net/~sundar/8027137/webrev.01/
>
> PS. I've changed all counters (used from NativeDebug) to use LongAdder.
>
> -Sundar
>
> On 9/9/2015 2:57 PM, Attila Szegedi wrote:
>> Great work! I?m very happy that ScriptFunctionImpl is going away.
>>
>> Some implementation remarks:
>>
>> - The newly public methods in Global.java, getFunctionPrototype and 
>> getTypeErrorThrower don?t have Javadoc.
>> - The newly public two constructors of PrototypeObject also don?t 
>> hava Javadoc.
>> -  while you're at it, how about we replace 
>> ScriptFunction.constructorCount/invokes/allocations fields with 
>> LongAdder objects? We should gradually be replacing all such static 
>> counters.
>> - can we create an explicit subclass for bound functions? It can be 
>> declared as "private static class Bound extends ScriptFunction { ... 
>> }" within the ScriptFunction class. When we debug, we'll then see its 
>> name as ScriptFunction$Bound instead of ScriptFunction$1.
>>
>> Attila.
>>
>>> On Sep 9, 2015, at 10:19 AM, Sundararajan Athijegannathan 
>>> <sundararajan.athijegannathan at oracle.com> wrote:
>>>
>>> Please review http://cr.openjdk.java.net/~sundar/8027137/ for 
>>> https://bugs.openjdk.java.net/browse/JDK-8027137
>>>
>>> Thanks,
>>> -Sundar
>


From attila.szegedi at oracle.com  Wed Sep  9 13:35:36 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 9 Sep 2015 15:35:36 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for
	loading Nashorn script code
Message-ID: <BE54CAF4-021A-428B-808E-6198996E581B@oracle.com>

Please review JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code" at <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135251>

Implementation notes are in <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379 <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379>>

Thanks,
  Attila.

From forax at univ-mlv.fr  Wed Sep  9 14:40:34 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 9 Sep 2015 16:40:34 +0200 (CEST)
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for	loading Nashorn script code
In-Reply-To: <BE54CAF4-021A-428B-808E-6198996E581B@oracle.com>
References: <BE54CAF4-021A-428B-808E-6198996E581B@oracle.com>
Message-ID: <708977541.1236366.1441809634753.JavaMail.zimbra@u-pem.fr>

Hi Attila,
in your patch you're using several different host classes (i beleive one by script) and i don't understand why ?

cheers,
R?mi

On 09/09/2015 03:35 PM, Attila Szegedi wrote:
> Please review JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code" at <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135251>
>
> Implementation notes are in <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379 <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379>>
>
> Thanks,
>   Attila.


From attila.szegedi at oracle.com  Wed Sep  9 14:56:50 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 9 Sep 2015 16:56:50 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for	loading Nashorn script code
In-Reply-To: <708977541.1236366.1441809634753.JavaMail.zimbra@u-pem.fr>
References: <BE54CAF4-021A-428B-808E-6198996E581B@oracle.com>
	<708977541.1236366.1441809634753.JavaMail.zimbra@u-pem.fr>
Message-ID: <7A0A9B60-D28F-4FB1-A3EB-F5F9F2900BF8@oracle.com>

There?s one host class per CodeSource. Host classes provide their ProtectionDomain to the anonymous classes, and we must code for running under a security manager.

> On Sep 9, 2015, at 4:40 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi Attila,
> in your patch you're using several different host classes (i beleive one by script) and i don't understand why ?
> 
> cheers,
> R?mi
> 
> On 09/09/2015 03:35 PM, Attila Szegedi wrote:
>> Please review JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code" at <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135251>
>> 
>> Implementation notes are in <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379 <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379>>
>> 
>> Thanks,
>>  Attila.
> 


From forax at univ-mlv.fr  Wed Sep  9 19:05:32 2015
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 9 Sep 2015 21:05:32 +0200 (CEST)
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for	loading Nashorn script code
In-Reply-To: <7A0A9B60-D28F-4FB1-A3EB-F5F9F2900BF8@oracle.com>
References: <BE54CAF4-021A-428B-808E-6198996E581B@oracle.com>
	<708977541.1236366.1441809634753.JavaMail.zimbra@u-pem.fr>
	<7A0A9B60-D28F-4FB1-A3EB-F5F9F2900BF8@oracle.com>
Message-ID: <1774276452.1316122.1441825532699.JavaMail.zimbra@u-pem.fr>

If you create one class in an empty package (like with sun.invoke.empty.Empty) and use it as host class, it should be ok, no ?

R?mi

----- Mail original -----
> De: "Attila Szegedi" <attila.szegedi at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: nashorn-dev at openjdk.java.net
> Envoy?: Mercredi 9 Septembre 2015 16:56:50
> Objet: Re: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for	loading Nashorn script code
> 
> There?s one host class per CodeSource. Host classes provide their
> ProtectionDomain to the anonymous classes, and we must code for running
> under a security manager.
> 
> > On Sep 9, 2015, at 4:40 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> > 
> > Hi Attila,
> > in your patch you're using several different host classes (i beleive one by
> > script) and i don't understand why ?
> > 
> > cheers,
> > R?mi
> > 
> > On 09/09/2015 03:35 PM, Attila Szegedi wrote:
> >> Please review JDK-8135251 "Use Unsafe.defineAnonymousClass for loading
> >> Nashorn script code" at
> >> <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9> for
> >> <https://bugs.openjdk.java.net/browse/JDK-8135251>
> >> 
> >> Implementation notes are in
> >> <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379
> >> <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379>>
> >> 
> >> Thanks,
> >>  Attila.
> > 
> 
> 

From attila.szegedi at oracle.com  Wed Sep  9 20:43:34 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 9 Sep 2015 22:43:34 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for	loading Nashorn script code
In-Reply-To: <1774276452.1316122.1441825532699.JavaMail.zimbra@u-pem.fr>
References: <BE54CAF4-021A-428B-808E-6198996E581B@oracle.com>
	<708977541.1236366.1441809634753.JavaMail.zimbra@u-pem.fr>
	<7A0A9B60-D28F-4FB1-A3EB-F5F9F2900BF8@oracle.com>
	<1774276452.1316122.1441825532699.JavaMail.zimbra@u-pem.fr>
Message-ID: <5125C44B-B667-46BD-85DC-79F733C61DFF@oracle.com>

If I load one class from x.js and another from y.js and I have a security.policy file that says:

grant codeBase ?x.js? {
    ? some permissions ...
}

grant codeBase ?y.js? {
    ? some different permissions ...
}

then the class containing code compiled from x.js and y.js belongs to different protection domains. They can?t have the same host class. I need to create one host class with CodeSource representing the URL of x.js and one representing the URL of y.js so that a call to SecureClassLoader.defineClass(?, CodeSource) will instantiate them in appropriate protection domains based on their code source.

Attila.

> On Sep 9, 2015, at 9:05 PM, forax at univ-mlv.fr wrote:
> 
> If you create one class in an empty package (like with sun.invoke.empty.Empty) and use it as host class, it should be ok, no ?
> 
> R?mi
> 
> ----- Mail original -----
>> De: "Attila Szegedi" <attila.szegedi at oracle.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: nashorn-dev at openjdk.java.net
>> Envoy?: Mercredi 9 Septembre 2015 16:56:50
>> Objet: Re: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for	loading Nashorn script code
>> 
>> There?s one host class per CodeSource. Host classes provide their
>> ProtectionDomain to the anonymous classes, and we must code for running
>> under a security manager.
>> 
>>> On Sep 9, 2015, at 4:40 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> 
>>> Hi Attila,
>>> in your patch you're using several different host classes (i beleive one by
>>> script) and i don't understand why ?
>>> 
>>> cheers,
>>> R?mi
>>> 
>>> On 09/09/2015 03:35 PM, Attila Szegedi wrote:
>>>> Please review JDK-8135251 "Use Unsafe.defineAnonymousClass for loading
>>>> Nashorn script code" at
>>>> <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9> for
>>>> <https://bugs.openjdk.java.net/browse/JDK-8135251>
>>>> 
>>>> Implementation notes are in
>>>> <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379
>>>> <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379>>
>>>> 
>>>> Thanks,
>>>> Attila.
>>> 
>> 
>> 


From sundararajan.athijegannathan at oracle.com  Thu Sep 10 08:17:32 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 10 Sep 2015 13:47:32 +0530
Subject: [8u] approval request for 8027137, 8087292 and 8130888
Message-ID: <55F13C9C.1000302@oracle.com>

Please approve the backport of the following fixes:

Bugs:

https://bugs.openjdk.java.net/browse/JDK-8027137
https://bugs.openjdk.java.net/browse/JDK-8087292
https://bugs.openjdk.java.net/browse/JDK-8130888

jdk9 review threads:

http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005166.html
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005144.html
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-July/004914.html

jdk8u webrev:

http://cr.openjdk.java.net/~sundar/8027137_8087292_8130888/8u/webrev.00/

Mostly backported "as is" except for modular layout difference and one 
manual diff applied on ScriptClassInfoCollector.java as diffs on that 
class won't apply automatically (due to another ASM version fix changes 
- which is not backported to jdk8u - as that is not applicable to 8u).

http://cr.openjdk.java.net/~sundar/8027137_8087292_8130888/8u/webrev.00/buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java.udiff.html

CC'ing nashorn team as well.

Thanks,
-Sundar

From hannes.wallnoefer at oracle.com  Thu Sep 10 09:04:25 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 10 Sep 2015 11:04:25 +0200
Subject: [8u] approval request for 8027137, 8087292 and 8130888
In-Reply-To: <55F13C9C.1000302@oracle.com>
References: <55F13C9C.1000302@oracle.com>
Message-ID: <55F14799.80406@oracle.com>

The backport looks good to me.

Hannes

Am 2015-09-10 um 10:17 schrieb Sundararajan Athijegannathan:
> Please approve the backport of the following fixes:
>
> Bugs:
>
> https://bugs.openjdk.java.net/browse/JDK-8027137
> https://bugs.openjdk.java.net/browse/JDK-8087292
> https://bugs.openjdk.java.net/browse/JDK-8130888
>
> jdk9 review threads:
>
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005166.html 
>
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005144.html 
>
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-July/004914.html
>
> jdk8u webrev:
>
> http://cr.openjdk.java.net/~sundar/8027137_8087292_8130888/8u/webrev.00/
>
> Mostly backported "as is" except for modular layout difference and one 
> manual diff applied on ScriptClassInfoCollector.java as diffs on that 
> class won't apply automatically (due to another ASM version fix 
> changes - which is not backported to jdk8u - as that is not applicable 
> to 8u).
>
> http://cr.openjdk.java.net/~sundar/8027137_8087292_8130888/8u/webrev.00/buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java.udiff.html 
>
>
> CC'ing nashorn team as well.
>
> Thanks,
> -Sundar


From attila.szegedi at oracle.com  Thu Sep 10 09:05:32 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 10 Sep 2015 11:05:32 +0200
Subject: [8u] approval request for 8027137, 8087292 and 8130888
In-Reply-To: <55F13C9C.1000302@oracle.com>
References: <55F13C9C.1000302@oracle.com>
Message-ID: <B40C1837-BE52-4B85-A990-AF64DA2AA887@oracle.com>

+1 on the backport with its trivial changes.

> On Sep 10, 2015, at 10:17 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please approve the backport of the following fixes:
> 
> Bugs:
> 
> https://bugs.openjdk.java.net/browse/JDK-8027137
> https://bugs.openjdk.java.net/browse/JDK-8087292
> https://bugs.openjdk.java.net/browse/JDK-8130888
> 
> jdk9 review threads:
> 
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005166.html
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005144.html
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-July/004914.html
> 
> jdk8u webrev:
> 
> http://cr.openjdk.java.net/~sundar/8027137_8087292_8130888/8u/webrev.00/
> 
> Mostly backported "as is" except for modular layout difference and one manual diff applied on ScriptClassInfoCollector.java as diffs on that class won't apply automatically (due to another ASM version fix changes - which is not backported to jdk8u - as that is not applicable to 8u).
> 
> http://cr.openjdk.java.net/~sundar/8027137_8087292_8130888/8u/webrev.00/buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java.udiff.html
> 
> CC'ing nashorn team as well.
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Thu Sep 10 09:19:22 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 10 Sep 2015 11:19:22 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <BE54CAF4-021A-428B-808E-6198996E581B@oracle.com>
References: <BE54CAF4-021A-428B-808E-6198996E581B@oracle.com>
Message-ID: <55F14B1A.6080806@oracle.com>

Looks good to me.

Hannes

Am 2015-09-09 um 15:35 schrieb Attila Szegedi:
> Please review JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code" at <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135251>
>
> Implementation notes are in <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379 <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379>>
>
> Thanks,
>    Attila.


From attila.szegedi at oracle.com  Thu Sep 10 09:30:39 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 10 Sep 2015 11:30:39 +0200
Subject: Review request for JDK-8135262: Sanitize CodeInstaller API
Message-ID: <CA08ED3A-72D9-4F94-9744-A7A4EC282E51@oracle.com>

Please review JDK-8135262 "Sanitize CodeInstaller and Compiler API" at <http://cr.openjdk.java.net/~attila/8135262/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135262>

Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Thu Sep 10 09:44:40 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 10 Sep 2015 11:44:40 +0200
Subject: Review request for JDK-8135262: Sanitize CodeInstaller API
In-Reply-To: <CA08ED3A-72D9-4F94-9744-A7A4EC282E51@oracle.com>
References: <CA08ED3A-72D9-4F94-9744-A7A4EC282E51@oracle.com>
Message-ID: <55F15108.8090200@oracle.com>

+1

Am 2015-09-10 um 11:30 schrieb Attila Szegedi:
> Please review JDK-8135262 "Sanitize CodeInstaller and Compiler API" at <http://cr.openjdk.java.net/~attila/8135262/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135262>
>
> Thanks,
>    Attila.


From hannes.wallnoefer at oracle.com  Thu Sep 10 09:46:14 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 10 Sep 2015 11:46:14 +0200
Subject: Review request for JDK-8135000: Number.prototype.toFixed returns
	wrong string for 0.5 and -0.5
Message-ID: <55F15166.3030204@oracle.com>

Please review JDK-8135000: Number.prototype.toFixed returns wrong string 
for 0.5 and -0.5:

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

Thanks,
Hannes

From attila.szegedi at oracle.com  Thu Sep 10 09:47:45 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 10 Sep 2015 11:47:45 +0200
Subject: Review request for JDK-8135000: Number.prototype.toFixed returns
	wrong string for 0.5 and -0.5
In-Reply-To: <55F15166.3030204@oracle.com>
References: <55F15166.3030204@oracle.com>
Message-ID: <77A902C5-FE61-4714-B6C7-125FF95758FE@oracle.com>

+1

> On Sep 10, 2015, at 11:46 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review JDK-8135000: Number.prototype.toFixed returns wrong string for 0.5 and -0.5:
> 
> http://cr.openjdk.java.net/~hannesw/8135000/
> 
> Thanks,
> Hannes


From hannes.wallnoefer at oracle.com  Thu Sep 10 09:47:56 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 10 Sep 2015 11:47:56 +0200
Subject: Review request for JDK-8134569: Add tests for prototype callsites
Message-ID: <55F151CC.2020508@oracle.com>

Please review JDK-8134569: Add tests for prototype callsites:

http://cr.openjdk.java.net/~hannesw/8134569/webrev/

This just adds a few test cases for the nested constructor code pattern.

Thanks,
Hannes

From attila.szegedi at oracle.com  Thu Sep 10 09:58:03 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 10 Sep 2015 11:58:03 +0200
Subject: Review request for JDK-8134569: Add tests for prototype callsites
In-Reply-To: <55F151CC.2020508@oracle.com>
References: <55F151CC.2020508@oracle.com>
Message-ID: <C96B964A-A7D0-4827-B3B8-58DB0DAD0188@oracle.com>

+1

> On Sep 10, 2015, at 11:47 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review JDK-8134569: Add tests for prototype callsites:
> 
> http://cr.openjdk.java.net/~hannesw/8134569/webrev/
> 
> This just adds a few test cases for the nested constructor code pattern.
> 
> Thanks,
> Hannes


From sundararajan.athijegannathan at oracle.com  Thu Sep 10 10:33:56 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 10 Sep 2015 16:03:56 +0530
Subject: Review request for JDK-8135000: Number.prototype.toFixed returns
	wrong string for 0.5 and -0.5
In-Reply-To: <55F15166.3030204@oracle.com>
References: <55F15166.3030204@oracle.com>
Message-ID: <55F15C94.8030505@oracle.com>

+1

On 9/10/2015 3:16 PM, Hannes Wallnoefer wrote:
> Please review JDK-8135000: Number.prototype.toFixed returns wrong 
> string for 0.5 and -0.5:
>
> http://cr.openjdk.java.net/~hannesw/8135000/
>
> Thanks,
> Hannes


From sundararajan.athijegannathan at oracle.com  Thu Sep 10 10:37:15 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 10 Sep 2015 16:07:15 +0530
Subject: Review request for JDK-8135262: Sanitize CodeInstaller API
In-Reply-To: <CA08ED3A-72D9-4F94-9744-A7A4EC282E51@oracle.com>
References: <CA08ED3A-72D9-4F94-9744-A7A4EC282E51@oracle.com>
Message-ID: <55F15D5B.5050507@oracle.com>

+1

On 9/10/2015 3:00 PM, Attila Szegedi wrote:
> Please review JDK-8135262 "Sanitize CodeInstaller and Compiler API" at <http://cr.openjdk.java.net/~attila/8135262/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135262>
>
> Thanks,
>    Attila.


From rob.mckenna at oracle.com  Thu Sep 10 11:29:25 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 10 Sep 2015 12:29:25 +0100
Subject: [8u] approval request for 8027137, 8087292 and 8130888
In-Reply-To: <55F13C9C.1000302@oracle.com>
References: <55F13C9C.1000302@oracle.com>
Message-ID: <55F16995.6090702@oracle.com>

Approved

	-Rob

On 10/09/15 09:17, Sundararajan Athijegannathan wrote:
> Please approve the backport of the following fixes:
>
> Bugs:
>
> https://bugs.openjdk.java.net/browse/JDK-8027137
> https://bugs.openjdk.java.net/browse/JDK-8087292
> https://bugs.openjdk.java.net/browse/JDK-8130888
>
> jdk9 review threads:
>
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005166.html
>
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005144.html
>
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-July/004914.html
>
> jdk8u webrev:
>
> http://cr.openjdk.java.net/~sundar/8027137_8087292_8130888/8u/webrev.00/
>
> Mostly backported "as is" except for modular layout difference and one
> manual diff applied on ScriptClassInfoCollector.java as diffs on that
> class won't apply automatically (due to another ASM version fix changes
> - which is not backported to jdk8u - as that is not applicable to 8u).
>
> http://cr.openjdk.java.net/~sundar/8027137_8087292_8130888/8u/webrev.00/buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java.udiff.html
>
>
> CC'ing nashorn team as well.
>
> Thanks,
> -Sundar

From forax at univ-mlv.fr  Thu Sep 10 11:44:54 2015
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 10 Sep 2015 13:44:54 +0200 (CEST)
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for	loading Nashorn script code
In-Reply-To: <5125C44B-B667-46BD-85DC-79F733C61DFF@oracle.com>
References: <BE54CAF4-021A-428B-808E-6198996E581B@oracle.com>
	<708977541.1236366.1441809634753.JavaMail.zimbra@u-pem.fr>
	<7A0A9B60-D28F-4FB1-A3EB-F5F9F2900BF8@oracle.com>
	<1774276452.1316122.1441825532699.JavaMail.zimbra@u-pem.fr>
	<5125C44B-B667-46BD-85DC-79F733C61DFF@oracle.com>
Message-ID: <712874206.1529933.1441885494547.JavaMail.zimbra@u-pem.fr>

Ok,
i see, you need at least one host class by security.policy file.

R?mi

On 09/09/2015 10:43 PM, Attila Szegedi wrote:
> If I load one class from x.js and another from y.js and I have a security.policy file that says:
>
> grant codeBase ?x.js? {
>     ? some permissions ...
> }
>
> grant codeBase ?y.js? {
>     ? some different permissions ...
> }
>
> then the class containing code compiled from x.js and y.js belongs to different protection domains. They can?t have the same host class. I need to create one host class with CodeSource representing the URL of x.js and one representing the URL of y.js so that a call to SecureClassLoader.defineClass(?, CodeSource) will instantiate them in appropriate protection domains based on their code source.
>
> Attila.
>
>> On Sep 9, 2015, at 9:05 PM, forax at univ-mlv.fr wrote:
>>
>> If you create one class in an empty package (like with sun.invoke.empty.Empty) and use it as host class, it should be ok, no ?
>>
>> R?mi
>>
>> ----- Mail original -----
>>> De: "Attila Szegedi" <attila.szegedi at oracle.com>
>>> ?: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: nashorn-dev at openjdk.java.net
>>> Envoy?: Mercredi 9 Septembre 2015 16:56:50
>>> Objet: Re: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for	loading Nashorn script code
>>>
>>> There?s one host class per CodeSource. Host classes provide their
>>> ProtectionDomain to the anonymous classes, and we must code for running
>>> under a security manager.
>>>
>>>> On Sep 9, 2015, at 4:40 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>>>
>>>> Hi Attila,
>>>> in your patch you're using several different host classes (i beleive one by
>>>> script) and i don't understand why ?
>>>>
>>>> cheers,
>>>> R?mi
>>>>
>>>> On 09/09/2015 03:35 PM, Attila Szegedi wrote:
>>>>> Please review JDK-8135251 "Use Unsafe.defineAnonymousClass for loading
>>>>> Nashorn script code" at
>>>>> <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9> for
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8135251>
>>>>>
>>>>> Implementation notes are in
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379>>
>>>>>
>>>>> Thanks,
>>>>> Attila.
>>>>
>>>
>>>
>


From sundararajan.athijegannathan at oracle.com  Thu Sep 10 11:45:49 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 10 Sep 2015 17:15:49 +0530
Subject: RFR 8135332: ScriptFunction constructor should use is bound and is
	strict check rather than checking for 'arguments' and 'caller'
Message-ID: <55F16D6D.1000900@oracle.com>

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

Thanks,
-Sundar

From attila.szegedi at oracle.com  Thu Sep 10 11:58:59 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 10 Sep 2015 13:58:59 +0200
Subject: RFR 8135332: ScriptFunction constructor should use is bound and
	is strict check rather than checking for 'arguments' and 'caller'
In-Reply-To: <55F16D6D.1000900@oracle.com>
References: <55F16D6D.1000900@oracle.com>
Message-ID: <903DE150-32B1-4DB9-A7C1-BCDDECCFEDD3@oracle.com>

+1

> On Sep 10, 2015, at 1:45 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8135332/ for https://bugs.openjdk.java.net/browse/JDK-8135332
> 
> Thanks,
> -Sundar


From asashour at yahoo.com  Thu Sep 10 12:27:22 2015
From: asashour at yahoo.com (Ahmed Ashour)
Date: Thu, 10 Sep 2015 12:27:22 +0000 (UTC)
Subject: NativeDebug.dumpCounters with incorrect scope count
Message-ID: <346271245.338265.1441888042838.JavaMail.yahoo@mail.yahoo.com>

Hi all,

In NativeDebug.dumpCounters(), there is: 


out.println("Scope count " + Scope.getCount());

However, Scope doesn't have its own .getCount(), but calls the super (ScriptObject) one.

I think Scope.getScopeCount() should be used instead.

Thanks,
Ahmed

From attila.szegedi at oracle.com  Thu Sep 10 12:36:41 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 10 Sep 2015 14:36:41 +0200
Subject: Review request for JDK-8135336: Fix broken build after JDK-8135262
Message-ID: <B1E32A50-0601-4144-A908-FB7E8BD826C7@oracle.com>

Please review JDK-8135336 "Fix broken build after JDK-8135262" at <http://cr.openjdk.java.net/~attila/8135336/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135336>

Thanks,
  Attila.

From attila.szegedi at oracle.com  Thu Sep 10 12:38:51 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 10 Sep 2015 14:38:51 +0200
Subject: NativeDebug.dumpCounters with incorrect scope count
In-Reply-To: <346271245.338265.1441888042838.JavaMail.yahoo@mail.yahoo.com>
References: <346271245.338265.1441888042838.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <6BCC06CB-7F92-4A74-9CFC-DE330E0ECC12@oracle.com>

Looks like you?re right. I registered this as https://bugs.openjdk.java.net/browse/JDK-8135337 <https://bugs.openjdk.java.net/browse/JDK-8135337>

Thanks,
  Attila.

> On Sep 10, 2015, at 2:27 PM, Ahmed Ashour <asashour at yahoo.com> wrote:
> 
> Hi all,
> 
> In NativeDebug.dumpCounters(), there is: 
> 
> 
> out.println("Scope count " + Scope.getCount());
> 
> However, Scope doesn't have its own .getCount(), but calls the super (ScriptObject) one.
> 
> I think Scope.getScopeCount() should be used instead.
> 
> Thanks,
> Ahmed


From attila.szegedi at oracle.com  Thu Sep 10 12:48:07 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 10 Sep 2015 14:48:07 +0200
Subject: Review request for JDK-8135337: NativeDebug.dumpCounters with
	incorrect scope count
Message-ID: <8532E31B-C7C3-4747-BAF6-CA21F08A56F3@oracle.com>

Please review JDK-8135337 "NativeDebug.dumpCounters with incorrect scope count" at <http://cr.openjdk.java.net/~attila/8135337/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135337>

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Thu Sep 10 13:02:17 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 10 Sep 2015 18:32:17 +0530
Subject: Review request for JDK-8135337: NativeDebug.dumpCounters with
	incorrect scope count
In-Reply-To: <8532E31B-C7C3-4747-BAF6-CA21F08A56F3@oracle.com>
References: <8532E31B-C7C3-4747-BAF6-CA21F08A56F3@oracle.com>
Message-ID: <55F17F59.30807@oracle.com>

+1

On 9/10/2015 6:18 PM, Attila Szegedi wrote:
> Please review JDK-8135337 "NativeDebug.dumpCounters with incorrect scope count" at <http://cr.openjdk.java.net/~attila/8135337/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135337>
>
> Thanks,
>    Attila.


From hannes.wallnoefer at oracle.com  Thu Sep 10 13:19:04 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 10 Sep 2015 15:19:04 +0200
Subject: RFR 8135332: ScriptFunction constructor should use is bound and
	is strict check rather than checking for 'arguments' and 'caller'
In-Reply-To: <55F16D6D.1000900@oracle.com>
References: <55F16D6D.1000900@oracle.com>
Message-ID: <55F18348.3010700@oracle.com>

+1

Am 2015-09-10 um 13:45 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8135332/ for 
> https://bugs.openjdk.java.net/browse/JDK-8135332
>
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Thu Sep 10 13:23:41 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 10 Sep 2015 18:53:41 +0530
Subject: Review request for JDK-8135336: Fix broken build after JDK-8135262
In-Reply-To: <B1E32A50-0601-4144-A908-FB7E8BD826C7@oracle.com>
References: <B1E32A50-0601-4144-A908-FB7E8BD826C7@oracle.com>
Message-ID: <55F1845D.8070007@oracle.com>

+1

On 9/10/2015 6:06 PM, Attila Szegedi wrote:
> Please review JDK-8135336 "Fix broken build after JDK-8135262" at <http://cr.openjdk.java.net/~attila/8135336/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135336>
>
> Thanks,
>    Attila.


From hannes.wallnoefer at oracle.com  Thu Sep 10 13:25:46 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 10 Sep 2015 15:25:46 +0200
Subject: Review request for JDK-8135336: Fix broken build after JDK-8135262
In-Reply-To: <B1E32A50-0601-4144-A908-FB7E8BD826C7@oracle.com>
References: <B1E32A50-0601-4144-A908-FB7E8BD826C7@oracle.com>
Message-ID: <55F184DA.2030503@oracle.com>

+1

Am 2015-09-10 um 14:36 schrieb Attila Szegedi:
> Please review JDK-8135336 "Fix broken build after JDK-8135262" at <http://cr.openjdk.java.net/~attila/8135336/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135336>
>
> Thanks,
>    Attila.


From hannes.wallnoefer at oracle.com  Thu Sep 10 13:25:58 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 10 Sep 2015 15:25:58 +0200
Subject: Review request for JDK-8135337: NativeDebug.dumpCounters with
	incorrect scope count
In-Reply-To: <8532E31B-C7C3-4747-BAF6-CA21F08A56F3@oracle.com>
References: <8532E31B-C7C3-4747-BAF6-CA21F08A56F3@oracle.com>
Message-ID: <55F184E6.6040305@oracle.com>

+1

Am 2015-09-10 um 14:48 schrieb Attila Szegedi:
> Please review JDK-8135337 "NativeDebug.dumpCounters with incorrect scope count" at <http://cr.openjdk.java.net/~attila/8135337/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135337>
>
> Thanks,
>    Attila.


From asashour at yahoo.com  Thu Sep 10 20:06:57 2015
From: asashour at yahoo.com (Ahmed Ashour)
Date: Thu, 10 Sep 2015 22:06:57 +0200
Subject: [PATCH] Some typos
Message-ID: <55F1E2E1.5040901@yahoo.com>

Dear all,

Please find below patch, which:
     - Handles some typos
     - Removes unused imports from two files.

Also, there are other potential places to modify (if appropriate):
     - WarnCallback: references '@gmail.com' in @author, this is the 
only place, which looks strange.
     - 'behavior' could be 'behavior': there are three places.

Hope you find it useful.

Yours,
Ahmed


diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -117,7 +117,7 @@
   *         return factory.createLinker();
   *     }
   *
- *     public static CallSite bootstrap(MethodHandles.Lookup caller, 
String name, MethodType type) {
+ *     public static CallSite bootstrap(MethodHandles.Lookup lookup, 
String name, MethodType type) {
   *         return dynamicLinker.link(new 
MonomorphicCallSite(CallSiteDescriptorFactory.create(lookup, name, type)));
   *     }
   * }
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -152,7 +152,7 @@
      boolean isAccessible(final Member m) {
          final Class<?> declaring = m.getDeclaringClass();
          // (declaring == clazz) is just an optimization - we're 
calling this only from code that operates on a
-        // non-restriced class, so if the declaring class is identical 
to the class being inspected, then forego
+        // non-restricted class, so if the declaring class is identical 
to the class being inspected, then forego
          // a potentially expensive restricted-package check.
          return declaring == clazz || 
!CheckRestrictedPackage.isRestrictedClass(declaring);
      }
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -98,7 +98,6 @@
   * target method to a call site type (including mapping variable arity 
methods to a call site signature with different
   * arity).
   * @author Attila Szegedi
- * @version $Id: $
   */
  abstract class SingleDynamicMethod extends DynamicMethod {

diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -353,7 +353,7 @@

      /**
       * Applies argument filters to both the invocation and the guard 
(if there is one).
-     * @param pos the position of the first argumen being filtered
+     * @param pos the position of the first argument being filtered
       * @param filters the argument filters
       * @return a filtered invocation
       */
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -110,7 +110,7 @@

      /**
       * Check if invocation is cacheable
-     * @return true if cachable, false otherwise
+     * @return true if cacheable, false otherwise
       */
      public boolean isCacheable() {
          return cacheable;
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/URLReader.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/URLReader.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/URLReader.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -103,7 +103,7 @@
      /**
       * Charset used by this reader
       *
-     * @return the Chartset used to convert bytes to chars
+     * @return the Charset used to convert bytes to chars
       */
      public Charset getCharset() {
          return cs;
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/Parser.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/Parser.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/Parser.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -80,7 +80,7 @@
      public CompilationUnitTree parse(final URL url, final 
DiagnosticListener listener) throws IOException, NashornException;

      /**
-     * Parses the readerand returns compilation unit tree
+     * Parses the reader and returns compilation unit tree
       *
       * @param name name of the source file to parse
       * @param reader from which source is read
@@ -133,7 +133,7 @@
       * <dt>"-strict"</dt><dd>enable ECMAScript strict mode</dd>
       * </dl>
       *
-     * @throws NullPointerException if options arrry or any of it's 
element is null
+     * @throws NullPointerException if options array or any of it's 
element is null
       * @throws IllegalArgumentException on unsupported option value.
       * @return a new Parser instance.
       */
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/RegExpLiteralTree.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/RegExpLiteralTree.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/RegExpLiteralTree.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -35,7 +35,7 @@
      /**
       * Regular expression pattern to match.
       *
-     * @return regular expression patten
+     * @return regular expression pattern
       */
      public String getPattern();

diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -244,7 +244,7 @@

      /**
       * Creates a synthetic initializer for a variable (a var statement 
that doesn't occur in the source code). Typically
-     * used to create assignmnent of {@code :callee} to the function 
name symbol in self-referential function
+     * used to create assignment of {@code :callee} to the function 
name symbol in self-referential function
       * expressions as well as for assignment of {@code :arguments} to 
{@code arguments}.
       *
       * @param name the ident node identifying the variable to initialize
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -1494,7 +1494,7 @@
                      int argsCount;
                      @Override
                      void loadStack() {
-                        /**
+                        /*
                           * We want to load 'eval' to check if it is 
indeed global builtin eval.
                           * If this eval call is inside a 'with' 
statement, dyn:getMethod|getProp|getElem
                           * would be generated if ident is a 
"isFunction". But, that would result in a
@@ -4329,7 +4329,7 @@
          }

          private void prologue() {
-            /**
+            /*
               * This loads the parts of the target, e.g base and index. 
they are kept
               * on the stack throughout the store and used at the end 
to execute it
               */
@@ -4797,7 +4797,7 @@
           * conversion has no side effects.
           * @param name the name of the property being get
           * @param flags call site flags
-         * @param isMethod whether we're preferrably retrieving a function
+         * @param isMethod whether we're preferably retrieving a function
           * @return the current method emitter
           */
          MethodEmitter dynamicGet(final String name, final int flags, 
final boolean isMethod, final boolean isIndex) {
@@ -5229,7 +5229,7 @@
          private Type returnValueType;
          // If we are in the middle of an object literal 
initialization, we need to update the map
          private PropertyMap objectLiteralMap;
-        // Object literal stack depth for object literal - not 
necessarly top if property is a tree
+        // Object literal stack depth for object literal - not 
necessarily top if property is a tree
          private int objectLiteralStackDepth = -1;
          // The line number at the continuation point
          private int lineNumber;
@@ -5394,7 +5394,7 @@
                  method.load(lvarTypes.get(slot), slot);
                  method.convert(stackTypes[i]);
                  // stack: s0=object literal being initialized
-                // change map of s0 so that the property we are 
initilizing when we failed
+                // change map of s0 so that the property we are 
initializing when we failed
                  // is now ci.returnValueType
                  if (i == objectLiteralStackDepth) {
                      method.dup();
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -745,7 +745,7 @@
      abstract FunctionNode transform(final Compiler compiler, final 
CompilationPhases phases, final FunctionNode functionNode) throws 
CompilationException;

      /**
-     * Apply a transform to a function node, returning the transfored 
function node. If the transform is not
+     * Apply a transform to a function node, returning the transformed 
function node. If the transform is not
       * applicable, an exception is thrown. Every transform requires 
the function to have a certain number of
       * states to operate. It can have more states set, but not fewer. 
The state list, i.e. the constructor
       * arguments to any of the CompilationPhase enum entries, is a set 
of REQUIRED states.
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilerConstants.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilerConstants.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilerConstants.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -192,7 +192,7 @@
      private static Set<String> symbolNames;

      /**
-     * Prefix used for internal methods generated in script clases.
+     * Prefix used for internal methods generated in script classes.
       */
      private static final String INTERNAL_METHOD_PREFIX = ":";

@@ -225,7 +225,7 @@
      }

      /**
-     * Check whether a name is that of a reserved compiler constnat
+     * Check whether a name is that of a reserved compiler constant
       * @param name name
       * @return true if compiler constant name
       */
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -521,7 +521,7 @@
          }

          /*
-         * create a new trynode
+         * create a new try node
           *    if we have catches:
           *
           *    try            try
@@ -532,7 +532,7 @@
           *                   catchall
           *                        rethrow
           *
-         *   otheriwse
+         *   otherwise
           *
           *   try              try
           *      x               x
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -1158,7 +1158,7 @@
      /**
       * Pop a value from the stack and store it in a variable denoted 
by the given symbol. The variable should be either
       * a local variable, or a function parameter (and not a scoped 
variable). For local variables, this method will also
-     * do the bookeeping of the local variable table as well as mark 
values in all alternative slots for the symbol as
+     * do the bookkeeping of the local variable table as well as mark 
values in all alternative slots for the symbol as
       * dead. In this regard it differs from {@link #storeHidden(Type, 
int)}.
       *
       * @param symbol the symbol to store into.
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ObjectClassGenerator.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ObjectClassGenerator.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ObjectClassGenerator.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -786,7 +786,7 @@
       * @param primitiveSetter   primitive setter for the current type 
with an element of the current type
       * @param objectSetter      the object setter
       *
-     * @return method handle that checks if the element to be set is of 
the currenttype, even though it's boxed
+     * @return method handle that checks if the element to be set is of 
the current type, even though it's boxed
       *  and instead of using the generic object setter, that would 
blow up the type and invalidate the map,
       *  unbox it and call the primitive setter instead
       */
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/BytecodeOps.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/BytecodeOps.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/BytecodeOps.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -36,7 +36,7 @@
   * The bytecode ops are coupled to a MethodVisitor from ASM for
   * byte code generation. They know nothing about our MethodGenerator,
   * which is the abstraction for working with Nashorn JS types
- * For exmaple, anything like "two or one slots" for a type, which
+ * For example, anything like "two or one slots" for a type, which
   * is represented in bytecode and ASM, is abstracted away in the
   * MethodGenerator. There you just say "dup" or "store".
   *
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BlockLexicalContext.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BlockLexicalContext.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BlockLexicalContext.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -34,7 +34,7 @@
   * This is a subclass of lexical context used for filling
   * blocks (and function nodes) with statements. When popping
   * a block from the lexical context, any statements that have
- * been generated in it are commited to the block. This saves
+ * been generated in it are committed to the block. This saves
   * unnecessary object mutations and lexical context replacement
   */
  public class BlockLexicalContext extends LexicalContext {
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -452,7 +452,7 @@
       *
       * @param token   token
       * @param finish  finish
-     * @param value   undefined value, passed only for polymorphisism 
discrimination
+     * @param value   undefined value, passed only for polymorphism 
discrimination
       *
       * @return the new literal node
       */
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -276,7 +276,7 @@
           *
           * @param request a request
           *
-         * @return the inverted rquest, or null if not applicable
+         * @return the inverted request, or null if not applicable
           */
          public static Request invert(final Request request) {
              switch (request) {
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornClassReader.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornClassReader.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornClassReader.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -36,7 +36,7 @@
  import jdk.nashorn.internal.ir.debug.NashornTextifier.NashornLabel;

  /**
- * Subclass of the ASM classs reader that retains more info, such
+ * Subclass of the ASM class reader that retains more info, such
   * as bytecode offsets
   */
  public class NashornClassReader extends ClassReader {
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -193,7 +193,7 @@
      }

      /**
-     * Get the class histograpm
+     * Get the class histogram
       * @return class histogram element list
       */
      public List<ClassHistogramElement> getClassHistogram() {
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayBufferView.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayBufferView.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayBufferView.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -192,7 +192,7 @@
          /**
           * Factory method for array data
           *
-         * @param nb    underlying nativebuffer
+         * @param nb    underlying native buffer
           * @param start start element
           * @param end   end element
           *
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -2166,7 +2166,7 @@

          // We want to avoid adding our generic lexical scope 
switchpoint to global constant invocations,
          // because those are invalidated per-key in the 
addBoundProperties method above.
-        // We therefor check if the invocation does already have a 
switchpoint and the property is non-inherited,
+        // We therefore check if the invocation does already have a 
switchpoint and the property is non-inherited,
          // assuming this only applies to global constants. If other 
non-inherited properties will
          // start using switchpoints some time in the future we'll have 
to revisit this.
          if (isScope && context.getEnv()._es6 && 
(invocation.getSwitchPoints() == null || !hasOwnProperty(name))) {
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -728,7 +728,7 @@
           *
           * $$ -> $
           * $& -> the matched substring
-         * $` -> the portion of string that preceeds matched substring
+         * $` -> the portion of string that preceds matched substring
           * $' -> the portion of string that follows the matched substring
           * $n -> the nth capture, where n is [1-9] and $n is NOT 
followed by a decimal digit
           * $nn -> the nnth capture, where nn is a two digit decimal 
number [01-99].
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -808,7 +808,7 @@
                                  if (!oldStrictMode && directiveStmts 
!= null) {
                                      // check that directives preceding 
this one do not violate strictness
                                      for (final Node statement : 
directiveStmts) {
-                                        // the get value will force 
unescape of preceeding
+                                        // the get value will force 
unescape of preceding
                                          // escaped string directives
getValue(statement.getToken());
                                      }
@@ -2507,7 +2507,7 @@
          //         run: function() { println("run"); }
          //     };
          //
-        // The object literal following the "new Constructor()" expresssion
+        // The object literal following the "new Constructor()" expression
          // is passed as an additional (last) argument to the constructor.
          if (!env._no_syntax_extensions && type == LBRACE) {
              arguments.add(objectLiteral());
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextBaseNode.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextBaseNode.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextBaseNode.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -90,7 +90,7 @@
      }

      /**
-     * Adds a Statement at the end of the Statementlist
+     * Adds a statement at the end of the statement list
       * @param statement The statement to add
       */
      @Override
@@ -99,7 +99,7 @@
      }

      /**
-     * Adds a statement at the begining of the statementlist
+     * Adds a statement at the beginning of the statement list
       * @param statement The statement to add
       */
      @Override
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextNode.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextNode.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextNode.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -53,13 +53,13 @@
      public void setStatements(final List<Statement> statements);

      /**
-     * Adds a Statement at the end of the Statementlist
+     * Adds a statement at the end of the statement list
       * @param statement The statement to add
       */
      public void appendStatement(final Statement statement);

      /**
-     * Adds a statement at the begining of the statementlist
+     * Adds a statement at the beginning of the statement list
       * @param statement The statement to add
       */
      public void prependStatement(final Statement statement);
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -102,7 +102,7 @@
              /*
               * An optimistic builtin with isOptimistic=true works like 
any optimistic generated function, i.e. it
               * can throw unwarranted optimism exceptions. As native 
functions trivially can't have parts of them
-             * regenerated as restof methods, this only works if the 
methods are atomic/functional in their behavior
+             * regenerated as rest of methods, this only works if the 
methods are atomic/functional in their behavior
               * and doesn't modify state before an UOE can be thrown. 
If they aren't, we can reexecute a wider version
               * of the same builtin in a recompilation handler for 
FinalScriptFunctionData. There are several
               * candidate methods in Native* that would benefit from 
this, but I haven't had time to implement any
@@ -567,7 +567,7 @@
              return handle;
          }

-        // Otherwise, we need a new level of indirection; need to 
introduce a mutable call site that can relink itslef
+        // Otherwise, we need a new level of indirection; need to 
introduce a mutable call site that can relink itself
          // to the compiled function's changed target whenever the 
optimistic assumptions are invalidated.
          final CallSite cs = new MutableCallSite(handle.type());
          relinkComposableInvoker(cs, this, isConstructor);
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -153,7 +153,7 @@
       * Currently we are conservative and associate the name of a 
builtin class with all
       * its properties, so it's enough to invalidate a property to 
break all assumptions
       * about a prototype. This can be changed to a more fine grained 
approach, but no one
-     * ever needs this, given the very rare occurance of swapping out 
only parts of
+     * ever needs this, given the very rare occurrence of swapping out 
only parts of
       * a builtin v.s. the entire builtin object
       */
      private final Map<String, SwitchPoint> builtinSwitchPoints = new 
HashMap<>();
@@ -1475,7 +1475,7 @@
       * @param level            log level
       * @param mh               method handle
       * @param paramStart       first parameter to print
-     * @param printReturnValue should we print the return vaulue?
+     * @param printReturnValue should we print the return value?
       * @param text             debug printout to add
       *
       * @return instrumented method handle, or null if logger not enabled
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -297,4 +297,3 @@
      }

  }
-
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -67,7 +67,7 @@
   *
   * Thus everything registered as a global constant gets an extra 
chance. Set once,
   * reregister the switchpoint. Set twice or more - don't try again 
forever, or we'd
- * just end up relinking our way into megamorphisism.
+ * just end up relinking our way into megamorphism.
   *
   * Also it has to be noted that this kind of linking creates a 
coupling between a Global
   * and the call sites in compiled code belonging to the Context. For 
this reason, the
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -26,7 +26,6 @@
  package jdk.nashorn.internal.runtime;

  import java.lang.invoke.MethodHandle;
-import java.util.Iterator;
  import java.util.concurrent.Callable;
  import jdk.nashorn.internal.objects.Global;
  import jdk.nashorn.internal.parser.JSONParser;
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -1967,7 +1967,7 @@
      /**
       * Get the unboxed (primitive) type for an object
       * @param o object
-     * @return primive type or Object.class if not primitive
+     * @return primitive type or Object.class if not primitive
       */
      public static Class<?> unboxedFieldType(final Object o) {
          if (o == null) {
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ParserException.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ParserException.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ParserException.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -38,7 +38,7 @@
      private final Source source;
      // token responsible for this exception
      private final long token;
-    // if this is traslated as ECMA error, which type should be used?
+    // if this is translated as ECMA error, which type should be used?
      private final JSErrorType errorType;

      /**
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -191,7 +191,7 @@

      /**
       * Return element setter for a {@link ContinuousArrayData}
-     * @param clazz        clazz for exact type guard
+     * @param clazz        class for exact type guard
       * @param setHas       set has guard
       * @param elementType  element type
       * @return method handle for element setter
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -34,7 +34,7 @@
   * This filter handles the presence of undefined array elements.
   */
  final class UndefinedArrayFilter extends ArrayFilter {
-    /** Bit vector tracking undefines. */
+    /** Bit vector tracking undefineds. */
      private final BitVector undefined;

      UndefinedArrayFilter(final ArrayData underlying) {
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -26,7 +26,6 @@
  package jdk.nashorn.internal.runtime.linker;

  import static jdk.nashorn.internal.lookup.Lookup.MH;
-import static jdk.nashorn.internal.runtime.ECMAErrors.typeError;

  import java.lang.invoke.MethodHandle;
  import java.lang.invoke.MethodHandles;
@@ -42,13 +41,11 @@
  import jdk.internal.dynalink.linker.LinkerServices;
  import jdk.internal.dynalink.linker.MethodHandleTransformer;
  import jdk.internal.dynalink.support.DefaultInternalObjectFilter;
-import jdk.internal.dynalink.support.Guards;
  import jdk.internal.dynalink.support.Lookup;
  import jdk.nashorn.api.scripting.ScriptUtils;
  import jdk.nashorn.internal.runtime.ConsString;
  import jdk.nashorn.internal.runtime.Context;
  import jdk.nashorn.internal.runtime.ScriptObject;
-import jdk.nashorn.internal.runtime.ScriptRuntime;
  import jdk.nashorn.internal.runtime.options.Options;

  /**
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Config.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Config.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Config.java 
Thu Sep 10 18:56:56 2015 +0200
@@ -65,7 +65,7 @@

      final boolean DONT_OPTIMIZE                     = false;

-    final boolean USE_STRING_TEMPLATES              = true; // use 
embeded string templates in Regex object as byte arrays instead of 
compiling them into int bytecode array
+    final boolean USE_STRING_TEMPLATES              = true; // use 
embedded string templates in Regex object as byte arrays instead of 
compiling them into int bytecode array

      final boolean NON_UNICODE_SDW                   = true;

diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js 
Thu Sep 10 18:56:56 2015 +0200
@@ -55,7 +55,7 @@
                  // do not start with '/'. If regexp, then eval it to 
make RegExp object
                  return value.startsWith('/')? eval(value) : 
value.substring(1);
              } else {
-                // anythin else is returned "as is""
+                // anything else is returned "as is"
                  return value;
              }
          });


From james.laskey at oracle.com  Thu Sep 10 20:38:52 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Thu, 10 Sep 2015 17:38:52 -0300
Subject: [PATCH] Some typos
In-Reply-To: <55F1E2E1.5040901@yahoo.com>
References: <55F1E2E1.5040901@yahoo.com>
Message-ID: <F51D563B-5737-4800-A168-2E1199E3768C@oracle.com>

Ahmed,

Before we can accept these changes, we need to verify that you have completed a Oracle Contributor Agreement. http://www.oracle.com/technetwork/community/oca-486395.html

Cheers,

? Jim



> On Sep 10, 2015, at 5:06 PM, Ahmed Ashour <asashour at yahoo.com> wrote:
> 
> Dear all,
> 
> Please find below patch, which:
>    - Handles some typos
>    - Removes unused imports from two files.
> 
> Also, there are other potential places to modify (if appropriate):
>    - WarnCallback: references '@gmail.com' in @author, this is the only place, which looks strange.
>    - 'behavior' could be 'behavior': there are three places.
> 
> Hope you find it useful.
> 
> Yours,
> Ahmed
> 
> 
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java Thu Sep 10 18:56:56 2015 +0200
> @@ -117,7 +117,7 @@
>  *         return factory.createLinker();
>  *     }
>  *
> - *     public static CallSite bootstrap(MethodHandles.Lookup caller, String name, MethodType type) {
> + *     public static CallSite bootstrap(MethodHandles.Lookup lookup, String name, MethodType type) {
>  *         return dynamicLinker.link(new MonomorphicCallSite(CallSiteDescriptorFactory.create(lookup, name, type)));
>  *     }
>  * }
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java Thu Sep 10 18:56:56 2015 +0200
> @@ -152,7 +152,7 @@
>     boolean isAccessible(final Member m) {
>         final Class<?> declaring = m.getDeclaringClass();
>         // (declaring == clazz) is just an optimization - we're calling this only from code that operates on a
> -        // non-restriced class, so if the declaring class is identical to the class being inspected, then forego
> +        // non-restricted class, so if the declaring class is identical to the class being inspected, then forego
>         // a potentially expensive restricted-package check.
>         return declaring == clazz || !CheckRestrictedPackage.isRestrictedClass(declaring);
>     }
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java Thu Sep 10 18:56:56 2015 +0200
> @@ -98,7 +98,6 @@
>  * target method to a call site type (including mapping variable arity methods to a call site signature with different
>  * arity).
>  * @author Attila Szegedi
> - * @version $Id: $
>  */
> abstract class SingleDynamicMethod extends DynamicMethod {
> 
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java Thu Sep 10 18:56:56 2015 +0200
> @@ -353,7 +353,7 @@
> 
>     /**
>      * Applies argument filters to both the invocation and the guard (if there is one).
> -     * @param pos the position of the first argumen being filtered
> +     * @param pos the position of the first argument being filtered
>      * @param filters the argument filters
>      * @return a filtered invocation
>      */
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java Thu Sep 10 18:56:56 2015 +0200
> @@ -110,7 +110,7 @@
> 
>     /**
>      * Check if invocation is cacheable
> -     * @return true if cachable, false otherwise
> +     * @return true if cacheable, false otherwise
>      */
>     public boolean isCacheable() {
>         return cacheable;
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/URLReader.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/URLReader.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/URLReader.java Thu Sep 10 18:56:56 2015 +0200
> @@ -103,7 +103,7 @@
>     /**
>      * Charset used by this reader
>      *
> -     * @return the Chartset used to convert bytes to chars
> +     * @return the Charset used to convert bytes to chars
>      */
>     public Charset getCharset() {
>         return cs;
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/Parser.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/Parser.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/Parser.java Thu Sep 10 18:56:56 2015 +0200
> @@ -80,7 +80,7 @@
>     public CompilationUnitTree parse(final URL url, final DiagnosticListener listener) throws IOException, NashornException;
> 
>     /**
> -     * Parses the readerand returns compilation unit tree
> +     * Parses the reader and returns compilation unit tree
>      *
>      * @param name name of the source file to parse
>      * @param reader from which source is read
> @@ -133,7 +133,7 @@
>      * <dt>"-strict"</dt><dd>enable ECMAScript strict mode</dd>
>      * </dl>
>      *
> -     * @throws NullPointerException if options arrry or any of it's element is null
> +     * @throws NullPointerException if options array or any of it's element is null
>      * @throws IllegalArgumentException on unsupported option value.
>      * @return a new Parser instance.
>      */
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/RegExpLiteralTree.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/RegExpLiteralTree.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/RegExpLiteralTree.java Thu Sep 10 18:56:56 2015 +0200
> @@ -35,7 +35,7 @@
>     /**
>      * Regular expression pattern to match.
>      *
> -     * @return regular expression patten
> +     * @return regular expression pattern
>      */
>     public String getPattern();
> 
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java Thu Sep 10 18:56:56 2015 +0200
> @@ -244,7 +244,7 @@
> 
>     /**
>      * Creates a synthetic initializer for a variable (a var statement that doesn't occur in the source code). Typically
> -     * used to create assignmnent of {@code :callee} to the function name symbol in self-referential function
> +     * used to create assignment of {@code :callee} to the function name symbol in self-referential function
>      * expressions as well as for assignment of {@code :arguments} to {@code arguments}.
>      *
>      * @param name the ident node identifying the variable to initialize
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java Thu Sep 10 18:56:56 2015 +0200
> @@ -1494,7 +1494,7 @@
>                     int argsCount;
>                     @Override
>                     void loadStack() {
> -                        /**
> +                        /*
>                          * We want to load 'eval' to check if it is indeed global builtin eval.
>                          * If this eval call is inside a 'with' statement, dyn:getMethod|getProp|getElem
>                          * would be generated if ident is a "isFunction". But, that would result in a
> @@ -4329,7 +4329,7 @@
>         }
> 
>         private void prologue() {
> -            /**
> +            /*
>              * This loads the parts of the target, e.g base and index. they are kept
>              * on the stack throughout the store and used at the end to execute it
>              */
> @@ -4797,7 +4797,7 @@
>          * conversion has no side effects.
>          * @param name the name of the property being get
>          * @param flags call site flags
> -         * @param isMethod whether we're preferrably retrieving a function
> +         * @param isMethod whether we're preferably retrieving a function
>          * @return the current method emitter
>          */
>         MethodEmitter dynamicGet(final String name, final int flags, final boolean isMethod, final boolean isIndex) {
> @@ -5229,7 +5229,7 @@
>         private Type returnValueType;
>         // If we are in the middle of an object literal initialization, we need to update the map
>         private PropertyMap objectLiteralMap;
> -        // Object literal stack depth for object literal - not necessarly top if property is a tree
> +        // Object literal stack depth for object literal - not necessarily top if property is a tree
>         private int objectLiteralStackDepth = -1;
>         // The line number at the continuation point
>         private int lineNumber;
> @@ -5394,7 +5394,7 @@
>                 method.load(lvarTypes.get(slot), slot);
>                 method.convert(stackTypes[i]);
>                 // stack: s0=object literal being initialized
> -                // change map of s0 so that the property we are initilizing when we failed
> +                // change map of s0 so that the property we are initializing when we failed
>                 // is now ci.returnValueType
>                 if (i == objectLiteralStackDepth) {
>                     method.dup();
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java Thu Sep 10 18:56:56 2015 +0200
> @@ -745,7 +745,7 @@
>     abstract FunctionNode transform(final Compiler compiler, final CompilationPhases phases, final FunctionNode functionNode) throws CompilationException;
> 
>     /**
> -     * Apply a transform to a function node, returning the transfored function node. If the transform is not
> +     * Apply a transform to a function node, returning the transformed function node. If the transform is not
>      * applicable, an exception is thrown. Every transform requires the function to have a certain number of
>      * states to operate. It can have more states set, but not fewer. The state list, i.e. the constructor
>      * arguments to any of the CompilationPhase enum entries, is a set of REQUIRED states.
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilerConstants.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilerConstants.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilerConstants.java Thu Sep 10 18:56:56 2015 +0200
> @@ -192,7 +192,7 @@
>     private static Set<String> symbolNames;
> 
>     /**
> -     * Prefix used for internal methods generated in script clases.
> +     * Prefix used for internal methods generated in script classes.
>      */
>     private static final String INTERNAL_METHOD_PREFIX = ":";
> 
> @@ -225,7 +225,7 @@
>     }
> 
>     /**
> -     * Check whether a name is that of a reserved compiler constnat
> +     * Check whether a name is that of a reserved compiler constant
>      * @param name name
>      * @return true if compiler constant name
>      */
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java Thu Sep 10 18:56:56 2015 +0200
> @@ -521,7 +521,7 @@
>         }
> 
>         /*
> -         * create a new trynode
> +         * create a new try node
>          *    if we have catches:
>          *
>          *    try            try
> @@ -532,7 +532,7 @@
>          *                   catchall
>          *                        rethrow
>          *
> -         *   otheriwse
> +         *   otherwise
>          *
>          *   try              try
>          *      x               x
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java Thu Sep 10 18:56:56 2015 +0200
> @@ -1158,7 +1158,7 @@
>     /**
>      * Pop a value from the stack and store it in a variable denoted by the given symbol. The variable should be either
>      * a local variable, or a function parameter (and not a scoped variable). For local variables, this method will also
> -     * do the bookeeping of the local variable table as well as mark values in all alternative slots for the symbol as
> +     * do the bookkeeping of the local variable table as well as mark values in all alternative slots for the symbol as
>      * dead. In this regard it differs from {@link #storeHidden(Type, int)}.
>      *
>      * @param symbol the symbol to store into.
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ObjectClassGenerator.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ObjectClassGenerator.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ObjectClassGenerator.java Thu Sep 10 18:56:56 2015 +0200
> @@ -786,7 +786,7 @@
>      * @param primitiveSetter   primitive setter for the current type with an element of the current type
>      * @param objectSetter      the object setter
>      *
> -     * @return method handle that checks if the element to be set is of the currenttype, even though it's boxed
> +     * @return method handle that checks if the element to be set is of the current type, even though it's boxed
>      *  and instead of using the generic object setter, that would blow up the type and invalidate the map,
>      *  unbox it and call the primitive setter instead
>      */
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/BytecodeOps.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/BytecodeOps.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/BytecodeOps.java Thu Sep 10 18:56:56 2015 +0200
> @@ -36,7 +36,7 @@
>  * The bytecode ops are coupled to a MethodVisitor from ASM for
>  * byte code generation. They know nothing about our MethodGenerator,
>  * which is the abstraction for working with Nashorn JS types
> - * For exmaple, anything like "two or one slots" for a type, which
> + * For example, anything like "two or one slots" for a type, which
>  * is represented in bytecode and ASM, is abstracted away in the
>  * MethodGenerator. There you just say "dup" or "store".
>  *
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BlockLexicalContext.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BlockLexicalContext.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BlockLexicalContext.java Thu Sep 10 18:56:56 2015 +0200
> @@ -34,7 +34,7 @@
>  * This is a subclass of lexical context used for filling
>  * blocks (and function nodes) with statements. When popping
>  * a block from the lexical context, any statements that have
> - * been generated in it are commited to the block. This saves
> + * been generated in it are committed to the block. This saves
>  * unnecessary object mutations and lexical context replacement
>  */
> public class BlockLexicalContext extends LexicalContext {
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java Thu Sep 10 18:56:56 2015 +0200
> @@ -452,7 +452,7 @@
>      *
>      * @param token   token
>      * @param finish  finish
> -     * @param value   undefined value, passed only for polymorphisism discrimination
> +     * @param value   undefined value, passed only for polymorphism discrimination
>      *
>      * @return the new literal node
>      */
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java Thu Sep 10 18:56:56 2015 +0200
> @@ -276,7 +276,7 @@
>          *
>          * @param request a request
>          *
> -         * @return the inverted rquest, or null if not applicable
> +         * @return the inverted request, or null if not applicable
>          */
>         public static Request invert(final Request request) {
>             switch (request) {
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornClassReader.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornClassReader.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornClassReader.java Thu Sep 10 18:56:56 2015 +0200
> @@ -36,7 +36,7 @@
> import jdk.nashorn.internal.ir.debug.NashornTextifier.NashornLabel;
> 
> /**
> - * Subclass of the ASM classs reader that retains more info, such
> + * Subclass of the ASM class reader that retains more info, such
>  * as bytecode offsets
>  */
> public class NashornClassReader extends ClassReader {
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Thu Sep 10 18:56:56 2015 +0200
> @@ -193,7 +193,7 @@
>     }
> 
>     /**
> -     * Get the class histograpm
> +     * Get the class histogram
>      * @return class histogram element list
>      */
>     public List<ClassHistogramElement> getClassHistogram() {
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayBufferView.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayBufferView.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayBufferView.java Thu Sep 10 18:56:56 2015 +0200
> @@ -192,7 +192,7 @@
>         /**
>          * Factory method for array data
>          *
> -         * @param nb    underlying nativebuffer
> +         * @param nb    underlying native buffer
>          * @param start start element
>          * @param end   end element
>          *
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java Thu Sep 10 18:56:56 2015 +0200
> @@ -2166,7 +2166,7 @@
> 
>         // We want to avoid adding our generic lexical scope switchpoint to global constant invocations,
>         // because those are invalidated per-key in the addBoundProperties method above.
> -        // We therefor check if the invocation does already have a switchpoint and the property is non-inherited,
> +        // We therefore check if the invocation does already have a switchpoint and the property is non-inherited,
>         // assuming this only applies to global constants. If other non-inherited properties will
>         // start using switchpoints some time in the future we'll have to revisit this.
>         if (isScope && context.getEnv()._es6 && (invocation.getSwitchPoints() == null || !hasOwnProperty(name))) {
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java Thu Sep 10 18:56:56 2015 +0200
> @@ -728,7 +728,7 @@
>          *
>          * $$ -> $
>          * $& -> the matched substring
> -         * $` -> the portion of string that preceeds matched substring
> +         * $` -> the portion of string that preceds matched substring
>          * $' -> the portion of string that follows the matched substring
>          * $n -> the nth capture, where n is [1-9] and $n is NOT followed by a decimal digit
>          * $nn -> the nnth capture, where nn is a two digit decimal number [01-99].
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java Thu Sep 10 18:56:56 2015 +0200
> @@ -808,7 +808,7 @@
>                                 if (!oldStrictMode && directiveStmts != null) {
>                                     // check that directives preceding this one do not violate strictness
>                                     for (final Node statement : directiveStmts) {
> -                                        // the get value will force unescape of preceeding
> +                                        // the get value will force unescape of preceding
>                                         // escaped string directives
> getValue(statement.getToken());
>                                     }
> @@ -2507,7 +2507,7 @@
>         //         run: function() { println("run"); }
>         //     };
>         //
> -        // The object literal following the "new Constructor()" expresssion
> +        // The object literal following the "new Constructor()" expression
>         // is passed as an additional (last) argument to the constructor.
>         if (!env._no_syntax_extensions && type == LBRACE) {
>             arguments.add(objectLiteral());
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextBaseNode.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextBaseNode.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextBaseNode.java Thu Sep 10 18:56:56 2015 +0200
> @@ -90,7 +90,7 @@
>     }
> 
>     /**
> -     * Adds a Statement at the end of the Statementlist
> +     * Adds a statement at the end of the statement list
>      * @param statement The statement to add
>      */
>     @Override
> @@ -99,7 +99,7 @@
>     }
> 
>     /**
> -     * Adds a statement at the begining of the statementlist
> +     * Adds a statement at the beginning of the statement list
>      * @param statement The statement to add
>      */
>     @Override
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextNode.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextNode.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextNode.java Thu Sep 10 18:56:56 2015 +0200
> @@ -53,13 +53,13 @@
>     public void setStatements(final List<Statement> statements);
> 
>     /**
> -     * Adds a Statement at the end of the Statementlist
> +     * Adds a statement at the end of the statement list
>      * @param statement The statement to add
>      */
>     public void appendStatement(final Statement statement);
> 
>     /**
> -     * Adds a statement at the begining of the statementlist
> +     * Adds a statement at the beginning of the statement list
>      * @param statement The statement to add
>      */
>     public void prependStatement(final Statement statement);
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java Thu Sep 10 18:56:56 2015 +0200
> @@ -102,7 +102,7 @@
>             /*
>              * An optimistic builtin with isOptimistic=true works like any optimistic generated function, i.e. it
>              * can throw unwarranted optimism exceptions. As native functions trivially can't have parts of them
> -             * regenerated as restof methods, this only works if the methods are atomic/functional in their behavior
> +             * regenerated as rest of methods, this only works if the methods are atomic/functional in their behavior
>              * and doesn't modify state before an UOE can be thrown. If they aren't, we can reexecute a wider version
>              * of the same builtin in a recompilation handler for FinalScriptFunctionData. There are several
>              * candidate methods in Native* that would benefit from this, but I haven't had time to implement any
> @@ -567,7 +567,7 @@
>             return handle;
>         }
> 
> -        // Otherwise, we need a new level of indirection; need to introduce a mutable call site that can relink itslef
> +        // Otherwise, we need a new level of indirection; need to introduce a mutable call site that can relink itself
>         // to the compiled function's changed target whenever the optimistic assumptions are invalidated.
>         final CallSite cs = new MutableCallSite(handle.type());
>         relinkComposableInvoker(cs, this, isConstructor);
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java Thu Sep 10 18:56:56 2015 +0200
> @@ -153,7 +153,7 @@
>      * Currently we are conservative and associate the name of a builtin class with all
>      * its properties, so it's enough to invalidate a property to break all assumptions
>      * about a prototype. This can be changed to a more fine grained approach, but no one
> -     * ever needs this, given the very rare occurance of swapping out only parts of
> +     * ever needs this, given the very rare occurrence of swapping out only parts of
>      * a builtin v.s. the entire builtin object
>      */
>     private final Map<String, SwitchPoint> builtinSwitchPoints = new HashMap<>();
> @@ -1475,7 +1475,7 @@
>      * @param level            log level
>      * @param mh               method handle
>      * @param paramStart       first parameter to print
> -     * @param printReturnValue should we print the return vaulue?
> +     * @param printReturnValue should we print the return value?
>      * @param text             debug printout to add
>      *
>      * @return instrumented method handle, or null if logger not enabled
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java Thu Sep 10 18:56:56 2015 +0200
> @@ -297,4 +297,3 @@
>     }
> 
> }
> -
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java Thu Sep 10 18:56:56 2015 +0200
> @@ -67,7 +67,7 @@
>  *
>  * Thus everything registered as a global constant gets an extra chance. Set once,
>  * reregister the switchpoint. Set twice or more - don't try again forever, or we'd
> - * just end up relinking our way into megamorphisism.
> + * just end up relinking our way into megamorphism.
>  *
>  * Also it has to be noted that this kind of linking creates a coupling between a Global
>  * and the call sites in compiled code belonging to the Context. For this reason, the
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java Thu Sep 10 18:56:56 2015 +0200
> @@ -26,7 +26,6 @@
> package jdk.nashorn.internal.runtime;
> 
> import java.lang.invoke.MethodHandle;
> -import java.util.Iterator;
> import java.util.concurrent.Callable;
> import jdk.nashorn.internal.objects.Global;
> import jdk.nashorn.internal.parser.JSONParser;
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java Thu Sep 10 18:56:56 2015 +0200
> @@ -1967,7 +1967,7 @@
>     /**
>      * Get the unboxed (primitive) type for an object
>      * @param o object
> -     * @return primive type or Object.class if not primitive
> +     * @return primitive type or Object.class if not primitive
>      */
>     public static Class<?> unboxedFieldType(final Object o) {
>         if (o == null) {
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ParserException.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ParserException.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ParserException.java Thu Sep 10 18:56:56 2015 +0200
> @@ -38,7 +38,7 @@
>     private final Source source;
>     // token responsible for this exception
>     private final long token;
> -    // if this is traslated as ECMA error, which type should be used?
> +    // if this is translated as ECMA error, which type should be used?
>     private final JSErrorType errorType;
> 
>     /**
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java Thu Sep 10 18:56:56 2015 +0200
> @@ -191,7 +191,7 @@
> 
>     /**
>      * Return element setter for a {@link ContinuousArrayData}
> -     * @param clazz        clazz for exact type guard
> +     * @param clazz        class for exact type guard
>      * @param setHas       set has guard
>      * @param elementType  element type
>      * @return method handle for element setter
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java Thu Sep 10 18:56:56 2015 +0200
> @@ -34,7 +34,7 @@
>  * This filter handles the presence of undefined array elements.
>  */
> final class UndefinedArrayFilter extends ArrayFilter {
> -    /** Bit vector tracking undefines. */
> +    /** Bit vector tracking undefineds. */
>     private final BitVector undefined;
> 
>     UndefinedArrayFilter(final ArrayData underlying) {
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java Thu Sep 10 18:56:56 2015 +0200
> @@ -26,7 +26,6 @@
> package jdk.nashorn.internal.runtime.linker;
> 
> import static jdk.nashorn.internal.lookup.Lookup.MH;
> -import static jdk.nashorn.internal.runtime.ECMAErrors.typeError;
> 
> import java.lang.invoke.MethodHandle;
> import java.lang.invoke.MethodHandles;
> @@ -42,13 +41,11 @@
> import jdk.internal.dynalink.linker.LinkerServices;
> import jdk.internal.dynalink.linker.MethodHandleTransformer;
> import jdk.internal.dynalink.support.DefaultInternalObjectFilter;
> -import jdk.internal.dynalink.support.Guards;
> import jdk.internal.dynalink.support.Lookup;
> import jdk.nashorn.api.scripting.ScriptUtils;
> import jdk.nashorn.internal.runtime.ConsString;
> import jdk.nashorn.internal.runtime.Context;
> import jdk.nashorn.internal.runtime.ScriptObject;
> -import jdk.nashorn.internal.runtime.ScriptRuntime;
> import jdk.nashorn.internal.runtime.options.Options;
> 
> /**
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Config.java
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Config.java Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Config.java Thu Sep 10 18:56:56 2015 +0200
> @@ -65,7 +65,7 @@
> 
>     final boolean DONT_OPTIMIZE                     = false;
> 
> -    final boolean USE_STRING_TEMPLATES              = true; // use embeded string templates in Regex object as byte arrays instead of compiling them into int bytecode array
> +    final boolean USE_STRING_TEMPLATES              = true; // use embedded string templates in Regex object as byte arrays instead of compiling them into int bytecode array
> 
>     final boolean NON_UNICODE_SDW                   = true;
> 
> diff -r 882bbbfcaf03 src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js
> --- a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js Thu Sep 10 19:09:23 2015 +0530
> +++ b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js Thu Sep 10 18:56:56 2015 +0200
> @@ -55,7 +55,7 @@
>                 // do not start with '/'. If regexp, then eval it to make RegExp object
>                 return value.startsWith('/')? eval(value) : value.substring(1);
>             } else {
> -                // anythin else is returned "as is""
> +                // anything else is returned "as is"
>                 return value;
>             }
>         });
> 


From asashour at yahoo.com  Thu Sep 10 20:44:36 2015
From: asashour at yahoo.com (Ahmed Ashour)
Date: Thu, 10 Sep 2015 20:44:36 +0000 (UTC)
Subject: [PATCH] Some typos
In-Reply-To: <F51D563B-5737-4800-A168-2E1199E3768C@oracle.com>
References: <F51D563B-5737-4800-A168-2E1199E3768C@oracle.com>
Message-ID: <1301741220.630950.1441917876553.JavaMail.yahoo@mail.yahoo.com>

Hi Jim,

Yes, I have signed the agreement, and I am listed into that page.

"Ahmed Ashour - OpenJDK - asashour"

Thanks,
Ahmed


----- Original Message -----
From: Jim Laskey (Oracle) <james.laskey at oracle.com>
To: Ahmed Ashour <asashour at yahoo.com>
Cc: nashorn-dev at openjdk.java.net
Sent: Thursday, September 10, 2015 10:38 PM
Subject: Re: [PATCH] Some typos

Ahmed,

Before we can accept these changes, we need to verify that you have completed a Oracle Contributor Agreement. http://www.oracle.com/technetwork/community/oca-486395.html

Cheers,

? Jim



> On Sep 10, 2015, at 5:06 PM, Ahmed Ashour <asashour at yahoo.com> wrote:
> 
> Dear all,
> 
> Please find below patch, which:
>    - Handles some typos
>    - Removes unused imports from two files.
> 
> Also, there are other potential places to modify (if appropriate):
>    - WarnCallback: references '@gmail.com' in @author, this is the only place, which looks strange.
>    - 'behavior' could be 'behavior': there are three places.
> 
> Hope you find it useful.
> 
> Yours,
> Ahmed

From james.laskey at oracle.com  Thu Sep 10 23:56:03 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Thu, 10 Sep 2015 20:56:03 -0300
Subject: [PATCH] Some typos
In-Reply-To: <1301741220.630950.1441917876553.JavaMail.yahoo@mail.yahoo.com>
References: <F51D563B-5737-4800-A168-2E1199E3768C@oracle.com>
	<1301741220.630950.1441917876553.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <28BA27BE-2F9F-4488-A2DC-D398642F65CA@oracle.com>

Thank you.

> On Sep 10, 2015, at 5:44 PM, Ahmed Ashour <asashour at yahoo.com> wrote:
> 
> Hi Jim,
> 
> Yes, I have signed the agreement, and I am listed into that page.
> 
> "Ahmed Ashour - OpenJDK - asashour"
> 
> Thanks,
> Ahmed
> 
> 
> ----- Original Message -----
> From: Jim Laskey (Oracle) <james.laskey at oracle.com>
> To: Ahmed Ashour <asashour at yahoo.com>
> Cc: nashorn-dev at openjdk.java.net
> Sent: Thursday, September 10, 2015 10:38 PM
> Subject: Re: [PATCH] Some typos
> 
> Ahmed,
> 
> Before we can accept these changes, we need to verify that you have completed a Oracle Contributor Agreement. http://www.oracle.com/technetwork/community/oca-486395.html
> 
> Cheers,
> 
> ? Jim
> 
> 
> 
>> On Sep 10, 2015, at 5:06 PM, Ahmed Ashour <asashour at yahoo.com> wrote:
>> 
>> Dear all,
>> 
>> Please find below patch, which:
>>   - Handles some typos
>>   - Removes unused imports from two files.
>> 
>> Also, there are other potential places to modify (if appropriate):
>>   - WarnCallback: references '@gmail.com' in @author, this is the only place, which looks strange.
>>   - 'behavior' could be 'behavior': there are three places.
>> 
>> Hope you find it useful.
>> 
>> Yours,
>> Ahmed


From sundararajan.athijegannathan at oracle.com  Fri Sep 11 03:50:13 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 11 Sep 2015 09:20:13 +0530
Subject: [PATCH] Some typos
In-Reply-To: <55F1E2E1.5040901@yahoo.com>
References: <55F1E2E1.5040901@yahoo.com>
Message-ID: <55F24F75.8070104@oracle.com>

Hi Ahmed,

Thanks for submitting this patch. I've filed 
https://bugs.openjdk.java.net/browse/JDK-8136349

PS. Did you find these while reading code or used any automation/tool to 
find spelling issues? Just curious..

Thanks,
-Sundar

On 9/11/2015 1:36 AM, Ahmed Ashour wrote:
> Dear all,
>
> Please find below patch, which:
>     - Handles some typos
>     - Removes unused imports from two files.
>
> Also, there are other potential places to modify (if appropriate):
>     - WarnCallback: references '@gmail.com' in @author, this is the 
> only place, which looks strange.
>     - 'behavior' could be 'behavior': there are three places.
>
> Hope you find it useful.
>
> Yours,
> Ahmed
>
>
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/DynamicLinker.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -117,7 +117,7 @@
>   *         return factory.createLinker();
>   *     }
>   *
> - *     public static CallSite bootstrap(MethodHandles.Lookup caller, 
> String name, MethodType type) {
> + *     public static CallSite bootstrap(MethodHandles.Lookup lookup, 
> String name, MethodType type) {
>   *         return dynamicLinker.link(new 
> MonomorphicCallSite(CallSiteDescriptorFactory.create(lookup, name, 
> type)));
>   *     }
>   * }
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/FacetIntrospector.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -152,7 +152,7 @@
>      boolean isAccessible(final Member m) {
>          final Class<?> declaring = m.getDeclaringClass();
>          // (declaring == clazz) is just an optimization - we're 
> calling this only from code that operates on a
> -        // non-restriced class, so if the declaring class is 
> identical to the class being inspected, then forego
> +        // non-restricted class, so if the declaring class is 
> identical to the class being inspected, then forego
>          // a potentially expensive restricted-package check.
>          return declaring == clazz || 
> !CheckRestrictedPackage.isRestrictedClass(declaring);
>      }
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/SingleDynamicMethod.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -98,7 +98,6 @@
>   * target method to a call site type (including mapping variable 
> arity methods to a call site signature with different
>   * arity).
>   * @author Attila Szegedi
> - * @version $Id: $
>   */
>  abstract class SingleDynamicMethod extends DynamicMethod {
>
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedInvocation.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -353,7 +353,7 @@
>
>      /**
>       * Applies argument filters to both the invocation and the guard 
> (if there is one).
> -     * @param pos the position of the first argumen being filtered
> +     * @param pos the position of the first argument being filtered
>       * @param filters the argument filters
>       * @return a filtered invocation
>       */
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/linker/GuardedTypeConversion.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -110,7 +110,7 @@
>
>      /**
>       * Check if invocation is cacheable
> -     * @return true if cachable, false otherwise
> +     * @return true if cacheable, false otherwise
>       */
>      public boolean isCacheable() {
>          return cacheable;
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/URLReader.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/URLReader.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/scripting/URLReader.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -103,7 +103,7 @@
>      /**
>       * Charset used by this reader
>       *
> -     * @return the Chartset used to convert bytes to chars
> +     * @return the Charset used to convert bytes to chars
>       */
>      public Charset getCharset() {
>          return cs;
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/Parser.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/Parser.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/Parser.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -80,7 +80,7 @@
>      public CompilationUnitTree parse(final URL url, final 
> DiagnosticListener listener) throws IOException, NashornException;
>
>      /**
> -     * Parses the readerand returns compilation unit tree
> +     * Parses the reader and returns compilation unit tree
>       *
>       * @param name name of the source file to parse
>       * @param reader from which source is read
> @@ -133,7 +133,7 @@
>       * <dt>"-strict"</dt><dd>enable ECMAScript strict mode</dd>
>       * </dl>
>       *
> -     * @throws NullPointerException if options arrry or any of it's 
> element is null
> +     * @throws NullPointerException if options array or any of it's 
> element is null
>       * @throws IllegalArgumentException on unsupported option value.
>       * @return a new Parser instance.
>       */
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/RegExpLiteralTree.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/RegExpLiteralTree.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/api/tree/RegExpLiteralTree.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -35,7 +35,7 @@
>      /**
>       * Regular expression pattern to match.
>       *
> -     * @return regular expression patten
> +     * @return regular expression pattern
>       */
>      public String getPattern();
>
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -244,7 +244,7 @@
>
>      /**
>       * Creates a synthetic initializer for a variable (a var 
> statement that doesn't occur in the source code). Typically
> -     * used to create assignmnent of {@code :callee} to the function 
> name symbol in self-referential function
> +     * used to create assignment of {@code :callee} to the function 
> name symbol in self-referential function
>       * expressions as well as for assignment of {@code :arguments} to 
> {@code arguments}.
>       *
>       * @param name the ident node identifying the variable to initialize
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CodeGenerator.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -1494,7 +1494,7 @@
>                      int argsCount;
>                      @Override
>                      void loadStack() {
> -                        /**
> +                        /*
>                           * We want to load 'eval' to check if it is 
> indeed global builtin eval.
>                           * If this eval call is inside a 'with' 
> statement, dyn:getMethod|getProp|getElem
>                           * would be generated if ident is a 
> "isFunction". But, that would result in a
> @@ -4329,7 +4329,7 @@
>          }
>
>          private void prologue() {
> -            /**
> +            /*
>               * This loads the parts of the target, e.g base and 
> index. they are kept
>               * on the stack throughout the store and used at the end 
> to execute it
>               */
> @@ -4797,7 +4797,7 @@
>           * conversion has no side effects.
>           * @param name the name of the property being get
>           * @param flags call site flags
> -         * @param isMethod whether we're preferrably retrieving a 
> function
> +         * @param isMethod whether we're preferably retrieving a 
> function
>           * @return the current method emitter
>           */
>          MethodEmitter dynamicGet(final String name, final int flags, 
> final boolean isMethod, final boolean isIndex) {
> @@ -5229,7 +5229,7 @@
>          private Type returnValueType;
>          // If we are in the middle of an object literal 
> initialization, we need to update the map
>          private PropertyMap objectLiteralMap;
> -        // Object literal stack depth for object literal - not 
> necessarly top if property is a tree
> +        // Object literal stack depth for object literal - not 
> necessarily top if property is a tree
>          private int objectLiteralStackDepth = -1;
>          // The line number at the continuation point
>          private int lineNumber;
> @@ -5394,7 +5394,7 @@
>                  method.load(lvarTypes.get(slot), slot);
>                  method.convert(stackTypes[i]);
>                  // stack: s0=object literal being initialized
> -                // change map of s0 so that the property we are 
> initilizing when we failed
> +                // change map of s0 so that the property we are 
> initializing when we failed
>                  // is now ci.returnValueType
>                  if (i == objectLiteralStackDepth) {
>                      method.dup();
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilationPhase.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -745,7 +745,7 @@
>      abstract FunctionNode transform(final Compiler compiler, final 
> CompilationPhases phases, final FunctionNode functionNode) throws 
> CompilationException;
>
>      /**
> -     * Apply a transform to a function node, returning the transfored 
> function node. If the transform is not
> +     * Apply a transform to a function node, returning the 
> transformed function node. If the transform is not
>       * applicable, an exception is thrown. Every transform requires 
> the function to have a certain number of
>       * states to operate. It can have more states set, but not fewer. 
> The state list, i.e. the constructor
>       * arguments to any of the CompilationPhase enum entries, is a 
> set of REQUIRED states.
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilerConstants.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilerConstants.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/CompilerConstants.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -192,7 +192,7 @@
>      private static Set<String> symbolNames;
>
>      /**
> -     * Prefix used for internal methods generated in script clases.
> +     * Prefix used for internal methods generated in script classes.
>       */
>      private static final String INTERNAL_METHOD_PREFIX = ":";
>
> @@ -225,7 +225,7 @@
>      }
>
>      /**
> -     * Check whether a name is that of a reserved compiler constnat
> +     * Check whether a name is that of a reserved compiler constant
>       * @param name name
>       * @return true if compiler constant name
>       */
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -521,7 +521,7 @@
>          }
>
>          /*
> -         * create a new trynode
> +         * create a new try node
>           *    if we have catches:
>           *
>           *    try            try
> @@ -532,7 +532,7 @@
>           *                   catchall
>           *                        rethrow
>           *
> -         *   otheriwse
> +         *   otherwise
>           *
>           *   try              try
>           *      x               x
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/MethodEmitter.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -1158,7 +1158,7 @@
>      /**
>       * Pop a value from the stack and store it in a variable denoted 
> by the given symbol. The variable should be either
>       * a local variable, or a function parameter (and not a scoped 
> variable). For local variables, this method will also
> -     * do the bookeeping of the local variable table as well as mark 
> values in all alternative slots for the symbol as
> +     * do the bookkeeping of the local variable table as well as mark 
> values in all alternative slots for the symbol as
>       * dead. In this regard it differs from {@link #storeHidden(Type, 
> int)}.
>       *
>       * @param symbol the symbol to store into.
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ObjectClassGenerator.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ObjectClassGenerator.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/ObjectClassGenerator.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -786,7 +786,7 @@
>       * @param primitiveSetter   primitive setter for the current type 
> with an element of the current type
>       * @param objectSetter      the object setter
>       *
> -     * @return method handle that checks if the element to be set is 
> of the currenttype, even though it's boxed
> +     * @return method handle that checks if the element to be set is 
> of the current type, even though it's boxed
>       *  and instead of using the generic object setter, that would 
> blow up the type and invalidate the map,
>       *  unbox it and call the primitive setter instead
>       */
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/BytecodeOps.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/BytecodeOps.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/BytecodeOps.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -36,7 +36,7 @@
>   * The bytecode ops are coupled to a MethodVisitor from ASM for
>   * byte code generation. They know nothing about our MethodGenerator,
>   * which is the abstraction for working with Nashorn JS types
> - * For exmaple, anything like "two or one slots" for a type, which
> + * For example, anything like "two or one slots" for a type, which
>   * is represented in bytecode and ASM, is abstracted away in the
>   * MethodGenerator. There you just say "dup" or "store".
>   *
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BlockLexicalContext.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BlockLexicalContext.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BlockLexicalContext.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -34,7 +34,7 @@
>   * This is a subclass of lexical context used for filling
>   * blocks (and function nodes) with statements. When popping
>   * a block from the lexical context, any statements that have
> - * been generated in it are commited to the block. This saves
> + * been generated in it are committed to the block. This saves
>   * unnecessary object mutations and lexical context replacement
>   */
>  public class BlockLexicalContext extends LexicalContext {
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/LiteralNode.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -452,7 +452,7 @@
>       *
>       * @param token   token
>       * @param finish  finish
> -     * @param value   undefined value, passed only for polymorphisism 
> discrimination
> +     * @param value   undefined value, passed only for polymorphism 
> discrimination
>       *
>       * @return the new literal node
>       */
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/RuntimeNode.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -276,7 +276,7 @@
>           *
>           * @param request a request
>           *
> -         * @return the inverted rquest, or null if not applicable
> +         * @return the inverted request, or null if not applicable
>           */
>          public static Request invert(final Request request) {
>              switch (request) {
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornClassReader.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornClassReader.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornClassReader.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -36,7 +36,7 @@
>  import jdk.nashorn.internal.ir.debug.NashornTextifier.NashornLabel;
>
>  /**
> - * Subclass of the ASM classs reader that retains more info, such
> + * Subclass of the ASM class reader that retains more info, such
>   * as bytecode offsets
>   */
>  public class NashornClassReader extends ClassReader {
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -193,7 +193,7 @@
>      }
>
>      /**
> -     * Get the class histograpm
> +     * Get the class histogram
>       * @return class histogram element list
>       */
>      public List<ClassHistogramElement> getClassHistogram() {
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayBufferView.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayBufferView.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/ArrayBufferView.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -192,7 +192,7 @@
>          /**
>           * Factory method for array data
>           *
> -         * @param nb    underlying nativebuffer
> +         * @param nb    underlying native buffer
>           * @param start start element
>           * @param end   end element
>           *
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/Global.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -2166,7 +2166,7 @@
>
>          // We want to avoid adding our generic lexical scope 
> switchpoint to global constant invocations,
>          // because those are invalidated per-key in the 
> addBoundProperties method above.
> -        // We therefor check if the invocation does already have a 
> switchpoint and the property is non-inherited,
> +        // We therefore check if the invocation does already have a 
> switchpoint and the property is non-inherited,
>          // assuming this only applies to global constants. If other 
> non-inherited properties will
>          // start using switchpoints some time in the future we'll 
> have to revisit this.
>          if (isScope && context.getEnv()._es6 && 
> (invocation.getSwitchPoints() == null || !hasOwnProperty(name))) {
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeRegExp.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -728,7 +728,7 @@
>           *
>           * $$ -> $
>           * $& -> the matched substring
> -         * $` -> the portion of string that preceeds matched substring
> +         * $` -> the portion of string that preceds matched substring
>           * $' -> the portion of string that follows the matched 
> substring
>           * $n -> the nth capture, where n is [1-9] and $n is NOT 
> followed by a decimal digit
>           * $nn -> the nnth capture, where nn is a two digit decimal 
> number [01-99].
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -808,7 +808,7 @@
>                                  if (!oldStrictMode && directiveStmts 
> != null) {
>                                      // check that directives 
> preceding this one do not violate strictness
>                                      for (final Node statement : 
> directiveStmts) {
> -                                        // the get value will force 
> unescape of preceeding
> +                                        // the get value will force 
> unescape of preceding
>                                          // escaped string directives
> getValue(statement.getToken());
>                                      }
> @@ -2507,7 +2507,7 @@
>          //         run: function() { println("run"); }
>          //     };
>          //
> -        // The object literal following the "new Constructor()" 
> expresssion
> +        // The object literal following the "new Constructor()" 
> expression
>          // is passed as an additional (last) argument to the 
> constructor.
>          if (!env._no_syntax_extensions && type == LBRACE) {
>              arguments.add(objectLiteral());
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextBaseNode.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextBaseNode.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextBaseNode.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -90,7 +90,7 @@
>      }
>
>      /**
> -     * Adds a Statement at the end of the Statementlist
> +     * Adds a statement at the end of the statement list
>       * @param statement The statement to add
>       */
>      @Override
> @@ -99,7 +99,7 @@
>      }
>
>      /**
> -     * Adds a statement at the begining of the statementlist
> +     * Adds a statement at the beginning of the statement list
>       * @param statement The statement to add
>       */
>      @Override
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextNode.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextNode.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/ParserContextNode.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -53,13 +53,13 @@
>      public void setStatements(final List<Statement> statements);
>
>      /**
> -     * Adds a Statement at the end of the Statementlist
> +     * Adds a statement at the end of the statement list
>       * @param statement The statement to add
>       */
>      public void appendStatement(final Statement statement);
>
>      /**
> -     * Adds a statement at the begining of the statementlist
> +     * Adds a statement at the beginning of the statement list
>       * @param statement The statement to add
>       */
>      public void prependStatement(final Statement statement);
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/CompiledFunction.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -102,7 +102,7 @@
>              /*
>               * An optimistic builtin with isOptimistic=true works 
> like any optimistic generated function, i.e. it
>               * can throw unwarranted optimism exceptions. As native 
> functions trivially can't have parts of them
> -             * regenerated as restof methods, this only works if the 
> methods are atomic/functional in their behavior
> +             * regenerated as rest of methods, this only works if the 
> methods are atomic/functional in their behavior
>               * and doesn't modify state before an UOE can be thrown. 
> If they aren't, we can reexecute a wider version
>               * of the same builtin in a recompilation handler for 
> FinalScriptFunctionData. There are several
>               * candidate methods in Native* that would benefit from 
> this, but I haven't had time to implement any
> @@ -567,7 +567,7 @@
>              return handle;
>          }
>
> -        // Otherwise, we need a new level of indirection; need to 
> introduce a mutable call site that can relink itslef
> +        // Otherwise, we need a new level of indirection; need to 
> introduce a mutable call site that can relink itself
>          // to the compiled function's changed target whenever the 
> optimistic assumptions are invalidated.
>          final CallSite cs = new MutableCallSite(handle.type());
>          relinkComposableInvoker(cs, this, isConstructor);
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -153,7 +153,7 @@
>       * Currently we are conservative and associate the name of a 
> builtin class with all
>       * its properties, so it's enough to invalidate a property to 
> break all assumptions
>       * about a prototype. This can be changed to a more fine grained 
> approach, but no one
> -     * ever needs this, given the very rare occurance of swapping out 
> only parts of
> +     * ever needs this, given the very rare occurrence of swapping 
> out only parts of
>       * a builtin v.s. the entire builtin object
>       */
>      private final Map<String, SwitchPoint> builtinSwitchPoints = new 
> HashMap<>();
> @@ -1475,7 +1475,7 @@
>       * @param level            log level
>       * @param mh               method handle
>       * @param paramStart       first parameter to print
> -     * @param printReturnValue should we print the return vaulue?
> +     * @param printReturnValue should we print the return value?
>       * @param text             debug printout to add
>       *
>       * @return instrumented method handle, or null if logger not enabled
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/FindProperty.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -297,4 +297,3 @@
>      }
>
>  }
> -
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/GlobalConstants.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -67,7 +67,7 @@
>   *
>   * Thus everything registered as a global constant gets an extra 
> chance. Set once,
>   * reregister the switchpoint. Set twice or more - don't try again 
> forever, or we'd
> - * just end up relinking our way into megamorphisism.
> + * just end up relinking our way into megamorphism.
>   *
>   * Also it has to be noted that this kind of linking creates a 
> coupling between a Global
>   * and the call sites in compiled code belonging to the Context. For 
> this reason, the
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSONFunctions.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -26,7 +26,6 @@
>  package jdk.nashorn.internal.runtime;
>
>  import java.lang.invoke.MethodHandle;
> -import java.util.Iterator;
>  import java.util.concurrent.Callable;
>  import jdk.nashorn.internal.objects.Global;
>  import jdk.nashorn.internal.parser.JSONParser;
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/JSType.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -1967,7 +1967,7 @@
>      /**
>       * Get the unboxed (primitive) type for an object
>       * @param o object
> -     * @return primive type or Object.class if not primitive
> +     * @return primitive type or Object.class if not primitive
>       */
>      public static Class<?> unboxedFieldType(final Object o) {
>          if (o == null) {
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ParserException.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ParserException.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ParserException.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -38,7 +38,7 @@
>      private final Source source;
>      // token responsible for this exception
>      private final long token;
> -    // if this is traslated as ECMA error, which type should be used?
> +    // if this is translated as ECMA error, which type should be used?
>      private final JSErrorType errorType;
>
>      /**
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/ContinuousArrayData.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -191,7 +191,7 @@
>
>      /**
>       * Return element setter for a {@link ContinuousArrayData}
> -     * @param clazz        clazz for exact type guard
> +     * @param clazz        class for exact type guard
>       * @param setHas       set has guard
>       * @param elementType  element type
>       * @return method handle for element setter
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -34,7 +34,7 @@
>   * This filter handles the presence of undefined array elements.
>   */
>  final class UndefinedArrayFilter extends ArrayFilter {
> -    /** Bit vector tracking undefines. */
> +    /** Bit vector tracking undefineds. */
>      private final BitVector undefined;
>
>      UndefinedArrayFilter(final ArrayData underlying) {
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornBeansLinker.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -26,7 +26,6 @@
>  package jdk.nashorn.internal.runtime.linker;
>
>  import static jdk.nashorn.internal.lookup.Lookup.MH;
> -import static jdk.nashorn.internal.runtime.ECMAErrors.typeError;
>
>  import java.lang.invoke.MethodHandle;
>  import java.lang.invoke.MethodHandles;
> @@ -42,13 +41,11 @@
>  import jdk.internal.dynalink.linker.LinkerServices;
>  import jdk.internal.dynalink.linker.MethodHandleTransformer;
>  import jdk.internal.dynalink.support.DefaultInternalObjectFilter;
> -import jdk.internal.dynalink.support.Guards;
>  import jdk.internal.dynalink.support.Lookup;
>  import jdk.nashorn.api.scripting.ScriptUtils;
>  import jdk.nashorn.internal.runtime.ConsString;
>  import jdk.nashorn.internal.runtime.Context;
>  import jdk.nashorn.internal.runtime.ScriptObject;
> -import jdk.nashorn.internal.runtime.ScriptRuntime;
>  import jdk.nashorn.internal.runtime.options.Options;
>
>  /**
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Config.java
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Config.java 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Config.java 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -65,7 +65,7 @@
>
>      final boolean DONT_OPTIMIZE                     = false;
>
> -    final boolean USE_STRING_TEMPLATES              = true; // use 
> embeded string templates in Regex object as byte arrays instead of 
> compiling them into int bytecode array
> +    final boolean USE_STRING_TEMPLATES              = true; // use 
> embedded string templates in Regex object as byte arrays instead of 
> compiling them into int bytecode array
>
>      final boolean NON_UNICODE_SDW                   = true;
>
> diff -r 882bbbfcaf03 
> src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js
> --- 
> a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js 
> Thu Sep 10 19:09:23 2015 +0530
> +++ 
> b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/parser.js 
> Thu Sep 10 18:56:56 2015 +0200
> @@ -55,7 +55,7 @@
>                  // do not start with '/'. If regexp, then eval it to 
> make RegExp object
>                  return value.startsWith('/')? eval(value) : 
> value.substring(1);
>              } else {
> -                // anythin else is returned "as is""
> +                // anything else is returned "as is"
>                  return value;
>              }
>          });
>


From asashour at yahoo.com  Fri Sep 11 06:33:50 2015
From: asashour at yahoo.com (Ahmed Ashour)
Date: Fri, 11 Sep 2015 06:33:50 +0000 (UTC)
Subject: [PATCH] Some typos
In-Reply-To: <1441944770621.2071257876@boxbe>
References: <1441944770621.2071257876@boxbe>
Message-ID: <167623495.889639.1441953230257.JavaMail.yahoo@mail.yahoo.com>

Hi Sundar,
Eclipse has automatic highlight of potential spelling mistakes, you just need to go through the code.
In the other comments I mistyped, and it should be:?? ? - 'behaviour' could be 'behavior': there are three places.? ? - WarnCallback: references '@gmail.com' in @author, this is the?only place, which looks strange.


Thanks again,Ahmed
      From: Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>
 To: nashorn-dev at openjdk.java.net 
 Sent: Friday, September 11, 2015 5:50 AM
 Subject: Re: [PATCH] Some typos
   
Hi Ahmed,

Thanks for submitting this patch. I've filed 
https://bugs.openjdk.java.net/browse/JDK-8136349

PS. Did you find these while reading code or used any automation/tool to 
find spelling issues? Just curious..

Thanks,
-Sundar

On 9/11/2015 1:36 AM, Ahmed Ashour wrote:
> Dear all,
>
> Please find below patch, which:
>? ? - Handles some typos
>? ? - Removes unused imports from two files.
>
> Also, there are other potential places to modify (if appropriate):
>? ? - WarnCallback: references '@gmail.com' in @author, this is the 
> only place, which looks strange.
>? ? - 'behavior' could be 'behavior': there are three places.
>
> Hope you find it useful.
>
> Yours,
> Ahmed

  

From sundararajan.athijegannathan at oracle.com  Fri Sep 11 07:31:39 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 11 Sep 2015 13:01:39 +0530
Subject: [PATCH] Some typos
In-Reply-To: <167623495.889639.1441953230257.JavaMail.yahoo@mail.yahoo.com>
References: <1441944770621.2071257876@boxbe>
	<167623495.889639.1441953230257.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <55F2835B.9050400@oracle.com>

Hi Ahmed,

Thanks. NetBeans has similar feature - but that means opening and 
reading/looking at each file. I thought if there is any automated way to 
search for all typos across files of a project or a directory.

* behaviour / behavior being British / American spelling, I'd rather 
leave it..

* I'll check out @gmail.com in @author

Thanks,
-Sundar


On 9/11/2015 12:03 PM, Ahmed Ashour wrote:
> Hi Sundar,
> Eclipse has automatic highlight of potential spelling mistakes, you just need to go through the code.
> In the other comments I mistyped, and it should be:     - 'behaviour' could be 'behavior': there are three places.    - WarnCallback: references '@gmail.com' in @author, this is the only place, which looks strange.
>
>
> Thanks again,Ahmed
>        From: Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>
>   To: nashorn-dev at openjdk.java.net
>   Sent: Friday, September 11, 2015 5:50 AM
>   Subject: Re: [PATCH] Some typos
>     
> Hi Ahmed,
>
> Thanks for submitting this patch. I've filed
> https://bugs.openjdk.java.net/browse/JDK-8136349
>
> PS. Did you find these while reading code or used any automation/tool to
> find spelling issues? Just curious..
>
> Thanks,
> -Sundar
>
> On 9/11/2015 1:36 AM, Ahmed Ashour wrote:
>> Dear all,
>>
>> Please find below patch, which:
>>      - Handles some typos
>>      - Removes unused imports from two files.
>>
>> Also, there are other potential places to modify (if appropriate):
>>      - WarnCallback: references '@gmail.com' in @author, this is the
>> only place, which looks strange.
>>      - 'behavior' could be 'behavior': there are three places.
>>
>> Hope you find it useful.
>>
>> Yours,
>> Ahmed
>    


From sundararajan.athijegannathan at oracle.com  Fri Sep 11 07:52:49 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 11 Sep 2015 13:22:49 +0530
Subject: RFR 8136349: Typos patch for nashorn sources submitted on Sep 10, 2015
Message-ID: <55F28851.5070607@oracle.com>

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

This is a contribution by Ahmed Ashour. Please see this thread -> 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005206.html

This webrev was generated by after applying Ahmed's patch & then fixing 
the following manually on top of that:

1) File: NativeRegExp.java

     preceds -> precedes

2) File: CompiledFunction.java

     rest of -> "restOf" - this is a reference to "restOf" methods 
generated and so should not be "rest of".

Thanks,
-Sundar

From michael.haupt at oracle.com  Fri Sep 11 08:28:05 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Fri, 11 Sep 2015 10:28:05 +0200
Subject: RFR 8136349: Typos patch for nashorn sources submitted on Sep 10,
	2015
In-Reply-To: <55F28851.5070607@oracle.com>
References: <55F28851.5070607@oracle.com>
Message-ID: <747ED77A-A930-44FA-A861-32D0D12E95B2@oracle.com>

Hi Sundar,

lower-case thumbs up!

Best,

Michael

> Am 11.09.2015 um 09:52 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Please review http://cr.openjdk.java.net/~sundar/8136349/ for https://bugs.openjdk.java.net/browse/JDK-8136349
> 
> This is a contribution by Ahmed Ashour. Please see this thread -> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005206.html
> 
> This webrev was generated by after applying Ahmed's patch & then fixing the following manually on top of that:
> 
> 1) File: NativeRegExp.java
> 
>    preceds -> precedes
> 
> 2) File: CompiledFunction.java
> 
>    rest of -> "restOf" - this is a reference to "restOf" methods generated and so should not be "rest of".
> 
> Thanks,
> -Sundar

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From michael.haupt at oracle.com  Fri Sep 11 08:41:39 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Fri, 11 Sep 2015 10:41:39 +0200
Subject: RFR 8136349: Typos patch for nashorn sources submitted on Sep 10,
	2015
In-Reply-To: <747ED77A-A930-44FA-A861-32D0D12E95B2@oracle.com>
References: <55F28851.5070607@oracle.com>
	<747ED77A-A930-44FA-A861-32D0D12E95B2@oracle.com>
Message-ID: <E159664D-5028-4986-8460-3394F324632F@oracle.com>

... small correction: in Parser.java, "any of it's element" should be "any of its elements".

Best,

Michael

> Am 11.09.2015 um 10:28 schrieb Michael Haupt <michael.haupt at oracle.com>:
> 
> Hi Sundar,
> 
> lower-case thumbs up!
> 
> Best,
> 
> Michael
> 
>> Am 11.09.2015 um 09:52 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
>> 
>> Please review http://cr.openjdk.java.net/~sundar/8136349/ for https://bugs.openjdk.java.net/browse/JDK-8136349
>> 
>> This is a contribution by Ahmed Ashour. Please see this thread -> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005206.html
>> 
>> This webrev was generated by after applying Ahmed's patch & then fixing the following manually on top of that:
>> 
>> 1) File: NativeRegExp.java
>> 
>>   preceds -> precedes
>> 
>> 2) File: CompiledFunction.java
>> 
>>   rest of -> "restOf" - this is a reference to "restOf" methods generated and so should not be "rest of".
>> 
>> Thanks,
>> -Sundar


-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From hannes.wallnoefer at oracle.com  Fri Sep 11 08:46:47 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 11 Sep 2015 10:46:47 +0200
Subject: RFR 8136349: Typos patch for nashorn sources submitted on Sep 10, 
	2015
In-Reply-To: <55F28851.5070607@oracle.com>
References: <55F28851.5070607@oracle.com>
Message-ID: <55F294F7.4010501@oracle.com>

Looks good.

I'm not sure "undefineds" is a valid plural form of "undefined" in 
UndefinedArrayFilter, maybe use "undefined slots"?

Hannes

Am 2015-09-11 um 09:52 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8136349/ for 
> https://bugs.openjdk.java.net/browse/JDK-8136349
>
> This is a contribution by Ahmed Ashour. Please see this thread -> 
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005206.html
>
> This webrev was generated by after applying Ahmed's patch & then 
> fixing the following manually on top of that:
>
> 1) File: NativeRegExp.java
>
>     preceds -> precedes
>
> 2) File: CompiledFunction.java
>
>     rest of -> "restOf" - this is a reference to "restOf" methods 
> generated and so should not be "rest of".
>
> Thanks,
> -Sundar


From asashour at yahoo.com  Fri Sep 11 08:58:49 2015
From: asashour at yahoo.com (Ahmed Ashour)
Date: Fri, 11 Sep 2015 08:58:49 +0000 (UTC)
Subject: RFR 8136349: Typos patch for nashorn sources submitted on Sep
	10, 	2015
In-Reply-To: <55F294F7.4010501@oracle.com>
References: <55F294F7.4010501@oracle.com>
Message-ID: <1721197912.952059.1441961929084.JavaMail.yahoo@mail.yahoo.com>

Hi Hannes,
You are right, it is a little confusing, but:? ? - 'undefineds' is used in two other places:? ? ? ? Label.java:?"No trailing undefineds"? ? ? ??ScriptFunctionData: "when padded with undefineds"
I guess all three should be the same, whatever is decided.
Ahmed
      From: Hannes Wallnoefer <hannes.wallnoefer at oracle.com>
 To: Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>; "nashorn-dev at openjdk.java.net" <nashorn-dev at openjdk.java.net> 
 Sent: Friday, September 11, 2015 10:46 AM
 Subject: Re: RFR 8136349: Typos patch for nashorn sources submitted on Sep 10, 2015
   
Looks good.

I'm not sure "undefineds" is a valid plural form of "undefined" in 
UndefinedArrayFilter, maybe use "undefined slots"?

Hannes



Am 2015-09-11 um 09:52 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8136349/ for 
> https://bugs.openjdk.java.net/browse/JDK-8136349
>
> This is a contribution by Ahmed Ashour. Please see this thread -> 
> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005206.html
>
> This webrev was generated by after applying Ahmed's patch & then 
> fixing the following manually on top of that:
>
> 1) File: NativeRegExp.java
>
>? ? preceds -> precedes
>
> 2) File: CompiledFunction.java
>
>? ? rest of -> "restOf" - this is a reference to "restOf" methods 
> generated and so should not be "rest of".
>
> Thanks,
> -Sundar



  

From lagergren at gmail.com  Fri Sep 11 09:03:05 2015
From: lagergren at gmail.com (Marcus Lagergren)
Date: Fri, 11 Sep 2015 11:03:05 +0200
Subject: RFR 8136349: Typos patch for nashorn sources submitted on Sep 10,
	2015
In-Reply-To: <747ED77A-A930-44FA-A861-32D0D12E95B2@oracle.com>
References: <55F28851.5070607@oracle.com>
	<747ED77A-A930-44FA-A861-32D0D12E95B2@oracle.com>
Message-ID: <3E0124AB-F296-448A-BBE7-9566D4241223@lagergren.net>

+1.

I might be a bit slow, or it?s a Swedish/German culture gap or something, but Michael, this ?lower case? that you have before thumbs up - what does it mean? :)

/M

> On 11 Sep 2015, at 10:28, Michael Haupt <michael.haupt at oracle.com> wrote:
> 
> Hi Sundar,
> 
> lower-case thumbs up!
> 
> Best,
> 
> Michael
> 
>> Am 11.09.2015 um 09:52 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
>> 
>> Please review http://cr.openjdk.java.net/~sundar/8136349/ for https://bugs.openjdk.java.net/browse/JDK-8136349
>> 
>> This is a contribution by Ahmed Ashour. Please see this thread -> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005206.html
>> 
>> This webrev was generated by after applying Ahmed's patch & then fixing the following manually on top of that:
>> 
>> 1) File: NativeRegExp.java
>> 
>>   preceds -> precedes
>> 
>> 2) File: CompiledFunction.java
>> 
>>   rest of -> "restOf" - this is a reference to "restOf" methods generated and so should not be "rest of".
>> 
>> Thanks,
>> -Sundar
> 
> --
> 
> <http://www.oracle.com/>
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> Oracle Java Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
> <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment
> 


From lagergren at gmail.com  Fri Sep 11 09:04:15 2015
From: lagergren at gmail.com (Marcus Lagergren)
Date: Fri, 11 Sep 2015 11:04:15 +0200
Subject: [PATCH] Some typos
In-Reply-To: <55F2835B.9050400@oracle.com>
References: <1441944770621.2071257876@boxbe>
	<167623495.889639.1441953230257.JavaMail.yahoo@mail.yahoo.com>
	<55F2835B.9050400@oracle.com>
Message-ID: <6335E4E8-B018-4DF7-85E3-449660FC2651@lagergren.net>

I think we use American English as the standard. It says ?optimization? everywhere, for example. Also ?color?. Thus, it should probably remain ?behavior?.

/M

> On 11 Sep 2015, at 09:31, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Hi Ahmed,
> 
> Thanks. NetBeans has similar feature - but that means opening and reading/looking at each file. I thought if there is any automated way to search for all typos across files of a project or a directory.
> 
> * behaviour / behavior being British / American spelling, I'd rather leave it..
> 
> * I'll check out @gmail.com in @author
> 
> Thanks,
> -Sundar
> 
> 
> On 9/11/2015 12:03 PM, Ahmed Ashour wrote:
>> Hi Sundar,
>> Eclipse has automatic highlight of potential spelling mistakes, you just need to go through the code.
>> In the other comments I mistyped, and it should be:     - 'behaviour' could be 'behavior': there are three places.    - WarnCallback: references '@gmail.com' in @author, this is the only place, which looks strange.
>> 
>> 
>> Thanks again,Ahmed
>>       From: Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>
>>  To: nashorn-dev at openjdk.java.net
>>  Sent: Friday, September 11, 2015 5:50 AM
>>  Subject: Re: [PATCH] Some typos
>>    Hi Ahmed,
>> 
>> Thanks for submitting this patch. I've filed
>> https://bugs.openjdk.java.net/browse/JDK-8136349
>> 
>> PS. Did you find these while reading code or used any automation/tool to
>> find spelling issues? Just curious..
>> 
>> Thanks,
>> -Sundar
>> 
>> On 9/11/2015 1:36 AM, Ahmed Ashour wrote:
>>> Dear all,
>>> 
>>> Please find below patch, which:
>>>     - Handles some typos
>>>     - Removes unused imports from two files.
>>> 
>>> Also, there are other potential places to modify (if appropriate):
>>>     - WarnCallback: references '@gmail.com' in @author, this is the
>>> only place, which looks strange.
>>>     - 'behavior' could be 'behavior': there are three places.
>>> 
>>> Hope you find it useful.
>>> 
>>> Yours,
>>> Ahmed
>> 
> 


From lagergren at gmail.com  Fri Sep 11 09:18:26 2015
From: lagergren at gmail.com (Marcus Lagergren)
Date: Fri, 11 Sep 2015 11:18:26 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <55F14B1A.6080806@oracle.com>
References: <BE54CAF4-021A-428B-808E-6198996E581B@oracle.com>
	<55F14B1A.6080806@oracle.com>
Message-ID: <BAB267A1-B4CA-4A88-95CE-A7D5523E9E01@lagergren.net>

+1 Looks good to me too. Great that you cleaned up that ?owner? generic. I can?t remember what else we had as owners in the beginning for CodeInstallers than ScriptEnvironments.

Nitpicks: not sure if we had a convention that static final fields are named UPPER_CASE_LIKE_THIS. We have e.g. the LongAdder called ?emittedUnitCount? in CompileUnit etc.

/M

> On 10 Sep 2015, at 11:19, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Looks good to me.
> 
> Hannes
> 
> Am 2015-09-09 um 15:35 schrieb Attila Szegedi:
>> Please review JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code" at <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8135251>
>> 
>> Implementation notes are in <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379 <https://bugs.openjdk.java.net/browse/JDK-8135251?focusedCommentId=13841379&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13841379>>
>> 
>> Thanks,
>>   Attila.
> 


From lagergren at gmail.com  Fri Sep 11 09:19:30 2015
From: lagergren at gmail.com (Marcus Lagergren)
Date: Fri, 11 Sep 2015 11:19:30 +0200
Subject: Review request for JDK-8134569: Add tests for prototype callsites
In-Reply-To: <55F151CC.2020508@oracle.com>
References: <55F151CC.2020508@oracle.com>
Message-ID: <00EFB056-3FB9-4557-9C93-27A8CD2646F8@lagergren.net>

+1

> On 10 Sep 2015, at 11:47, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review JDK-8134569: Add tests for prototype callsites:
> 
> http://cr.openjdk.java.net/~hannesw/8134569/webrev/
> 
> This just adds a few test cases for the nested constructor code pattern.
> 
> Thanks,
> Hannes


From lagergren at gmail.com  Fri Sep 11 09:24:51 2015
From: lagergren at gmail.com (Marcus Lagergren)
Date: Fri, 11 Sep 2015 11:24:51 +0200
Subject: RFR 8027137: Merge ScriptFunction and ScriptFunctionImpl
In-Reply-To: <55F01A65.9080107@oracle.com>
References: <55EFEB81.7060404@oracle.com>
	<D1E4FF8B-CA74-47F5-82C7-C2BCFEE8AF7E@oracle.com>
	<55F01661.4050000@oracle.com> <55F01A65.9080107@oracle.com>
Message-ID: <6B0777CB-AC79-436A-AE27-8172FECF689B@lagergren.net>

I love this change! Thanks for it!

/M

> On 09 Sep 2015, at 13:39, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Looks good!
> 
> Am 2015-09-09 um 13:22 schrieb Sundararajan Athijegannathan:
>> Thanks for the reviews Hannes & Attila.
>> 
>> I've incorporated the changes suggested. Updated webrev: http://cr.openjdk.java.net/~sundar/8027137/webrev.01/
>> 
>> PS. I've changed all counters (used from NativeDebug) to use LongAdder.
>> 
>> -Sundar
>> 
>> On 9/9/2015 2:57 PM, Attila Szegedi wrote:
>>> Great work! I?m very happy that ScriptFunctionImpl is going away.
>>> 
>>> Some implementation remarks:
>>> 
>>> - The newly public methods in Global.java, getFunctionPrototype and getTypeErrorThrower don?t have Javadoc.
>>> - The newly public two constructors of PrototypeObject also don?t hava Javadoc.
>>> -  while you're at it, how about we replace ScriptFunction.constructorCount/invokes/allocations fields with LongAdder objects? We should gradually be replacing all such static counters.
>>> - can we create an explicit subclass for bound functions? It can be declared as "private static class Bound extends ScriptFunction { ... }" within the ScriptFunction class. When we debug, we'll then see its name as ScriptFunction$Bound instead of ScriptFunction$1.
>>> 
>>> Attila.
>>> 
>>>> On Sep 9, 2015, at 10:19 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>>> 
>>>> Please review http://cr.openjdk.java.net/~sundar/8027137/ for https://bugs.openjdk.java.net/browse/JDK-8027137
>>>> 
>>>> Thanks,
>>>> -Sundar
>> 
> 


From attila.szegedi at oracle.com  Fri Sep 11 09:56:47 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 11 Sep 2015 11:56:47 +0200
Subject: RFR 8136349: Typos patch for nashorn sources submitted on Sep 10,
	2015
In-Reply-To: <55F28851.5070607@oracle.com>
References: <55F28851.5070607@oracle.com>
Message-ID: <34AC2652-7D05-4853-973A-2FF47D9CAB4B@oracle.com>

+1 - I have already reviewed the .01 webrev.

> On Sep 11, 2015, at 9:52 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8136349/ for https://bugs.openjdk.java.net/browse/JDK-8136349
> 
> This is a contribution by Ahmed Ashour. Please see this thread -> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005206.html
> 
> This webrev was generated by after applying Ahmed's patch & then fixing the following manually on top of that:
> 
> 1) File: NativeRegExp.java
> 
>    preceds -> precedes
> 
> 2) File: CompiledFunction.java
> 
>    rest of -> "restOf" - this is a reference to "restOf" methods generated and so should not be "rest of".
> 
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Fri Sep 11 10:16:41 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 11 Sep 2015 15:46:41 +0530
Subject: RFR 8136349: Typos patch for nashorn sources submitted on Sep 10, 
	2015
In-Reply-To: <34AC2652-7D05-4853-973A-2FF47D9CAB4B@oracle.com>
References: <55F28851.5070607@oracle.com>
	<34AC2652-7D05-4853-973A-2FF47D9CAB4B@oracle.com>
Message-ID: <55F2AA09.20507@oracle.com>

Thanks for all the reviews! Ahmed, thanks for your contribution!

http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/c13179703f65

PS. Pushed changes in webrev.01 @ 
http://cr.openjdk.java.net/~sundar/8136349/webrev.01/

Thanks
-Sundar

On 9/11/2015 3:26 PM, Attila Szegedi wrote:
> +1 - I have already reviewed the .01 webrev.
>
>> On Sep 11, 2015, at 9:52 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>
>> Please review http://cr.openjdk.java.net/~sundar/8136349/ for https://bugs.openjdk.java.net/browse/JDK-8136349
>>
>> This is a contribution by Ahmed Ashour. Please see this thread -> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005206.html
>>
>> This webrev was generated by after applying Ahmed's patch & then fixing the following manually on top of that:
>>
>> 1) File: NativeRegExp.java
>>
>>     preceds -> precedes
>>
>> 2) File: CompiledFunction.java
>>
>>     rest of -> "restOf" - this is a reference to "restOf" methods generated and so should not be "rest of".
>>
>> Thanks,
>> -Sundar


From asashour at yahoo.com  Fri Sep 11 11:05:26 2015
From: asashour at yahoo.com (Ahmed Ashour)
Date: Fri, 11 Sep 2015 13:05:26 +0200
Subject: [PATCH] SuppressWarnings
Message-ID: <55F2B576.20308@yahoo.com>

Hi all,

Please find the below patch, which covers:
     - Unneeded @SuppressWarnings
     - Generics Eclipse warnings
     - Spacing before and after comma.
     - 'everytime' to be 'every time'

Thanks,
Ahmed


diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -111,7 +111,7 @@
          private final TypeBasedGuardingDynamicLinker[] linkers;
          private final List<TypeBasedGuardingDynamicLinker>[] 
singletonLinkers;

-        @SuppressWarnings({"unchecked", "rawtypes"})
+        @SuppressWarnings("unchecked")
          ClassToLinker(final TypeBasedGuardingDynamicLinker[] linkers) {
              this.linkers = linkers;
              singletonLinkers = new List[linkers.length];
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -219,7 +219,7 @@
      // If expression is a primitive literal that is not an array index 
and does return its string value. Else return null.
      private static String getConstantPropertyName(final Expression 
expression) {
          if (expression instanceof LiteralNode.PrimitiveLiteralNode) {
-            final Object value = ((LiteralNode) expression).getValue();
+            final Object value = ((LiteralNode<?>) expression).getValue();
              if (value instanceof String && 
SAFE_PROPERTY_NAME.matcher((String) value).matches()) {
                  return (String) value;
              }
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornTextifier.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornTextifier.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/debug/NashornTextifier.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -679,7 +679,7 @@
      }

      @Override
-    public void visitLocalVariable(final String name, final String 
desc,final String signature, final Label start, final Label end, final 
int index) {
+    public void visitLocalVariable(final String name, final String 
desc, final String signature, final Label start, final Label end, final 
int index) {

          final StringBuilder sb = new StringBuilder();
          if (!localVarsStarted) {
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeMath.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeMath.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/objects/NativeMath.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -238,7 +238,7 @@
       */
      @SpecializedFunction
      public static double atan2(final Object self, final double y, 
final double x) {
-        return Math.atan2(y,x);
+        return Math.atan2(y, x);
      }

      /**
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/DateParser.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/DateParser.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/DateParser.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -78,7 +78,7 @@
      private int yearSign = 0;
      private boolean namedMonth = false;

-    private final static HashMap<String,Name> names = new HashMap<>();
+    private final static HashMap<String, Name> names = new HashMap<>();

      static {
          addName("monday", Name.DAY_OF_WEEK, 0);
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessorProperty.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessorProperty.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/AccessorProperty.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -649,7 +649,7 @@

              final MethodHandle widerSetter = 
newProperty.getSetter(type, newMap);
              final Class<?>     ct = getLocalType();
-            mh = MH.filterArguments(widerSetter, 0, 
MH.insertArguments(debugReplace(ct, type, currentMap, newMap) , 1, newMap));
+            mh = MH.filterArguments(widerSetter, 0, 
MH.insertArguments(debugReplace(ct, type, currentMap, newMap), 1, newMap));
              if (ct != null && ct.isPrimitive() && !type.isPrimitive()) {
                   mh = 
ObjectClassGenerator.createGuardBoxedPrimitiveSetter(ct, 
generateSetter(ct, ct), mh);
              }
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Context.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -234,7 +234,7 @@

          @Override
          public void storeScript(final String cacheKey, final Source 
source, final String mainClassName,
-                                final Map<String,byte[]> classBytes, 
final Map<Integer, FunctionInitializer> initializers,
+                                final Map<String, byte[]> classBytes, 
final Map<Integer, FunctionInitializer> initializers,
                                  final Object[] constants, final int 
compilationId) {
              if (context.codeStore != null) {
                  context.codeStore.store(cacheKey, source, 
mainClassName, classBytes, initializers, constants, compilationId);
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NativeJavaPackage.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NativeJavaPackage.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/NativeJavaPackage.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -235,7 +235,7 @@
          }

          // Check for explicit constructor signature use
-        // Example: new (java.awt["Color(int, int,int)"])(2, 3, 4);
+        // Example: new (java.awt["Color(int, int, int)"])(2, 3, 4);
          final int openBrace = propertyName.indexOf('(');
          final int closeBrace = propertyName.lastIndexOf(')');
          if (openBrace != -1 || closeBrace != -1) {
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -679,7 +679,6 @@
       * @return either the existing map, or a loaded map from the 
persistent type info cache, or a new empty map if
       * neither an existing map or a persistent cached type info is 
available.
       */
-    @SuppressWarnings("unused")
      private static Map<Integer, Type> 
getEffectiveInvalidatedProgramPoints(
              final Map<Integer, Type> invalidatedProgramPoints, final 
Object typeInformationFile) {
          if(invalidatedProgramPoints != null) {
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptEnvironment.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptEnvironment.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptEnvironment.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -220,7 +220,6 @@
       * @param out output print writer
       * @param err error print writer
       */
-    @SuppressWarnings("unused")
      public ScriptEnvironment(final Options options, final PrintWriter 
out, final PrintWriter err) {
          this.out = out;
          this.err = err;
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/UserAccessorProperty.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -298,8 +298,7 @@
      // User defined getter and setter are always called by "dyn:call". 
Note that the user
      // getter/setter may be inherited. If so, proto is bound during 
lookup. In either
      // inherited or self case, slot is also bound during lookup. 
Actual ScriptFunction
-    // to be called is retrieved everytime and applied.
-    @SuppressWarnings("unused")
+    // to be called is retrieved every time and applied.
      private static Object invokeObjectGetter(final Accessors gs, final 
MethodHandle invoker, final Object self) throws Throwable {
          final Object func = gs.getter;
          if (func instanceof ScriptFunction) {
@@ -339,7 +338,6 @@
          throw new UnwarrantedOptimismException(UNDEFINED, programPoint);
      }

-    @SuppressWarnings("unused")
      private static void invokeObjectSetter(final Accessors gs, final 
MethodHandle invoker, final String name, final Object self, final Object 
value) throws Throwable {
          final Object func = gs.setter;
          if (func instanceof ScriptFunction) {
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -69,7 +69,7 @@
          final int l = Array.getLength(value);
          for (int i = 0; i < l; i++) {
              if (undefined.isSet(i)) {
-                Array.set(value, i,undefValue);
+                Array.set(value, i, undefValue);
              }
          }

diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JavaSuperAdapterLinker.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -109,7 +109,7 @@
              // Short circuit the lookup here for non-existent methods 
by linking an empty getter. If we just returned
              // null instead, BeansLinker would find final methods on 
the JavaSuperAdapter instead: getClass() and
              // wait().
-            return new 
GuardedInvocation(MethodHandles.dropArguments(EMPTY_GETTER, 
1,type.parameterList().subList(1,
+            return new 
GuardedInvocation(MethodHandles.dropArguments(EMPTY_GETTER, 1, 
type.parameterList().subList(1,
                      type.parameterCount())), guard).asType(descriptor);
          }

diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -98,7 +98,7 @@
      public static final int FLAGS_MASK = (1 << 
CALLSITE_PROGRAM_POINT_SHIFT) - 1;

      private static final 
ClassValue<ConcurrentMap<NashornCallSiteDescriptor, 
NashornCallSiteDescriptor>> canonicals =
-            new 
ClassValue<ConcurrentMap<NashornCallSiteDescriptor,NashornCallSiteDescriptor>>() 
{
+            new ClassValue<ConcurrentMap<NashornCallSiteDescriptor, 
NashornCallSiteDescriptor>>() {
          @Override
          protected ConcurrentMap<NashornCallSiteDescriptor, 
NashornCallSiteDescriptor> computeValue(final Class<?> type) {
              return new ConcurrentHashMap<>();
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -162,7 +162,7 @@
                  return TargetInfo.IS_EMPTY_MEM;

              case EncloseType.OPTION:
-            case EncloseNode.STOP_BACKTRACK:
+            case EncloseType.STOP_BACKTRACK:
                  info = quantifiersMemoryInfo(en.target);
                  break;

@@ -907,7 +907,6 @@
          int altNum = 1;

          ConsAltNode topRoot = null, r = null;
-        @SuppressWarnings("unused")
          final ObjPtr<Node> prevNode = new ObjPtr<Node>();
          StringNode stringNode = null;

diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -840,7 +840,7 @@
          regex.operands[regex.operandLength++] = o;
      }

-    private void addChars(final char[] chars, final int pp ,final int 
length) {
+    private void addChars(final char[] chars, final int pp, final int 
length) {
          ensure(codeLength + length);
          int p = pp;
          final int end = p + length;
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -32,7 +32,7 @@
      protected final int[]repeatStk;
      protected final int memStartStk, memEndStk;

-    protected StackMachine(final Regex regex, final char[] chars, final 
int p , final int end) {
+    protected StackMachine(final Regex regex, final char[] chars, final 
int p, final int end) {
          super(regex, chars, p, end);

          this.stack = regex.stackNeeded ? fetchStack() : null;
@@ -59,14 +59,12 @@

      static final ThreadLocal<WeakReference<StackEntry[]>> stacks
              = new ThreadLocal<WeakReference<StackEntry[]>>() {
-        @SuppressWarnings("unused")
          @Override
          protected WeakReference<StackEntry[]> initialValue() {
              return new WeakReference<StackEntry[]>(allocateStack());
          }
      };

-    @SuppressWarnings("unused")
      private static StackEntry[] fetchStack() {
          WeakReference<StackEntry[]> ref = stacks.get();
          StackEntry[] stack = ref.get();
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/ast/ConsAltNode.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/ast/ConsAltNode.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/ast/ConsAltNode.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -110,13 +110,13 @@
                  if (car.parent != this) {
                      warnings.warn("broken list car: " + 
this.getAddressName() + " -> " +  car.getAddressName());
                  }
-                car.verifyTree(set,warnings);
+                car.verifyTree(set, warnings);
              }
              if (cdr != null) {
                  if (cdr.parent != this) {
                      warnings.warn("broken list cdr: " + 
this.getAddressName() + " -> " +  cdr.getAddressName());
                  }
-                cdr.verifyTree(set,warnings);
+                cdr.verifyTree(set, warnings);
              }
          }
      }
diff -r 882bbbfcaf03 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/tools/Shell.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/tools/Shell.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/tools/Shell.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -406,7 +406,7 @@
      public final int getLastExpressionStart(final Context context, 
final String code) {
          final int[] exprStart = { -1 };

-        final Parser p = new Parser(context.getEnv(), 
sourceFor("<partial_code>", code),new Context.ThrowErrorManager()) {
+        final Parser p = new Parser(context.getEnv(), 
sourceFor("<partial_code>", code), new Context.ThrowErrorManager()) {
              @Override
              protected Expression expression() {
                  exprStart[0] = this.start;
diff -r 882bbbfcaf03 
test/src/jdk/nashorn/api/scripting/JSONCompatibleTest.java
--- a/test/src/jdk/nashorn/api/scripting/JSONCompatibleTest.java Thu Sep 
10 19:09:23 2015 +0530
+++ b/test/src/jdk/nashorn/api/scripting/JSONCompatibleTest.java Fri Sep 
11 11:49:39 2015 +0200
@@ -101,14 +101,14 @@
      private static List<Object> asList(final Object obj) {
          assertJSObject(obj);
          Assert.assertTrue(obj instanceof List);
-        return (List)obj;
+        return (List<Object>)obj;
      }

      @SuppressWarnings("unchecked")
      private static Map<String, Object> asMap(final Object obj) {
          assertJSObject(obj);
          Assert.assertTrue(obj instanceof Map);
-        return (Map)obj;
+        return (Map<String, Object>)obj;
      }

      private static void assertJSObject(final Object obj) {
diff -r 882bbbfcaf03 
test/src/jdk/nashorn/api/scripting/test/PluggableJSObjectTest.java
--- a/test/src/jdk/nashorn/api/scripting/test/PluggableJSObjectTest.java 
Thu Sep 10 19:09:23 2015 +0530
+++ b/test/src/jdk/nashorn/api/scripting/test/PluggableJSObjectTest.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -233,7 +233,6 @@
      }

      public static class Factory extends AbstractJSObject {
-        @SuppressWarnings("unused")
          @Override
          public Object newObject(final Object... args) {
              return new HashMap<Object, Object>();
diff -r 882bbbfcaf03 
test/src/jdk/nashorn/api/scripting/test/ScriptObjectMirrorTest.java
--- 
a/test/src/jdk/nashorn/api/scripting/test/ScriptObjectMirrorTest.java 
Thu Sep 10 19:09:23 2015 +0530
+++ 
b/test/src/jdk/nashorn/api/scripting/test/ScriptObjectMirrorTest.java 
Fri Sep 11 11:49:39 2015 +0200
@@ -361,7 +361,7 @@
              " return obj instanceof 
Packages.jdk.nashorn.api.scripting.ScriptObjectMirror; " +
              "}");
          @SuppressWarnings("unchecked")
-        final Function<Object,Object> func = 
invocable.getInterface(Function.class);
+        final Function<Object, Object> func = 
invocable.getInterface(Function.class);
          assertFalse((boolean)func.apply(engine.eval("({ x: 2 })")));
      }



From hannes.wallnoefer at oracle.com  Fri Sep 11 12:20:13 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 11 Sep 2015 14:20:13 +0200
Subject: Review request for JDK-8134609: Allow constructors with same
	prototoype map to share the allocator map
Message-ID: <55F2C6FD.7090804@oracle.com>

Please review JDK-8134609: Allow constructors with same prototoype map 
to share the allocator map:

http://cr.openjdk.java.net/~hannesw/8134609/webrev/

The details for this are a bit tricky, so I added some notes to the jira 
bug:

https://bugs.openjdk.java.net/browse/JDK-8134609?focusedCommentId=13843176&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13843176

Thanks,
Hannes

From sundararajan.athijegannathan at oracle.com  Fri Sep 11 14:50:52 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 11 Sep 2015 20:20:52 +0530
Subject: [8u] approval request for 8136349: Typos patch for nashorn sources
	submitted on Sep 10, 2015
Message-ID: <55F2EA4C.7080102@oracle.com>

Please approve.

Bug: https://bugs.openjdk.java.net/browse/JDK-8136349
jdk9 review thread: 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005213.html
jdk8u webrev: http://cr.openjdk.java.net/~sundar/8136349/8u/webrev.00/

I had to apply patch manually but ignore diffs the files that are not 
present in jdk8u (eg. jdk.nashorn.api.tree.* files). Other than that 
except for modular layout difference, diff is same.

Thanks,
-Sundar

From sundararajan.athijegannathan at oracle.com  Fri Sep 11 14:51:05 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 11 Sep 2015 20:21:05 +0530
Subject: [8u] approval request for 8136349: Typos patch for nashorn sources
	submitted on Sep 10, 2015
Message-ID: <55F2EA59.6030005@oracle.com>

Please approve.

Bug: https://bugs.openjdk.java.net/browse/JDK-8136349
jdk9 review thread: 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005213.html
jdk8u webrev: http://cr.openjdk.java.net/~sundar/8136349/8u/webrev.00/

I had to apply patch manually but ignore diffs on the files that are not 
present in jdk8u (eg. jdk.nashorn.api.tree.* files). Other than that 
except for modular layout difference, diff is same.

Thanks,
-Sundar

From attila.szegedi at oracle.com  Fri Sep 11 15:27:32 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 11 Sep 2015 17:27:32 +0200
Subject: [8u] approval request for 8136349: Typos patch for nashorn
	sources submitted on Sep 10, 2015
In-Reply-To: <55F2EA59.6030005@oracle.com>
References: <55F2EA59.6030005@oracle.com>
Message-ID: <6F3BB7E6-18B7-4BE7-AFF8-276FDA9E3F01@oracle.com>

+1 on the backported changes

> On Sep 11, 2015, at 4:51 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please approve.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8136349
> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005213.html
> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8136349/8u/webrev.00/
> 
> I had to apply patch manually but ignore diffs on the files that are not present in jdk8u (eg. jdk.nashorn.api.tree.* files). Other than that except for modular layout difference, diff is same.
> 
> Thanks,
> -Sundar


From sean.coffey at oracle.com  Fri Sep 11 15:29:43 2015
From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=)
Date: Fri, 11 Sep 2015 16:29:43 +0100
Subject: [8u] approval request for 8136349: Typos patch for nashorn sources
	submitted on Sep 10, 2015
In-Reply-To: <6F3BB7E6-18B7-4BE7-AFF8-276FDA9E3F01@oracle.com>
References: <55F2EA59.6030005@oracle.com>
	<6F3BB7E6-18B7-4BE7-AFF8-276FDA9E3F01@oracle.com>
Message-ID: <55F2F367.8080302@oracle.com>

Approved.

Regards,
Sean.

On 11/09/15 16:27, Attila Szegedi wrote:
> +1 on the backported changes
>
>> On Sep 11, 2015, at 4:51 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>
>> Please approve.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136349
>> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005213.html
>> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8136349/8u/webrev.00/
>>
>> I had to apply patch manually but ignore diffs on the files that are not present in jdk8u (eg. jdk.nashorn.api.tree.* files). Other than that except for modular layout difference, diff is same.
>>
>> Thanks,
>> -Sundar


From attila.szegedi at oracle.com  Fri Sep 11 16:00:14 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 11 Sep 2015 18:00:14 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for
	loading Nashorn script code
Message-ID: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>

Please review the revised changes for JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code? <https://bugs.openjdk.java.net/browse/JDK-8135251>

The revision incorporates the following changes:
- the feature can be disabled by setting the "nashorn.disableVmAnonymousClasses system property?
- jdk9 root-level modules.xml explicitly exports sun.misc to jdk.scripting.nashorn
- the changes to the CodeInstaller and Compiler API have since been separately committed, so they are no longer part of this issue, making its surface area smaller.

Webrevs are found at:
http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9>
http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn>

The fist webrev is for jdk9/modules.xml; the change simply adds an export of sun.misc to jdk.scripting.nashorn; it is also the reason why I included build-dev on this review.
The second webrev is the changes to the Nashorn code.

Thanks,
  Attila.


From lagergren at gmail.com  Sun Sep 13 10:47:01 2015
From: lagergren at gmail.com (Marcus Lagergren)
Date: Sun, 13 Sep 2015 12:47:01 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
Message-ID: <1966C2A9-6460-4529-8879-932ABFE65EDD@lagergren.net>

+1. Nicely done.

Does this compile without unsafe warnings, though?

/M

> On 11 Sep 2015, at 18:00, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> e


From sundararajan.athijegannathan at oracle.com  Mon Sep 14 07:04:16 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 14 Sep 2015 12:34:16 +0530
Subject: [8u] RFR 8055917: jdk.nashorn.internal., , codegen, ,
	.CompilationPhase$N should be renamed to proper classes
Message-ID: <55F67170.4090103@oracle.com>

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

PS. Piggybacking few cleanups in samples and also adding 2 new samples.

Thanks,
-Sundar

From sundararajan.athijegannathan at oracle.com  Mon Sep 14 07:15:45 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 14 Sep 2015 12:45:45 +0530
Subject: [8u] RFR 8055917: jdk.nashorn.internal., , codegen, ,
	.CompilationPhase$N should be renamed to proper classes
In-Reply-To: <55F67170.4090103@oracle.com>
References: <55F67170.4090103@oracle.com>
Message-ID: <55F67421.3080707@oracle.com>

Oops. Wrong cut-paste of [8u] in the title.  This review request is for 
jdk9-dev/nashorn.

Thanks,
-Sundar

On 9/14/2015 12:34 PM, Sundararajan Athijegannathan wrote:
> Please review http://cr.openjdk.java.net/~sundar/8055917/ for 
> https://bugs.openjdk.java.net/browse/JDK-8055917
>
> PS. Piggybacking few cleanups in samples and also adding 2 new samples.
>
> Thanks,
> -Sundar


From attila.szegedi at oracle.com  Mon Sep 14 07:54:05 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 14 Sep 2015 09:54:05 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <1966C2A9-6460-4529-8879-932ABFE65EDD@lagergren.net>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
	<1966C2A9-6460-4529-8879-932ABFE65EDD@lagergren.net>
Message-ID: <E74C2620-2CC7-44FD-B99C-E33492642804@oracle.com>

What do you mean by ?unsafe warning??

> On Sep 13, 2015, at 12:47 PM, Marcus Lagergren <lagergren at gmail.com> wrote:
> 
> +1. Nicely done.
> 
> Does this compile without unsafe warnings, though?
> 
> /M
> 
>> On 11 Sep 2015, at 18:00, Attila Szegedi <attila.szegedi at oracle.com <mailto:attila.szegedi at oracle.com>> wrote:
>> 
>> e
> 


From lagergren at gmail.com  Mon Sep 14 07:55:19 2015
From: lagergren at gmail.com (Marcus Lagergren)
Date: Mon, 14 Sep 2015 09:55:19 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <E74C2620-2CC7-44FD-B99C-E33492642804@oracle.com>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
	<1966C2A9-6460-4529-8879-932ABFE65EDD@lagergren.net>
	<E74C2620-2CC7-44FD-B99C-E33492642804@oracle.com>
Message-ID: <7A200E46-2784-4772-9019-AB658705958B@lagergren.net>

ant test

Does it spit out warnings like e.g.

Temp.java:1: warning: Unsafe is internal proprietary API and may be removed in a future release
import sun.misc.Unsafe;
               ^
Temp.java:6: warning: Unsafe is internal proprietary API and may be removed in a future release
    private static Unsafe getUnsafe() {
                   ^
Temp.java:7: warning: Unsafe is internal proprietary API and may be removed in a future release
	return AccessController.doPrivileged(new PrivilegedAction<Unsafe>() {
	                                                          ^
Temp.java:9: warning: Unsafe is internal proprietary API and may be removed in a future release
                    public Unsafe run() {
                           ^
Temp.java:11: warning: Unsafe is internal proprietary API and may be removed in a future release
			final Field theUnsafeField = Unsafe.class.getDeclaredField("theUnsafe");
			                             ^
Temp.java:13: warning: Unsafe is internal proprietary API and may be removed in a future release
			return (Unsafe)theUnsafeField.get(null);
			        ^
Temp.java:21: warning: Unsafe is internal proprietary API and may be removed in a future release
    private static Unsafe UNSAFE = getUnsafe();
                   ^
7 warnings

Because we don?t want compile warnings ;-)

/M


> On 14 Sep 2015, at 09:54, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> What do you mean by ?unsafe warning??
> 
>> On Sep 13, 2015, at 12:47 PM, Marcus Lagergren <lagergren at gmail.com <mailto:lagergren at gmail.com>> wrote:
>> 
>> +1. Nicely done.
>> 
>> Does this compile without unsafe warnings, though?
>> 
>> /M
>> 
>>> On 11 Sep 2015, at 18:00, Attila Szegedi <attila.szegedi at oracle.com <mailto:attila.szegedi at oracle.com>> wrote:
>>> 
>>> e
>> 
> 


From attila.szegedi at oracle.com  Mon Sep 14 07:57:48 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 14 Sep 2015 09:57:48 +0200
Subject: [8u] RFR 8055917: jdk.nashorn.internal., , codegen, ,
	.CompilationPhase$N should be renamed to proper classes
In-Reply-To: <55F67170.4090103@oracle.com>
References: <55F67170.4090103@oracle.com>
Message-ID: <88DA7E64-C397-4286-ADF7-F87AED6A1280@oracle.com>

I?d achieve the same effect by changing CompilationPhase to be a regular class instead of an enum, and creating named inner classes.

While we?re at it, let?s also rename ?BuiltinTransform? to something closer to ?ApplySpecialization?.

For bonus points, you might consider removing CompilationState altogether. CompilationState serves no functional purpose just to ensure that a phase only runs when it's preceding states did. In fact, some compilation phases have been added since that don?t even bother updating CompilationState anymore, so it?s effectively abandoned.

Attila.

[9/14/15, 9:39:54 AM] Attila Szegedi: but we guarantee that with the construction of phases in Compiler.java anyway
> On Sep 14, 2015, at 9:04 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8055917/ for https://bugs.openjdk.java.net/browse/JDK-8055917
> 
> PS. Piggybacking few cleanups in samples and also adding 2 new samples.
> 
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Mon Sep 14 09:23:24 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 14 Sep 2015 14:53:24 +0530
Subject: [8u] RFR 8055917: jdk.nashorn.internal., , codegen, ,
	.CompilationPhase$N should be renamed to proper classes
In-Reply-To: <88DA7E64-C397-4286-ADF7-F87AED6A1280@oracle.com>
References: <55F67170.4090103@oracle.com>
	<88DA7E64-C397-4286-ADF7-F87AED6A1280@oracle.com>
Message-ID: <55F6920C.5070100@oracle.com>

Updated webrev as per the suggestions: 
http://cr.openjdk.java.net/~sundar/8055917/webrev.01/

* CompilationPhase is an abstract class (not an enum).
* Nested subclasses are private and final - static final field for each 
subclass instance
* All subclasses follow ABCPhase name pattern (can't use 
ApplySpecialization, CacheAst etc. - as that would clash with class 
doing actual transformation)
* Removed CompilationState.

Thanks,
-Sundar

On 9/14/2015 1:27 PM, Attila Szegedi wrote:
> I?d achieve the same effect by changing CompilationPhase to be a regular class instead of an enum, and creating named inner classes.
>
> While we?re at it, let?s also rename ?BuiltinTransform? to something closer to ?ApplySpecialization?.
>
> For bonus points, you might consider removing CompilationState altogether. CompilationState serves no functional purpose just to ensure that a phase only runs when it's preceding states did. In fact, some compilation phases have been added since that don?t even bother updating CompilationState anymore, so it?s effectively abandoned.
>
> Attila.
>
> [9/14/15, 9:39:54 AM] Attila Szegedi: but we guarantee that with the construction of phases in Compiler.java anyway
>> On Sep 14, 2015, at 9:04 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>
>> Please review http://cr.openjdk.java.net/~sundar/8055917/ for https://bugs.openjdk.java.net/browse/JDK-8055917
>>
>> PS. Piggybacking few cleanups in samples and also adding 2 new samples.
>>
>> Thanks,
>> -Sundar


From attila.szegedi at oracle.com  Mon Sep 14 09:48:32 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 14 Sep 2015 11:48:32 +0200
Subject: Review request for JDK-8134609: Allow constructors with same
	prototoype map to share the allocator map
In-Reply-To: <55F2C6FD.7090804@oracle.com>
References: <55F2C6FD.7090804@oracle.com>
Message-ID: <0606D015-2025-4A49-B09D-C34B39A0105E@oracle.com>

Overall, great work. Really well thought out; adding features to runtimes to optimize special cases always has the possibility of becoming complicated, and you have managed to keep the changes to the minimum, and pretty well contained. E.g. I like how even before your changes we have a fast path in ScriptObject.findProperty for the case where the property is not in the prototype, so the shared proto check there only kicks in when we do actually need to deal with prototypes, etc.

I only have some very small remarks:

- AllocatorMap could use getSharedPrototypeMap() in various places where it explicitly uses allocatorMap.getSharedProtoMap() now
- Debug.scriptStack() doesn't seem to be used
- PropertyMap.invalidateProtoGetSwitchPoint should be renamed invalidateProtoSwitchPoint. invalidateAllProtoGetSwitchPoints too
- PropertyMap.invalidateSharedProtoSwitchPoint: there's the "switchPoint != null && !switchPoint.hasBeenInvalidated()" predicate. Is it possible for switchPoint to not be null and be invalidated? If not, maybe hasBeenInvalidated should be an assert within if instead
- I wonder if "sharedProtoMap != myProto.getMap() || !myProto.getMap().isValidSharedProtoMap()" in ScriptObject.checkSharedProtoMap and a similar predicate "allocatorMap.getSharedProtoMap() != prototype.getMap() || !prototype.getMap().isValidSharedProtoMap())? in ScriptFunction.getAllocatorMap() couldn?t be extracted into a single method somewhere, if they share semantic similarity (syntactically they look very similar)

Attila.

> On Sep 11, 2015, at 2:20 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review JDK-8134609: Allow constructors with same prototoype map to share the allocator map:
> 
> http://cr.openjdk.java.net/~hannesw/8134609/webrev/
> 
> The details for this are a bit tricky, so I added some notes to the jira bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8134609?focusedCommentId=13843176&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13843176
> 
> Thanks,
> Hannes


From hannes.wallnoefer at oracle.com  Mon Sep 14 10:09:24 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 14 Sep 2015 12:09:24 +0200
Subject: [8u] RFR 8055917: jdk.nashorn.internal., , codegen, ,
	.CompilationPhase$N should be renamed to proper classes
In-Reply-To: <55F6920C.5070100@oracle.com>
References: <55F67170.4090103@oracle.com>
	<88DA7E64-C397-4286-ADF7-F87AED6A1280@oracle.com>
	<55F6920C.5070100@oracle.com>
Message-ID: <55F69CD4.2020301@oracle.com>

+1

I like the new, simpler code!

Am 2015-09-14 um 11:23 schrieb Sundararajan Athijegannathan:
> Updated webrev as per the suggestions: 
> http://cr.openjdk.java.net/~sundar/8055917/webrev.01/
>
> * CompilationPhase is an abstract class (not an enum).
> * Nested subclasses are private and final - static final field for 
> each subclass instance
> * All subclasses follow ABCPhase name pattern (can't use 
> ApplySpecialization, CacheAst etc. - as that would clash with class 
> doing actual transformation)
> * Removed CompilationState.
>
> Thanks,
> -Sundar
>
> On 9/14/2015 1:27 PM, Attila Szegedi wrote:
>> I?d achieve the same effect by changing CompilationPhase to be a 
>> regular class instead of an enum, and creating named inner classes.
>>
>> While we?re at it, let?s also rename ?BuiltinTransform? to something 
>> closer to ?ApplySpecialization?.
>>
>> For bonus points, you might consider removing CompilationState 
>> altogether. CompilationState serves no functional purpose just to 
>> ensure that a phase only runs when it's preceding states did. In 
>> fact, some compilation phases have been added since that don?t even 
>> bother updating CompilationState anymore, so it?s effectively abandoned.
>>
>> Attila.
>>
>> [9/14/15, 9:39:54 AM] Attila Szegedi: but we guarantee that with the 
>> construction of phases in Compiler.java anyway
>>> On Sep 14, 2015, at 9:04 AM, Sundararajan Athijegannathan 
>>> <sundararajan.athijegannathan at oracle.com> wrote:
>>>
>>> Please review http://cr.openjdk.java.net/~sundar/8055917/ for 
>>> https://bugs.openjdk.java.net/browse/JDK-8055917
>>>
>>> PS. Piggybacking few cleanups in samples and also adding 2 new samples.
>>>
>>> Thanks,
>>> -Sundar
>


From attila.szegedi at oracle.com  Mon Sep 14 10:19:19 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 14 Sep 2015 12:19:19 +0200
Subject: [8u] RFR 8055917: jdk.nashorn.internal., , codegen, ,
	.CompilationPhase$N should be renamed to proper classes
In-Reply-To: <55F6920C.5070100@oracle.com>
References: <55F67170.4090103@oracle.com>
	<88DA7E64-C397-4286-ADF7-F87AED6A1280@oracle.com>
	<55F6920C.5070100@oracle.com>
Message-ID: <09410786-D800-4183-9CBB-E3A8E26AFCAB@oracle.com>

+1

> On Sep 14, 2015, at 11:23 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Updated webrev as per the suggestions: http://cr.openjdk.java.net/~sundar/8055917/webrev.01/
> 
> * CompilationPhase is an abstract class (not an enum).
> * Nested subclasses are private and final - static final field for each subclass instance
> * All subclasses follow ABCPhase name pattern (can't use ApplySpecialization, CacheAst etc. - as that would clash with class doing actual transformation)
> * Removed CompilationState.
> 
> Thanks,
> -Sundar
> 
> On 9/14/2015 1:27 PM, Attila Szegedi wrote:
>> I?d achieve the same effect by changing CompilationPhase to be a regular class instead of an enum, and creating named inner classes.
>> 
>> While we?re at it, let?s also rename ?BuiltinTransform? to something closer to ?ApplySpecialization?.
>> 
>> For bonus points, you might consider removing CompilationState altogether. CompilationState serves no functional purpose just to ensure that a phase only runs when it's preceding states did. In fact, some compilation phases have been added since that don?t even bother updating CompilationState anymore, so it?s effectively abandoned.
>> 
>> Attila.
>> 
>> [9/14/15, 9:39:54 AM] Attila Szegedi: but we guarantee that with the construction of phases in Compiler.java anyway
>>> On Sep 14, 2015, at 9:04 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>> 
>>> Please review http://cr.openjdk.java.net/~sundar/8055917/ for https://bugs.openjdk.java.net/browse/JDK-8055917
>>> 
>>> PS. Piggybacking few cleanups in samples and also adding 2 new samples.
>>> 
>>> Thanks,
>>> -Sundar
> 


From sundararajan.athijegannathan at oracle.com  Mon Sep 14 10:41:27 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 14 Sep 2015 16:11:27 +0530
Subject: [8u] RFR 8055917: jdk.nashorn.internal., , codegen, ,
	.CompilationPhase$N should be renamed to proper classes
In-Reply-To: <09410786-D800-4183-9CBB-E3A8E26AFCAB@oracle.com>
References: <55F67170.4090103@oracle.com>
	<88DA7E64-C397-4286-ADF7-F87AED6A1280@oracle.com>
	<55F6920C.5070100@oracle.com>
	<09410786-D800-4183-9CBB-E3A8E26AFCAB@oracle.com>
Message-ID: <55F6A457.1070403@oracle.com>

Also, updated ConstantFolding to be ConstantFoldingPhase to be uniform 
(offline comment). I'm going ahead with updated webrev: 
http://cr.openjdk.java.net/~sundar/8055917/webrev.02/

Thanks,
-Sundar

On 9/14/2015 3:49 PM, Attila Szegedi wrote:
> +1
>
>> On Sep 14, 2015, at 11:23 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>
>> Updated webrev as per the suggestions: http://cr.openjdk.java.net/~sundar/8055917/webrev.01/
>>
>> * CompilationPhase is an abstract class (not an enum).
>> * Nested subclasses are private and final - static final field for each subclass instance
>> * All subclasses follow ABCPhase name pattern (can't use ApplySpecialization, CacheAst etc. - as that would clash with class doing actual transformation)
>> * Removed CompilationState.
>>
>> Thanks,
>> -Sundar
>>
>> On 9/14/2015 1:27 PM, Attila Szegedi wrote:
>>> I?d achieve the same effect by changing CompilationPhase to be a regular class instead of an enum, and creating named inner classes.
>>>
>>> While we?re at it, let?s also rename ?BuiltinTransform? to something closer to ?ApplySpecialization?.
>>>
>>> For bonus points, you might consider removing CompilationState altogether. CompilationState serves no functional purpose just to ensure that a phase only runs when it's preceding states did. In fact, some compilation phases have been added since that don?t even bother updating CompilationState anymore, so it?s effectively abandoned.
>>>
>>> Attila.
>>>
>>> [9/14/15, 9:39:54 AM] Attila Szegedi: but we guarantee that with the construction of phases in Compiler.java anyway
>>>> On Sep 14, 2015, at 9:04 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>>>
>>>> Please review http://cr.openjdk.java.net/~sundar/8055917/ for https://bugs.openjdk.java.net/browse/JDK-8055917
>>>>
>>>> PS. Piggybacking few cleanups in samples and also adding 2 new samples.
>>>>
>>>> Thanks,
>>>> -Sundar


From asashour at yahoo.com  Mon Sep 14 12:54:40 2015
From: asashour at yahoo.com (Ahmed Ashour)
Date: Mon, 14 Sep 2015 14:54:40 +0200
Subject: [PATCH] Type Inference
Message-ID: <55F6C390.1030802@yahoo.com>

Hi all,

Please find the below proposed batch for generics Type Inference.

Thanks a lot,
Ahmed


diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -118,7 +118,7 @@
       * @param name the name of the method
       */
      OverloadedDynamicMethod(final Class<?> clazz, final String name) {
-        this(new LinkedList<SingleDynamicMethod>(), 
clazz.getClassLoader(), getClassAndMethodName(clazz, name));
+        this(new LinkedList<>(), clazz.getClassLoader(), 
getClassAndMethodName(clazz, name));
      }

      private OverloadedDynamicMethod(final 
LinkedList<SingleDynamicMethod> methods, final ClassLoader classLoader, 
final String name) {
diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/AssignSymbols.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -519,7 +519,7 @@
      public boolean enterFunctionNode(final FunctionNode functionNode) {
          start(functionNode, false);

-        thisProperties.push(new HashSet<String>());
+        thisProperties.push(new HashSet<>());

          // Every function has a body, even the ones skipped on reparse 
(they have an empty one). We're
          // asserting this as even for those, enterBlock() must be 
invoked to correctly process symbols that
diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/LocalVariableTypesCalculator.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -1635,7 +1635,7 @@
          }
          assert symbol.hasSlot();
          assert !symbol.isGlobal();
-        localVariableTypes = localVariableTypes.isEmpty() ? new 
IdentityHashMap<Symbol, LvarType>() : cloneMap(localVariableTypes);
+        localVariableTypes = localVariableTypes.isEmpty() ? new 
IdentityHashMap<>() : cloneMap(localVariableTypes);
          localVariableTypes.put(symbol, type);
      }

diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/Lower.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -189,7 +189,7 @@
          final int line = debuggerNode.getLineNumber();
          final long token = debuggerNode.getToken();
          final int finish = debuggerNode.getFinish();
-        addStatement(new ExpressionStatement(line, token, finish, new 
RuntimeNode(token, finish, RuntimeNode.Request.DEBUGGER, new 
ArrayList<Expression>())));
+        addStatement(new ExpressionStatement(line, token, finish, new 
RuntimeNode(token, finish, RuntimeNode.Request.DEBUGGER, new 
ArrayList<>())));
          return false;
      }

diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/Type.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/Type.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/codegen/types/Type.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -109,11 +109,11 @@
      private final Class<?> clazz;

      /**
-     * Cache for internal types - this is a query that requires complex 
stringbuilding inside
+     * Cache for internal types - this is a query that requires complex 
string building inside
       * ASM and it saves startup time to cache the type mappings
       */
      private static final Map<Class<?>, 
jdk.internal.org.objectweb.asm.Type> INTERNAL_TYPE_CACHE =
-            Collections.synchronizedMap(new WeakHashMap<Class<?>, 
jdk.internal.org.objectweb.asm.Type>());
+            Collections.synchronizedMap(new WeakHashMap<>());

      /** Internal ASM type for this Type - computed once at construction */
      private transient final jdk.internal.org.objectweb.asm.Type 
internalType;
diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BlockLexicalContext.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BlockLexicalContext.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/BlockLexicalContext.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -49,7 +49,7 @@
      public <T extends LexicalContextNode> T push(final T node) {
          final T pushed = super.push(node);
          if (node instanceof Block) {
-            sstack.push(new ArrayList<Statement>());
+            sstack.push(new ArrayList<>());
          }
          return pushed;
      }
diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/OptimisticLexicalContext.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/OptimisticLexicalContext.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/OptimisticLexicalContext.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -107,7 +107,7 @@
      public <T extends LexicalContextNode> T push(final T node) {
          if (isEnabled) {
              if(node instanceof FunctionNode) {
-                optimisticAssumptions.push(new ArrayList<Assumption>());
+                optimisticAssumptions.push(new ArrayList<>());
              }
          }

diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -686,7 +686,7 @@
              return invalidatedProgramPoints;
          }
          final Map<Integer, Type> loadedProgramPoints = 
OptimisticTypesPersistence.load(typeInformationFile);
-        return loadedProgramPoints != null ? loadedProgramPoints : new 
TreeMap<Integer, Type>();
+        return loadedProgramPoints != null ? loadedProgramPoints : new 
TreeMap<>();
      }

      private FunctionInitializer compileTypeSpecialization(final 
MethodType actualCallSiteType, final ScriptObject runtimeScope, final 
boolean persist) {
diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptEnvironment.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptEnvironment.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptEnvironment.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -343,7 +343,7 @@
          }

          final LoggingOption loggingOption = 
(LoggingOption)options.get("log");
-        this._loggers = loggingOption == null ? new HashMap<String, 
LoggerInfo>() : loggingOption.getLoggers();
+        this._loggers = loggingOption == null ? new HashMap<>() : 
loggingOption.getLoggers();

          final LoggerInfo timeLoggerInfo = 
_loggers.get(Timing.getLoggerName());
          this._timing = new Timing(timeLoggerInfo != null && 
timeLoggerInfo.getLevel() != Level.OFF);
diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/LengthNotWritableFilter.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/LengthNotWritableFilter.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/LengthNotWritableFilter.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -19,7 +19,7 @@
       * @param underlying array
       */
      LengthNotWritableFilter(final ArrayData underlying) {
-        this(underlying, new TreeMap<Long, Object>());
+        this(underlying, new TreeMap<>());
      }

      private LengthNotWritableFilter(final ArrayData underlying, final 
SortedMap<Long, Object> extraElements) {
diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -48,7 +48,7 @@
      private TreeMap<Long, Object> sparseMap;

      SparseArrayData(final ArrayData underlying, final long length) {
-        this(underlying, length, new TreeMap<Long, Object>());
+        this(underlying, length, new TreeMap<>());
      }

      SparseArrayData(final ArrayData underlying, final long length, 
final TreeMap<Long, Object> sparseMap) {
diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -48,7 +48,7 @@
       *  startup
       */
      private static final Map<String, RegExp> REGEXP_CACHE =
-            Collections.synchronizedMap(new WeakHashMap<String, RegExp>());
+            Collections.synchronizedMap(new WeakHashMap<>());

      static {
          final String impl = 
Options.getStringProperty("nashorn.regexp.impl", JONI);
diff -r 751ada854e5a 
src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java
--- 
a/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java 
Mon Sep 14 16:13:10 2015 +0530
+++ 
b/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -79,7 +79,7 @@
              if (Config.DEBUG_PARSE_TREE_RAW) {
                  Config.log.println("<TREE>");
              }
-            root.verifyTree(new HashSet<Node>(), env.reg.warnings);
+            root.verifyTree(new HashSet<>(), env.reg.warnings);
              Config.log.println(root + "\n");
          }

@@ -908,7 +908,7 @@

          ConsAltNode topRoot = null, r = null;
          @SuppressWarnings("unused")
-        final ObjPtr<Node> prevNode = new ObjPtr<Node>();
+        final ObjPtr<Node> prevNode = new ObjPtr<>();
          StringNode stringNode = null;

          while (pt < end) {
diff -r 751ada854e5a 
test/src/jdk/nashorn/api/scripting/test/PluggableJSObjectTest.java
--- a/test/src/jdk/nashorn/api/scripting/test/PluggableJSObjectTest.java 
Mon Sep 14 16:13:10 2015 +0530
+++ b/test/src/jdk/nashorn/api/scripting/test/PluggableJSObjectTest.java 
Mon Sep 14 13:40:46 2015 +0200
@@ -236,7 +236,7 @@
          @SuppressWarnings("unused")
          @Override
          public Object newObject(final Object... args) {
-            return new HashMap<Object, Object>();
+            return new HashMap<>();
          }

          @Override
diff -r 751ada854e5a test/src/jdk/nashorn/api/tree/test/ParseAPITest.java
--- a/test/src/jdk/nashorn/api/tree/test/ParseAPITest.java    Mon Sep 14 
16:13:10 2015 +0530
+++ b/test/src/jdk/nashorn/api/tree/test/ParseAPITest.java    Mon Sep 14 
13:40:46 2015 +0200
@@ -145,7 +145,7 @@

              final Parser parser = Parser.create(options);
              final Tree tree = parser.parse(file.getAbsolutePath(), 
content, null);
-            tree.accept(new SimpleTreeVisitorES5_1<Void, Void>(), null);
+            tree.accept(new SimpleTreeVisitorES5_1<>(), null);
              passed++;
          } catch (final Throwable exp) {
              log("Parse API failed: " + file.getAbsolutePath() + " : " 
+ exp);


From sundararajan.athijegannathan at oracle.com  Tue Sep 15 05:27:02 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 15 Sep 2015 10:57:02 +0530
Subject: [8u] approval request for 8055917:
	jdk.nashorn.internal.codegen.CompilationPhase$N should be renamed to
	proper classes
Message-ID: <55F7AC26.7020903@oracle.com>

Please approve.

Bug: https://bugs.openjdk.java.net/browse/JDK-8055917
jdk9 review thread: 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005233.html
jdk8u webrev: http://cr.openjdk.java.net/~sundar/8055917/8u/webrev.00/

The patch wouldn't apply cleanly as there are code differences between 
jdk9 and jdk8u nashorn repos. I did manual changes after applying the 
patch. I'm CC'ing nashorn team for further review.

Thanks,
-Sundar

From michael.haupt at oracle.com  Tue Sep 15 07:01:33 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Tue, 15 Sep 2015 09:01:33 +0200
Subject: [8u] approval request for 8055917:
	jdk.nashorn.internal.codegen.CompilationPhase$N should be
	renamed to proper classes
In-Reply-To: <55F7AC26.7020903@oracle.com>
References: <55F7AC26.7020903@oracle.com>
Message-ID: <BC75816B-B2C8-45F5-83DE-CC02CC1D197D@oracle.com>

Hi Sundar,

lower-case thumbs up.

Best,

Michael

> Am 15.09.2015 um 07:27 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Please approve.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8055917
> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005233.html
> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8055917/8u/webrev.00/
> 
> The patch wouldn't apply cleanly as there are code differences between jdk9 and jdk8u nashorn repos. I did manual changes after applying the patch. I'm CC'ing nashorn team for further review.
> 
> Thanks,
> -Sundar

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From sean.coffey at oracle.com  Tue Sep 15 07:21:00 2015
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 15 Sep 2015 08:21:00 +0100
Subject: [8u] approval request for 8055917:
	jdk.nashorn.internal.codegen.CompilationPhase$N should be renamed to
	proper classes
In-Reply-To: <BC75816B-B2C8-45F5-83DE-CC02CC1D197D@oracle.com>
References: <55F7AC26.7020903@oracle.com>
	<BC75816B-B2C8-45F5-83DE-CC02CC1D197D@oracle.com>
Message-ID: <55F7C6DC.80809@oracle.com>

Approved for jdk8u-dev.

Regards,
Sean.

On 15/09/2015 08:01, Michael Haupt wrote:
> Hi Sundar,
>
> lower-case thumbs up.
>
> Best,
>
> Michael
>
>> Am 15.09.2015 um 07:27 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
>>
>> Please approve.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055917
>> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005233.html
>> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8055917/8u/webrev.00/
>>
>> The patch wouldn't apply cleanly as there are code differences between jdk9 and jdk8u nashorn repos. I did manual changes after applying the patch. I'm CC'ing nashorn team for further review.
>>
>> Thanks,
>> -Sundar


From sdeleuze at pivotal.io  Tue Sep 15 12:29:33 2015
From: sdeleuze at pivotal.io (Sebastien Deleuze)
Date: Tue, 15 Sep 2015 08:29:33 -0400
Subject: WebAssembly
Message-ID: <CAF_xPQLcu8NsRWTOEescyu3bGxdb=L2SM_pXL92P7xZWTgO30Q@mail.gmail.com>

Hi,

It seems that browsers may move from interpreting directly Javascript code
to using WebAssembly bytecode, Javascript being just one language supported
on many.

That could enable faster runtime, supporting new languages, etc.

It may be a significant and disruptive change, so I am wondering if you
have any early thoughts or plans about WebAssembly support for Nashorn (or
maybe via Graal/Truffle)?

Regards,
S?bastien

From sundararajan.athijegannathan at oracle.com  Tue Sep 15 12:46:16 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 15 Sep 2015 18:16:16 +0530
Subject: RFR 8080501: javaarrayconversion.js test is flawed
Message-ID: <55F81318.2000607@oracle.com>

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

Thanks,
-Sundar

From hannes.wallnoefer at oracle.com  Tue Sep 15 13:44:23 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 15 Sep 2015 15:44:23 +0200
Subject: RFR 8080501: javaarrayconversion.js test is flawed
In-Reply-To: <55F81318.2000607@oracle.com>
References: <55F81318.2000607@oracle.com>
Message-ID: <55F820B7.9000004@oracle.com>

+1

Am 2015-09-15 um 14:46 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8080501/ for 
> https://bugs.openjdk.java.net/browse/JDK-8080501
>
> Thanks,
> -Sundar


From attila.szegedi at oracle.com  Tue Sep 15 13:47:10 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 15 Sep 2015 15:47:10 +0200
Subject: RFR 8080501: javaarrayconversion.js test is flawed
In-Reply-To: <55F81318.2000607@oracle.com>
References: <55F81318.2000607@oracle.com>
Message-ID: <BC9B222B-EA7A-488D-8406-DB154CC25781@oracle.com>

+1

> On Sep 15, 2015, at 2:46 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8080501/ for https://bugs.openjdk.java.net/browse/JDK-8080501
> 
> Thanks,
> -Sundar


From attila.szegedi at oracle.com  Tue Sep 15 15:29:19 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 15 Sep 2015 17:29:19 +0200
Subject: Review request for JDK-8133300: Ensure symbol table immutability
	in Nashorn AST
In-Reply-To: <DFFE9620-6089-4B51-90E4-4C96B96380F5@lagergren.net>
References: <1FF60D9D-02BC-45C1-A949-2947C5B03C01@oracle.com>
	<D63C61AD-E5E4-4E11-A7DE-35DB4968F7EC@lagergren.net>
	<9799463A-0862-4FCE-9C4E-D1C3E36B1665@oracle.com>
	<C96FE3F0-0910-4CBB-B7C6-617D77DEF62A@oracle.com>
	<DFFE9620-6089-4B51-90E4-4C96B96380F5@lagergren.net>
Message-ID: <50A69E90-0EB1-4607-92CD-2B8CFBEE080D@oracle.com>

Folks, I?m preparing to backport this to 8u-dev. I had to prepare a separate webrev, as I had to change few things, namely:

- I resolved a conflict in CompilationPhase.java stemming from Sundar?s 8055917 being committed to 8u-dev before this change (this was BTW also the reason poor Sundar himself had a conflict and had to manually prepare a 8u-dev webrev?)
- Some omitted type parameters in 9 can?t be omitted in 8 because of weaker type parameter inference, hence some more explicit type specializations were used in few places
- use of lambdas in RecompilableScriptFunctionData was not compatible with Nashorn using source -1.7 in 8u-dev.

Please review so I can request a backport to 8u-dev.

Thanks,
  Attila.

> On Sep 1, 2015, at 9:14 AM, Marcus Lagergren <lagergren at gmail.com> wrote:
> 
> Reviewed new webrev. Happy +1
> 
> /M
> 
>> On 31 Aug 2015, at 12:09, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>> 
>> I posted another webrev, can you please review: http://cr.openjdk.java.net/~attila/8133300/webrev.01.jdk9 <http://cr.openjdk.java.net/~attila/8133300/webrev.01.jdk9>
>> The only changes are:
>> - added JavaDoc comments explaining SerializedAst class, as per Marcus? suggestion
>> - external symbols? re-marking as global now only happens for non-cached split functions (previously, it happened for all non-cached functions). Other functions will already have external symbols marked as globals, as they?re coming from a lazy compilation.
>> 
>> Thanks,
>> Attila.
>> 
>>> On Aug 31, 2015, at 10:58 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>> 
>>> if the FunctionNode object is set as the cached representation of a RecompilableScriptFunctionData using its setCached method, its IS_CACHED flag is set to true. The flag is used in recompilation to determine the necessary compilation phases: if the function is cached, it means phases in Compiler.COMPILE_UPTO_CACHED were already run on it, so they don't need to be repeated. Otherwise the function is freshly reparsed, so the full compiler pipeline needs to be re-run.
>>> 
>>> There?s also the issue of re-marking external symbols as globals in RecompilableScriptFunctionData.cloneSymbols(). We normally don?t have to do that ? I implemented that back when I was caching pre-pass ASTs. Now that we're only caching AST resulting from lazy compilation, we don't really need it except for split functions, which are incidentally cached from the eager pass :-)
>>> 
>>> When we lazily compile a function from scratch, all symbols outside of it are considered global (since AssignSymbols won't find them in the enclosing lexical scope, as the enclosing source text is not reparsed). OTOH, if we cache a FunctionNode resulting from the eager first pass, it will have the full lexical scope, so those symbols won't be marked as "global" (which is rather a misnomer at the moment and should be instead considered ?external? instead). We need the cached AST and a lazily parsed AST to be identical though, otherwise things break down further down the line.
>>> 
>>> Split functions are cached from eager pre-pass (and before they were serialized from eager pre-pass). They didn't suffer from this problem though as AssignSymbols was re-run every time after deserialization. Now however, I moved AssignSymbols to be a pre-cache phase.
>>> 
>>> I'll modify the code though so that this marking of external symbols only happens when we cache a split function.
>>> 
>>> Attila.
>>> 
>>>> On Aug 30, 2015, at 3:07 PM, Marcus Lagergren <marcus at lagergren.net> wrote:
>>>> 
>>>> Can you elaborate a bit on the isCached mechanism in FunctionNode?
>>>> 
>>>> /M
>>>> 
>>>>> On 26 Aug 2015, at 14:18, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>>>> 
>>>>> Please review JDK-8133300 "Ensure symbol table immutability in Nashorn AST" at <http://cr.openjdk.java.net/~attila/8133300/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8133300>
>>>>> 
>>>>> Implementation notes for reviewers are here: <https://bugs.openjdk.java.net/browse/JDK-8133300?focusedCommentId=13837384&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837384 <https://bugs.openjdk.java.net/browse/JDK-8133300?focusedCommentId=13837384&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837384>>
>>>>> 
>>>>> Thanks,
>>>>> Attila.
>>>> 
>>> 
>> 
> 


From attila.szegedi at oracle.com  Tue Sep 15 15:31:09 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 15 Sep 2015 17:31:09 +0200
Subject: Review request for JDK-8133300: Ensure symbol table immutability
	in Nashorn AST
In-Reply-To: <50A69E90-0EB1-4607-92CD-2B8CFBEE080D@oracle.com>
References: <1FF60D9D-02BC-45C1-A949-2947C5B03C01@oracle.com>
	<D63C61AD-E5E4-4E11-A7DE-35DB4968F7EC@lagergren.net>
	<9799463A-0862-4FCE-9C4E-D1C3E36B1665@oracle.com>
	<C96FE3F0-0910-4CBB-B7C6-617D77DEF62A@oracle.com>
	<DFFE9620-6089-4B51-90E4-4C96B96380F5@lagergren.net>
	<50A69E90-0EB1-4607-92CD-2B8CFBEE080D@oracle.com>
Message-ID: <952A7A68-2C88-4FBC-A3CC-522AFE23EBFE@oracle.com>

Sorry, forgot to specify the link: http://cr.openjdk.java.net/~attila/8133300/webrev.jdk8u-dev <http://cr.openjdk.java.net/~attila/8133300/webrev.jdk8u-dev>

> On Sep 15, 2015, at 5:29 PM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Folks, I?m preparing to backport this to 8u-dev. I had to prepare a separate webrev, as I had to change few things, namely:
> 
> - I resolved a conflict in CompilationPhase.java stemming from Sundar?s 8055917 being committed to 8u-dev before this change (this was BTW also the reason poor Sundar himself had a conflict and had to manually prepare a 8u-dev webrev?)
> - Some omitted type parameters in 9 can?t be omitted in 8 because of weaker type parameter inference, hence some more explicit type specializations were used in few places
> - use of lambdas in RecompilableScriptFunctionData was not compatible with Nashorn using source -1.7 in 8u-dev.
> 
> Please review so I can request a backport to 8u-dev.
> 
> Thanks,
>  Attila.
> 
>> On Sep 1, 2015, at 9:14 AM, Marcus Lagergren <lagergren at gmail.com> wrote:
>> 
>> Reviewed new webrev. Happy +1
>> 
>> /M
>> 
>>> On 31 Aug 2015, at 12:09, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>> 
>>> I posted another webrev, can you please review: http://cr.openjdk.java.net/~attila/8133300/webrev.01.jdk9 <http://cr.openjdk.java.net/~attila/8133300/webrev.01.jdk9>
>>> The only changes are:
>>> - added JavaDoc comments explaining SerializedAst class, as per Marcus? suggestion
>>> - external symbols? re-marking as global now only happens for non-cached split functions (previously, it happened for all non-cached functions). Other functions will already have external symbols marked as globals, as they?re coming from a lazy compilation.
>>> 
>>> Thanks,
>>> Attila.
>>> 
>>>> On Aug 31, 2015, at 10:58 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>>> 
>>>> if the FunctionNode object is set as the cached representation of a RecompilableScriptFunctionData using its setCached method, its IS_CACHED flag is set to true. The flag is used in recompilation to determine the necessary compilation phases: if the function is cached, it means phases in Compiler.COMPILE_UPTO_CACHED were already run on it, so they don't need to be repeated. Otherwise the function is freshly reparsed, so the full compiler pipeline needs to be re-run.
>>>> 
>>>> There?s also the issue of re-marking external symbols as globals in RecompilableScriptFunctionData.cloneSymbols(). We normally don?t have to do that ? I implemented that back when I was caching pre-pass ASTs. Now that we're only caching AST resulting from lazy compilation, we don't really need it except for split functions, which are incidentally cached from the eager pass :-)
>>>> 
>>>> When we lazily compile a function from scratch, all symbols outside of it are considered global (since AssignSymbols won't find them in the enclosing lexical scope, as the enclosing source text is not reparsed). OTOH, if we cache a FunctionNode resulting from the eager first pass, it will have the full lexical scope, so those symbols won't be marked as "global" (which is rather a misnomer at the moment and should be instead considered ?external? instead). We need the cached AST and a lazily parsed AST to be identical though, otherwise things break down further down the line.
>>>> 
>>>> Split functions are cached from eager pre-pass (and before they were serialized from eager pre-pass). They didn't suffer from this problem though as AssignSymbols was re-run every time after deserialization. Now however, I moved AssignSymbols to be a pre-cache phase.
>>>> 
>>>> I'll modify the code though so that this marking of external symbols only happens when we cache a split function.
>>>> 
>>>> Attila.
>>>> 
>>>>> On Aug 30, 2015, at 3:07 PM, Marcus Lagergren <marcus at lagergren.net> wrote:
>>>>> 
>>>>> Can you elaborate a bit on the isCached mechanism in FunctionNode?
>>>>> 
>>>>> /M
>>>>> 
>>>>>> On 26 Aug 2015, at 14:18, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>>>>> 
>>>>>> Please review JDK-8133300 "Ensure symbol table immutability in Nashorn AST" at <http://cr.openjdk.java.net/~attila/8133300/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8133300>
>>>>>> 
>>>>>> Implementation notes for reviewers are here: <https://bugs.openjdk.java.net/browse/JDK-8133300?focusedCommentId=13837384&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837384 <https://bugs.openjdk.java.net/browse/JDK-8133300?focusedCommentId=13837384&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837384>>
>>>>>> 
>>>>>> Thanks,
>>>>>> Attila.
>>>>> 
>>>> 
>>> 
>> 
> 


From sundararajan.athijegannathan at oracle.com  Wed Sep 16 04:27:53 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 16 Sep 2015 09:57:53 +0530
Subject: RFR 8136544: Call site switching to megamorphic causes incorrect
	property read
Message-ID: <55F8EFC9.6020700@oracle.com>

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

Thanks,
-Sundar

From lagergren at gmail.com  Wed Sep 16 06:20:29 2015
From: lagergren at gmail.com (Marcus Lagergren)
Date: Wed, 16 Sep 2015 08:20:29 +0200
Subject: Review request for JDK-8133300: Ensure symbol table immutability
	in Nashorn AST
In-Reply-To: <50A69E90-0EB1-4607-92CD-2B8CFBEE080D@oracle.com>
References: <1FF60D9D-02BC-45C1-A949-2947C5B03C01@oracle.com>
	<D63C61AD-E5E4-4E11-A7DE-35DB4968F7EC@lagergren.net>
	<9799463A-0862-4FCE-9C4E-D1C3E36B1665@oracle.com>
	<C96FE3F0-0910-4CBB-B7C6-617D77DEF62A@oracle.com>
	<DFFE9620-6089-4B51-90E4-4C96B96380F5@lagergren.net>
	<50A69E90-0EB1-4607-92CD-2B8CFBEE080D@oracle.com>
Message-ID: <657EC275-CCD5-40A8-931E-0E067F3FBB5A@lagergren.net>

+1

> On 15 Sep 2015, at 17:29, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Folks, I?m preparing to backport this to 8u-dev. I had to prepare a separate webrev, as I had to change few things, namely:
> 
> - I resolved a conflict in CompilationPhase.java stemming from Sundar?s 8055917 being committed to 8u-dev before this change (this was BTW also the reason poor Sundar himself had a conflict and had to manually prepare a 8u-dev webrev?)
> - Some omitted type parameters in 9 can?t be omitted in 8 because of weaker type parameter inference, hence some more explicit type specializations were used in few places
> - use of lambdas in RecompilableScriptFunctionData was not compatible with Nashorn using source -1.7 in 8u-dev.
> 
> Please review so I can request a backport to 8u-dev.
> 
> Thanks,
>  Attila.
> 
>> On Sep 1, 2015, at 9:14 AM, Marcus Lagergren <lagergren at gmail.com> wrote:
>> 
>> Reviewed new webrev. Happy +1
>> 
>> /M
>> 
>>> On 31 Aug 2015, at 12:09, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>> 
>>> I posted another webrev, can you please review: http://cr.openjdk.java.net/~attila/8133300/webrev.01.jdk9 <http://cr.openjdk.java.net/~attila/8133300/webrev.01.jdk9>
>>> The only changes are:
>>> - added JavaDoc comments explaining SerializedAst class, as per Marcus? suggestion
>>> - external symbols? re-marking as global now only happens for non-cached split functions (previously, it happened for all non-cached functions). Other functions will already have external symbols marked as globals, as they?re coming from a lazy compilation.
>>> 
>>> Thanks,
>>> Attila.
>>> 
>>>> On Aug 31, 2015, at 10:58 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>>> 
>>>> if the FunctionNode object is set as the cached representation of a RecompilableScriptFunctionData using its setCached method, its IS_CACHED flag is set to true. The flag is used in recompilation to determine the necessary compilation phases: if the function is cached, it means phases in Compiler.COMPILE_UPTO_CACHED were already run on it, so they don't need to be repeated. Otherwise the function is freshly reparsed, so the full compiler pipeline needs to be re-run.
>>>> 
>>>> There?s also the issue of re-marking external symbols as globals in RecompilableScriptFunctionData.cloneSymbols(). We normally don?t have to do that ? I implemented that back when I was caching pre-pass ASTs. Now that we're only caching AST resulting from lazy compilation, we don't really need it except for split functions, which are incidentally cached from the eager pass :-)
>>>> 
>>>> When we lazily compile a function from scratch, all symbols outside of it are considered global (since AssignSymbols won't find them in the enclosing lexical scope, as the enclosing source text is not reparsed). OTOH, if we cache a FunctionNode resulting from the eager first pass, it will have the full lexical scope, so those symbols won't be marked as "global" (which is rather a misnomer at the moment and should be instead considered ?external? instead). We need the cached AST and a lazily parsed AST to be identical though, otherwise things break down further down the line.
>>>> 
>>>> Split functions are cached from eager pre-pass (and before they were serialized from eager pre-pass). They didn't suffer from this problem though as AssignSymbols was re-run every time after deserialization. Now however, I moved AssignSymbols to be a pre-cache phase.
>>>> 
>>>> I'll modify the code though so that this marking of external symbols only happens when we cache a split function.
>>>> 
>>>> Attila.
>>>> 
>>>>> On Aug 30, 2015, at 3:07 PM, Marcus Lagergren <marcus at lagergren.net> wrote:
>>>>> 
>>>>> Can you elaborate a bit on the isCached mechanism in FunctionNode?
>>>>> 
>>>>> /M
>>>>> 
>>>>>> On 26 Aug 2015, at 14:18, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>>>>> 
>>>>>> Please review JDK-8133300 "Ensure symbol table immutability in Nashorn AST" at <http://cr.openjdk.java.net/~attila/8133300/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8133300>
>>>>>> 
>>>>>> Implementation notes for reviewers are here: <https://bugs.openjdk.java.net/browse/JDK-8133300?focusedCommentId=13837384&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837384 <https://bugs.openjdk.java.net/browse/JDK-8133300?focusedCommentId=13837384&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837384>>
>>>>>> 
>>>>>> Thanks,
>>>>>> Attila.
>>>>> 
>>>> 
>>> 
>> 
> 


From ninghua at linux.vnet.ibm.com  Wed Sep 16 07:12:23 2015
From: ninghua at linux.vnet.ibm.com (ninghua at linux.vnet.ibm.com)
Date: Wed, 16 Sep 2015 03:12:23 -0400
Subject: Get nashron work in opnjdk8
In-Reply-To: <CAEXeE2zsyHTwmVXWov4MxM7_qWr0+W5cGFASB+_vZBrgwp3=4w@mail.gmail.com>
References: <CAEXeE2zsyHTwmVXWov4MxM7_qWr0+W5cGFASB+_vZBrgwp3=4w@mail.gmail.com>
Message-ID: <20150916031223.Horde.RsvPm-bQ5XHOyCnSWSuZFQ1@ltc.linux.ibm.com>

Rhino should be removed in OpenJDK8? What's your OpenJDK version?

Regards,
Quoting Harsha Kumara <harsz89 at gmail.com>:

> Hi!
> I had tried to run some performance tests.But results are not impressive
> than I thought.I have build openjdk8 and set JAVA_HOME to it.Then I have
> build nashron.But when I run the jrunscript -q it still show the rhino as
> underline javascript engine.Then how can I configure it to use nashron?
> Thanks!
>
> --
> *Harsha Kumara*
> *Undergraduate*
> *Department of Computer Science and Engineering*
> *University of Moratuwa*
> *Sri Lanka.*



From sundararajan.athijegannathan at oracle.com  Wed Sep 16 08:27:26 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 16 Sep 2015 13:57:26 +0530
Subject: Get nashron work in opnjdk8
In-Reply-To: <20150916031223.Horde.RsvPm-bQ5XHOyCnSWSuZFQ1@ltc.linux.ibm.com>
References: <CAEXeE2zsyHTwmVXWov4MxM7_qWr0+W5cGFASB+_vZBrgwp3=4w@mail.gmail.com>
	<20150916031223.Horde.RsvPm-bQ5XHOyCnSWSuZFQ1@ltc.linux.ibm.com>
Message-ID: <55F927EE.1020300@oracle.com>

Rhino was never in openjdk code (even in jdk7). It was always in 
"closed" code. And it was removed in jdk8.  You may want to check your 
java version. If you run jdk8 java, you're running Nashorn engine.

$ jrunscript -q

should print something like:

Language ECMAScript ECMA - 262 Edition 5.1 implementation "Oracle 
Nashorn" 1.8.0_60

Thanks,
-Sundar

On 9/16/2015 12:42 PM, ninghua at linux.vnet.ibm.com wrote:
> Rhino should be removed in OpenJDK8? What's your OpenJDK version?
>
> Regards,
> Quoting Harsha Kumara <harsz89 at gmail.com>:
>
>> Hi!
>> I had tried to run some performance tests.But results are not impressive
>> than I thought.I have build openjdk8 and set JAVA_HOME to it.Then I have
>> build nashron.But when I run the jrunscript -q it still show the 
>> rhino as
>> underline javascript engine.Then how can I configure it to use nashron?
>> Thanks!
>>
>> -- 
>> *Harsha Kumara*
>> *Undergraduate*
>> *Department of Computer Science and Engineering*
>> *University of Moratuwa*
>> *Sri Lanka.*
>
>


From michael.haupt at oracle.com  Wed Sep 16 08:35:39 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Wed, 16 Sep 2015 10:35:39 +0200
Subject: RFR 8136544: Call site switching to megamorphic causes incorrect
	property read
In-Reply-To: <55F8EFC9.6020700@oracle.com>
References: <55F8EFC9.6020700@oracle.com>
Message-ID: <1D8FFDE4-89EB-4A1C-BE35-61486882DA12@oracle.com>

Hi Sundar,

lower-case thumbs up, with two remarks:
* the new boolean argument in NativeJavaImporter should be called isScope, not isStrict
* ScopeTest could better illustrate the conditions it tests if it used a symbolic constant instead of 16 ("magic number") - can the megamorphism threshold be queried from the engine?

Best,

Michael

> Am 16.09.2015 um 06:27 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Please review http://cr.openjdk.java.net/~sundar/8136544/ for https://bugs.openjdk.java.net/browse/JDK-8136544
> 
> Thanks,
> -Sundar

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From hannes.wallnoefer at oracle.com  Wed Sep 16 08:48:55 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 16 Sep 2015 10:48:55 +0200
Subject: Review request for JDK-8134609: Allow constructors with same
	prototoype map to share the allocator map
In-Reply-To: <0606D015-2025-4A49-B09D-C34B39A0105E@oracle.com>
References: <55F2C6FD.7090804@oracle.com>
	<0606D015-2025-4A49-B09D-C34B39A0105E@oracle.com>
Message-ID: <55F92CF7.3060201@oracle.com>

Thanks for the review!

As discussed, in addition to the changes you suggested below I did some 
refactoring on the PropertyMap class, making more fields final to better 
reflect its immutable nature. I soon noticed that all the core fields 
(flags, field/spill boundaries, class name) could quite easily be made 
final except for the new shared map flags I introduced. That gave me an 
additional reason to turn shared proto map feature into a separete 
PropertyMap subclass (something I had already considered before).

So I added the SharedPropertyMap subclass to represent the new shared 
prototype property maps. All the things fell quite nicely into place, 
and I'm much happier with the code now than with the first version. I 
also tweaked the property listener code to make it a bit simpler. 
Finally, I discovered an issue with unsetting prototypes with shared 
maps that was not handled correctly in the first version which I fixed 
and added/improved tests for.

Please review the new webrev:

http://cr.openjdk.java.net/~hannesw/8134609/webrev.01/

Thanks,
Hannes

Am 2015-09-14 um 11:48 schrieb Attila Szegedi:
> Overall, great work. Really well thought out; adding features to runtimes to optimize special cases always has the possibility of becoming complicated, and you have managed to keep the changes to the minimum, and pretty well contained. E.g. I like how even before your changes we have a fast path in ScriptObject.findProperty for the case where the property is not in the prototype, so the shared proto check there only kicks in when we do actually need to deal with prototypes, etc.
>
> I only have some very small remarks:
>
> - AllocatorMap could use getSharedPrototypeMap() in various places where it explicitly uses allocatorMap.getSharedProtoMap() now
> - Debug.scriptStack() doesn't seem to be used
> - PropertyMap.invalidateProtoGetSwitchPoint should be renamed invalidateProtoSwitchPoint. invalidateAllProtoGetSwitchPoints too
> - PropertyMap.invalidateSharedProtoSwitchPoint: there's the "switchPoint != null && !switchPoint.hasBeenInvalidated()" predicate. Is it possible for switchPoint to not be null and be invalidated? If not, maybe hasBeenInvalidated should be an assert within if instead
> - I wonder if "sharedProtoMap != myProto.getMap() || !myProto.getMap().isValidSharedProtoMap()" in ScriptObject.checkSharedProtoMap and a similar predicate "allocatorMap.getSharedProtoMap() != prototype.getMap() || !prototype.getMap().isValidSharedProtoMap())? in ScriptFunction.getAllocatorMap() couldn?t be extracted into a single method somewhere, if they share semantic similarity (syntactically they look very similar)
>
> Attila.
>
>> On Sep 11, 2015, at 2:20 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>>
>> Please review JDK-8134609: Allow constructors with same prototoype map to share the allocator map:
>>
>> http://cr.openjdk.java.net/~hannesw/8134609/webrev/
>>
>> The details for this are a bit tricky, so I added some notes to the jira bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8134609?focusedCommentId=13843176&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13843176
>>
>> Thanks,
>> Hannes


From sundararajan.athijegannathan at oracle.com  Wed Sep 16 10:40:37 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 16 Sep 2015 16:10:37 +0530
Subject: Review request for JDK-8133300: Ensure symbol table immutability
	in Nashorn AST
In-Reply-To: <952A7A68-2C88-4FBC-A3CC-522AFE23EBFE@oracle.com>
References: <1FF60D9D-02BC-45C1-A949-2947C5B03C01@oracle.com>
	<D63C61AD-E5E4-4E11-A7DE-35DB4968F7EC@lagergren.net>
	<9799463A-0862-4FCE-9C4E-D1C3E36B1665@oracle.com>
	<C96FE3F0-0910-4CBB-B7C6-617D77DEF62A@oracle.com>
	<DFFE9620-6089-4B51-90E4-4C96B96380F5@lagergren.net>
	<50A69E90-0EB1-4607-92CD-2B8CFBEE080D@oracle.com>
	<952A7A68-2C88-4FBC-A3CC-522AFE23EBFE@oracle.com>
Message-ID: <55F94725.9030402@oracle.com>

+1

On 9/15/2015 9:01 PM, Attila Szegedi wrote:
> Sorry, forgot to specify the link: http://cr.openjdk.java.net/~attila/8133300/webrev.jdk8u-dev <http://cr.openjdk.java.net/~attila/8133300/webrev.jdk8u-dev>
>
>> On Sep 15, 2015, at 5:29 PM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>
>> Folks, I?m preparing to backport this to 8u-dev. I had to prepare a separate webrev, as I had to change few things, namely:
>>
>> - I resolved a conflict in CompilationPhase.java stemming from Sundar?s 8055917 being committed to 8u-dev before this change (this was BTW also the reason poor Sundar himself had a conflict and had to manually prepare a 8u-dev webrev?)
>> - Some omitted type parameters in 9 can?t be omitted in 8 because of weaker type parameter inference, hence some more explicit type specializations were used in few places
>> - use of lambdas in RecompilableScriptFunctionData was not compatible with Nashorn using source -1.7 in 8u-dev.
>>
>> Please review so I can request a backport to 8u-dev.
>>
>> Thanks,
>>   Attila.
>>
>>> On Sep 1, 2015, at 9:14 AM, Marcus Lagergren <lagergren at gmail.com> wrote:
>>>
>>> Reviewed new webrev. Happy +1
>>>
>>> /M
>>>
>>>> On 31 Aug 2015, at 12:09, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>>>
>>>> I posted another webrev, can you please review: http://cr.openjdk.java.net/~attila/8133300/webrev.01.jdk9 <http://cr.openjdk.java.net/~attila/8133300/webrev.01.jdk9>
>>>> The only changes are:
>>>> - added JavaDoc comments explaining SerializedAst class, as per Marcus? suggestion
>>>> - external symbols? re-marking as global now only happens for non-cached split functions (previously, it happened for all non-cached functions). Other functions will already have external symbols marked as globals, as they?re coming from a lazy compilation.
>>>>
>>>> Thanks,
>>>> Attila.
>>>>
>>>>> On Aug 31, 2015, at 10:58 AM, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>>>>
>>>>> if the FunctionNode object is set as the cached representation of a RecompilableScriptFunctionData using its setCached method, its IS_CACHED flag is set to true. The flag is used in recompilation to determine the necessary compilation phases: if the function is cached, it means phases in Compiler.COMPILE_UPTO_CACHED were already run on it, so they don't need to be repeated. Otherwise the function is freshly reparsed, so the full compiler pipeline needs to be re-run.
>>>>>
>>>>> There?s also the issue of re-marking external symbols as globals in RecompilableScriptFunctionData.cloneSymbols(). We normally don?t have to do that ? I implemented that back when I was caching pre-pass ASTs. Now that we're only caching AST resulting from lazy compilation, we don't really need it except for split functions, which are incidentally cached from the eager pass :-)
>>>>>
>>>>> When we lazily compile a function from scratch, all symbols outside of it are considered global (since AssignSymbols won't find them in the enclosing lexical scope, as the enclosing source text is not reparsed). OTOH, if we cache a FunctionNode resulting from the eager first pass, it will have the full lexical scope, so those symbols won't be marked as "global" (which is rather a misnomer at the moment and should be instead considered ?external? instead). We need the cached AST and a lazily parsed AST to be identical though, otherwise things break down further down the line.
>>>>>
>>>>> Split functions are cached from eager pre-pass (and before they were serialized from eager pre-pass). They didn't suffer from this problem though as AssignSymbols was re-run every time after deserialization. Now however, I moved AssignSymbols to be a pre-cache phase.
>>>>>
>>>>> I'll modify the code though so that this marking of external symbols only happens when we cache a split function.
>>>>>
>>>>> Attila.
>>>>>
>>>>>> On Aug 30, 2015, at 3:07 PM, Marcus Lagergren <marcus at lagergren.net> wrote:
>>>>>>
>>>>>> Can you elaborate a bit on the isCached mechanism in FunctionNode?
>>>>>>
>>>>>> /M
>>>>>>
>>>>>>> On 26 Aug 2015, at 14:18, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>>>>>>
>>>>>>> Please review JDK-8133300 "Ensure symbol table immutability in Nashorn AST" at <http://cr.openjdk.java.net/~attila/8133300/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8133300>
>>>>>>>
>>>>>>> Implementation notes for reviewers are here: <https://bugs.openjdk.java.net/browse/JDK-8133300?focusedCommentId=13837384&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837384 <https://bugs.openjdk.java.net/browse/JDK-8133300?focusedCommentId=13837384&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13837384>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Attila.


From sundararajan.athijegannathan at oracle.com  Wed Sep 16 10:46:28 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 16 Sep 2015 16:16:28 +0530
Subject: RFR 8136544: Call site switching to megamorphic causes incorrect
	property read
In-Reply-To: <1D8FFDE4-89EB-4A1C-BE35-61486882DA12@oracle.com>
References: <55F8EFC9.6020700@oracle.com>
	<1D8FFDE4-89EB-4A1C-BE35-61486882DA12@oracle.com>
Message-ID: <55F94884.6080307@oracle.com>

Hi,

* Changed NativeJavaImporter param name.
* Commented on magic upper limit in ScopeTest.
* Also added a .js test that explicitly sets the dynalink threshold and 
uses a limit slightly beyond that

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

Thanks
-Sundar

On 9/16/2015 2:05 PM, Michael Haupt wrote:
> Hi Sundar,
>
> lower-case thumbs up, with two remarks:
> * the new boolean argument in NativeJavaImporter should be called 
> isScope, not isStrict
> * ScopeTest could better illustrate the conditions it tests if it used 
> a symbolic constant instead of 16 ("magic number") - can the 
> megamorphism threshold be queried from the engine?
>
> Best,
>
> Michael
>
>> Am 16.09.2015 um 06:27 schrieb Sundararajan Athijegannathan 
>> <sundararajan.athijegannathan at oracle.com 
>> <mailto:sundararajan.athijegannathan at oracle.com>>:
>>
>> Please review http://cr.openjdk.java.net/~sundar/8136544/ 
>> <http://cr.openjdk.java.net/%7Esundar/8136544/> for 
>> https://bugs.openjdk.java.net/browse/JDK-8136544
>>
>> Thanks,
>> -Sundar
>
> -- 
>
> Oracle <http://www.oracle.com/>
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> OracleJava Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, 
> Germany
> Green Oracle <http://www.oracle.com/commitment> 	Oracle is committed 
> to developing practices and products that help protect the environment
>
>


From attila.szegedi at oracle.com  Wed Sep 16 10:49:02 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 16 Sep 2015 12:49:02 +0200
Subject: RFR 8136544: Call site switching to megamorphic causes incorrect
	property read
In-Reply-To: <55F94884.6080307@oracle.com>
References: <55F8EFC9.6020700@oracle.com>
	<1D8FFDE4-89EB-4A1C-BE35-61486882DA12@oracle.com>
	<55F94884.6080307@oracle.com>
Message-ID: <757ECE8D-7EF4-4142-845F-E1ECF4C02BFB@oracle.com>

+1. I?m happy with the very quick turnaround on fixing this.

> On Sep 16, 2015, at 12:46 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Hi,
> 
> * Changed NativeJavaImporter param name.
> * Commented on magic upper limit in ScopeTest.
> * Also added a .js test that explicitly sets the dynalink threshold and uses a limit slightly beyond that
> 
> http://cr.openjdk.java.net/~sundar/8136544/webrev.01/
> 
> Thanks
> -Sundar
> 
> On 9/16/2015 2:05 PM, Michael Haupt wrote:
>> Hi Sundar,
>> 
>> lower-case thumbs up, with two remarks:
>> * the new boolean argument in NativeJavaImporter should be called isScope, not isStrict
>> * ScopeTest could better illustrate the conditions it tests if it used a symbolic constant instead of 16 ("magic number") - can the megamorphism threshold be queried from the engine?
>> 
>> Best,
>> 
>> Michael
>> 
>>> Am 16.09.2015 um 06:27 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com <mailto:sundararajan.athijegannathan at oracle.com>>:
>>> 
>>> Please review http://cr.openjdk.java.net/~sundar/8136544/ <http://cr.openjdk.java.net/%7Esundar/8136544/> for https://bugs.openjdk.java.net/browse/JDK-8136544
>>> 
>>> Thanks,
>>> -Sundar
>> 
>> -- 
>> 
>> Oracle <http://www.oracle.com/>
>> Dr. Michael Haupt | Principal Member of Technical Staff
>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>> OracleJava Platform Group | LangTools Team | Nashorn
>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
>> Green Oracle <http://www.oracle.com/commitment> 	Oracle is committed to developing practices and products that help protect the environment
>> 
>> 
> 


From attila.szegedi at oracle.com  Wed Sep 16 10:51:23 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 16 Sep 2015 12:51:23 +0200
Subject: Review request for JDK-8134609: Allow constructors with same
	prototoype map to share the allocator map
In-Reply-To: <55F92CF7.3060201@oracle.com>
References: <55F2C6FD.7090804@oracle.com>
	<0606D015-2025-4A49-B09D-C34B39A0105E@oracle.com>
	<55F92CF7.3060201@oracle.com>
Message-ID: <470D304E-C648-4C7A-AA5E-4DC762D03F90@oracle.com>

Okay, this is indeed substantially even better than the first version. I, too, am much happier with it in its form.

Few very minor things:

AllocatorMap.hasValidSharedProtoMap could use hasSharedProtoMap
"Return number listeners added to a ScriptObject." - missing "of"
"can shared" - missing "be"

Other than these, +1. I?m fine if you fix these without a new webrev.

Attila.

> On Sep 16, 2015, at 10:48 AM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Thanks for the review!
> 
> As discussed, in addition to the changes you suggested below I did some refactoring on the PropertyMap class, making more fields final to better reflect its immutable nature. I soon noticed that all the core fields (flags, field/spill boundaries, class name) could quite easily be made final except for the new shared map flags I introduced. That gave me an additional reason to turn shared proto map feature into a separete PropertyMap subclass (something I had already considered before).
> 
> So I added the SharedPropertyMap subclass to represent the new shared prototype property maps. All the things fell quite nicely into place, and I'm much happier with the code now than with the first version. I also tweaked the property listener code to make it a bit simpler. Finally, I discovered an issue with unsetting prototypes with shared maps that was not handled correctly in the first version which I fixed and added/improved tests for.
> 
> Please review the new webrev:
> 
> http://cr.openjdk.java.net/~hannesw/8134609/webrev.01/
> 
> Thanks,
> Hannes
> 
> Am 2015-09-14 um 11:48 schrieb Attila Szegedi:
>> Overall, great work. Really well thought out; adding features to runtimes to optimize special cases always has the possibility of becoming complicated, and you have managed to keep the changes to the minimum, and pretty well contained. E.g. I like how even before your changes we have a fast path in ScriptObject.findProperty for the case where the property is not in the prototype, so the shared proto check there only kicks in when we do actually need to deal with prototypes, etc.
>> 
>> I only have some very small remarks:
>> 
>> - AllocatorMap could use getSharedPrototypeMap() in various places where it explicitly uses allocatorMap.getSharedProtoMap() now
>> - Debug.scriptStack() doesn't seem to be used
>> - PropertyMap.invalidateProtoGetSwitchPoint should be renamed invalidateProtoSwitchPoint. invalidateAllProtoGetSwitchPoints too
>> - PropertyMap.invalidateSharedProtoSwitchPoint: there's the "switchPoint != null && !switchPoint.hasBeenInvalidated()" predicate. Is it possible for switchPoint to not be null and be invalidated? If not, maybe hasBeenInvalidated should be an assert within if instead
>> - I wonder if "sharedProtoMap != myProto.getMap() || !myProto.getMap().isValidSharedProtoMap()" in ScriptObject.checkSharedProtoMap and a similar predicate "allocatorMap.getSharedProtoMap() != prototype.getMap() || !prototype.getMap().isValidSharedProtoMap())? in ScriptFunction.getAllocatorMap() couldn?t be extracted into a single method somewhere, if they share semantic similarity (syntactically they look very similar)
>> 
>> Attila.
>> 
>>> On Sep 11, 2015, at 2:20 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>>> 
>>> Please review JDK-8134609: Allow constructors with same prototoype map to share the allocator map:
>>> 
>>> http://cr.openjdk.java.net/~hannesw/8134609/webrev/
>>> 
>>> The details for this are a bit tricky, so I added some notes to the jira bug:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8134609?focusedCommentId=13843176&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13843176
>>> 
>>> Thanks,
>>> Hannes
> 


From michael.haupt at oracle.com  Wed Sep 16 10:58:26 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Wed, 16 Sep 2015 12:58:26 +0200
Subject: RFR 8136544: Call site switching to megamorphic causes incorrect
	property read
In-Reply-To: <757ECE8D-7EF4-4142-845F-E1ECF4C02BFB@oracle.com>
References: <55F8EFC9.6020700@oracle.com>
	<1D8FFDE4-89EB-4A1C-BE35-61486882DA12@oracle.com>
	<55F94884.6080307@oracle.com>
	<757ECE8D-7EF4-4142-845F-E1ECF4C02BFB@oracle.com>
Message-ID: <F6014CDE-8D3A-4175-9E53-73B02DD7A7F6@oracle.com>

.. thumbs still up!

Michael

> Am 16.09.2015 um 12:49 schrieb Attila Szegedi <attila.szegedi at oracle.com>:
> 
> +1. I?m happy with the very quick turnaround on fixing this.
> 
>> On Sep 16, 2015, at 12:46 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>> 
>> Hi,
>> 
>> * Changed NativeJavaImporter param name.
>> * Commented on magic upper limit in ScopeTest.
>> * Also added a .js test that explicitly sets the dynalink threshold and uses a limit slightly beyond that
>> 
>> http://cr.openjdk.java.net/~sundar/8136544/webrev.01/
>> 
>> Thanks
>> -Sundar
>> 
>> On 9/16/2015 2:05 PM, Michael Haupt wrote:
>>> Hi Sundar,
>>> 
>>> lower-case thumbs up, with two remarks:
>>> * the new boolean argument in NativeJavaImporter should be called isScope, not isStrict
>>> * ScopeTest could better illustrate the conditions it tests if it used a symbolic constant instead of 16 ("magic number") - can the megamorphism threshold be queried from the engine?
>>> 
>>> Best,
>>> 
>>> Michael
>>> 
>>>> Am 16.09.2015 um 06:27 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com <mailto:sundararajan.athijegannathan at oracle.com>>:
>>>> 
>>>> Please review http://cr.openjdk.java.net/~sundar/8136544/ <http://cr.openjdk.java.net/%7Esundar/8136544/> for https://bugs.openjdk.java.net/browse/JDK-8136544
>>>> 
>>>> Thanks,
>>>> -Sundar
>>> 
>>> -- 
>>> 
>>> Oracle <http://www.oracle.com/>
>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>> OracleJava Platform Group | LangTools Team | Nashorn
>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
>>> Green Oracle <http://www.oracle.com/commitment> 	Oracle is committed to developing practices and products that help protect the environment
>>> 
>>> 


From sundararajan.athijegannathan at oracle.com  Wed Sep 16 11:11:13 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 16 Sep 2015 16:41:13 +0530
Subject: Review request for JDK-8134609: Allow constructors with same
	prototoype map to share the allocator map
In-Reply-To: <55F92CF7.3060201@oracle.com>
References: <55F2C6FD.7090804@oracle.com>
	<0606D015-2025-4A49-B09D-C34B39A0105E@oracle.com>
	<55F92CF7.3060201@oracle.com>
Message-ID: <55F94E51.4060700@oracle.com>

+1

NIce cleanup of PropertyMap as well!

-Sundar

On 9/16/2015 2:18 PM, Hannes Wallnoefer wrote:
> Thanks for the review!
>
> As discussed, in addition to the changes you suggested below I did 
> some refactoring on the PropertyMap class, making more fields final to 
> better reflect its immutable nature. I soon noticed that all the core 
> fields (flags, field/spill boundaries, class name) could quite easily 
> be made final except for the new shared map flags I introduced. That 
> gave me an additional reason to turn shared proto map feature into a 
> separete PropertyMap subclass (something I had already considered 
> before).
>
> So I added the SharedPropertyMap subclass to represent the new shared 
> prototype property maps. All the things fell quite nicely into place, 
> and I'm much happier with the code now than with the first version. I 
> also tweaked the property listener code to make it a bit simpler. 
> Finally, I discovered an issue with unsetting prototypes with shared 
> maps that was not handled correctly in the first version which I fixed 
> and added/improved tests for.
>
> Please review the new webrev:
>
> http://cr.openjdk.java.net/~hannesw/8134609/webrev.01/
>
> Thanks,
> Hannes
>
> Am 2015-09-14 um 11:48 schrieb Attila Szegedi:
>> Overall, great work. Really well thought out; adding features to 
>> runtimes to optimize special cases always has the possibility of 
>> becoming complicated, and you have managed to keep the changes to the 
>> minimum, and pretty well contained. E.g. I like how even before your 
>> changes we have a fast path in ScriptObject.findProperty for the case 
>> where the property is not in the prototype, so the shared proto check 
>> there only kicks in when we do actually need to deal with prototypes, 
>> etc.
>>
>> I only have some very small remarks:
>>
>> - AllocatorMap could use getSharedPrototypeMap() in various places 
>> where it explicitly uses allocatorMap.getSharedProtoMap() now
>> - Debug.scriptStack() doesn't seem to be used
>> - PropertyMap.invalidateProtoGetSwitchPoint should be renamed 
>> invalidateProtoSwitchPoint. invalidateAllProtoGetSwitchPoints too
>> - PropertyMap.invalidateSharedProtoSwitchPoint: there's the 
>> "switchPoint != null && !switchPoint.hasBeenInvalidated()" predicate. 
>> Is it possible for switchPoint to not be null and be invalidated? If 
>> not, maybe hasBeenInvalidated should be an assert within if instead
>> - I wonder if "sharedProtoMap != myProto.getMap() || 
>> !myProto.getMap().isValidSharedProtoMap()" in 
>> ScriptObject.checkSharedProtoMap and a similar predicate 
>> "allocatorMap.getSharedProtoMap() != prototype.getMap() || 
>> !prototype.getMap().isValidSharedProtoMap())? in 
>> ScriptFunction.getAllocatorMap() couldn?t be extracted into a single 
>> method somewhere, if they share semantic similarity (syntactically 
>> they look very similar)
>>
>> Attila.
>>
>>> On Sep 11, 2015, at 2:20 PM, Hannes Wallnoefer 
>>> <hannes.wallnoefer at oracle.com> wrote:
>>>
>>> Please review JDK-8134609: Allow constructors with same prototoype 
>>> map to share the allocator map:
>>>
>>> http://cr.openjdk.java.net/~hannesw/8134609/webrev/
>>>
>>> The details for this are a bit tricky, so I added some notes to the 
>>> jira bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8134609?focusedCommentId=13843176&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13843176 
>>>
>>>
>>> Thanks,
>>> Hannes
>


From magnus.ihse.bursie at oracle.com  Wed Sep 16 12:28:27 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 16 Sep 2015 14:28:27 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
Message-ID: <55F9606B.2060701@oracle.com>

On 2015-09-11 18:00, Attila Szegedi wrote:
> Please review the revised changes for JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code? <https://bugs.openjdk.java.net/browse/JDK-8135251>
>
> The revision incorporates the following changes:
> - the feature can be disabled by setting the "nashorn.disableVmAnonymousClasses system property?
> - jdk9 root-level modules.xml explicitly exports sun.misc to jdk.scripting.nashorn
> - the changes to the CodeInstaller and Compiler API have since been separately committed, so they are no longer part of this issue, making its surface area smaller.
>
> Webrevs are found at:
> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9>
> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn>
>
> The fist webrev is for jdk9/modules.xml; the change simply adds an export of sun.misc to jdk.scripting.nashorn; it is also the reason why I included build-dev on this review.

Actually, I think it's a better idea to direct module.xml related 
changes to jigsaw-dev. (Cc:ing them).

/Magnus

> The second webrev is the changes to the Nashorn code.
>
> Thanks,
>    Attila.
>


From Alan.Bateman at oracle.com  Wed Sep 16 12:51:34 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Sep 2015 13:51:34 +0100
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <55F9606B.2060701@oracle.com>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
	<55F9606B.2060701@oracle.com>
Message-ID: <55F965D6.1080709@oracle.com>



On 16/09/2015 13:28, Magnus Ihse Bursie wrote:
> On 2015-09-11 18:00, Attila Szegedi wrote:
>> Please review the revised changes for JDK-8135251 "Use 
>> Unsafe.defineAnonymousClass for loading Nashorn script code? 
>> <https://bugs.openjdk.java.net/browse/JDK-8135251>
>>
>> The revision incorporates the following changes:
>> - the feature can be disabled by setting the 
>> "nashorn.disableVmAnonymousClasses system property?
>> - jdk9 root-level modules.xml explicitly exports sun.misc to 
>> jdk.scripting.nashorn
>> - the changes to the CodeInstaller and Compiler API have since been 
>> separately committed, so they are no longer part of this issue, 
>> making its surface area smaller.
>>
>> Webrevs are found at:
>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 
>> <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9>
>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn 
>> <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn>
>>
>> The fist webrev is for jdk9/modules.xml; the change simply adds an 
>> export of sun.misc to jdk.scripting.nashorn; it is also the reason 
>> why I included build-dev on this review.
>
> Actually, I think it's a better idea to direct module.xml related 
> changes to jigsaw-dev. (Cc:ing them).
The changes to modules.xml looks fine. Also just to say that modules.xml 
has been removed in the jigsaw/jake forest as it was just a temporary 
document to maintain the module graph until the module system came along.

-Alan.

From magnus.ihse.bursie at oracle.com  Wed Sep 16 13:04:03 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 16 Sep 2015 15:04:03 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <55F965D6.1080709@oracle.com>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
	<55F9606B.2060701@oracle.com> <55F965D6.1080709@oracle.com>
Message-ID: <55F968C3.6030509@oracle.com>

On 2015-09-16 14:51, Alan Bateman wrote:
>
>
> On 16/09/2015 13:28, Magnus Ihse Bursie wrote:
>> On 2015-09-11 18:00, Attila Szegedi wrote:
>>> Please review the revised changes for JDK-8135251 "Use 
>>> Unsafe.defineAnonymousClass for loading Nashorn script code? 
>>> <https://bugs.openjdk.java.net/browse/JDK-8135251>
>>>
>>> The revision incorporates the following changes:
>>> - the feature can be disabled by setting the 
>>> "nashorn.disableVmAnonymousClasses system property?
>>> - jdk9 root-level modules.xml explicitly exports sun.misc to 
>>> jdk.scripting.nashorn
>>> - the changes to the CodeInstaller and Compiler API have since been 
>>> separately committed, so they are no longer part of this issue, 
>>> making its surface area smaller.
>>>
>>> Webrevs are found at:
>>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 
>>> <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9>
>>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn 
>>> <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn>
>>>
>>> The fist webrev is for jdk9/modules.xml; the change simply adds an 
>>> export of sun.misc to jdk.scripting.nashorn; it is also the reason 
>>> why I included build-dev on this review.
>>
>> Actually, I think it's a better idea to direct module.xml related 
>> changes to jigsaw-dev. (Cc:ing them).
> The changes to modules.xml looks fine. Also just to say that 
> modules.xml has been removed in the jigsaw/jake forest as it was just 
> a temporary document to maintain the module graph until the module 
> system came along.

Does this mean that updates to modules.xml between now and the 
integration-to-come of jigsaw/jake do not anymore need specific approval?

/Magnus

>
> -Alan.


From Alan.Bateman at oracle.com  Wed Sep 16 13:12:21 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Sep 2015 14:12:21 +0100
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <55F968C3.6030509@oracle.com>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
	<55F9606B.2060701@oracle.com> <55F965D6.1080709@oracle.com>
	<55F968C3.6030509@oracle.com>
Message-ID: <55F96AB5.7000702@oracle.com>


On 16/09/2015 14:04, Magnus Ihse Bursie wrote:
>
> Does this mean that updates to modules.xml between now and the 
> integration-to-come of jigsaw/jake do not anymore need specific approval?
I think we should keep the status quo and CC jigsaw-dev when there are 
changes to modules.xml. If nothing else, it creates aware of the changes 
because they require adjustment when jigsaw/jake is sync'ed up from 
jdk9/jdk9. These sync ups are non-trivial at times. Aside from merging 
almost every repo, then often require looking at the changes to 
modules.xml in the promoted build to ensure that the equivalent changes 
are make to the module declarations.

-Alan

From Alan.Bateman at oracle.com  Wed Sep 16 13:23:58 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Sep 2015 14:23:58 +0100
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <55F9695A.60205@redhat.com>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>	<55F9606B.2060701@oracle.com>
	<55F965D6.1080709@oracle.com> <55F9695A.60205@redhat.com>
Message-ID: <55F96D6E.5040506@oracle.com>


On 16/09/2015 14:06, David M. Lloyd wrote:
>
> Also I could be wrong but it looks to me like the jigsaw/jake forest's 
> equivalent module graph has evolved somewhat, and thus doesn't quite 
> match this file anyway.
jigsaw/jake is currently at jdk9-b81. There may be changes backed up in 
jdk9/dev that aren't in jake yet, we'll get those once those changes get 
to master and there is a sync up. As I mentioned in the reply to Magnus 
then these sync ups often require changes to the module declarations.

Other than the pipeline there is one new module in jigsaw/jake 
(jdk.jlink), a few additional exports, and a few adjustments to 
qualified exports to take account of the wide changes in the jake 
forest. The nice thing about working in jake is that it will catch a lot 
more at compile time compared to working in jdk9/dev.

-Alan.

From david.lloyd at redhat.com  Wed Sep 16 13:06:34 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 16 Sep 2015 08:06:34 -0500
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <55F965D6.1080709@oracle.com>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>	<55F9606B.2060701@oracle.com>
	<55F965D6.1080709@oracle.com>
Message-ID: <55F9695A.60205@redhat.com>

On 09/16/2015 07:51 AM, Alan Bateman wrote:
>
>
> On 16/09/2015 13:28, Magnus Ihse Bursie wrote:
>> On 2015-09-11 18:00, Attila Szegedi wrote:
>>> Please review the revised changes for JDK-8135251 "Use
>>> Unsafe.defineAnonymousClass for loading Nashorn script code?
>>> <https://bugs.openjdk.java.net/browse/JDK-8135251>
>>>
>>> The revision incorporates the following changes:
>>> - the feature can be disabled by setting the
>>> "nashorn.disableVmAnonymousClasses system property?
>>> - jdk9 root-level modules.xml explicitly exports sun.misc to
>>> jdk.scripting.nashorn
>>> - the changes to the CodeInstaller and Compiler API have since been
>>> separately committed, so they are no longer part of this issue,
>>> making its surface area smaller.
>>>
>>> Webrevs are found at:
>>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9
>>> <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9>
>>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn
>>> <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn>
>>>
>>> The fist webrev is for jdk9/modules.xml; the change simply adds an
>>> export of sun.misc to jdk.scripting.nashorn; it is also the reason
>>> why I included build-dev on this review.
>>
>> Actually, I think it's a better idea to direct module.xml related
>> changes to jigsaw-dev. (Cc:ing them).
> The changes to modules.xml looks fine. Also just to say that modules.xml
> has been removed in the jigsaw/jake forest as it was just a temporary
> document to maintain the module graph until the module system came along.

Also I could be wrong but it looks to me like the jigsaw/jake forest's 
equivalent module graph has evolved somewhat, and thus doesn't quite 
match this file anyway.
-- 
- DML

From hannes.wallnoefer at oracle.com  Wed Sep 16 13:56:07 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 16 Sep 2015 15:56:07 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
Message-ID: <55F974F7.5080400@oracle.com>

+1 for the Nashorn changes.


Am 2015-09-11 um 18:00 schrieb Attila Szegedi:
> Please review the revised changes for JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code? <https://bugs.openjdk.java.net/browse/JDK-8135251>
>
> The revision incorporates the following changes:
> - the feature can be disabled by setting the "nashorn.disableVmAnonymousClasses system property?
> - jdk9 root-level modules.xml explicitly exports sun.misc to jdk.scripting.nashorn
> - the changes to the CodeInstaller and Compiler API have since been separately committed, so they are no longer part of this issue, making its surface area smaller.
>
> Webrevs are found at:
> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9>
> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn>
>
> The fist webrev is for jdk9/modules.xml; the change simply adds an export of sun.misc to jdk.scripting.nashorn; it is also the reason why I included build-dev on this review.
> The second webrev is the changes to the Nashorn code.
>
> Thanks,
>    Attila.
>


From attila.szegedi at oracle.com  Wed Sep 16 13:57:26 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 16 Sep 2015 15:57:26 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <7A200E46-2784-4772-9019-AB658705958B@lagergren.net>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
	<1966C2A9-6460-4529-8879-932ABFE65EDD@lagergren.net>
	<E74C2620-2CC7-44FD-B99C-E33492642804@oracle.com>
	<7A200E46-2784-4772-9019-AB658705958B@lagergren.net>
Message-ID: <E1EA035F-FE1A-43D3-A686-9BDC178BBF2D@oracle.com>

Nope. Just compiled it with 9-b81 and no such warnings are present.

> On Sep 14, 2015, at 9:55 AM, Marcus Lagergren <lagergren at gmail.com> wrote:
> 
> ant test
> 
> Does it spit out warnings like e.g.
> 
> Temp.java:1: warning: Unsafe is internal proprietary API and may be removed in a future release
> import sun.misc.Unsafe;
>                ^
> Temp.java:6: warning: Unsafe is internal proprietary API and may be removed in a future release
>     private static Unsafe getUnsafe() {
>                    ^
> Temp.java:7: warning: Unsafe is internal proprietary API and may be removed in a future release
> 	return AccessController.doPrivileged(new PrivilegedAction<Unsafe>() {
> 	                                                          ^
> Temp.java:9: warning: Unsafe is internal proprietary API and may be removed in a future release
>                     public Unsafe run() {
>                            ^
> Temp.java:11: warning: Unsafe is internal proprietary API and may be removed in a future release
> 			final Field theUnsafeField = Unsafe.class.getDeclaredField("theUnsafe");
> 			                             ^
> Temp.java:13: warning: Unsafe is internal proprietary API and may be removed in a future release
> 			return (Unsafe)theUnsafeField.get(null);
> 			        ^
> Temp.java:21: warning: Unsafe is internal proprietary API and may be removed in a future release
>     private static Unsafe UNSAFE = getUnsafe();
>                    ^
> 7 warnings
> 
> Because we don?t want compile warnings ;-)
> 
> /M
> 
> 
>> On 14 Sep 2015, at 09:54, Attila Szegedi <attila.szegedi at oracle.com <mailto:attila.szegedi at oracle.com>> wrote:
>> 
>> What do you mean by ?unsafe warning??
>> 
>>> On Sep 13, 2015, at 12:47 PM, Marcus Lagergren <lagergren at gmail.com <mailto:lagergren at gmail.com>> wrote:
>>> 
>>> +1. Nicely done.
>>> 
>>> Does this compile without unsafe warnings, though?
>>> 
>>> /M
>>> 
>>>> On 11 Sep 2015, at 18:00, Attila Szegedi <attila.szegedi at oracle.com <mailto:attila.szegedi at oracle.com>> wrote:
>>>> 
>>>> e
>>> 
>> 
> 


From attila.szegedi at oracle.com  Wed Sep 16 14:05:57 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 16 Sep 2015 16:05:57 +0200
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <55F965D6.1080709@oracle.com>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
	<55F9606B.2060701@oracle.com> <55F965D6.1080709@oracle.com>
Message-ID: <D74F090C-9F0A-48D4-9C70-B5B036BCD26C@oracle.com>

> On Sep 16, 2015, at 2:51 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 16/09/2015 13:28, Magnus Ihse Bursie wrote:
>> On 2015-09-11 18:00, Attila Szegedi wrote:
>>> Please review the revised changes for JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code? <https://bugs.openjdk.java.net/browse/JDK-8135251>
>>> 
>>> The revision incorporates the following changes:
>>> - the feature can be disabled by setting the "nashorn.disableVmAnonymousClasses system property?
>>> - jdk9 root-level modules.xml explicitly exports sun.misc to jdk.scripting.nashorn
>>> - the changes to the CodeInstaller and Compiler API have since been separately committed, so they are no longer part of this issue, making its surface area smaller.
>>> 
>>> Webrevs are found at:
>>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9>
>>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn>
>>> 
>>> The fist webrev is for jdk9/modules.xml; the change simply adds an export of sun.misc to jdk.scripting.nashorn; it is also the reason why I included build-dev on this review.
>> 
>> Actually, I think it's a better idea to direct module.xml related changes to jigsaw-dev. (Cc:ing them).
> The changes to modules.xml looks fine. Also just to say that modules.xml has been removed in the jigsaw/jake forest as it was just a temporary document to maintain the module graph until the module system came along.

Alan, can I cite you in "Reviewed-by? line as a reviewer for the modules.xml change?

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Wed Sep 16 14:28:01 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 16 Sep 2015 19:58:01 +0530
Subject: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass
	for loading Nashorn script code
In-Reply-To: <D74F090C-9F0A-48D4-9C70-B5B036BCD26C@oracle.com>
References: <76202E19-2AF7-4EC8-A337-7D18C1E404A2@oracle.com>
	<55F9606B.2060701@oracle.com> <55F965D6.1080709@oracle.com>
	<D74F090C-9F0A-48D4-9C70-B5B036BCD26C@oracle.com>
Message-ID: <55F97C71.8060806@oracle.com>

+1

Nashorn changes and modules.xml changes look good to me.

-Sundar

On 9/16/2015 7:35 PM, Attila Szegedi wrote:
>> On Sep 16, 2015, at 2:51 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>>
>>
>> On 16/09/2015 13:28, Magnus Ihse Bursie wrote:
>>> On 2015-09-11 18:00, Attila Szegedi wrote:
>>>> Please review the revised changes for JDK-8135251 "Use Unsafe.defineAnonymousClass for loading Nashorn script code? <https://bugs.openjdk.java.net/browse/JDK-8135251>
>>>>
>>>> The revision incorporates the following changes:
>>>> - the feature can be disabled by setting the "nashorn.disableVmAnonymousClasses system property?
>>>> - jdk9 root-level modules.xml explicitly exports sun.misc to jdk.scripting.nashorn
>>>> - the changes to the CodeInstaller and Compiler API have since been separately committed, so they are no longer part of this issue, making its surface area smaller.
>>>>
>>>> Webrevs are found at:
>>>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9 <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9>
>>>> http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn <http://cr.openjdk.java.net/~attila/8135251/webrev.jdk9-nashorn>
>>>>
>>>> The fist webrev is for jdk9/modules.xml; the change simply adds an export of sun.misc to jdk.scripting.nashorn; it is also the reason why I included build-dev on this review.
>>> Actually, I think it's a better idea to direct module.xml related changes to jigsaw-dev. (Cc:ing them).
>> The changes to modules.xml looks fine. Also just to say that modules.xml has been removed in the jigsaw/jake forest as it was just a temporary document to maintain the module graph until the module system came along.
> Alan, can I cite you in "Reviewed-by? line as a reviewer for the modules.xml change?
>
> Thanks,
>    Attila.


From attila.szegedi at oracle.com  Wed Sep 16 16:39:59 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 16 Sep 2015 18:39:59 +0200
Subject: Review request for JDK-8136647: Syntactic error accidentally left in
	JDK-8135251 changeset
Message-ID: <71E8F32C-6AD0-4D33-AD56-4E8971726D97@oracle.com>

Please review JDK-8136647 "Syntactic error accidentally left in JDK-8135251 changeset" at <http://cr.openjdk.java.net/~attila/8136647/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8136647>

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Wed Sep 16 16:41:22 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 16 Sep 2015 22:11:22 +0530
Subject: Review request for JDK-8136647: Syntactic error accidentally left
	in JDK-8135251 changeset
In-Reply-To: <71E8F32C-6AD0-4D33-AD56-4E8971726D97@oracle.com>
References: <71E8F32C-6AD0-4D33-AD56-4E8971726D97@oracle.com>
Message-ID: <55F99BB2.9020405@oracle.com>

+1

On 9/16/2015 10:09 PM, Attila Szegedi wrote:
> Please review JDK-8136647 "Syntactic error accidentally left in JDK-8135251 changeset" at <http://cr.openjdk.java.net/~attila/8136647/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8136647>
>
> Thanks,
>    Attila.


From michael.haupt at oracle.com  Thu Sep 17 07:06:08 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Thu, 17 Sep 2015 09:06:08 +0200
Subject: Review request for JDK-8136647: Syntactic error accidentally left
	in JDK-8135251 changeset
In-Reply-To: <71E8F32C-6AD0-4D33-AD56-4E8971726D97@oracle.com>
References: <71E8F32C-6AD0-4D33-AD56-4E8971726D97@oracle.com>
Message-ID: <7EF2E7F3-D9BD-42C6-B808-48BFD6423296@oracle.com>

Hi Attila,

lower-case thumbs up.

Best,

Michael

> Am 16.09.2015 um 18:39 schrieb Attila Szegedi <attila.szegedi at oracle.com>:
> 
> Please review JDK-8136647 "Syntactic error accidentally left in JDK-8135251 changeset" at <http://cr.openjdk.java.net/~attila/8136647/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8136647>
> 
> Thanks,
>  Attila.

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From sundararajan.athijegannathan at oracle.com  Thu Sep 17 12:39:45 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 17 Sep 2015 18:09:45 +0530
Subject: RFR 8136694: Megemorphic scope access does not throw ReferenceError
	when property is missing
Message-ID: <55FAB491.3070905@oracle.com>

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

Thanks,
-Sundar

From attila.szegedi at oracle.com  Thu Sep 17 12:46:58 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 17 Sep 2015 14:46:58 +0200
Subject: RFR 8136694: Megemorphic scope access does not throw
	ReferenceError when property is missing
In-Reply-To: <55FAB491.3070905@oracle.com>
References: <55FAB491.3070905@oracle.com>
Message-ID: <4D0F9FB1-0A19-4ADA-866F-847D23068A3C@oracle.com>

+1

> On Sep 17, 2015, at 2:39 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8136694/ for https://bugs.openjdk.java.net/browse/JDK-8136694
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Thu Sep 17 12:52:48 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 17 Sep 2015 14:52:48 +0200
Subject: RFR 8136694: Megemorphic scope access does not throw
	ReferenceError when property is missing
In-Reply-To: <55FAB491.3070905@oracle.com>
References: <55FAB491.3070905@oracle.com>
Message-ID: <55FAB7A0.2040602@oracle.com>

+1

Am 2015-09-17 um 14:39 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8136694/ for 
> https://bugs.openjdk.java.net/browse/JDK-8136694
>
> Thanks,
> -Sundar


From attila.szegedi at oracle.com  Thu Sep 17 14:14:51 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 17 Sep 2015 16:14:51 +0200
Subject: Review request for JDK-8136700: Make sure
	Context.anonymousHostClasses doesn't grow unbounded
Message-ID: <50C87084-0287-4409-9831-7D9AB82F04E0@oracle.com>

Please review JDK-8136700 "Make sure Context.anonymousHostClasses doesn't grow unbounded" at <http://cr.openjdk.java.net/~attila/8136700/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8136700>

Thanks,
  Attila.

From michael.haupt at oracle.com  Thu Sep 17 14:18:11 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Thu, 17 Sep 2015 16:18:11 +0200
Subject: Review request for JDK-8136700: Make sure
	Context.anonymousHostClasses doesn't grow unbounded
In-Reply-To: <50C87084-0287-4409-9831-7D9AB82F04E0@oracle.com>
References: <50C87084-0287-4409-9831-7D9AB82F04E0@oracle.com>
Message-ID: <D2C6183D-67A1-4712-99EF-4292B2BC49E1@oracle.com>

Hi Attila,

lower-case thumbs up!

Best,

Michael

> Am 17.09.2015 um 16:14 schrieb Attila Szegedi <attila.szegedi at oracle.com>:
> 
> Please review JDK-8136700 "Make sure Context.anonymousHostClasses doesn't grow unbounded" at <http://cr.openjdk.java.net/~attila/8136700/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8136700>
> 
> Thanks,
>  Attila.

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From michael.haupt at oracle.com  Thu Sep 17 14:29:05 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Thu, 17 Sep 2015 16:29:05 +0200
Subject: Review request for JDK-8136700: Make sure
	Context.anonymousHostClasses doesn't grow unbounded
In-Reply-To: <D2C6183D-67A1-4712-99EF-4292B2BC49E1@oracle.com>
References: <50C87084-0287-4409-9831-7D9AB82F04E0@oracle.com>
	<D2C6183D-67A1-4712-99EF-4292B2BC49E1@oracle.com>
Message-ID: <9B8D829E-C826-4E27-A30A-3083429C20DB@oracle.com>

Hi again,

no sorry; I have to revoke this as I forgot weak sets aren't weak in the way they have to be in this case.

Best,

Michael

> Am 17.09.2015 um 16:18 schrieb Michael Haupt <michael.haupt at oracle.com>:
> 
> Hi Attila,
> 
> lower-case thumbs up!
> 
> Best,
> 
> Michael
> 
>> Am 17.09.2015 um 16:14 schrieb Attila Szegedi <attila.szegedi at oracle.com>:
>> 
>> Please review JDK-8136700 "Make sure Context.anonymousHostClasses doesn't grow unbounded" at <http://cr.openjdk.java.net/~attila/8136700/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8136700>
>> 
>> Thanks,
>> Attila.


-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From attila.szegedi at oracle.com  Thu Sep 17 15:37:34 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 17 Sep 2015 17:37:34 +0200
Subject: Review request for JDK-8136700: Make sure
	Context.anonymousHostClasses doesn't grow unbounded
In-Reply-To: <9B8D829E-C826-4E27-A30A-3083429C20DB@oracle.com>
References: <50C87084-0287-4409-9831-7D9AB82F04E0@oracle.com>
	<D2C6183D-67A1-4712-99EF-4292B2BC49E1@oracle.com>
	<9B8D829E-C826-4E27-A30A-3083429C20DB@oracle.com>
Message-ID: <87899B8D-83EC-45B1-B8C7-423B225A35D3@oracle.com>

Indeed, that?s correct. A new webrev is available for review at <http://cr.openjdk.java.net/~attila/8136700/webrev.01.jdk9> that manually handles removal of cleared entries.

Attila.

> On Sep 17, 2015, at 4:29 PM, Michael Haupt <michael.haupt at oracle.com> wrote:
> 
> Hi again,
> 
> no sorry; I have to revoke this as I forgot weak sets aren't weak in the way they have to be in this case.
> 
> Best,
> 
> Michael
> 
>> Am 17.09.2015 um 16:18 schrieb Michael Haupt <michael.haupt at oracle.com>:
>> 
>> Hi Attila,
>> 
>> lower-case thumbs up!
>> 
>> Best,
>> 
>> Michael
>> 
>>> Am 17.09.2015 um 16:14 schrieb Attila Szegedi <attila.szegedi at oracle.com>:
>>> 
>>> Please review JDK-8136700 "Make sure Context.anonymousHostClasses doesn't grow unbounded" at <http://cr.openjdk.java.net/~attila/8136700/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8136700>
>>> 
>>> Thanks,
>>> Attila.
> 
> 
> -- 
> 
> <http://www.oracle.com/>
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> Oracle Java Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
> <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment
> 


From sundararajan.athijegannathan at oracle.com  Fri Sep 18 04:22:58 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 18 Sep 2015 09:52:58 +0530
Subject: Review request for JDK-8136700: Make sure
	Context.anonymousHostClasses doesn't grow unbounded
In-Reply-To: <87899B8D-83EC-45B1-B8C7-423B225A35D3@oracle.com>
References: <50C87084-0287-4409-9831-7D9AB82F04E0@oracle.com>
	<D2C6183D-67A1-4712-99EF-4292B2BC49E1@oracle.com>
	<9B8D829E-C826-4E27-A30A-3083429C20DB@oracle.com>
	<87899B8D-83EC-45B1-B8C7-423B225A35D3@oracle.com>
Message-ID: <55FB91A2.1090700@oracle.com>

* Context.compile is synchronized and so there is no need for 
ConcurrentHashMap + concurrency related comment.
* Map.remove(Object, Object) is used which is since jdk 1.8. If we have 
to backport this change to jdk8u (where jdk7 is used as JAVA_HOME to 
build/test), we've to take care of this.

-Sundar

On 9/17/2015 9:07 PM, Attila Szegedi wrote:
> Indeed, that?s correct. A new webrev is available for review at <http://cr.openjdk.java.net/~attila/8136700/webrev.01.jdk9> that manually handles removal of cleared entries.
>
> Attila.
>
>> On Sep 17, 2015, at 4:29 PM, Michael Haupt <michael.haupt at oracle.com> wrote:
>>
>> Hi again,
>>
>> no sorry; I have to revoke this as I forgot weak sets aren't weak in the way they have to be in this case.
>>
>> Best,
>>
>> Michael
>>
>>> Am 17.09.2015 um 16:18 schrieb Michael Haupt <michael.haupt at oracle.com>:
>>>
>>> Hi Attila,
>>>
>>> lower-case thumbs up!
>>>
>>> Best,
>>>
>>> Michael
>>>
>>>> Am 17.09.2015 um 16:14 schrieb Attila Szegedi <attila.szegedi at oracle.com>:
>>>>
>>>> Please review JDK-8136700 "Make sure Context.anonymousHostClasses doesn't grow unbounded" at <http://cr.openjdk.java.net/~attila/8136700/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8136700>
>>>>
>>>> Thanks,
>>>> Attila.
>>
>> -- 
>>
>> <http://www.oracle.com/>
>> Dr. Michael Haupt | Principal Member of Technical Staff
>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>> Oracle Java Platform Group | LangTools Team | Nashorn
>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
>> <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment
>>


From attila.szegedi at oracle.com  Fri Sep 18 09:54:57 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 18 Sep 2015 11:54:57 +0200
Subject: Review request for JDK-8136700: Make sure
	Context.anonymousHostClasses doesn't grow unbounded
In-Reply-To: <55FB91A2.1090700@oracle.com>
References: <50C87084-0287-4409-9831-7D9AB82F04E0@oracle.com>
	<D2C6183D-67A1-4712-99EF-4292B2BC49E1@oracle.com>
	<9B8D829E-C826-4E27-A30A-3083429C20DB@oracle.com>
	<87899B8D-83EC-45B1-B8C7-423B225A35D3@oracle.com>
	<55FB91A2.1090700@oracle.com>
Message-ID: <AB164581-6841-49D3-B44E-40CD6873751D@oracle.com>

> On Sep 18, 2015, at 6:22 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> * Context.compile is synchronized and so there is no need for ConcurrentHashMap + concurrency related comment.

You?re right, I removed them. I updated webrev in-place.

> * Map.remove(Object, Object) is used which is since jdk 1.8. If we have to backport this change to jdk8u (where jdk7 is used as JAVA_HOME to build/test), we've to take care of this.

If we backport, this will show up as a compile error, so we?ll adjust then. I?d rather run another round of a short review then than have a less efficient construct in 9 codebase.

Thanks,
  Attila.

> 
> -Sundar
> 
> On 9/17/2015 9:07 PM, Attila Szegedi wrote:
>> Indeed, that?s correct. A new webrev is available for review at <http://cr.openjdk.java.net/~attila/8136700/webrev.01.jdk9> that manually handles removal of cleared entries.
>> 
>> Attila.
>> 
>>> On Sep 17, 2015, at 4:29 PM, Michael Haupt <michael.haupt at oracle.com> wrote:
>>> 
>>> Hi again,
>>> 
>>> no sorry; I have to revoke this as I forgot weak sets aren't weak in the way they have to be in this case.
>>> 
>>> Best,
>>> 
>>> Michael
>>> 
>>>> Am 17.09.2015 um 16:18 schrieb Michael Haupt <michael.haupt at oracle.com>:
>>>> 
>>>> Hi Attila,
>>>> 
>>>> lower-case thumbs up!
>>>> 
>>>> Best,
>>>> 
>>>> Michael
>>>> 
>>>>> Am 17.09.2015 um 16:14 schrieb Attila Szegedi <attila.szegedi at oracle.com>:
>>>>> 
>>>>> Please review JDK-8136700 "Make sure Context.anonymousHostClasses doesn't grow unbounded" at <http://cr.openjdk.java.net/~attila/8136700/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8136700>
>>>>> 
>>>>> Thanks,
>>>>> Attila.
>>> 
>>> -- 
>>> 
>>> <http://www.oracle.com/>
>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>> Oracle Java Platform Group | LangTools Team | Nashorn
>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
>>> <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment
>>> 
> 


From hannes.wallnoefer at oracle.com  Fri Sep 18 10:03:06 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 18 Sep 2015 12:03:06 +0200
Subject: Review request for JDK-8135190: Method code too large in Babel
	browser.js script
Message-ID: <55FBE15A.5090806@oracle.com>

Please review JDK-8135190: Method code too large in Babel browser.js script:

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

This makes object literals splittable. I tried to share as much code as 
possible with array literal splitting so I had to introduce a couple of 
new interfaces.

Hannes

From sundararajan.athijegannathan at oracle.com  Fri Sep 18 12:05:56 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 18 Sep 2015 17:35:56 +0530
Subject: Review request for JDK-8136700: Make sure
	Context.anonymousHostClasses doesn't grow unbounded
In-Reply-To: <AB164581-6841-49D3-B44E-40CD6873751D@oracle.com>
References: <50C87084-0287-4409-9831-7D9AB82F04E0@oracle.com>
	<D2C6183D-67A1-4712-99EF-4292B2BC49E1@oracle.com>
	<9B8D829E-C826-4E27-A30A-3083429C20DB@oracle.com>
	<87899B8D-83EC-45B1-B8C7-423B225A35D3@oracle.com>
	<55FB91A2.1090700@oracle.com>
	<AB164581-6841-49D3-B44E-40CD6873751D@oracle.com>
Message-ID: <55FBFE24.20905@oracle.com>

+1

On 9/18/2015 3:24 PM, Attila Szegedi wrote:
>> On Sep 18, 2015, at 6:22 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>
>> * Context.compile is synchronized and so there is no need for ConcurrentHashMap + concurrency related comment.
> You?re right, I removed them. I updated webrev in-place.
>
>> * Map.remove(Object, Object) is used which is since jdk 1.8. If we have to backport this change to jdk8u (where jdk7 is used as JAVA_HOME to build/test), we've to take care of this.
> If we backport, this will show up as a compile error, so we?ll adjust then. I?d rather run another round of a short review then than have a less efficient construct in 9 codebase.
>
> Thanks,
>    Attila.
>
>> -Sundar
>>
>> On 9/17/2015 9:07 PM, Attila Szegedi wrote:
>>> Indeed, that?s correct. A new webrev is available for review at <http://cr.openjdk.java.net/~attila/8136700/webrev.01.jdk9> that manually handles removal of cleared entries.
>>>
>>> Attila.
>>>
>>>> On Sep 17, 2015, at 4:29 PM, Michael Haupt <michael.haupt at oracle.com> wrote:
>>>>
>>>> Hi again,
>>>>
>>>> no sorry; I have to revoke this as I forgot weak sets aren't weak in the way they have to be in this case.
>>>>
>>>> Best,
>>>>
>>>> Michael
>>>>
>>>>> Am 17.09.2015 um 16:18 schrieb Michael Haupt <michael.haupt at oracle.com>:
>>>>>
>>>>> Hi Attila,
>>>>>
>>>>> lower-case thumbs up!
>>>>>
>>>>> Best,
>>>>>
>>>>> Michael
>>>>>
>>>>>> Am 17.09.2015 um 16:14 schrieb Attila Szegedi <attila.szegedi at oracle.com>:
>>>>>>
>>>>>> Please review JDK-8136700 "Make sure Context.anonymousHostClasses doesn't grow unbounded" at <http://cr.openjdk.java.net/~attila/8136700/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8136700>
>>>>>>
>>>>>> Thanks,
>>>>>> Attila.
>>>> -- 
>>>>
>>>> <http://www.oracle.com/>
>>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>>> Oracle Java Platform Group | LangTools Team | Nashorn
>>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
>>>> <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment
>>>>


From attila.szegedi at oracle.com  Fri Sep 18 13:03:44 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 18 Sep 2015 15:03:44 +0200
Subject: Review request for JDK-8135190: Method code too large in Babel
	browser.js script
In-Reply-To: <55FBE15A.5090806@oracle.com>
References: <55FBE15A.5090806@oracle.com>
Message-ID: <971C8EBD-D94B-43E1-A6EA-5AB0B41BA10E@oracle.com>

Few minor remarks: 

* AssignSymbols.isSplitLiteral uses !(splitRanges == null || splitRanges.isEmpty()) while everywhere else in the code the check is (ranges != null).
* loadSplitLiteral: seems like there's a stray comment: // method.load(literalType, literalSlot);
* Terminology: Splittable is described as a "marker interface? yet it has a method.

Other than these small things, +1.

Attila.

> On Sep 18, 2015, at 12:03 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review JDK-8135190: Method code too large in Babel browser.js script:
> 
> http://cr.openjdk.java.net/~hannesw/8135190/
> 
> This makes object literals splittable. I tried to share as much code as possible with array literal splitting so I had to introduce a couple of new interfaces.
> 
> Hannes


From sundararajan.athijegannathan at oracle.com  Fri Sep 18 13:09:22 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 18 Sep 2015 18:39:22 +0530
Subject: Review request for JDK-8135190: Method code too large in Babel
	browser.js script
In-Reply-To: <971C8EBD-D94B-43E1-A6EA-5AB0B41BA10E@oracle.com>
References: <55FBE15A.5090806@oracle.com>
	<971C8EBD-D94B-43E1-A6EA-5AB0B41BA10E@oracle.com>
Message-ID: <55FC0D02.2090905@oracle.com>

* On naming: how about getHigh and getLow in Splittable?

* Types.typeFor can fallback to name pattern (JO subclass) and use 
JO.class (when getting CNFE) or context's sharedloader to do Class.forName

Other than that +1

-Sundar

On 9/18/2015 6:33 PM, Attila Szegedi wrote:
> Few minor remarks:
>
> * AssignSymbols.isSplitLiteral uses !(splitRanges == null || splitRanges.isEmpty()) while everywhere else in the code the check is (ranges != null).
> * loadSplitLiteral: seems like there's a stray comment: // method.load(literalType, literalSlot);
> * Terminology: Splittable is described as a "marker interface? yet it has a method.
>
> Other than these small things, +1.
>
> Attila.
>
>> On Sep 18, 2015, at 12:03 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
>>
>> Please review JDK-8135190: Method code too large in Babel browser.js script:
>>
>> http://cr.openjdk.java.net/~hannesw/8135190/
>>
>> This makes object literals splittable. I tried to share as much code as possible with array literal splitting so I had to introduce a couple of new interfaces.
>>
>> Hannes


From hannes.wallnoefer at oracle.com  Fri Sep 18 13:35:59 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 18 Sep 2015 15:35:59 +0200
Subject: Review request for JDK-8135190: Method code too large in Babel
	browser.js script
In-Reply-To: <55FC0D02.2090905@oracle.com>
References: <55FBE15A.5090806@oracle.com>
	<971C8EBD-D94B-43E1-A6EA-5AB0B41BA10E@oracle.com>
	<55FC0D02.2090905@oracle.com>
Message-ID: <55FC133F.2050001@oracle.com>

Thanks for the reviews!

I've uploaded a new webrev with all the changes you suggested. For 
Type.typeFor I added a call to a new Context.isStructureClass method. 
Note that structure classes are direct subclasses of ScriptObject, so we 
use Type.SCRIPT_OBJECT in that case.

http://cr.openjdk.java.net/~hannesw/8135190/webrev.01/

Hannes

Am 2015-09-18 um 15:09 schrieb Sundararajan Athijegannathan:
> * On naming: how about getHigh and getLow in Splittable?
>
> * Types.typeFor can fallback to name pattern (JO subclass) and use 
> JO.class (when getting CNFE) or context's sharedloader to do 
> Class.forName
>
> Other than that +1
>
> -Sundar
>
> On 9/18/2015 6:33 PM, Attila Szegedi wrote:
>> Few minor remarks:
>>
>> * AssignSymbols.isSplitLiteral uses !(splitRanges == null || 
>> splitRanges.isEmpty()) while everywhere else in the code the check is 
>> (ranges != null).
>> * loadSplitLiteral: seems like there's a stray comment: // 
>> method.load(literalType, literalSlot);
>> * Terminology: Splittable is described as a "marker interface? yet it 
>> has a method.
>>
>> Other than these small things, +1.
>>
>> Attila.
>>
>>> On Sep 18, 2015, at 12:03 PM, Hannes Wallnoefer 
>>> <hannes.wallnoefer at oracle.com> wrote:
>>>
>>> Please review JDK-8135190: Method code too large in Babel browser.js 
>>> script:
>>>
>>> http://cr.openjdk.java.net/~hannesw/8135190/
>>>
>>> This makes object literals splittable. I tried to share as much code 
>>> as possible with array literal splitting so I had to introduce a 
>>> couple of new interfaces.
>>>
>>> Hannes
>


From hannes.wallnoefer at oracle.com  Fri Sep 18 13:44:08 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 18 Sep 2015 15:44:08 +0200
Subject: Review request for JDK-8136700: Make sure
	Context.anonymousHostClasses doesn't grow unbounded
In-Reply-To: <55FBFE24.20905@oracle.com>
References: <50C87084-0287-4409-9831-7D9AB82F04E0@oracle.com>
	<D2C6183D-67A1-4712-99EF-4292B2BC49E1@oracle.com>
	<9B8D829E-C826-4E27-A30A-3083429C20DB@oracle.com>
	<87899B8D-83EC-45B1-B8C7-423B225A35D3@oracle.com>
	<55FB91A2.1090700@oracle.com>
	<AB164581-6841-49D3-B44E-40CD6873751D@oracle.com>
	<55FBFE24.20905@oracle.com>
Message-ID: <55FC1528.4060807@oracle.com>

Shouldn't the methods modifying the map also be synchronized, even if we 
know they are (currently) only called from a synchronized method?

Otherwise looks good.

Hannes

Am 2015-09-18 um 14:05 schrieb Sundararajan Athijegannathan:
> +1
>
> On 9/18/2015 3:24 PM, Attila Szegedi wrote:
>>> On Sep 18, 2015, at 6:22 AM, Sundararajan Athijegannathan 
>>> <sundararajan.athijegannathan at oracle.com> wrote:
>>>
>>> * Context.compile is synchronized and so there is no need for 
>>> ConcurrentHashMap + concurrency related comment.
>> You?re right, I removed them. I updated webrev in-place.
>>
>>> * Map.remove(Object, Object) is used which is since jdk 1.8. If we 
>>> have to backport this change to jdk8u (where jdk7 is used as 
>>> JAVA_HOME to build/test), we've to take care of this.
>> If we backport, this will show up as a compile error, so we?ll adjust 
>> then. I?d rather run another round of a short review then than have a 
>> less efficient construct in 9 codebase.
>>
>> Thanks,
>>    Attila.
>>
>>> -Sundar
>>>
>>> On 9/17/2015 9:07 PM, Attila Szegedi wrote:
>>>> Indeed, that?s correct. A new webrev is available for review at 
>>>> <http://cr.openjdk.java.net/~attila/8136700/webrev.01.jdk9> that 
>>>> manually handles removal of cleared entries.
>>>>
>>>> Attila.
>>>>
>>>>> On Sep 17, 2015, at 4:29 PM, Michael Haupt 
>>>>> <michael.haupt at oracle.com> wrote:
>>>>>
>>>>> Hi again,
>>>>>
>>>>> no sorry; I have to revoke this as I forgot weak sets aren't weak 
>>>>> in the way they have to be in this case.
>>>>>
>>>>> Best,
>>>>>
>>>>> Michael
>>>>>
>>>>>> Am 17.09.2015 um 16:18 schrieb Michael Haupt 
>>>>>> <michael.haupt at oracle.com>:
>>>>>>
>>>>>> Hi Attila,
>>>>>>
>>>>>> lower-case thumbs up!
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>>> Am 17.09.2015 um 16:14 schrieb Attila Szegedi 
>>>>>>> <attila.szegedi at oracle.com>:
>>>>>>>
>>>>>>> Please review JDK-8136700 "Make sure 
>>>>>>> Context.anonymousHostClasses doesn't grow unbounded" at 
>>>>>>> <http://cr.openjdk.java.net/~attila/8136700/webrev.jdk9> for 
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8136700>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Attila.
>>>>> -- 
>>>>>
>>>>> <http://www.oracle.com/>
>>>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>>>> Oracle Java Platform Group | LangTools Team | Nashorn
>>>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 
>>>>> Potsdam, Germany
>>>>> <http://www.oracle.com/commitment>    Oracle is committed to 
>>>>> developing practices and products that help protect the environment
>>>>>
>


From sundararajan.athijegannathan at oracle.com  Fri Sep 18 13:59:02 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 18 Sep 2015 19:29:02 +0530
Subject: Review request for JDK-8136700: Make sure
	Context.anonymousHostClasses doesn't grow unbounded
In-Reply-To: <55FC1528.4060807@oracle.com>
References: <50C87084-0287-4409-9831-7D9AB82F04E0@oracle.com>
	<D2C6183D-67A1-4712-99EF-4292B2BC49E1@oracle.com>
	<9B8D829E-C826-4E27-A30A-3083429C20DB@oracle.com>
	<87899B8D-83EC-45B1-B8C7-423B225A35D3@oracle.com>
	<55FB91A2.1090700@oracle.com>
	<AB164581-6841-49D3-B44E-40CD6873751D@oracle.com>
	<55FBFE24.20905@oracle.com> <55FC1528.4060807@oracle.com>
Message-ID: <55FC18A6.2080204@oracle.com>

I presume it is for code clarity sake? That is a private method in that 
class called only from the other synchronized method. How about just 
adding an assert using Thread.holdsLock?

-Sundar

On 9/18/2015 7:14 PM, Hannes Wallnoefer wrote:
> Shouldn't the methods modifying the map also be synchronized, even if 
> we know they are (currently) only called from a synchronized method?
>
> Otherwise looks good.
>
> Hannes
>
> Am 2015-09-18 um 14:05 schrieb Sundararajan Athijegannathan:
>> +1
>>
>> On 9/18/2015 3:24 PM, Attila Szegedi wrote:
>>>> On Sep 18, 2015, at 6:22 AM, Sundararajan Athijegannathan 
>>>> <sundararajan.athijegannathan at oracle.com> wrote:
>>>>
>>>> * Context.compile is synchronized and so there is no need for 
>>>> ConcurrentHashMap + concurrency related comment.
>>> You?re right, I removed them. I updated webrev in-place.
>>>
>>>> * Map.remove(Object, Object) is used which is since jdk 1.8. If we 
>>>> have to backport this change to jdk8u (where jdk7 is used as 
>>>> JAVA_HOME to build/test), we've to take care of this.
>>> If we backport, this will show up as a compile error, so we?ll 
>>> adjust then. I?d rather run another round of a short review then 
>>> than have a less efficient construct in 9 codebase.
>>>
>>> Thanks,
>>>    Attila.
>>>
>>>> -Sundar
>>>>
>>>> On 9/17/2015 9:07 PM, Attila Szegedi wrote:
>>>>> Indeed, that?s correct. A new webrev is available for review at 
>>>>> <http://cr.openjdk.java.net/~attila/8136700/webrev.01.jdk9> that 
>>>>> manually handles removal of cleared entries.
>>>>>
>>>>> Attila.
>>>>>
>>>>>> On Sep 17, 2015, at 4:29 PM, Michael Haupt 
>>>>>> <michael.haupt at oracle.com> wrote:
>>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> no sorry; I have to revoke this as I forgot weak sets aren't weak 
>>>>>> in the way they have to be in this case.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>>> Am 17.09.2015 um 16:18 schrieb Michael Haupt 
>>>>>>> <michael.haupt at oracle.com>:
>>>>>>>
>>>>>>> Hi Attila,
>>>>>>>
>>>>>>> lower-case thumbs up!
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>>> Am 17.09.2015 um 16:14 schrieb Attila Szegedi 
>>>>>>>> <attila.szegedi at oracle.com>:
>>>>>>>>
>>>>>>>> Please review JDK-8136700 "Make sure 
>>>>>>>> Context.anonymousHostClasses doesn't grow unbounded" at 
>>>>>>>> <http://cr.openjdk.java.net/~attila/8136700/webrev.jdk9> for 
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8136700>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Attila.
>>>>>> -- 
>>>>>>
>>>>>> <http://www.oracle.com/>
>>>>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>>>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>>>>> Oracle Java Platform Group | LangTools Team | Nashorn
>>>>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 
>>>>>> Potsdam, Germany
>>>>>> <http://www.oracle.com/commitment>    Oracle is committed to 
>>>>>> developing practices and products that help protect the environment
>>>>>>
>>
>


From hannes.wallnoefer at oracle.com  Fri Sep 18 14:13:52 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 18 Sep 2015 16:13:52 +0200
Subject: Review request for JDK-8136700: Make sure
	Context.anonymousHostClasses doesn't grow unbounded
In-Reply-To: <55FC18A6.2080204@oracle.com>
References: <50C87084-0287-4409-9831-7D9AB82F04E0@oracle.com>
	<D2C6183D-67A1-4712-99EF-4292B2BC49E1@oracle.com>
	<9B8D829E-C826-4E27-A30A-3083429C20DB@oracle.com>
	<87899B8D-83EC-45B1-B8C7-423B225A35D3@oracle.com>
	<55FB91A2.1090700@oracle.com>
	<AB164581-6841-49D3-B44E-40CD6873751D@oracle.com>
	<55FBFE24.20905@oracle.com>
	<55FC1528.4060807@oracle.com> <55FC18A6.2080204@oracle.com>
Message-ID: <55FC1C20.4010307@oracle.com>

Am 2015-09-18 um 15:59 schrieb Sundararajan Athijegannathan:
> I presume it is for code clarity sake? That is a private method in 
> that class called only from the other synchronized method. How about 
> just adding an assert using Thread.holdsLock?

Well it's mostly as a guard for potential changes down the road. Nothing 
says "this method needs to be synchronized" better than just making it 
synchronized IMO. :)

Hannes

> -Sundar
>
> On 9/18/2015 7:14 PM, Hannes Wallnoefer wrote:
>> Shouldn't the methods modifying the map also be synchronized, even if 
>> we know they are (currently) only called from a synchronized method?
>>
>> Otherwise looks good.
>>
>> Hannes
>>
>> Am 2015-09-18 um 14:05 schrieb Sundararajan Athijegannathan:
>>> +1
>>>
>>> On 9/18/2015 3:24 PM, Attila Szegedi wrote:
>>>>> On Sep 18, 2015, at 6:22 AM, Sundararajan Athijegannathan 
>>>>> <sundararajan.athijegannathan at oracle.com> wrote:
>>>>>
>>>>> * Context.compile is synchronized and so there is no need for 
>>>>> ConcurrentHashMap + concurrency related comment.
>>>> You?re right, I removed them. I updated webrev in-place.
>>>>
>>>>> * Map.remove(Object, Object) is used which is since jdk 1.8. If we 
>>>>> have to backport this change to jdk8u (where jdk7 is used as 
>>>>> JAVA_HOME to build/test), we've to take care of this.
>>>> If we backport, this will show up as a compile error, so we?ll 
>>>> adjust then. I?d rather run another round of a short review then 
>>>> than have a less efficient construct in 9 codebase.
>>>>
>>>> Thanks,
>>>>    Attila.
>>>>
>>>>> -Sundar
>>>>>
>>>>> On 9/17/2015 9:07 PM, Attila Szegedi wrote:
>>>>>> Indeed, that?s correct. A new webrev is available for review at 
>>>>>> <http://cr.openjdk.java.net/~attila/8136700/webrev.01.jdk9> that 
>>>>>> manually handles removal of cleared entries.
>>>>>>
>>>>>> Attila.
>>>>>>
>>>>>>> On Sep 17, 2015, at 4:29 PM, Michael Haupt 
>>>>>>> <michael.haupt at oracle.com> wrote:
>>>>>>>
>>>>>>> Hi again,
>>>>>>>
>>>>>>> no sorry; I have to revoke this as I forgot weak sets aren't 
>>>>>>> weak in the way they have to be in this case.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Michael
>>>>>>>
>>>>>>>> Am 17.09.2015 um 16:18 schrieb Michael Haupt 
>>>>>>>> <michael.haupt at oracle.com>:
>>>>>>>>
>>>>>>>> Hi Attila,
>>>>>>>>
>>>>>>>> lower-case thumbs up!
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>> Am 17.09.2015 um 16:14 schrieb Attila Szegedi 
>>>>>>>>> <attila.szegedi at oracle.com>:
>>>>>>>>>
>>>>>>>>> Please review JDK-8136700 "Make sure 
>>>>>>>>> Context.anonymousHostClasses doesn't grow unbounded" at 
>>>>>>>>> <http://cr.openjdk.java.net/~attila/8136700/webrev.jdk9> for 
>>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8136700>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Attila.
>>>>>>> -- 
>>>>>>>
>>>>>>> <http://www.oracle.com/>
>>>>>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>>>>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>>>>>> Oracle Java Platform Group | LangTools Team | Nashorn
>>>>>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 
>>>>>>> Potsdam, Germany
>>>>>>> <http://www.oracle.com/commitment>    Oracle is committed to 
>>>>>>> developing practices and products that help protect the environment
>>>>>>>
>>>
>>
>


From sundararajan.athijegannathan at oracle.com  Fri Sep 18 16:39:23 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 18 Sep 2015 22:09:23 +0530
Subject: Review request for JDK-8135190: Method code too large in Babel
	browser.js script
In-Reply-To: <55FC133F.2050001@oracle.com>
References: <55FBE15A.5090806@oracle.com>
	<971C8EBD-D94B-43E1-A6EA-5AB0B41BA10E@oracle.com>
	<55FC0D02.2090905@oracle.com> <55FC133F.2050001@oracle.com>
Message-ID: <55FC3E3B.9000105@oracle.com>

+1

On 9/18/2015 7:05 PM, Hannes Wallnoefer wrote:
> Thanks for the reviews!
>
> I've uploaded a new webrev with all the changes you suggested. For 
> Type.typeFor I added a call to a new Context.isStructureClass method. 
> Note that structure classes are direct subclasses of ScriptObject, so 
> we use Type.SCRIPT_OBJECT in that case.
>
> http://cr.openjdk.java.net/~hannesw/8135190/webrev.01/
>
> Hannes
>
> Am 2015-09-18 um 15:09 schrieb Sundararajan Athijegannathan:
>> * On naming: how about getHigh and getLow in Splittable?
>>
>> * Types.typeFor can fallback to name pattern (JO subclass) and use 
>> JO.class (when getting CNFE) or context's sharedloader to do 
>> Class.forName
>>
>> Other than that +1
>>
>> -Sundar
>>
>> On 9/18/2015 6:33 PM, Attila Szegedi wrote:
>>> Few minor remarks:
>>>
>>> * AssignSymbols.isSplitLiteral uses !(splitRanges == null || 
>>> splitRanges.isEmpty()) while everywhere else in the code the check 
>>> is (ranges != null).
>>> * loadSplitLiteral: seems like there's a stray comment: // 
>>> method.load(literalType, literalSlot);
>>> * Terminology: Splittable is described as a "marker interface? yet 
>>> it has a method.
>>>
>>> Other than these small things, +1.
>>>
>>> Attila.
>>>
>>>> On Sep 18, 2015, at 12:03 PM, Hannes Wallnoefer 
>>>> <hannes.wallnoefer at oracle.com> wrote:
>>>>
>>>> Please review JDK-8135190: Method code too large in Babel 
>>>> browser.js script:
>>>>
>>>> http://cr.openjdk.java.net/~hannesw/8135190/
>>>>
>>>> This makes object literals splittable. I tried to share as much 
>>>> code as possible with array literal splitting so I had to introduce 
>>>> a couple of new interfaces.
>>>>
>>>> Hannes
>>
>


From marcus at lagergren.net  Sun Sep 20 08:18:56 2015
From: marcus at lagergren.net (Marcus Lagergren)
Date: Sun, 20 Sep 2015 10:18:56 +0200
Subject: Review request for JDK-8134609: Allow constructors with same
	prototoype map to share the allocator map
In-Reply-To: <55F92CF7.3060201@oracle.com>
References: <55F2C6FD.7090804@oracle.com>
	<0606D015-2025-4A49-B09D-C34B39A0105E@oracle.com>
	<55F92CF7.3060201@oracle.com>
Message-ID: <FA70D6F7-7C53-4647-BA10-7A486E019090@lagergren.net>

Really great work, Hannes. +1 with Attila?s comments integrated.

/M

> On 16 Sep 2015, at 10:48, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> u suggested below I did some refactoring on the PropertyMap class, making more fields final to better reflect its immutable nature. I soon noticed that all the core fields (flags, field/spill boundaries, class name) could quite easily be made final except for the ne


From hannes.wallnoefer at oracle.com  Mon Sep 21 13:41:39 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 21 Sep 2015 15:41:39 +0200
Subject: Review request for JDK-8135190: Method code too large in Babel
	browser.js script
In-Reply-To: <55FC3E3B.9000105@oracle.com>
References: <55FBE15A.5090806@oracle.com>
	<971C8EBD-D94B-43E1-A6EA-5AB0B41BA10E@oracle.com>
	<55FC0D02.2090905@oracle.com> <55FC133F.2050001@oracle.com>
	<55FC3E3B.9000105@oracle.com>
Message-ID: <56000913.1060009@oracle.com>

Please review backport to 8u-dev.

I had to do a manual merge for ir/LiteralNode.java because 8u-dev does 
not have the parser API.

Thanks,
Hannes

Am 2015-09-18 um 18:39 schrieb Sundararajan Athijegannathan:
> +1
>
> On 9/18/2015 7:05 PM, Hannes Wallnoefer wrote:
>> Thanks for the reviews!
>>
>> I've uploaded a new webrev with all the changes you suggested. For 
>> Type.typeFor I added a call to a new Context.isStructureClass method. 
>> Note that structure classes are direct subclasses of ScriptObject, so 
>> we use Type.SCRIPT_OBJECT in that case.
>>
>> http://cr.openjdk.java.net/~hannesw/8135190/webrev.01/
>>
>> Hannes
>>
>> Am 2015-09-18 um 15:09 schrieb Sundararajan Athijegannathan:
>>> * On naming: how about getHigh and getLow in Splittable?
>>>
>>> * Types.typeFor can fallback to name pattern (JO subclass) and use 
>>> JO.class (when getting CNFE) or context's sharedloader to do 
>>> Class.forName
>>>
>>> Other than that +1
>>>
>>> -Sundar
>>>
>>> On 9/18/2015 6:33 PM, Attila Szegedi wrote:
>>>> Few minor remarks:
>>>>
>>>> * AssignSymbols.isSplitLiteral uses !(splitRanges == null || 
>>>> splitRanges.isEmpty()) while everywhere else in the code the check 
>>>> is (ranges != null).
>>>> * loadSplitLiteral: seems like there's a stray comment: // 
>>>> method.load(literalType, literalSlot);
>>>> * Terminology: Splittable is described as a "marker interface? yet 
>>>> it has a method.
>>>>
>>>> Other than these small things, +1.
>>>>
>>>> Attila.
>>>>
>>>>> On Sep 18, 2015, at 12:03 PM, Hannes Wallnoefer 
>>>>> <hannes.wallnoefer at oracle.com> wrote:
>>>>>
>>>>> Please review JDK-8135190: Method code too large in Babel 
>>>>> browser.js script:
>>>>>
>>>>> http://cr.openjdk.java.net/~hannesw/8135190/
>>>>>
>>>>> This makes object literals splittable. I tried to share as much 
>>>>> code as possible with array literal splitting so I had to 
>>>>> introduce a couple of new interfaces.
>>>>>
>>>>> Hannes
>>>
>>
>


From hannes.wallnoefer at oracle.com  Mon Sep 21 13:52:19 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 21 Sep 2015 15:52:19 +0200
Subject: Review request for JDK-8135190: Method code too large in Babel
	browser.js script
In-Reply-To: <56000913.1060009@oracle.com>
References: <55FBE15A.5090806@oracle.com>
	<971C8EBD-D94B-43E1-A6EA-5AB0B41BA10E@oracle.com>
	<55FC0D02.2090905@oracle.com> <55FC133F.2050001@oracle.com>
	<55FC3E3B.9000105@oracle.com> <56000913.1060009@oracle.com>
Message-ID: <56000B93.8000107@oracle.com>

Please ignore the review request - hg import actually managed to apply 
the patch cleanly.

Sorry for the inconvenience!

Hannes

Am 2015-09-21 um 15:41 schrieb Hannes Wallnoefer:
> Please review backport to 8u-dev.
>
> I had to do a manual merge for ir/LiteralNode.java because 8u-dev does 
> not have the parser API.
>
> Thanks,
> Hannes
>
> Am 2015-09-18 um 18:39 schrieb Sundararajan Athijegannathan:
>> +1
>>
>> On 9/18/2015 7:05 PM, Hannes Wallnoefer wrote:
>>> Thanks for the reviews!
>>>
>>> I've uploaded a new webrev with all the changes you suggested. For 
>>> Type.typeFor I added a call to a new Context.isStructureClass 
>>> method. Note that structure classes are direct subclasses of 
>>> ScriptObject, so we use Type.SCRIPT_OBJECT in that case.
>>>
>>> http://cr.openjdk.java.net/~hannesw/8135190/webrev.01/
>>>
>>> Hannes
>>>
>>> Am 2015-09-18 um 15:09 schrieb Sundararajan Athijegannathan:
>>>> * On naming: how about getHigh and getLow in Splittable?
>>>>
>>>> * Types.typeFor can fallback to name pattern (JO subclass) and use 
>>>> JO.class (when getting CNFE) or context's sharedloader to do 
>>>> Class.forName
>>>>
>>>> Other than that +1
>>>>
>>>> -Sundar
>>>>
>>>> On 9/18/2015 6:33 PM, Attila Szegedi wrote:
>>>>> Few minor remarks:
>>>>>
>>>>> * AssignSymbols.isSplitLiteral uses !(splitRanges == null || 
>>>>> splitRanges.isEmpty()) while everywhere else in the code the check 
>>>>> is (ranges != null).
>>>>> * loadSplitLiteral: seems like there's a stray comment: // 
>>>>> method.load(literalType, literalSlot);
>>>>> * Terminology: Splittable is described as a "marker interface? yet 
>>>>> it has a method.
>>>>>
>>>>> Other than these small things, +1.
>>>>>
>>>>> Attila.
>>>>>
>>>>>> On Sep 18, 2015, at 12:03 PM, Hannes Wallnoefer 
>>>>>> <hannes.wallnoefer at oracle.com> wrote:
>>>>>>
>>>>>> Please review JDK-8135190: Method code too large in Babel 
>>>>>> browser.js script:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~hannesw/8135190/
>>>>>>
>>>>>> This makes object literals splittable. I tried to share as much 
>>>>>> code as possible with array literal splitting so I had to 
>>>>>> introduce a couple of new interfaces.
>>>>>>
>>>>>> Hannes
>>>>
>>>
>>
>


From sundararajan.athijegannathan at oracle.com  Mon Sep 21 14:13:38 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 21 Sep 2015 19:43:38 +0530
Subject: RFR 8136832: property_delete.js tests be moved out from
	currently-failing
Message-ID: <56001092.4030204@oracle.com>

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

Thanks,
-Sundar

From attila.szegedi at oracle.com  Mon Sep 21 14:46:21 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 21 Sep 2015 16:46:21 +0200
Subject: RFR 8136832: property_delete.js tests be moved out from
	currently-failing
In-Reply-To: <56001092.4030204@oracle.com>
References: <56001092.4030204@oracle.com>
Message-ID: <ACBC1B48-BE90-4783-80B1-25E4436D5FAE@oracle.com>

+1

> On Sep 21, 2015, at 4:13 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8136832/ for https://bugs.openjdk.java.net/browse/JDK-8136832
> 
> Thanks,
> -Sundar


From marcus at lagergren.net  Tue Sep 22 05:11:40 2015
From: marcus at lagergren.net (Marcus Lagergren)
Date: Tue, 22 Sep 2015 07:11:40 +0200
Subject: RFR 8136832: property_delete.js tests be moved out from
	currently-failing
In-Reply-To: <56001092.4030204@oracle.com>
References: <56001092.4030204@oracle.com>
Message-ID: <66B78C5B-EF44-4659-87B0-AD473ECD27FF@lagergren.net>

+1

> On 21 Sep 2015, at 16:13, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8136832/ for https://bugs.openjdk.java.net/browse/JDK-8136832
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Tue Sep 22 07:09:30 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 22 Sep 2015 09:09:30 +0200
Subject: RFR 8136832: property_delete.js tests be moved out from
	currently-failing
In-Reply-To: <56001092.4030204@oracle.com>
References: <56001092.4030204@oracle.com>
Message-ID: <5600FEAA.1070109@oracle.com>

+1

Am 2015-09-21 um 16:13 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8136832/ for 
> https://bugs.openjdk.java.net/browse/JDK-8136832
>
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Tue Sep 22 07:58:21 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 22 Sep 2015 13:28:21 +0530
Subject: RFR 8136894: test/script/currently-failing/gettersetter.js passes,
	move it out of currently-failing tests
Message-ID: <56010A1D.3060508@oracle.com>

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

-Sundar

From michael.haupt at oracle.com  Tue Sep 22 08:04:55 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Tue, 22 Sep 2015 10:04:55 +0200
Subject: RFR 8136894: test/script/currently-failing/gettersetter.js passes,
	move it out of currently-failing tests
In-Reply-To: <56010A1D.3060508@oracle.com>
References: <56010A1D.3060508@oracle.com>
Message-ID: <8D57BF5D-5991-410E-A263-F040160C809C@oracle.com>

Hi Sundar,

lower-casee thumbs up.

Best,

Michael

> Am 22.09.2015 um 09:58 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>:
> 
> Please review http://cr.openjdk.java.net/~sundar/8136894/ for https://bugs.openjdk.java.net/browse/JDK-8136894
> 
> -Sundar

-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment


From hannes.wallnoefer at oracle.com  Tue Sep 22 08:30:38 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 22 Sep 2015 10:30:38 +0200
Subject: RFR 8136894: test/script/currently-failing/gettersetter.js
	passes, move it out of currently-failing tests
In-Reply-To: <56010A1D.3060508@oracle.com>
References: <56010A1D.3060508@oracle.com>
Message-ID: <560111AE.2040507@oracle.com>

+1

Am 2015-09-22 um 09:58 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8136894/ for 
> https://bugs.openjdk.java.net/browse/JDK-8136894
>
> -Sundar


From marcus at lagergren.net  Wed Sep 23 12:14:14 2015
From: marcus at lagergren.net (Marcus Lagergren)
Date: Wed, 23 Sep 2015 14:14:14 +0200
Subject: RFR 8136894: test/script/currently-failing/gettersetter.js passes,
	move it out of currently-failing tests
In-Reply-To: <56010A1D.3060508@oracle.com>
References: <56010A1D.3060508@oracle.com>
Message-ID: <F47AEADC-61FE-4A50-88C6-8F85F6892651@lagergren.net>

+1

> On 22 Sep 2015, at 09:58, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8136894/ for https://bugs.openjdk.java.net/browse/JDK-8136894
> 
> -Sundar


From axeld at pinc-software.de  Thu Sep 24 11:02:00 2015
From: axeld at pinc-software.de (=?UTF-8?Q?Axel_D=c3=b6rfler?=)
Date: Thu, 24 Sep 2015 13:02:00 +0200
Subject: Default methods
Message-ID: <5603D828.6000108@pinc-software.de>

Hi there,

I'm currently trying to implement an interface from JavaScript that has 
default implementations. Unfortunately, it's not working.

That's the code at the Java side:
     interface A {
         default void a() {
             System.out.println("a");
         }
     }
     interface B extends A {
         default void b() {
             System.out.println("b");
         }
         default void c() {
             System.out.println("c");
         }
     }

And that's the one in JavaScript:
     var B = Java.type("my.package.B");
     new B({
	b: function() {
		doMyStuff();
	}
     });

If I invoke a() on the new object, I get the following error:
     java.lang.IncompatibleClassChangeError: Interface method reference: 
my.package.A.a(;)Z, is in an indirect superinterface of 
my.package.B$$NashornJavaAdapter

The same works just fine in Java, so I assume that this is an actual bug 
in the Nashorn implementation, as I can invoke c() without a problem.
Is this known or even accepted behavior?

Also, when I create a class of this:
public class C implements B {
}

I cannot use the following:
     var C = Java.type("my.package.C");
     new C({
         b: function() {
	    doMyStuff();
	}
     });

I get this error:
javax.script.ScriptException: TypeError: Can not construct my.package.C 
with the passed arguments; they do not match any of its constructor 
signatures. in <eval> at line number 2

Removing the default methods, all is working as expected.

Kind regards,
    Axel D?rfler.

From attila.szegedi at oracle.com  Thu Sep 24 13:20:07 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 24 Sep 2015 15:20:07 +0200
Subject: Review request for JDK-8136700: Make sure
	Context.anonymousHostClasses doesn't grow unbounded
In-Reply-To: <55FC1C20.4010307@oracle.com>
References: <50C87084-0287-4409-9831-7D9AB82F04E0@oracle.com>
	<D2C6183D-67A1-4712-99EF-4292B2BC49E1@oracle.com>
	<9B8D829E-C826-4E27-A30A-3083429C20DB@oracle.com>
	<87899B8D-83EC-45B1-B8C7-423B225A35D3@oracle.com>
	<55FB91A2.1090700@oracle.com>
	<AB164581-6841-49D3-B44E-40CD6873751D@oracle.com>
	<55FBFE24.20905@oracle.com> <55FC1528.4060807@oracle.com>
	<55FC18A6.2080204@oracle.com> <55FC1C20.4010307@oracle.com>
Message-ID: <CFDFA568-84D5-4136-9B28-9EA6DDEB3127@oracle.com>

Well, you?re right in the sense that the method is, in fact, manipulating a non-threadsafe data structure, and it is probably better to have it explicitly synchronized than relying on the fact that all its callers are synchronized too. I mean, it?s private method calling private method, so we can have a closed-world assumption that the synchronization is unnecessary, but maybe this is one of those better safe than sorry situations. I?ll just hope that this is one of those assumptions that HotSpot can prove and optimize away :-)

Do I have the +1 if I add the synchronized keyword?

> On Sep 18, 2015, at 4:13 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Am 2015-09-18 um 15:59 schrieb Sundararajan Athijegannathan:
>> I presume it is for code clarity sake? That is a private method in that class called only from the other synchronized method. How about just adding an assert using Thread.holdsLock?
> 
> Well it's mostly as a guard for potential changes down the road. Nothing says "this method needs to be synchronized" better than just making it synchronized IMO. :)
> 
> Hannes
> 
>> -Sundar
>> 
>> On 9/18/2015 7:14 PM, Hannes Wallnoefer wrote:
>>> Shouldn't the methods modifying the map also be synchronized, even if we know they are (currently) only called from a synchronized method?
>>> 
>>> Otherwise looks good.
>>> 
>>> Hannes
>>> 
>>> Am 2015-09-18 um 14:05 schrieb Sundararajan Athijegannathan:
>>>> +1
>>>> 
>>>> On 9/18/2015 3:24 PM, Attila Szegedi wrote:
>>>>>> On Sep 18, 2015, at 6:22 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>>>>> 
>>>>>> * Context.compile is synchronized and so there is no need for ConcurrentHashMap + concurrency related comment.
>>>>> You?re right, I removed them. I updated webrev in-place.
>>>>> 
>>>>>> * Map.remove(Object, Object) is used which is since jdk 1.8. If we have to backport this change to jdk8u (where jdk7 is used as JAVA_HOME to build/test), we've to take care of this.
>>>>> If we backport, this will show up as a compile error, so we?ll adjust then. I?d rather run another round of a short review then than have a less efficient construct in 9 codebase.
>>>>> 
>>>>> Thanks,
>>>>>   Attila.
>>>>> 
>>>>>> -Sundar
>>>>>> 
>>>>>> On 9/17/2015 9:07 PM, Attila Szegedi wrote:
>>>>>>> Indeed, that?s correct. A new webrev is available for review at <http://cr.openjdk.java.net/~attila/8136700/webrev.01.jdk9> that manually handles removal of cleared entries.
>>>>>>> 
>>>>>>> Attila.
>>>>>>> 
>>>>>>>> On Sep 17, 2015, at 4:29 PM, Michael Haupt <michael.haupt at oracle.com> wrote:
>>>>>>>> 
>>>>>>>> Hi again,
>>>>>>>> 
>>>>>>>> no sorry; I have to revoke this as I forgot weak sets aren't weak in the way they have to be in this case.
>>>>>>>> 
>>>>>>>> Best,
>>>>>>>> 
>>>>>>>> Michael
>>>>>>>> 
>>>>>>>>> Am 17.09.2015 um 16:18 schrieb Michael Haupt <michael.haupt at oracle.com>:
>>>>>>>>> 
>>>>>>>>> Hi Attila,
>>>>>>>>> 
>>>>>>>>> lower-case thumbs up!
>>>>>>>>> 
>>>>>>>>> Best,
>>>>>>>>> 
>>>>>>>>> Michael
>>>>>>>>> 
>>>>>>>>>> Am 17.09.2015 um 16:14 schrieb Attila Szegedi <attila.szegedi at oracle.com>:
>>>>>>>>>> 
>>>>>>>>>> Please review JDK-8136700 "Make sure Context.anonymousHostClasses doesn't grow unbounded" at <http://cr.openjdk.java.net/~attila/8136700/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8136700>
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> Attila.
>>>>>>>> -- 
>>>>>>>> 
>>>>>>>> <http://www.oracle.com/>
>>>>>>>> Dr. Michael Haupt | Principal Member of Technical Staff
>>>>>>>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>>>>>>>> Oracle Java Platform Group | LangTools Team | Nashorn
>>>>>>>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
>>>>>>>> <http://www.oracle.com/commitment>    Oracle is committed to developing practices and products that help protect the environment
>>>>>>>> 
>>>> 
>>> 
>> 
> 


From attila.szegedi at oracle.com  Thu Sep 24 13:36:34 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 24 Sep 2015 15:36:34 +0200
Subject: Default methods
In-Reply-To: <5603D828.6000108@pinc-software.de>
References: <5603D828.6000108@pinc-software.de>
Message-ID: <FEA5DE45-E8DC-476C-8813-E7C7F39948C3@oracle.com>

Axel,

thanks for a very comprehensive demonstration of the problem. I agree these should work; I?ll investigate to see what?s up with them. I raised https://bugs.openjdk.java.net/browse/JDK-8137093 <https://bugs.openjdk.java.net/browse/JDK-8137093> to track the issue.

Thanks,
  Attila.

> On Sep 24, 2015, at 1:02 PM, Axel D?rfler <axeld at pinc-software.de> wrote:
> 
> Hi there,
> 
> I'm currently trying to implement an interface from JavaScript that has default implementations. Unfortunately, it's not working.
> 
> That's the code at the Java side:
>    interface A {
>        default void a() {
>            System.out.println("a");
>        }
>    }
>    interface B extends A {
>        default void b() {
>            System.out.println("b");
>        }
>        default void c() {
>            System.out.println("c");
>        }
>    }
> 
> And that's the one in JavaScript:
>    var B = Java.type("my.package.B");
>    new B({
> 	b: function() {
> 		doMyStuff();
> 	}
>    });
> 
> If I invoke a() on the new object, I get the following error:
>    java.lang.IncompatibleClassChangeError: Interface method reference: my.package.A.a(;)Z, is in an indirect superinterface of my.package.B$$NashornJavaAdapter
> 
> The same works just fine in Java, so I assume that this is an actual bug in the Nashorn implementation, as I can invoke c() without a problem.
> Is this known or even accepted behavior?
> 
> Also, when I create a class of this:
> public class C implements B {
> }
> 
> I cannot use the following:
>    var C = Java.type("my.package.C");
>    new C({
>        b: function() {
> 	    doMyStuff();
> 	}
>    });
> 
> I get this error:
> javax.script.ScriptException: TypeError: Can not construct my.package.C with the passed arguments; they do not match any of its constructor signatures. in <eval> at line number 2
> 
> Removing the default methods, all is working as expected.
> 
> Kind regards,
>   Axel D?rfler.


From axeld at pinc-software.de  Thu Sep 24 14:07:15 2015
From: axeld at pinc-software.de (=?UTF-8?Q?Axel_D=c3=b6rfler?=)
Date: Thu, 24 Sep 2015 16:07:15 +0200
Subject: Default methods
In-Reply-To: <FEA5DE45-E8DC-476C-8813-E7C7F39948C3@oracle.com>
References: <5603D828.6000108@pinc-software.de>
	<FEA5DE45-E8DC-476C-8813-E7C7F39948C3@oracle.com>
Message-ID: <56040393.9000702@pinc-software.de>

Hi Attila,

Am 24/09/2015 um 15:36 schrieb Attila Szegedi:
> thanks for a very comprehensive demonstration of the problem. I agree
> these should work; I?ll investigate to see what?s up with them. I raised
> https://bugs.openjdk.java.net/browse/JDK-8137093 to track the issue.

Thanks! Looking forward to see those fixed!

Kind regards,
    Axel D?rfler.


From hannes.wallnoefer at oracle.com  Thu Sep 24 14:44:57 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Thu, 24 Sep 2015 16:44:57 +0200
Subject: RFR 8134941: Implement ES6 template literal support
In-Reply-To: <55E87A0D.8020608@oracle.com>
References: <55E87A0D.8020608@oracle.com>
Message-ID: <56040C69.7010903@oracle.com>

Hi Andreas,

Thanks for the contribution, and sorry for the long time it took to get 
back to you.

I like the way you implemented this feature, the code looks very good.  
Comments inlined below.

Am 2015-09-03 um 18:49 schrieb Andreas Woess:
> Template literals are always scanned as a whole, quote-to-quote (as 
> with EditStringLexer). This turned out to be a problem with embedded 
> functions in expressions and lazy/optimistic compilation on: 
> Parser#skipFunctionBody would skip over the body and restart lexing at 
> the RBRACE, forgetting about the embedding string context. I've worked 
> around this in skipFunctionBody by skipping over to the RBRACE 
> directly if it is already in the token stream (which it is because 
> we've already scanned to the end quote).

It took me some time to figure this out. Maybe some more explanatory 
comments would be good. Does this also apply in other cases?

>
> Outstanding correctness issues not dealt with:
> * 12.2.9.3 GetTemplateObject stipulates that the returned template 
> object be cached and unique. I don't know why you'd want the spec to 
> demand caching rather than allow it (functionally it does not make a 
> difference, but you could observe it not being cached in a test).

Actually object identity can be observed by the tag function, and that 
was the reason for the committee to specify this. They chose caching of 
objects for performance reasons. The discussion can be found here:

https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-11/nov-18.md#48-template-literal-call-site-object-caching

Even though it's a minor issue we should follow the spec here.

> * 12.2.9.5 Evaluation: string concatenation using + is slightly 
> off-spec. There are two way to solve this: (a) wrap the expressions in 
> a ToString UnaryExpression (or RuntimeCall) or (b) generate a call to 
> concat with interleaved string and expression arguments.
>

The difference is between ToPrimitive being called with Number hint vs. 
String hint. This should not make a difference for the vast share of 
objects (all except those having a custom valueOf function I think), but 
it's something we should also get right. I've started experimenting with 
the solutions you suggested, I think adding a ToString conversion 
wrapper of some kind would be best.

All in all I think your patch looks good. We can probably file the 
issues as separate bugs and fix them later. One thing I want to do is 
add some more tests. Although your test script covers a lot of stuff 
(for its size) I would like to add a bit to it.

Thanks,
Hannes






From attila.szegedi at oracle.com  Thu Sep 24 15:16:52 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Thu, 24 Sep 2015 17:16:52 +0200
Subject: Review request for JDK-8134490: Dead var statement evacuation
	incorrectly descends into nested functions
Message-ID: <0F433B65-022B-479A-B090-9559E98C4B6C@oracle.com>

Please review JDK-8134490 "Dead var statement evacuation incorrectly descends into nested functions" at <http://cr.openjdk.java.net/~attila/8134490/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134490>

The essential change is the enterFunctionNode in Lower that returns false to avoid descending into nested functions.

The change in FindScopeDepths is actually a code tightening; I was poking in there for the bug first, and I realized that it can be streamlined; !compiler.isOnDemandCompilation is always true, and instead of using enterDefault with instanceof IdentNode we can just use enterIdentNode?

Thanks,
  Attila.

From lev at serebryakov.spb.ru  Thu Sep 24 15:33:17 2015
From: lev at serebryakov.spb.ru (Lev Serebryakov)
Date: Thu, 24 Sep 2015 18:33:17 +0300
Subject: How could I inject new buil-iin constructors / objects to nashorn?
Message-ID: <560417BD.10308@serebryakov.spb.ru>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


 I'm writing some framework in Java, and want to use JavaScript as
glue/DSL language for it (think about GNU Radio with C++ core classes
and Pythjon glue, for example).

 This framework contains meta-model for its classes and objects,
implemented as Java annotations. It helps to generate different
boilerplate code automatically and hide some tedious technical details
from framework's users.

 I want to export this meta-model to JavaScript (Nashorn) in most
efficient and JavaScript-idiomatic way. That is, I need built-in-like
constructors and objects, which is not exact reflection of Java
classes and objects, but reflection of my meta-model. Also, I want to
do it in runtime, not compile-time, as new classes (modules) for my
framework could be added by user and I don't want to force any
pre-processors and additional build steps. Of course, I could generate
code in runtime with ASM (it is used in framework anyway).

 What is proper way to do this? All documentation and examples shows
how to use Java classes and objects from JavaScript executed by
Nashorn, but it is direct mapping. Is here any good way to wrap my
meta-model for Nashorn to make it looks as JavaScript-native as
JavaScript's Number or String or Array?

 Other feature I want to have is to provide users way to implement new
modules (classes) for this framework, but without all these
annotations. Again, most samples shows how to make "Anonymous" class
in JavaScript (like "var i = new new java.util.Iterator({ ...});")
which looks not very JavaScript-friendly...

 Sorry, if this list is not suitable for such questions, but I cannot
find any other Nashorn-related mailing list and can not google answer
to my question on Internet, as all posts and articles about Nashorn
are very superficial.

- -- 
// Black Lion AKA Lev Serebryakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJWBBe9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePcSUQANP8ljdnnE7Lug+sn5S38cee
cKhBdQWqod/VzM3Ft90innbw+4HHuSTJpOw3LcxaRzskcRC7WSEvG7uJpRhmIWow
hOx521kCwmrprRee93eaJFJ+Szue3YBoIvcfHIJRglaljsiSt4DkdhjEJLkE+ct/
Dsit8KCy37UAR/sc82rhNM3Oa/hPNMvKi+C9LL5Eo/a5tffV7FLbGKcCoTHBp1eH
lq2HpnWVwCRLoL1YVuPmnrL/BDkkogr1YvCeM/TfWnM6EPnyDQq/Lbxckj2WPRJe
MUmtoCZ9rmlOCADn+8ag+yXnaeEG6+yj12K0HJJf9PP3PE/xXUe6nQmkQysVVJqj
hG2RwkOQxGsLCFiw9rlmHMems/axOCOd2u3GE7R51W9+Cc+G2Fb9vtnSf7kkYlUq
VNJiU8Tu2LnfaSN7gMmWBKMLUZXoxzueEbqO2P8katqwKusJB1RizF8Ev7pdvFgt
DbaKQW4JQIxNf8lG9Xj20rULTBazftd8rjsmUGt1hNHtjmd5oGKtso59epWR6bKY
c45keo1L3PVSnlXn9c2E/j2iwD2LrnIyYE4OzdkjvfQK2kvwE9Lj5Pm1BwZ04I3g
hicRnhaeey2oeafqeZMBN2VBqZjKmo2Ch38nwVTPU2PcbKc3UH6o6mIVRzTtDd7i
cin1TvpoN+ILR6r7uTLq
=wLD2
-----END PGP SIGNATURE-----

From sundararajan.athijegannathan at oracle.com  Fri Sep 25 09:11:42 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 25 Sep 2015 14:41:42 +0530
Subject: RFR 8137134: invokespecial on indirect super interface is generated
	by Java adapter generator
Message-ID: <56050FCE.2060205@oracle.com>

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

Thanks,
-Sundar

From sundararajan.athijegannathan at oracle.com  Fri Sep 25 09:13:56 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 25 Sep 2015 14:43:56 +0530
Subject: RFR 8137134: invokespecial on indirect super interface is
	generated by Java adapter generator
In-Reply-To: <56050FCE.2060205@oracle.com>
References: <56050FCE.2060205@oracle.com>
Message-ID: <56051054.6010806@oracle.com>

I'm piggybacking dyn:call text when called function is known to be a 
function. i.e., name of the function is not included when we know it is 
a script function (function name in dyn:call is used to report TypeError 
which won't happen in this case)

-Sundar

On 9/25/2015 2:41 PM, Sundararajan Athijegannathan wrote:
> Please review http://cr.openjdk.java.net/~sundar/8137134/ for 
> https://bugs.openjdk.java.net/browse/JDK-8137134
>
> Thanks,
> -Sundar


From attila.szegedi at oracle.com  Fri Sep 25 09:20:03 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 25 Sep 2015 11:20:03 +0200
Subject: RFR 8137134: invokespecial on indirect super interface is
	generated by Java adapter generator
In-Reply-To: <56051054.6010806@oracle.com>
References: <56050FCE.2060205@oracle.com> <56051054.6010806@oracle.com>
Message-ID: <E86992A5-26E2-4A22-A709-F7DD75302107@oracle.com>

+1 on both chances. Good work tracking this down quickly!

> On Sep 25, 2015, at 11:13 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> I'm piggybacking dyn:call text when called function is known to be a function. i.e., name of the function is not included when we know it is a script function (function name in dyn:call is used to report TypeError which won't happen in this case)
> 
> -Sundar
> 
> On 9/25/2015 2:41 PM, Sundararajan Athijegannathan wrote:
>> Please review http://cr.openjdk.java.net/~sundar/8137134/ for https://bugs.openjdk.java.net/browse/JDK-8137134
>> 
>> Thanks,
>> -Sundar
> 


From hannes.wallnoefer at oracle.com  Fri Sep 25 10:24:41 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 25 Sep 2015 12:24:41 +0200
Subject: Review request for JDK-8134490: Dead var statement evacuation
	incorrectly descends into nested functions
In-Reply-To: <0F433B65-022B-479A-B090-9559E98C4B6C@oracle.com>
References: <0F433B65-022B-479A-B090-9559E98C4B6C@oracle.com>
Message-ID: <560520E9.5050708@oracle.com>

+1

Am 2015-09-24 um 17:16 schrieb Attila Szegedi:
> Please review JDK-8134490 "Dead var statement evacuation incorrectly descends into nested functions" at <http://cr.openjdk.java.net/~attila/8134490/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134490>
>
> The essential change is the enterFunctionNode in Lower that returns false to avoid descending into nested functions.
>
> The change in FindScopeDepths is actually a code tightening; I was poking in there for the bug first, and I realized that it can be streamlined; !compiler.isOnDemandCompilation is always true, and instead of using enterDefault with instanceof IdentNode we can just use enterIdentNode?
>
> Thanks,
>    Attila.


From sundararajan.athijegannathan at oracle.com  Fri Sep 25 10:31:04 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 25 Sep 2015 16:01:04 +0530
Subject: How could I inject new buil-iin constructors / objects to nashorn?
In-Reply-To: <560417BD.10308@serebryakov.spb.ru>
References: <560417BD.10308@serebryakov.spb.ru>
Message-ID: <56052268.4030609@oracle.com>

Hi,

You may want to look at JSObject 
(https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/JSObject.html, 
https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/AbstractJSObject.html)

Simple example here -> 
https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-jsobject

If you want to do it in script itself (perhaps pre-loaded script for 
your model),  you can use JSAdapter.

Simple example here ->
https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-JSAdapterconstructor

Hope this helps,
-Sundar

On 9/24/2015 9:03 PM, Lev Serebryakov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>   I'm writing some framework in Java, and want to use JavaScript as
> glue/DSL language for it (think about GNU Radio with C++ core classes
> and Pythjon glue, for example).
>
>   This framework contains meta-model for its classes and objects,
> implemented as Java annotations. It helps to generate different
> boilerplate code automatically and hide some tedious technical details
> from framework's users.
>
>   I want to export this meta-model to JavaScript (Nashorn) in most
> efficient and JavaScript-idiomatic way. That is, I need built-in-like
> constructors and objects, which is not exact reflection of Java
> classes and objects, but reflection of my meta-model. Also, I want to
> do it in runtime, not compile-time, as new classes (modules) for my
> framework could be added by user and I don't want to force any
> pre-processors and additional build steps. Of course, I could generate
> code in runtime with ASM (it is used in framework anyway).
>
>   What is proper way to do this? All documentation and examples shows
> how to use Java classes and objects from JavaScript executed by
> Nashorn, but it is direct mapping. Is here any good way to wrap my
> meta-model for Nashorn to make it looks as JavaScript-native as
> JavaScript's Number or String or Array?
>
>   Other feature I want to have is to provide users way to implement new
> modules (classes) for this framework, but without all these
> annotations. Again, most samples shows how to make "Anonymous" class
> in JavaScript (like "var i = new new java.util.Iterator({ ...});")
> which looks not very JavaScript-friendly...
>
>   Sorry, if this list is not suitable for such questions, but I cannot
> find any other Nashorn-related mailing list and can not google answer
> to my question on Internet, as all posts and articles about Nashorn
> are very superficial.
>
> - -- 
> // Black Lion AKA Lev Serebryakov
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQJ8BAEBCgBmBQJWBBe9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
> QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePcSUQANP8ljdnnE7Lug+sn5S38cee
> cKhBdQWqod/VzM3Ft90innbw+4HHuSTJpOw3LcxaRzskcRC7WSEvG7uJpRhmIWow
> hOx521kCwmrprRee93eaJFJ+Szue3YBoIvcfHIJRglaljsiSt4DkdhjEJLkE+ct/
> Dsit8KCy37UAR/sc82rhNM3Oa/hPNMvKi+C9LL5Eo/a5tffV7FLbGKcCoTHBp1eH
> lq2HpnWVwCRLoL1YVuPmnrL/BDkkogr1YvCeM/TfWnM6EPnyDQq/Lbxckj2WPRJe
> MUmtoCZ9rmlOCADn+8ag+yXnaeEG6+yj12K0HJJf9PP3PE/xXUe6nQmkQysVVJqj
> hG2RwkOQxGsLCFiw9rlmHMems/axOCOd2u3GE7R51W9+Cc+G2Fb9vtnSf7kkYlUq
> VNJiU8Tu2LnfaSN7gMmWBKMLUZXoxzueEbqO2P8katqwKusJB1RizF8Ev7pdvFgt
> DbaKQW4JQIxNf8lG9Xj20rULTBazftd8rjsmUGt1hNHtjmd5oGKtso59epWR6bKY
> c45keo1L3PVSnlXn9c2E/j2iwD2LrnIyYE4OzdkjvfQK2kvwE9Lj5Pm1BwZ04I3g
> hicRnhaeey2oeafqeZMBN2VBqZjKmo2Ch38nwVTPU2PcbKc3UH6o6mIVRzTtDd7i
> cin1TvpoN+ILR6r7uTLq
> =wLD2
> -----END PGP SIGNATURE-----


From hannes.wallnoefer at oracle.com  Fri Sep 25 10:31:06 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 25 Sep 2015 12:31:06 +0200
Subject: RFR 8137134: invokespecial on indirect super interface is
	generated by Java adapter generator
In-Reply-To: <56051054.6010806@oracle.com>
References: <56050FCE.2060205@oracle.com> <56051054.6010806@oracle.com>
Message-ID: <5605226A.9040908@oracle.com>

+1

Am 2015-09-25 um 11:13 schrieb Sundararajan Athijegannathan:
> I'm piggybacking dyn:call text when called function is known to be a 
> function. i.e., name of the function is not included when we know it 
> is a script function (function name in dyn:call is used to report 
> TypeError which won't happen in this case)
>
> -Sundar
>
> On 9/25/2015 2:41 PM, Sundararajan Athijegannathan wrote:
>> Please review http://cr.openjdk.java.net/~sundar/8137134/ for 
>> https://bugs.openjdk.java.net/browse/JDK-8137134
>>
>> Thanks,
>> -Sundar
>


From attila.szegedi at oracle.com  Fri Sep 25 13:05:59 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 25 Sep 2015 15:05:59 +0200
Subject: Review request for JDK-8134488: var statement in if(false) block
	incorrectly evacuated into enclosing function
Message-ID: <06AA4F0D-0DCF-4422-8D9F-C930AD85931E@oracle.com>

Please review JDK-8134488 "var statement in if(false) block incorrectly evacuated into enclosing function" at <http://cr.openjdk.java.net/~attila/8134488/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134488>

Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Fri Sep 25 13:26:07 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 25 Sep 2015 15:26:07 +0200
Subject: Review request for JDK-8134488: var statement in if(false) block
	incorrectly evacuated into enclosing function
In-Reply-To: <06AA4F0D-0DCF-4422-8D9F-C930AD85931E@oracle.com>
References: <06AA4F0D-0DCF-4422-8D9F-C930AD85931E@oracle.com>
Message-ID: <56054B6F.6070906@oracle.com>

+1

Am 2015-09-25 um 15:05 schrieb Attila Szegedi:
> Please review JDK-8134488 "var statement in if(false) block incorrectly evacuated into enclosing function" at <http://cr.openjdk.java.net/~attila/8134488/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134488>
>
> Thanks,
>    Attila.


From marcus at lagergren.net  Fri Sep 25 14:21:34 2015
From: marcus at lagergren.net (Marcus Lagergren)
Date: Fri, 25 Sep 2015 16:21:34 +0200
Subject: Review request for JDK-8134490: Dead var statement evacuation
	incorrectly descends into nested functions
In-Reply-To: <0F433B65-022B-479A-B090-9559E98C4B6C@oracle.com>
References: <0F433B65-022B-479A-B090-9559E98C4B6C@oracle.com>
Message-ID: <D8178754-06A5-48E7-B6DE-8061D96BAEFE@lagergren.net>

Nice. +1


> On 24 Sep 2015, at 17:16, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Please review JDK-8134490 "Dead var statement evacuation incorrectly descends into nested functions" at <http://cr.openjdk.java.net/~attila/8134490/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134490>
> 
> The essential change is the enterFunctionNode in Lower that returns false to avoid descending into nested functions.
> 
> The change in FindScopeDepths is actually a code tightening; I was poking in there for the bug first, and I realized that it can be streamlined; !compiler.isOnDemandCompilation is always true, and instead of using enterDefault with instanceof IdentNode we can just use enterIdentNode?
> 
> Thanks,
>  Attila.


From sundararajan.athijegannathan at oracle.com  Fri Sep 25 15:26:11 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 25 Sep 2015 20:56:11 +0530
Subject: [8u] approval request for 8137134: invokespecial on indirect super
	interface is generated by Java adapter generator
Message-ID: <56056793.9000107@oracle.com>

Please approve.

bug: https://bugs.openjdk.java.net/browse/JDK-8137134
jdk9 review thread: 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005314.html
jdk8u webrev: http://cr.openjdk.java.net/~sundar/8137134/8u/webrev.00/

Apart from modular source layout difference, I had to make a slight 
change in makefiles to compile tests with -source 1.8 (so that test 
using "default" method can be compiled).

Thanks,
-Sundar

From cblackburn at netsuite.com  Fri Sep 25 15:33:48 2015
From: cblackburn at netsuite.com (Blackburn, Clinton)
Date: Fri, 25 Sep 2015 15:33:48 +0000
Subject: Current Level of ES6 Feature Support
Message-ID: <C6AD46A4-8D97-4C95-BCFF-8F84AEAF27DA@netsuite.com>

<html><bodyHello, please pardon me if this is the wrong mailing list for this question. 

Is there any place I can look that tracks ES6 Harmony feature completeness, and possibly roadmap for said support?

Thank you,
-Clinton 


NOTICE: This email and any attachments may contain confidential and proprietary information of NetSuite Inc. and is for the sole use of the intended recipient for the stated purpose. Any improper use or distribution is prohibited. If you are not the intended recipient, please notify the sender; do not review, copy or distribute; and promptly delete or destroy all transmitted information. Please note that all communications and information transmitted through this email system may be monitored by NetSuite or its agents and that all incoming email is automatically scanned by a third party spam and filtering service

</body></html>

From attila.szegedi at oracle.com  Fri Sep 25 15:40:49 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 25 Sep 2015 17:40:49 +0200
Subject: [8u] approval request for 8137134: invokespecial on indirect
	super interface is generated by Java adapter generator
In-Reply-To: <56056793.9000107@oracle.com>
References: <56056793.9000107@oracle.com>
Message-ID: <F0E5C19E-2B75-4769-B98F-0FE143072E7A@oracle.com>

+1 on backport changes

> On Sep 25, 2015, at 5:26 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please approve.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8137134
> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005314.html
> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8137134/8u/webrev.00/
> 
> Apart from modular source layout difference, I had to make a slight change in makefiles to compile tests with -source 1.8 (so that test using "default" method can be compiled).
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Fri Sep 25 15:43:50 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Fri, 25 Sep 2015 17:43:50 +0200
Subject: [8u] approval request for 8137134: invokespecial on indirect
	super interface is generated by Java adapter generator
In-Reply-To: <F0E5C19E-2B75-4769-B98F-0FE143072E7A@oracle.com>
References: <56056793.9000107@oracle.com>
	<F0E5C19E-2B75-4769-B98F-0FE143072E7A@oracle.com>
Message-ID: <56056BB6.3020509@oracle.com>

+1 from me as well.

Am 2015-09-25 um 17:40 schrieb Attila Szegedi:
> +1 on backport changes
>
>> On Sep 25, 2015, at 5:26 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>
>> Please approve.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8137134
>> jdk9 review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005314.html
>> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8137134/8u/webrev.00/
>>
>> Apart from modular source layout difference, I had to make a slight change in makefiles to compile tests with -source 1.8 (so that test using "default" method can be compiled).
>>
>> Thanks,
>> -Sundar


From sundararajan.athijegannathan at oracle.com  Fri Sep 25 15:49:47 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 25 Sep 2015 21:19:47 +0530
Subject: Review request for JDK-8134488: var statement in if(false) block
	incorrectly evacuated into enclosing function
Message-ID: <56056D1B.8040805@oracle.com>

+1 for 
http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005320.html

PS. Deleted the original request email inadvertently.

-Sundar

From david.buck at oracle.com  Fri Sep 25 16:01:45 2015
From: david.buck at oracle.com (david buck)
Date: Sat, 26 Sep 2015 01:01:45 +0900
Subject: [8u] approval request for 8137134: invokespecial on indirect
	super interface is generated by Java adapter generator
In-Reply-To: <56056BB6.3020509@oracle.com>
References: <56056793.9000107@oracle.com>
	<F0E5C19E-2B75-4769-B98F-0FE143072E7A@oracle.com>
	<56056BB6.3020509@oracle.com>
Message-ID: <56056FE9.20107@oracle.com>

Approved.

Cheers,
-Buck

On 2015/09/26 0:43, Hannes Wallnoefer wrote:
> +1 from me as well.
>
> Am 2015-09-25 um 17:40 schrieb Attila Szegedi:
>> +1 on backport changes
>>
>>> On Sep 25, 2015, at 5:26 PM, Sundararajan Athijegannathan
>>> <sundararajan.athijegannathan at oracle.com> wrote:
>>>
>>> Please approve.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8137134
>>> jdk9 review thread:
>>> http://mail.openjdk.java.net/pipermail/nashorn-dev/2015-September/005314.html
>>>
>>> jdk8u webrev: http://cr.openjdk.java.net/~sundar/8137134/8u/webrev.00/
>>>
>>> Apart from modular source layout difference, I had to make a slight
>>> change in makefiles to compile tests with -source 1.8 (so that test
>>> using "default" method can be compiled).
>>>
>>> Thanks,
>>> -Sundar
>

From attila.szegedi at oracle.com  Fri Sep 25 16:54:03 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Fri, 25 Sep 2015 18:54:03 +0200
Subject: Review request for JDK-8134502: introduce abstraction for basic
	NodeVisitor usage
Message-ID: <B498AFF4-6EAE-4E32-88BE-971788E28E17@oracle.com>

Please review JDK-8134502 "introduce abstraction for basic NodeVisitor usage" at <http://cr.openjdk.java.net/~attila/8134502/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134502>

Thanks,
  Attila.

From sundararajan.athijegannathan at oracle.com  Fri Sep 25 17:01:29 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 25 Sep 2015 22:31:29 +0530
Subject: Review request for JDK-8134502: introduce abstraction for basic
	NodeVisitor usage
In-Reply-To: <B498AFF4-6EAE-4E32-88BE-971788E28E17@oracle.com>
References: <B498AFF4-6EAE-4E32-88BE-971788E28E17@oracle.com>
Message-ID: <56057DE9.4030209@oracle.com>

+1

On 9/25/2015 10:24 PM, Attila Szegedi wrote:
> Please review JDK-8134502 "introduce abstraction for basic NodeVisitor usage" at <http://cr.openjdk.java.net/~attila/8134502/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134502>
>
> Thanks,
>    Attila.


From marcus at lagergren.net  Sun Sep 27 10:05:07 2015
From: marcus at lagergren.net (Marcus Lagergren)
Date: Sun, 27 Sep 2015 12:05:07 +0200
Subject: Review request for JDK-8134502: introduce abstraction for basic
	NodeVisitor usage
In-Reply-To: <B498AFF4-6EAE-4E32-88BE-971788E28E17@oracle.com>
References: <B498AFF4-6EAE-4E32-88BE-971788E28E17@oracle.com>
Message-ID: <CA33B694-3387-4B69-8741-CAC1C0F6FA9F@lagergren.net>

+1

> On 25 Sep 2015, at 18:54, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Please review JDK-8134502 "introduce abstraction for basic NodeVisitor usage" at <http://cr.openjdk.java.net/~attila/8134502/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134502>
> 
> Thanks,
>  Attila.


From attila.szegedi at oracle.com  Mon Sep 28 06:54:29 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 28 Sep 2015 08:54:29 +0200
Subject: Review request for JDK-8134502: introduce abstraction for basic
	NodeVisitor usage
In-Reply-To: <CA33B694-3387-4B69-8741-CAC1C0F6FA9F@lagergren.net>
References: <B498AFF4-6EAE-4E32-88BE-971788E28E17@oracle.com>
	<CA33B694-3387-4B69-8741-CAC1C0F6FA9F@lagergren.net>
Message-ID: <F6C6ABB0-7131-4F91-A9CD-F88186F4DBA3@oracle.com>

Thanks for the review folks; can I quickly get a review for the 8u-dev backport at <http://cr.openjdk.java.net/~attila/8134502/webrev.jdk8u-dev>? 

The changes from jdk9 are:
- Parser API changes are omitted
- RecompilableScriptFunctionData.java Hunk #2 failed to apply solely because its context is different ("IdentityHashMap<Symbol, Boolean>? in 8 vs. "IdentityHashMap<>" in 9 on the line preceding the change).

Thanks,
  Attila.

> On Sep 27, 2015, at 12:05 PM, Marcus Lagergren <marcus at lagergren.net> wrote:
> 
> +1
> 
>> On 25 Sep 2015, at 18:54, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>> 
>> Please review JDK-8134502 "introduce abstraction for basic NodeVisitor usage" at <http://cr.openjdk.java.net/~attila/8134502/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134502>
>> 
>> Thanks,
>> Attila.
> 


From sundararajan.athijegannathan at oracle.com  Mon Sep 28 07:33:49 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 28 Sep 2015 13:03:49 +0530
Subject: Review request for JDK-8134502: introduce abstraction for basic
	NodeVisitor usage
In-Reply-To: <F6C6ABB0-7131-4F91-A9CD-F88186F4DBA3@oracle.com>
References: <B498AFF4-6EAE-4E32-88BE-971788E28E17@oracle.com>
	<CA33B694-3387-4B69-8741-CAC1C0F6FA9F@lagergren.net>
	<F6C6ABB0-7131-4F91-A9CD-F88186F4DBA3@oracle.com>
Message-ID: <5608ED5D.80300@oracle.com>

+1 on backport changes..


On 9/28/2015 12:24 PM, Attila Szegedi wrote:
> Thanks for the review folks; can I quickly get a review for the 8u-dev backport at <http://cr.openjdk.java.net/~attila/8134502/webrev.jdk8u-dev>?
>
> The changes from jdk9 are:
> - Parser API changes are omitted
> - RecompilableScriptFunctionData.java Hunk #2 failed to apply solely because its context is different ("IdentityHashMap<Symbol, Boolean>? in 8 vs. "IdentityHashMap<>" in 9 on the line preceding the change).
>
> Thanks,
>    Attila.
>
>> On Sep 27, 2015, at 12:05 PM, Marcus Lagergren <marcus at lagergren.net> wrote:
>>
>> +1
>>
>>> On 25 Sep 2015, at 18:54, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>>
>>> Please review JDK-8134502 "introduce abstraction for basic NodeVisitor usage" at <http://cr.openjdk.java.net/~attila/8134502/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134502>
>>>
>>> Thanks,
>>> Attila.


From marcus at lagergren.net  Mon Sep 28 07:53:01 2015
From: marcus at lagergren.net (Marcus Lagergren)
Date: Mon, 28 Sep 2015 09:53:01 +0200
Subject: Review request for JDK-8134502: introduce abstraction for basic
	NodeVisitor usage
In-Reply-To: <F6C6ABB0-7131-4F91-A9CD-F88186F4DBA3@oracle.com>
References: <B498AFF4-6EAE-4E32-88BE-971788E28E17@oracle.com>
	<CA33B694-3387-4B69-8741-CAC1C0F6FA9F@lagergren.net>
	<F6C6ABB0-7131-4F91-A9CD-F88186F4DBA3@oracle.com>
Message-ID: <3ACA0833-55CB-4DEC-BB19-E1C32AAAF407@lagergren.net>

+1 on backport change.

> On 28 Sep 2015, at 08:54, Attila Szegedi <attila.szegedi at oracle.com> wrote:
> 
> Thanks for the review folks; can I quickly get a review for the 8u-dev backport at <http://cr.openjdk.java.net/~attila/8134502/webrev.jdk8u-dev>?
> 
> The changes from jdk9 are:
> - Parser API changes are omitted
> - RecompilableScriptFunctionData.java Hunk #2 failed to apply solely because its context is different ("IdentityHashMap<Symbol, Boolean>? in 8 vs. "IdentityHashMap<>" in 9 on the line preceding the change).
> 
> Thanks,
>  Attila.
> 
>> On Sep 27, 2015, at 12:05 PM, Marcus Lagergren <marcus at lagergren.net> wrote:
>> 
>> +1
>> 
>>> On 25 Sep 2015, at 18:54, Attila Szegedi <attila.szegedi at oracle.com> wrote:
>>> 
>>> Please review JDK-8134502 "introduce abstraction for basic NodeVisitor usage" at <http://cr.openjdk.java.net/~attila/8134502/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8134502>
>>> 
>>> Thanks,
>>> Attila.
>> 
> 


From sundararajan.athijegannathan at oracle.com  Mon Sep 28 12:11:28 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 28 Sep 2015 17:41:28 +0530
Subject: RFR 8137258: JSObjectLinker and BrowserJSObjectLinker should not
	expose internal JS objects
Message-ID: <56092E70.4030100@oracle.com>

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

Thanks,
-Sundar

From sundararajan.athijegannathan at oracle.com  Mon Sep 28 12:16:32 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 28 Sep 2015 17:46:32 +0530
Subject: RFR 8137258: JSObjectLinker and BrowserJSObjectLinker should not
	expose internal JS objects
In-Reply-To: <56092E70.4030100@oracle.com>
References: <56092E70.4030100@oracle.com>
Message-ID: <56092FA0.9030606@oracle.com>

That should have been http://cr.openjdk.java.net/~sundar/8137258/

-Sundar

On 9/28/2015 5:41 PM, Sundararajan Athijegannathan wrote:
> Please review http://cr.openjdk.java.net/~sundar/8137528  for 
> https://bugs.openjdk.java.net/browse/JDK-8137258
>
> Thanks,
> -Sundar


From attila.szegedi at oracle.com  Mon Sep 28 12:19:43 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 28 Sep 2015 14:19:43 +0200
Subject: RFR 8137258: JSObjectLinker and BrowserJSObjectLinker should not
	expose internal JS objects
In-Reply-To: <56092FA0.9030606@oracle.com>
References: <56092E70.4030100@oracle.com> <56092FA0.9030606@oracle.com>
Message-ID: <816D7B34-F56A-495C-B538-5290CD6CF003@oracle.com>

BeansLinker already adds filtering, so when both JSObjectLinker and BrowserJSObjectLinker delegate to it, they shouldn't add the filter themselves. They should only do it with invocations that don't come back from delegation to BeansLinker.

Attila.

> On Sep 28, 2015, at 2:16 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> That should have been http://cr.openjdk.java.net/~sundar/8137258/
> 
> -Sundar
> 
> On 9/28/2015 5:41 PM, Sundararajan Athijegannathan wrote:
>> Please review http://cr.openjdk.java.net/~sundar/8137528  for https://bugs.openjdk.java.net/browse/JDK-8137258
>> 
>> Thanks,
>> -Sundar
> 


From sundararajan.athijegannathan at oracle.com  Mon Sep 28 12:41:14 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 28 Sep 2015 18:11:14 +0530
Subject: RFR 8137258: JSObjectLinker and BrowserJSObjectLinker should not
	expose internal JS objects
In-Reply-To: <816D7B34-F56A-495C-B538-5290CD6CF003@oracle.com>
References: <56092E70.4030100@oracle.com> <56092FA0.9030606@oracle.com>
	<816D7B34-F56A-495C-B538-5290CD6CF003@oracle.com>
Message-ID: <5609356A.3020307@oracle.com>

Thanks for the review. Please find the updated webrev 
http://cr.openjdk.java.net/~sundar/8137258/webrev.01/index.html

Thanks,
-Sundar

On 9/28/2015 5:49 PM, Attila Szegedi wrote:
> BeansLinker already adds filtering, so when both JSObjectLinker and BrowserJSObjectLinker delegate to it, they shouldn't add the filter themselves. They should only do it with invocations that don't come back from delegation to BeansLinker.
>
> Attila.
>
>> On Sep 28, 2015, at 2:16 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>
>> That should have been http://cr.openjdk.java.net/~sundar/8137258/
>>
>> -Sundar
>>
>> On 9/28/2015 5:41 PM, Sundararajan Athijegannathan wrote:
>>> Please review http://cr.openjdk.java.net/~sundar/8137528  for https://bugs.openjdk.java.net/browse/JDK-8137258
>>>
>>> Thanks,
>>> -Sundar


From attila.szegedi at oracle.com  Mon Sep 28 12:46:58 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Mon, 28 Sep 2015 14:46:58 +0200
Subject: RFR 8137258: JSObjectLinker and BrowserJSObjectLinker should not
	expose internal JS objects
In-Reply-To: <5609356A.3020307@oracle.com>
References: <56092E70.4030100@oracle.com> <56092FA0.9030606@oracle.com>
	<816D7B34-F56A-495C-B538-5290CD6CF003@oracle.com>
	<5609356A.3020307@oracle.com>
Message-ID: <B85B44EE-F931-4218-A97B-26805D73ABEA@oracle.com>

+1

> On Sep 28, 2015, at 2:41 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Thanks for the review. Please find the updated webrev http://cr.openjdk.java.net/~sundar/8137258/webrev.01/index.html
> 
> Thanks,
> -Sundar
> 
> On 9/28/2015 5:49 PM, Attila Szegedi wrote:
>> BeansLinker already adds filtering, so when both JSObjectLinker and BrowserJSObjectLinker delegate to it, they shouldn't add the filter themselves. They should only do it with invocations that don't come back from delegation to BeansLinker.
>> 
>> Attila.
>> 
>>> On Sep 28, 2015, at 2:16 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
>>> 
>>> That should have been http://cr.openjdk.java.net/~sundar/8137258/
>>> 
>>> -Sundar
>>> 
>>> On 9/28/2015 5:41 PM, Sundararajan Athijegannathan wrote:
>>>> Please review http://cr.openjdk.java.net/~sundar/8137528  for https://bugs.openjdk.java.net/browse/JDK-8137258
>>>> 
>>>> Thanks,
>>>> -Sundar
> 


From hannes.wallnoefer at oracle.com  Mon Sep 28 13:18:37 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Mon, 28 Sep 2015 15:18:37 +0200
Subject: RFR 8137258: JSObjectLinker and BrowserJSObjectLinker should not
	expose internal JS objects
In-Reply-To: <5609356A.3020307@oracle.com>
References: <56092E70.4030100@oracle.com> <56092FA0.9030606@oracle.com>
	<816D7B34-F56A-495C-B538-5290CD6CF003@oracle.com>
	<5609356A.3020307@oracle.com>
Message-ID: <56093E2D.7020501@oracle.com>

+1


Am 2015-09-28 um 14:41 schrieb Sundararajan Athijegannathan:
> Thanks for the review. Please find the updated webrev 
> http://cr.openjdk.java.net/~sundar/8137258/webrev.01/index.html
>
> Thanks,
> -Sundar
>
> On 9/28/2015 5:49 PM, Attila Szegedi wrote:
>> BeansLinker already adds filtering, so when both JSObjectLinker and 
>> BrowserJSObjectLinker delegate to it, they shouldn't add the filter 
>> themselves. They should only do it with invocations that don't come 
>> back from delegation to BeansLinker.
>>
>> Attila.
>>
>>> On Sep 28, 2015, at 2:16 PM, Sundararajan Athijegannathan 
>>> <sundararajan.athijegannathan at oracle.com> wrote:
>>>
>>> That should have been http://cr.openjdk.java.net/~sundar/8137258/
>>>
>>> -Sundar
>>>
>>> On 9/28/2015 5:41 PM, Sundararajan Athijegannathan wrote:
>>>> Please review http://cr.openjdk.java.net/~sundar/8137528  for 
>>>> https://bugs.openjdk.java.net/browse/JDK-8137258
>>>>
>>>> Thanks,
>>>> -Sundar
>


From attila.szegedi at oracle.com  Tue Sep 29 15:56:18 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 29 Sep 2015 17:56:18 +0200
Subject: Review request for JDK-8137333: Boundless soft caching of property
	map histories causes high memory pressure
Message-ID: <60023A76-24DB-4596-B42D-ACD16F84F21F@oracle.com>

Please review JDK-8137333 "Boundless soft caching of property map histories causes high memory pressure" at <http://cr.openjdk.java.net/~attila/8137333/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8137333>

Thanks,
  Attila.

From hannes.wallnoefer at oracle.com  Tue Sep 29 16:27:22 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Tue, 29 Sep 2015 18:27:22 +0200
Subject: Review request for JDK-8137333: Boundless soft caching of
	property map histories causes high memory pressure
In-Reply-To: <60023A76-24DB-4596-B42D-ACD16F84F21F@oracle.com>
References: <60023A76-24DB-4596-B42D-ACD16F84F21F@oracle.com>
Message-ID: <560ABBEA.3090902@oracle.com>

Looks good.

Am 2015-09-29 um 17:56 schrieb Attila Szegedi:
> Please review JDK-8137333 "Boundless soft caching of property map histories causes high memory pressure" at <http://cr.openjdk.java.net/~attila/8137333/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8137333>
>
> Thanks,
>    Attila.


From sundararajan.athijegannathan at oracle.com  Tue Sep 29 16:34:15 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 29 Sep 2015 22:04:15 +0530
Subject: Review request for JDK-8137333: Boundless soft caching of
	property map histories causes high memory pressure
In-Reply-To: <560ABBEA.3090902@oracle.com>
References: <60023A76-24DB-4596-B42D-ACD16F84F21F@oracle.com>
	<560ABBEA.3090902@oracle.com>
Message-ID: <560ABD87.7090803@oracle.com>

+1

nitpick: couple of methods are declared as "private final"

-Sundar

On 9/29/2015 9:57 PM, Hannes Wallnoefer wrote:
> Looks good.
>
> Am 2015-09-29 um 17:56 schrieb Attila Szegedi:
>> Please review JDK-8137333 "Boundless soft caching of property map 
>> histories causes high memory pressure" at 
>> <http://cr.openjdk.java.net/~attila/8137333/webrev.jdk9> for 
>> <https://bugs.openjdk.java.net/browse/JDK-8137333>
>>
>> Thanks,
>>    Attila.
>


From sundararajan.athijegannathan at oracle.com  Tue Sep 29 16:35:58 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 29 Sep 2015 22:05:58 +0530
Subject: RFR 8137320: jjs should support @argfile to pass command line
	arguments from a file
Message-ID: <560ABDEE.20102@oracle.com>

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

Thanks,
-Sundar

From henry.jen at oracle.com  Tue Sep 29 16:41:12 2015
From: henry.jen at oracle.com (Henry Jen)
Date: Tue, 29 Sep 2015 09:41:12 -0700
Subject: RFR 8137320: jjs should support @argfile to pass command line
	arguments from a file
In-Reply-To: <560ABDEE.20102@oracle.com>
References: <560ABDEE.20102@oracle.com>
Message-ID: <403B3D7C-AA01-4162-98FE-917945FC72BD@oracle.com>

Looks good to me.

Cheers,
Henry


> On Sep 29, 2015, at 9:35 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8137320/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8137320
> 
> Thanks,
> -Sundar


From attila.szegedi at oracle.com  Tue Sep 29 20:21:32 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Tue, 29 Sep 2015 22:21:32 +0200
Subject: RFR 8137320: jjs should support @argfile to pass command line
	arguments from a file
In-Reply-To: <560ABDEE.20102@oracle.com>
References: <560ABDEE.20102@oracle.com>
Message-ID: <D8E715C6-5678-4409-92D5-B63AF5D3F0BD@oracle.com>

+1. Very handy that this can be implemented by enabling an existing feature!

> On Sep 29, 2015, at 6:35 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8137320/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8137320
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Wed Sep 30 06:02:14 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 30 Sep 2015 08:02:14 +0200
Subject: RFR 8137320: jjs should support @argfile to pass command line
	arguments from a file
In-Reply-To: <560ABDEE.20102@oracle.com>
References: <560ABDEE.20102@oracle.com>
Message-ID: <560B7AE6.400@oracle.com>

+1

Am 2015-09-29 um 18:35 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8137320/webrev.00/ 
> for https://bugs.openjdk.java.net/browse/JDK-8137320
>
> Thanks,
> -Sundar


From attila.szegedi at oracle.com  Wed Sep 30 08:09:33 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 30 Sep 2015 10:09:33 +0200
Subject: Review request for JDK-8137333: Boundless soft caching of
	property map histories causes high memory pressure
In-Reply-To: <560ABD87.7090803@oracle.com>
References: <60023A76-24DB-4596-B42D-ACD16F84F21F@oracle.com>
	<560ABBEA.3090902@oracle.com> <560ABD87.7090803@oracle.com>
Message-ID: <2BCA8C35-2C7C-4D59-AD5C-E2DA149070B5@oracle.com>

Thanks, fixed that and pushed.

> On Sep 29, 2015, at 6:34 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> +1
> 
> nitpick: couple of methods are declared as "private final"
> 
> -Sundar
> 
> On 9/29/2015 9:57 PM, Hannes Wallnoefer wrote:
>> Looks good.
>> 
>> Am 2015-09-29 um 17:56 schrieb Attila Szegedi:
>>> Please review JDK-8137333 "Boundless soft caching of property map histories causes high memory pressure" at <http://cr.openjdk.java.net/~attila/8137333/webrev.jdk9> for <https://bugs.openjdk.java.net/browse/JDK-8137333>
>>> 
>>> Thanks,
>>>   Attila.
>> 
> 


From sundararajan.athijegannathan at oracle.com  Wed Sep 30 14:07:57 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 30 Sep 2015 19:37:57 +0530
Subject: RFR 8138643: nashorn ant build.xml javadoc, javadocapi targets are
	broken and netbeans makefile does not include shell sources
Message-ID: <560BECBD.8020106@oracle.com>

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

Thanks,
-Sundar

From attila.szegedi at oracle.com  Wed Sep 30 14:10:02 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 30 Sep 2015 16:10:02 +0200
Subject: RFR 8138643: nashorn ant build.xml javadoc,
	javadocapi targets are broken and netbeans makefile does not include
	shell sources
In-Reply-To: <560BECBD.8020106@oracle.com>
References: <560BECBD.8020106@oracle.com>
Message-ID: <FE0E0B72-D2AC-4653-B7AE-E4CF557801C7@oracle.com>

+1

> On Sep 30, 2015, at 4:07 PM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8138643/ for https://bugs.openjdk.java.net/browse/JDK-8138643
> 
> Thanks,
> -Sundar


From hannes.wallnoefer at oracle.com  Wed Sep 30 14:19:05 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 30 Sep 2015 16:19:05 +0200
Subject: RFR 8138643: nashorn ant build.xml javadoc, javadocapi targets
	are broken and netbeans makefile does not include shell sources
In-Reply-To: <560BECBD.8020106@oracle.com>
References: <560BECBD.8020106@oracle.com>
Message-ID: <560BEF59.60405@oracle.com>

It seems like you have included 
../src/jdk.scripting.nashorn.shell/share/classes twice in 
make/nbproject/project.xml (around line 70). Is that intentional?

Otherwise looks good.

Hannes


Am 2015-09-30 um 16:07 schrieb Sundararajan Athijegannathan:
> Please review http://cr.openjdk.java.net/~sundar/8138643/ for 
> https://bugs.openjdk.java.net/browse/JDK-8138643
>
> Thanks,
> -Sundar


From sundararajan.athijegannathan at oracle.com  Wed Sep 30 14:22:10 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 30 Sep 2015 19:52:10 +0530
Subject: RFR 8138643: nashorn ant build.xml javadoc, javadocapi targets
	are broken and netbeans makefile does not include shell sources
In-Reply-To: <560BEF59.60405@oracle.com>
References: <560BECBD.8020106@oracle.com> <560BEF59.60405@oracle.com>
Message-ID: <560BF012.6050507@oracle.com>

I did that with NB UI - and not manually..

Thanks,
-Sundar

On 9/30/2015 7:49 PM, Hannes Wallnoefer wrote:
> It seems like you have included 
> ../src/jdk.scripting.nashorn.shell/share/classes twice in 
> make/nbproject/project.xml (around line 70). Is that intentional?
>
> Otherwise looks good.
>
> Hannes
>
>
> Am 2015-09-30 um 16:07 schrieb Sundararajan Athijegannathan:
>> Please review http://cr.openjdk.java.net/~sundar/8138643/ for 
>> https://bugs.openjdk.java.net/browse/JDK-8138643
>>
>> Thanks,
>> -Sundar
>


From hannes.wallnoefer at oracle.com  Wed Sep 30 14:46:37 2015
From: hannes.wallnoefer at oracle.com (Hannes Wallnoefer)
Date: Wed, 30 Sep 2015 16:46:37 +0200
Subject: RFR 8138632: Sparse array does not handle growth of underlying dense
	array
Message-ID: <560BF5CD.9070809@oracle.com>

Please review JDK-8138632: Sparse array does not handle growth of 
underlying dense array

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

This includes some cleanup (static methods marked final, removal of 
toIndex parameter in ArrayData.canDelete that was never used).

Thanks,
Hannes

From attila.szegedi at oracle.com  Wed Sep 30 15:19:38 2015
From: attila.szegedi at oracle.com (Attila Szegedi)
Date: Wed, 30 Sep 2015 17:19:38 +0200
Subject: RFR 8138632: Sparse array does not handle growth of underlying
	dense array
In-Reply-To: <560BF5CD.9070809@oracle.com>
References: <560BF5CD.9070809@oracle.com>
Message-ID: <36F4B78C-8124-4A71-B330-B04B12D279BC@oracle.com>

+1

> On Sep 30, 2015, at 4:46 PM, Hannes Wallnoefer <hannes.wallnoefer at oracle.com> wrote:
> 
> Please review JDK-8138632: Sparse array does not handle growth of underlying dense array
> 
> http://cr.openjdk.java.net/~hannesw/8138632/
> 
> This includes some cleanup (static methods marked final, removal of toIndex parameter in ArrayData.canDelete that was never used).
> 
> Thanks,
> Hannes


From sundararajan.athijegannathan at oracle.com  Wed Sep 30 15:19:51 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 30 Sep 2015 20:49:51 +0530
Subject: RFR 8138632: Sparse array does not handle growth of underlying
	dense array
In-Reply-To: <560BF5CD.9070809@oracle.com>
References: <560BF5CD.9070809@oracle.com>
Message-ID: <560BFD97.6090806@oracle.com>

+1

On 9/30/2015 8:16 PM, Hannes Wallnoefer wrote:
> Please review JDK-8138632: Sparse array does not handle growth of 
> underlying dense array
>
> http://cr.openjdk.java.net/~hannesw/8138632/
>
> This includes some cleanup (static methods marked final, removal of 
> toIndex parameter in ArrayData.canDelete that was never used).
>
> Thanks,
> Hannes