From paul.sandoz at oracle.com  Mon Sep  1 08:52:51 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 1 Sep 2014 10:52:51 +0200
Subject: RFR 8056249 Improve CompletableFuture resource usage
In-Reply-To: <CA+kOe088orcJMmGqzQHwTPD9yx0Um1aL=6YHWaHjd9619+T8iA@mail.gmail.com>
References: <FFBCFAA8-9652-4376-A5F3-6B673544A8F8@oracle.com>
	<CA+kOe088orcJMmGqzQHwTPD9yx0Um1aL=6YHWaHjd9619+T8iA@mail.gmail.com>
Message-ID: <520FE774-A7F9-4679-901D-C5254AC4DE33@oracle.com>

On Aug 29, 2014, at 5:56 PM, Martin Buchholz <martinrb at google.com> wrote:
> Looks fine.

Thanks Martin & Chris.


> Instead of using Contributed-by: for Doug's work, you should make him the hg "user", as is done in previous changesets.  E.g. hg import has a --user flag.
> 

Ok, i will do that.

Paul.


From paul.sandoz at oracle.com  Mon Sep  1 09:48:35 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 1 Sep 2014 11:48:35 +0200
Subject: [9] RFR (S): 8056926: Improve caching of GuardWithTest combinator
In-Reply-To: <5400B64F.5080408@oracle.com>
References: <5400B64F.5080408@oracle.com>
Message-ID: <994FA3F6-312D-43FA-9AFB-7BCB9FF4171C@oracle.com>


On Aug 29, 2014, at 7:20 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8056926/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8056926
> 
> Cache GuardWithTest per erased to basic types signature.
> 
> GWT shape is made friendly to sharing:
>  * GWT MH is implemented as BMH which stores 3 method handles
>  * LF loads them from the associated MethodHandle
> 
> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}.
> 
> Reviewed-by: vlivanov, ?
> Contributed-by: john.r.rose at oracle.com
> 

+1

To be on the safe side should a @ForceInline be stuffed on the "selectAlternative" method?

Paul.


From vladimir.x.ivanov at oracle.com  Mon Sep  1 10:29:47 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 01 Sep 2014 14:29:47 +0400
Subject: [9] RFR (S): 8056926: Improve caching of GuardWithTest combinator
In-Reply-To: <994FA3F6-312D-43FA-9AFB-7BCB9FF4171C@oracle.com>
References: <5400B64F.5080408@oracle.com>
	<994FA3F6-312D-43FA-9AFB-7BCB9FF4171C@oracle.com>
Message-ID: <54044A9B.7050304@oracle.com>

Thanks, Paul.

There's no need to add @ForceInline on selectAlternative.
It is used only during LF interpretation. There's an intrinsic for GWT 
combinator, which encodes it as a branch (see 
InvokerBytecodeGenerator.emitSelectAlternative).

Best regards,
Vladimir Ivanov

On 9/1/14, 1:48 PM, Paul Sandoz wrote:
>
> On Aug 29, 2014, at 7:20 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> http://cr.openjdk.java.net/~vlivanov/8056926/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8056926
>>
>> Cache GuardWithTest per erased to basic types signature.
>>
>> GWT shape is made friendly to sharing:
>>   * GWT MH is implemented as BMH which stores 3 method handles
>>   * LF loads them from the associated MethodHandle
>>
>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>>
>> Reviewed-by: vlivanov, ?
>> Contributed-by: john.r.rose at oracle.com
>>
>
> +1
>
> To be on the safe side should a @ForceInline be stuffed on the "selectAlternative" method?
>
> Paul.
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


From paul.sandoz at oracle.com  Mon Sep  1 10:49:45 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 1 Sep 2014 12:49:45 +0200
Subject: [9] RFR (S): 8056926: Improve caching of GuardWithTest combinator
In-Reply-To: <54044A9B.7050304@oracle.com>
References: <5400B64F.5080408@oracle.com>
	<994FA3F6-312D-43FA-9AFB-7BCB9FF4171C@oracle.com>
	<54044A9B.7050304@oracle.com>
Message-ID: <4F7B5FE1-F9A0-4D93-9E11-6978139B1650@oracle.com>


On Sep 1, 2014, at 12:29 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> Thanks, Paul.
> 
> There's no need to add @ForceInline on selectAlternative.
> It is used only during LF interpretation. There's an intrinsic for GWT combinator, which encodes it as a branch (see InvokerBytecodeGenerator.emitSelectAlternative).
> 

Ah yes, i forgot about those recently added intrinsics,
Paul.


From ron at paralleluniverse.co  Mon Sep  1 10:50:25 2014
From: ron at paralleluniverse.co (Ron Pressler)
Date: Mon, 1 Sep 2014 13:50:25 +0300
Subject: Process API Updates (JEP 102)
In-Reply-To: <53FF5F9E.60701@oracle.com>
References: <CAAsnhpAYsxh_=90Bb-utQKqA4Q88RsH8qSUHn4fcvNNM3HTysQ@mail.gmail.com>
	<53FF5F9E.60701@oracle.com>
Message-ID: <F01696895C084FA3A01B0693F82C7037@paralleluniverse.co>

If the second process is indeed a JVM, is that any different from spawning a Java process with a shell-script exec (something that?s quite commonly done, I assume)?


On Thursday, August 28, 2014 at 7:58 PM, roger riggs wrote:

> Hi Ron,
>  
> I have not looked at that idea closely but I would be concerned
> about the robustness of the 2nd, execve'd Java runtime. Since it would  
> not be
> a brand new process, there might be leftover state from the previous
> execution that would break the usual assumptions of a newly started Java  
> Runtime.
> Anything from signal handler state to open file descriptors to the specific
> memory mapping and there may be others.
>  
> Roger
>  
>  
> On 8/26/2014 7:25 AM, Ron Pressler wrote:
> > I might be a little late to this party, but recently I've had a (rather
> > frustrating) need for the ability to execve a process rather than fork-exec
> > it. I understand that the ability to exec (replace the current process's
> > image) is also available on Windows. This operation (on ProcessBuilder?),
> > which never returns, would have the same semantics as
> > System.exit(pb.start().waitFor()), only it would replace the current JVM
> > process (i.e. maintain the same pid/handle) with the command.
> >  
> > This is required when a JVM process is used to set up and launch another,
> > JVM or other, process, but we'd want the user running the program to be
> > oblivious to the setup process (because, say, they want to monitor the
> > running program with some OS tool).
> >  
> > Ron  



From vladimir.x.ivanov at oracle.com  Mon Sep  1 11:07:33 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 01 Sep 2014 15:07:33 +0400
Subject: [9] RFR (S): 8056926: Improve caching of GuardWithTest combinator
In-Reply-To: <4F7B5FE1-F9A0-4D93-9E11-6978139B1650@oracle.com>
References: <5400B64F.5080408@oracle.com>	<994FA3F6-312D-43FA-9AFB-7BCB9FF4171C@oracle.com>	<54044A9B.7050304@oracle.com>
	<4F7B5FE1-F9A0-4D93-9E11-6978139B1650@oracle.com>
Message-ID: <54045375.7010704@oracle.com>

FTR, selectAlternative intrinsic is there from the very beginning.
Recent changes improved how intrinsics are represented on LF level + 
added a bunch of new intrinsics.

Best regards,
Vladimir Ivanov

On 9/1/14, 2:49 PM, Paul Sandoz wrote:
>
> On Sep 1, 2014, at 12:29 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> Thanks, Paul.
>>
>> There's no need to add @ForceInline on selectAlternative.
>> It is used only during LF interpretation. There's an intrinsic for GWT combinator, which encodes it as a branch (see InvokerBytecodeGenerator.emitSelectAlternative).
>>
>
> Ah yes, i forgot about those recently added intrinsics,
> Paul.
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


From aleksej.efimov at oracle.com  Mon Sep  1 14:10:44 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Mon, 01 Sep 2014 18:10:44 +0400
Subject: RFR: 8049343: (tz) Support tzdata2014g
In-Reply-To: <53FEA567.9020601@oracle.com>
References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com>
	<53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com>
	<53F734D8.1000801@oracle.com> <53FD9819.7080000@oracle.com>
	<53FDE2CD.8040709@oracle.com> <53FEA567.9020601@oracle.com>
Message-ID: <54047E64.9020206@oracle.com>

Masayoshi,

I have addressed all your comments with proposed resolution. Thank you 
for such thorough analysis of this changes.

Also the new tzdata is out (2014g) - I have updated the JBS bug by 
adding 2014g related change notes and renamed this bug appropriately + 
I'm renaming this thread.
The new webrev contains new changes related to 2014g:
-            {"America/Grand_Turk", EST},
+            {"America/Grand_Turk", AST},


The 2014e/f related changes, discussed previously, are still in place.

New webrev can be found here: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04

The bug for the incomplete localization of new/updated time zone names 
was filed: https://bugs.openjdk.java.net/browse/JDK-8057004

With Best Regards,
Aleksej

On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote:
>  src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
>
>  239         String SLST[] = new String[] {"Greenwich Mean Time", "GMT",
>  240                                       "Sierra Leone Summer Time", 
> "SLST",
>  241                                       "Sierra Leone Time", "SLT"};
>
>  251         String WART[] = new String[] {"Western Argentine Time", 
> "WART",
>  252                                       "Western Argentine Summer 
> Time", "WARST",
>  253                                       "Western Argentine Time", 
> "WART"};
>
> It seems these are no longer used.
>
> -            {"Antarctica/Macquarie", new String[] {"Macquarie Island 
> Time", "MIST",
> -                                                   "Macquarie Island 
> Summer Time", "MIST",
> +            {"Antarctica/Macquarie", new String[] {"Macquarie Island 
> Standard Time", "MIST",
> +                                                   "Macquarie Island 
> Daylight Time", "MIST",
>
> The daylight saving time abbreviation should be MIDT.
>
> Thanks,
> Masayoshi
>
> On 8/27/2014 10:53 PM, Aleksej Efimov wrote:
>> Masayoshi,
>> Thank you for a detailed review - I tried to address all your 
>> comments. Please, see the updated review: 
>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03
>> About the workarounds - I will start discussion with Sherman when the 
>> tzdata2014f (and I suppose the 2014g - it will be available soon 
>> according to tzdata mail-list [1]) integration will be complete.
>>
>> -Aleksej
>>
>> [1] tzdata2014g is coming: 
>> http://mm.icann.org/pipermail/tz/2014-August/021528.html
>>
>> On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote:
>>> Here are additional comments.
>>>
>>> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:
>>>
>>> I'm concerned about the workarounds. It's not new in this update, 
>>> but this problem would make tzupdater data void until the workaround 
>>> is added to the next update release. Could you please work with 
>>> Sherman to eliminate the workaround (outside of this 2014f update)?
>>>
>>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
>>>
>>>          String LORD_HOWE[] = new String[] {"Lord Howe Standard 
>>> Time", "LHST",
>>> -                                           "Lord Howe Summer Time", 
>>> "LHST",
>>> +                                           "Lord Howe Summer Time", 
>>> "LHDT",
>>>
>>> The S-D convention is applied to Lord Howe as well.
>>>
>>>  567             {"Antarctica/Macquarie", new String[] {"Macquarie 
>>> Island Time", "MIST",
>>>  568 "Macquarie Island Summer Time", "MIST",
>>>  569 "Macquarie Island Time", "MIST"}},
>>>
>>> This one should also follow the S-D convention, although this time 
>>> zone doesn't observe daylight saving time.
>>>
>>>
>>> +        String XJT[] = new String[] {"China Standard Time", "XJT",
>>> +                                     "China Daylight Time", "XJDT",
>>> +                                     "China Time", "XJT"};
>>>
>>> Should the long names be based on Xinjiang?
>>>
>>> Africa/Freetown is now a link to Africa/Abidjan. Those should be the 
>>> same time zone.
>>>
>>> -            {"America/Metlakatla", new String[] {"Metlakatla 
>>> Standard Time", "MeST",
>>> -                                                 "Metlakatla 
>>> Daylight Time", "MeDT",
>>> -                                                 "Metlakatla Time", 
>>> "MeT"}},
>>> +            {"America/Metlakatla", new String[] {"Metlakatla 
>>> Standard Time", "PST",
>>> +                                                 "Metlakatla 
>>> Daylight Time", "PDT",
>>> +                                                 "Metlakatla Time", 
>>> "PT"}},
>>>
>>> -            {"Europe/Volgograd", new String[] {"Volgograd Time", 
>>> "VOLT",
>>> -                                               "Volgograd Summer 
>>> Time", "VOLST",
>>> -                                               "Volgograd Time", 
>>> "VOLT"}},
>>> +            {"Europe/Volgograd", new String[] {"Volgograd Time", 
>>> "MSK",
>>> +                                               "Volgograd Summer 
>>> Time", "MSK",
>>> +                                               "Volgograd Time", 
>>> "MSK"}},
>>>
>>>
>>> The long names should be changed accordingly.
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 8/22/2014 9:17 PM, Aleksej Efimov wrote:
>>>> Masayoshi,
>>>> You're right that the "root names" should be changed as part of 
>>>> this update. The names were changed according to Australian 
>>>> official document here: 
>>>> http://australia.gov.au/about-australia/our-country/time
>>>> The fixed version of the webrev can be found here: 
>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02
>>>>
>>>> Thanks,
>>>> Aleksej
>>>>
>>>>
>>>> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote:
>>>>> We used to make name changes in the root (base) bundle as part of 
>>>>> time zone data maintenance and deter only translations. But if you 
>>>>> want to handle name changes later, that would be fine. It's your 
>>>>> call.
>>>>>
>>>>> Thanks,
>>>>> Masayoshi
>>>>>
>>>>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote:
>>>>>> Masayoshi,
>>>>>> I agree that we should change the long names to match the new 
>>>>>> short names introduced by tzdata.
>>>>>> But I suggest to log a different CR for such activity to handle 
>>>>>> long name changes and their translations (this activity is 
>>>>>> slightly out of tzdata update scope). Does it make sense?
>>>>>>
>>>>>> -Aleksej
>>>>>>
>>>>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
>>>>>>> I think the long names of the Australia time zones should be 
>>>>>>> revisited to be consistent with the abbreviation changes. The 
>>>>>>> new abbreviations follow the S[tandard] and D[aylight saving] 
>>>>>>> convention rather than the S[tandard] and S[ummer time] one. The 
>>>>>>> long names, such as "Eastern Summer Time (Queensland)", no 
>>>>>>> longer make sense.
>>>>>>>
>>>>>>> On the other hand, you will need to access impact of the name 
>>>>>>> changes, including abbreviations. Also, if you change the long 
>>>>>>> names, their translations will need to be changed as well.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Masayoshi
>>>>>>>
>>>>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please, review the tzdata2014f integration (with tzdata2014e 
>>>>>>>> related changes included too) [1] fix to JDK9: 
>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
>>>>>>>>
>>>>>>>> The tzdata2014f changes are extensive and relates mostly to 
>>>>>>>> timezone short names changes + "Asia/Srednekolymsk" time zone 
>>>>>>>> were added.
>>>>>>>> Almost complete list of changes can be found in the JBS bug 
>>>>>>>> description [1], plus some changes wasn't documented in tzdata 
>>>>>>>> release notes - for such cases raw tzdata diff was used for the 
>>>>>>>> names modifications.
>>>>>>>>
>>>>>>>> Two issues with JSR310 implementation were discovered during 
>>>>>>>> integration process:
>>>>>>>> First issue is related to the internal representation of the 
>>>>>>>> '24:00' value. The JSR310 implementation treats this value as a 
>>>>>>>> next day 00:00 time. The workaround already exists in JSR310 
>>>>>>>> code for similar entries and this failure is resolved in 
>>>>>>>> similar way [2] as part of this update.
>>>>>>>> For the second issue JDK-8051641 [3] was filled and 
>>>>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only 
>>>>>>>> one that fails with this tzdata.
>>>>>>>> Other time zone related tests [4] passes without failures.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Aleksej
>>>>>>>>
>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
>>>>>>>> [2] 
>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
>>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
>>>>>>>> [4] TZ related test sets: test/sun/util/calendar 
>>>>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone 
>>>>>>>> test/sun/util/calendar test/java/util/TimeZone test/java/time\ 
>>>>>>>> test/java/util/Formatter test/closed/java/util/Calendar 
>>>>>>>> test/closed/java/util/TimeZone
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From Alan.Bateman at oracle.com  Mon Sep  1 16:05:12 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 01 Sep 2014 17:05:12 +0100
Subject: RFR: JDK-8056934: ZipInputStream does not correctly handle local
	header data descriptors with the optional signature missing
In-Reply-To: <CA+kOe0_56ahydPyi0TJZWn5fhh-3Ss5bP=PaRqYGitwsy4EbwA@mail.gmail.com>
References: <CA+kOe0_56ahydPyi0TJZWn5fhh-3Ss5bP=PaRqYGitwsy4EbwA@mail.gmail.com>
Message-ID: <54049938.3040507@oracle.com>

On 29/08/2014 20:12, Martin Buchholz wrote:
> Hi Xueming and Alan,
>
> I'd like you to do a code review.
>
> https://bugs.openjdk.java.net/browse/JDK-8056934
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/zip-DataDescriptorSignatureMissing/ 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/zip-DataDescriptorSignatureMissing/>
>
> This seems like an atypical off-by-one, so I'm not sure how it 
> happened, and I have the nagging feeling I'm missing something.
>
> Greg, this java code review contains a python program!
I looked at 4.3.9.3. For ZIP64 then we'll read 24 bytes which is 4 bytes 
too much if the signature is not present. The offset of those 4 bytes is 
position 20 (ZIP64_EXTHDR - ZIP64_EXTHDR with the current constants). 
With ZIP then we'll need 16 bytes and need to unread 4 bytes from 
position 12 (EXTHDR - EXTCRC with the current constants).

So I think you're right that the -1, I can only assume that we haven't 
encountered zip files that have a data descriptor without the signature.

For the comment in ZipInputStream then it might be better to move that 
to readEnd. My preference would be to not include the part starting "As 
of 2014-08, phyton ..." as that might not interesting in years to come.

-Alan.






From xueming.shen at oracle.com  Mon Sep  1 18:39:37 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 01 Sep 2014 11:39:37 -0700
Subject: RFR: JDK-8056934: ZipInputStream does not correctly handle local
	header data descriptors with the optional signature missing
In-Reply-To: <CA+kOe0_56ahydPyi0TJZWn5fhh-3Ss5bP=PaRqYGitwsy4EbwA@mail.gmail.com>
References: <CA+kOe0_56ahydPyi0TJZWn5fhh-3Ss5bP=PaRqYGitwsy4EbwA@mail.gmail.com>
Message-ID: <5404BD69.4090705@oracle.com>

On 8/29/14 12:12 PM, Martin Buchholz wrote:
> Hi Xueming and Alan,
>
> I'd like you to do a code review.
>
> https://bugs.openjdk.java.net/browse/JDK-8056934
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/zip-DataDescriptorSignatureMissing/ 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/zip-DataDescriptorSignatureMissing/>
>
> This seems like an atypical off-by-one, so I'm not sure how it 
> happened, and I have the nagging feeling I'm missing something.
>
> Greg, this java code review contains a python program!

Agreed, it appears to be off-by-1. I don't know how it happened as well. 
The code was put in
back to 1.4.2 (4635869) to fix exactly the same issue (a local 
descriptors without signature bits).
Obviously we did not put into the regression test for it :-(

The fix looks fine. Though the comment part is a little long:-) It might 
be desirable to simply keep
the first part and move it into readEND?

-Sherman


From xueming.shen at oracle.com  Mon Sep  1 19:04:35 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 01 Sep 2014 12:04:35 -0700
Subject: RFR: JDK-8056934: ZipInputStream does not correctly handle local
	header data descriptors with the optional signature missing
In-Reply-To: <54049938.3040507@oracle.com>
References: <CA+kOe0_56ahydPyi0TJZWn5fhh-3Ss5bP=PaRqYGitwsy4EbwA@mail.gmail.com>
	<54049938.3040507@oracle.com>
Message-ID: <5404C343.6060408@oracle.com>

On 9/1/14 9:05 AM, Alan Bateman wrote:
> On 29/08/2014 20:12, Martin Buchholz wrote:
>> Hi Xueming and Alan,
>>
>> I'd like you to do a code review.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8056934
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/zip-DataDescriptorSignatureMissing/ 
>> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/zip-DataDescriptorSignatureMissing/> 
>>
>>
>> This seems like an atypical off-by-one, so I'm not sure how it 
>> happened, and I have the nagging feeling I'm missing something.
>>
>> Greg, this java code review contains a python program!
> I looked at 4.3.9.3. For ZIP64 then we'll read 24 bytes which is 4 
> bytes too much if the signature is not present. The offset of those 4 
> bytes is position 20 (ZIP64_EXTHDR - ZIP64_EXTHDR with the current 
> constants). With ZIP then we'll need 16 bytes and need to unread 4 
> bytes from position 12 (EXTHDR - EXTCRC with the current constants).
>
> So I think you're right that the -1, I can only assume that we haven't 
> encountered zip files that have a data descriptor without the signature.

The zip64 part was the copy/paste of the existing code, and we did not 
add any test for this corner case we
implemented zip64. Before the fix of 4635869, the implementation simply 
throws an exception. With the "fix"
it appears it can work well with the first entry of such a zip file, but 
skip the rest...my guess is that the test
case zip file in original bug report happens to be a single entry zip file.

-Sherman

>
> For the comment in ZipInputStream then it might be better to move that 
> to readEnd. My preference would be to not include the part starting 
> "As of 2014-08, phyton ..." as that might not interesting in years to 
> come.
>
> -Alan.
>
>
>
>



From masayoshi.okutsu at oracle.com  Tue Sep  2 06:03:42 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 02 Sep 2014 15:03:42 +0900
Subject: RFR: 8049343: (tz) Support tzdata2014g
In-Reply-To: <54047E64.9020206@oracle.com>
References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com>
	<53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com>
	<53F734D8.1000801@oracle.com> <53FD9819.7080000@oracle.com>
	<53FDE2CD.8040709@oracle.com> <53FEA567.9020601@oracle.com>
	<54047E64.9020206@oracle.com>
Message-ID: <54055DBE.3060804@oracle.com>

Aleksej,

I don't see the America/Grand_Turk change in webrev.04. I wonder if the 
webrev wasn't updated correctly.

Thanks,
Masayoshi

On 9/1/2014 11:10 PM, Aleksej Efimov wrote:
> Masayoshi,
>
> I have addressed all your comments with proposed resolution. Thank you 
> for such thorough analysis of this changes.
>
> Also the new tzdata is out (2014g) - I have updated the JBS bug by 
> adding 2014g related change notes and renamed this bug appropriately + 
> I'm renaming this thread.
> The new webrev contains new changes related to 2014g:
> -            {"America/Grand_Turk", EST},
> +            {"America/Grand_Turk", AST},
>
>
> The 2014e/f related changes, discussed previously, are still in place.
>
> New webrev can be found here: 
> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04
>
> The bug for the incomplete localization of new/updated time zone names 
> was filed: https://bugs.openjdk.java.net/browse/JDK-8057004
>
> With Best Regards,
> Aleksej
>
> On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote:
>>  src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
>>
>>  239         String SLST[] = new String[] {"Greenwich Mean Time", "GMT",
>>  240                                       "Sierra Leone Summer 
>> Time", "SLST",
>>  241                                       "Sierra Leone Time", "SLT"};
>>
>>  251         String WART[] = new String[] {"Western Argentine Time", 
>> "WART",
>>  252                                       "Western Argentine Summer 
>> Time", "WARST",
>>  253                                       "Western Argentine Time", 
>> "WART"};
>>
>> It seems these are no longer used.
>>
>> -            {"Antarctica/Macquarie", new String[] {"Macquarie Island 
>> Time", "MIST",
>> -                                                   "Macquarie Island 
>> Summer Time", "MIST",
>> +            {"Antarctica/Macquarie", new String[] {"Macquarie Island 
>> Standard Time", "MIST",
>> +                                                   "Macquarie Island 
>> Daylight Time", "MIST",
>>
>> The daylight saving time abbreviation should be MIDT.
>>
>> Thanks,
>> Masayoshi
>>
>> On 8/27/2014 10:53 PM, Aleksej Efimov wrote:
>>> Masayoshi,
>>> Thank you for a detailed review - I tried to address all your 
>>> comments. Please, see the updated review: 
>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03
>>> About the workarounds - I will start discussion with Sherman when 
>>> the tzdata2014f (and I suppose the 2014g - it will be available soon 
>>> according to tzdata mail-list [1]) integration will be complete.
>>>
>>> -Aleksej
>>>
>>> [1] tzdata2014g is coming: 
>>> http://mm.icann.org/pipermail/tz/2014-August/021528.html
>>>
>>> On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote:
>>>> Here are additional comments.
>>>>
>>>> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:
>>>>
>>>> I'm concerned about the workarounds. It's not new in this update, 
>>>> but this problem would make tzupdater data void until the 
>>>> workaround is added to the next update release. Could you please 
>>>> work with Sherman to eliminate the workaround (outside of this 
>>>> 2014f update)?
>>>>
>>>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
>>>>
>>>>          String LORD_HOWE[] = new String[] {"Lord Howe Standard 
>>>> Time", "LHST",
>>>> -                                           "Lord Howe Summer 
>>>> Time", "LHST",
>>>> +                                           "Lord Howe Summer 
>>>> Time", "LHDT",
>>>>
>>>> The S-D convention is applied to Lord Howe as well.
>>>>
>>>>  567             {"Antarctica/Macquarie", new String[] {"Macquarie 
>>>> Island Time", "MIST",
>>>>  568 "Macquarie Island Summer Time", "MIST",
>>>>  569 "Macquarie Island Time", "MIST"}},
>>>>
>>>> This one should also follow the S-D convention, although this time 
>>>> zone doesn't observe daylight saving time.
>>>>
>>>>
>>>> +        String XJT[] = new String[] {"China Standard Time", "XJT",
>>>> +                                     "China Daylight Time", "XJDT",
>>>> +                                     "China Time", "XJT"};
>>>>
>>>> Should the long names be based on Xinjiang?
>>>>
>>>> Africa/Freetown is now a link to Africa/Abidjan. Those should be 
>>>> the same time zone.
>>>>
>>>> -            {"America/Metlakatla", new String[] {"Metlakatla 
>>>> Standard Time", "MeST",
>>>> - "Metlakatla Daylight Time", "MeDT",
>>>> - "Metlakatla Time", "MeT"}},
>>>> +            {"America/Metlakatla", new String[] {"Metlakatla 
>>>> Standard Time", "PST",
>>>> + "Metlakatla Daylight Time", "PDT",
>>>> + "Metlakatla Time", "PT"}},
>>>>
>>>> -            {"Europe/Volgograd", new String[] {"Volgograd Time", 
>>>> "VOLT",
>>>> -                                               "Volgograd Summer 
>>>> Time", "VOLST",
>>>> -                                               "Volgograd Time", 
>>>> "VOLT"}},
>>>> +            {"Europe/Volgograd", new String[] {"Volgograd Time", 
>>>> "MSK",
>>>> +                                               "Volgograd Summer 
>>>> Time", "MSK",
>>>> +                                               "Volgograd Time", 
>>>> "MSK"}},
>>>>
>>>>
>>>> The long names should be changed accordingly.
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 8/22/2014 9:17 PM, Aleksej Efimov wrote:
>>>>> Masayoshi,
>>>>> You're right that the "root names" should be changed as part of 
>>>>> this update. The names were changed according to Australian 
>>>>> official document here: 
>>>>> http://australia.gov.au/about-australia/our-country/time
>>>>> The fixed version of the webrev can be found here: 
>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02
>>>>>
>>>>> Thanks,
>>>>> Aleksej
>>>>>
>>>>>
>>>>> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote:
>>>>>> We used to make name changes in the root (base) bundle as part of 
>>>>>> time zone data maintenance and deter only translations. But if 
>>>>>> you want to handle name changes later, that would be fine. It's 
>>>>>> your call.
>>>>>>
>>>>>> Thanks,
>>>>>> Masayoshi
>>>>>>
>>>>>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote:
>>>>>>> Masayoshi,
>>>>>>> I agree that we should change the long names to match the new 
>>>>>>> short names introduced by tzdata.
>>>>>>> But I suggest to log a different CR for such activity to handle 
>>>>>>> long name changes and their translations (this activity is 
>>>>>>> slightly out of tzdata update scope). Does it make sense?
>>>>>>>
>>>>>>> -Aleksej
>>>>>>>
>>>>>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
>>>>>>>> I think the long names of the Australia time zones should be 
>>>>>>>> revisited to be consistent with the abbreviation changes. The 
>>>>>>>> new abbreviations follow the S[tandard] and D[aylight saving] 
>>>>>>>> convention rather than the S[tandard] and S[ummer time] one. 
>>>>>>>> The long names, such as "Eastern Summer Time (Queensland)", no 
>>>>>>>> longer make sense.
>>>>>>>>
>>>>>>>> On the other hand, you will need to access impact of the name 
>>>>>>>> changes, including abbreviations. Also, if you change the long 
>>>>>>>> names, their translations will need to be changed as well.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Masayoshi
>>>>>>>>
>>>>>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please, review the tzdata2014f integration (with tzdata2014e 
>>>>>>>>> related changes included too) [1] fix to JDK9: 
>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
>>>>>>>>>
>>>>>>>>> The tzdata2014f changes are extensive and relates mostly to 
>>>>>>>>> timezone short names changes + "Asia/Srednekolymsk" time zone 
>>>>>>>>> were added.
>>>>>>>>> Almost complete list of changes can be found in the JBS bug 
>>>>>>>>> description [1], plus some changes wasn't documented in tzdata 
>>>>>>>>> release notes - for such cases raw tzdata diff was used for 
>>>>>>>>> the names modifications.
>>>>>>>>>
>>>>>>>>> Two issues with JSR310 implementation were discovered during 
>>>>>>>>> integration process:
>>>>>>>>> First issue is related to the internal representation of the 
>>>>>>>>> '24:00' value. The JSR310 implementation treats this value as 
>>>>>>>>> a next day 00:00 time. The workaround already exists in JSR310 
>>>>>>>>> code for similar entries and this failure is resolved in 
>>>>>>>>> similar way [2] as part of this update.
>>>>>>>>> For the second issue JDK-8051641 [3] was filled and 
>>>>>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only 
>>>>>>>>> one that fails with this tzdata.
>>>>>>>>> Other time zone related tests [4] passes without failures.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Aleksej
>>>>>>>>>
>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
>>>>>>>>> [2] 
>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
>>>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
>>>>>>>>> [4] TZ related test sets: test/sun/util/calendar 
>>>>>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone 
>>>>>>>>> test/sun/util/calendar test/java/util/TimeZone test/java/time\ 
>>>>>>>>> test/java/util/Formatter test/closed/java/util/Calendar 
>>>>>>>>> test/closed/java/util/TimeZone
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From aleksej.efimov at oracle.com  Tue Sep  2 13:41:13 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Tue, 02 Sep 2014 17:41:13 +0400
Subject: RFR: 8049343: (tz) Support tzdata2014g
In-Reply-To: <54055DBE.3060804@oracle.com>
References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com>
	<53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com>
	<53F734D8.1000801@oracle.com> <53FD9819.7080000@oracle.com>
	<53FDE2CD.8040709@oracle.com> <53FEA567.9020601@oracle.com>
	<54047E64.9020206@oracle.com> <54055DBE.3060804@oracle.com>
Message-ID: <5405C8F9.7090606@oracle.com>

Masayoshi,
Sorry for the confusion - for some reason (most probably this change was 
added after webrev generation) I forgot to include it. Now it's in 
place: http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04

Thank you,
Aleksej

On 09/02/2014 10:03 AM, Masayoshi Okutsu wrote:
> Aleksej,
>
> I don't see the America/Grand_Turk change in webrev.04. I wonder if 
> the webrev wasn't updated correctly.
>
> Thanks,
> Masayoshi
>
> On 9/1/2014 11:10 PM, Aleksej Efimov wrote:
>> Masayoshi,
>>
>> I have addressed all your comments with proposed resolution. Thank 
>> you for such thorough analysis of this changes.
>>
>> Also the new tzdata is out (2014g) - I have updated the JBS bug by 
>> adding 2014g related change notes and renamed this bug appropriately 
>> + I'm renaming this thread.
>> The new webrev contains new changes related to 2014g:
>> -            {"America/Grand_Turk", EST},
>> +            {"America/Grand_Turk", AST},
>>
>>
>> The 2014e/f related changes, discussed previously, are still in place.
>>
>> New webrev can be found here: 
>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04
>>
>> The bug for the incomplete localization of new/updated time zone 
>> names was filed: https://bugs.openjdk.java.net/browse/JDK-8057004
>>
>> With Best Regards,
>> Aleksej
>>
>> On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote:
>>>  src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
>>>
>>>  239         String SLST[] = new String[] {"Greenwich Mean Time", 
>>> "GMT",
>>>  240                                       "Sierra Leone Summer 
>>> Time", "SLST",
>>>  241                                       "Sierra Leone Time", "SLT"};
>>>
>>>  251         String WART[] = new String[] {"Western Argentine Time", 
>>> "WART",
>>>  252                                       "Western Argentine Summer 
>>> Time", "WARST",
>>>  253                                       "Western Argentine Time", 
>>> "WART"};
>>>
>>> It seems these are no longer used.
>>>
>>> -            {"Antarctica/Macquarie", new String[] {"Macquarie 
>>> Island Time", "MIST",
>>> -                                                   "Macquarie 
>>> Island Summer Time", "MIST",
>>> +            {"Antarctica/Macquarie", new String[] {"Macquarie 
>>> Island Standard Time", "MIST",
>>> +                                                   "Macquarie 
>>> Island Daylight Time", "MIST",
>>>
>>> The daylight saving time abbreviation should be MIDT.
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 8/27/2014 10:53 PM, Aleksej Efimov wrote:
>>>> Masayoshi,
>>>> Thank you for a detailed review - I tried to address all your 
>>>> comments. Please, see the updated review: 
>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03
>>>> About the workarounds - I will start discussion with Sherman when 
>>>> the tzdata2014f (and I suppose the 2014g - it will be available 
>>>> soon according to tzdata mail-list [1]) integration will be complete.
>>>>
>>>> -Aleksej
>>>>
>>>> [1] tzdata2014g is coming: 
>>>> http://mm.icann.org/pipermail/tz/2014-August/021528.html
>>>>
>>>> On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote:
>>>>> Here are additional comments.
>>>>>
>>>>> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:
>>>>>
>>>>> I'm concerned about the workarounds. It's not new in this update, 
>>>>> but this problem would make tzupdater data void until the 
>>>>> workaround is added to the next update release. Could you please 
>>>>> work with Sherman to eliminate the workaround (outside of this 
>>>>> 2014f update)?
>>>>>
>>>>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
>>>>>
>>>>>          String LORD_HOWE[] = new String[] {"Lord Howe Standard 
>>>>> Time", "LHST",
>>>>> -                                           "Lord Howe Summer 
>>>>> Time", "LHST",
>>>>> +                                           "Lord Howe Summer 
>>>>> Time", "LHDT",
>>>>>
>>>>> The S-D convention is applied to Lord Howe as well.
>>>>>
>>>>>  567             {"Antarctica/Macquarie", new String[] {"Macquarie 
>>>>> Island Time", "MIST",
>>>>>  568 "Macquarie Island Summer Time", "MIST",
>>>>>  569 "Macquarie Island Time", "MIST"}},
>>>>>
>>>>> This one should also follow the S-D convention, although this time 
>>>>> zone doesn't observe daylight saving time.
>>>>>
>>>>>
>>>>> +        String XJT[] = new String[] {"China Standard Time", "XJT",
>>>>> +                                     "China Daylight Time", "XJDT",
>>>>> +                                     "China Time", "XJT"};
>>>>>
>>>>> Should the long names be based on Xinjiang?
>>>>>
>>>>> Africa/Freetown is now a link to Africa/Abidjan. Those should be 
>>>>> the same time zone.
>>>>>
>>>>> -            {"America/Metlakatla", new String[] {"Metlakatla 
>>>>> Standard Time", "MeST",
>>>>> - "Metlakatla Daylight Time", "MeDT",
>>>>> - "Metlakatla Time", "MeT"}},
>>>>> +            {"America/Metlakatla", new String[] {"Metlakatla 
>>>>> Standard Time", "PST",
>>>>> + "Metlakatla Daylight Time", "PDT",
>>>>> + "Metlakatla Time", "PT"}},
>>>>>
>>>>> -            {"Europe/Volgograd", new String[] {"Volgograd Time", 
>>>>> "VOLT",
>>>>> -                                               "Volgograd Summer 
>>>>> Time", "VOLST",
>>>>> -                                               "Volgograd Time", 
>>>>> "VOLT"}},
>>>>> +            {"Europe/Volgograd", new String[] {"Volgograd Time", 
>>>>> "MSK",
>>>>> +                                               "Volgograd Summer 
>>>>> Time", "MSK",
>>>>> +                                               "Volgograd Time", 
>>>>> "MSK"}},
>>>>>
>>>>>
>>>>> The long names should be changed accordingly.
>>>>>
>>>>> Thanks,
>>>>> Masayoshi
>>>>>
>>>>> On 8/22/2014 9:17 PM, Aleksej Efimov wrote:
>>>>>> Masayoshi,
>>>>>> You're right that the "root names" should be changed as part of 
>>>>>> this update. The names were changed according to Australian 
>>>>>> official document here: 
>>>>>> http://australia.gov.au/about-australia/our-country/time
>>>>>> The fixed version of the webrev can be found here: 
>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02
>>>>>>
>>>>>> Thanks,
>>>>>> Aleksej
>>>>>>
>>>>>>
>>>>>> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote:
>>>>>>> We used to make name changes in the root (base) bundle as part 
>>>>>>> of time zone data maintenance and deter only translations. But 
>>>>>>> if you want to handle name changes later, that would be fine. 
>>>>>>> It's your call.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Masayoshi
>>>>>>>
>>>>>>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote:
>>>>>>>> Masayoshi,
>>>>>>>> I agree that we should change the long names to match the new 
>>>>>>>> short names introduced by tzdata.
>>>>>>>> But I suggest to log a different CR for such activity to handle 
>>>>>>>> long name changes and their translations (this activity is 
>>>>>>>> slightly out of tzdata update scope). Does it make sense?
>>>>>>>>
>>>>>>>> -Aleksej
>>>>>>>>
>>>>>>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
>>>>>>>>> I think the long names of the Australia time zones should be 
>>>>>>>>> revisited to be consistent with the abbreviation changes. The 
>>>>>>>>> new abbreviations follow the S[tandard] and D[aylight saving] 
>>>>>>>>> convention rather than the S[tandard] and S[ummer time] one. 
>>>>>>>>> The long names, such as "Eastern Summer Time (Queensland)", no 
>>>>>>>>> longer make sense.
>>>>>>>>>
>>>>>>>>> On the other hand, you will need to access impact of the name 
>>>>>>>>> changes, including abbreviations. Also, if you change the long 
>>>>>>>>> names, their translations will need to be changed as well.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Masayoshi
>>>>>>>>>
>>>>>>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please, review the tzdata2014f integration (with tzdata2014e 
>>>>>>>>>> related changes included too) [1] fix to JDK9: 
>>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
>>>>>>>>>>
>>>>>>>>>> The tzdata2014f changes are extensive and relates mostly to 
>>>>>>>>>> timezone short names changes + "Asia/Srednekolymsk" time zone 
>>>>>>>>>> were added.
>>>>>>>>>> Almost complete list of changes can be found in the JBS bug 
>>>>>>>>>> description [1], plus some changes wasn't documented in 
>>>>>>>>>> tzdata release notes - for such cases raw tzdata diff was 
>>>>>>>>>> used for the names modifications.
>>>>>>>>>>
>>>>>>>>>> Two issues with JSR310 implementation were discovered during 
>>>>>>>>>> integration process:
>>>>>>>>>> First issue is related to the internal representation of the 
>>>>>>>>>> '24:00' value. The JSR310 implementation treats this value as 
>>>>>>>>>> a next day 00:00 time. The workaround already exists in 
>>>>>>>>>> JSR310 code for similar entries and this failure is resolved 
>>>>>>>>>> in similar way [2] as part of this update.
>>>>>>>>>> For the second issue JDK-8051641 [3] was filled and 
>>>>>>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only 
>>>>>>>>>> one that fails with this tzdata.
>>>>>>>>>> Other time zone related tests [4] passes without failures.
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Aleksej
>>>>>>>>>>
>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
>>>>>>>>>> [2] 
>>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
>>>>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
>>>>>>>>>> [4] TZ related test sets: test/sun/util/calendar 
>>>>>>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone 
>>>>>>>>>> test/sun/util/calendar test/java/util/TimeZone 
>>>>>>>>>> test/java/time\ test/java/util/Formatter 
>>>>>>>>>> test/closed/java/util/Calendar test/closed/java/util/TimeZone
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From vladimir.x.ivanov at oracle.com  Tue Sep  2 13:57:47 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 02 Sep 2014 17:57:47 +0400
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF
Message-ID: <5405CCDB.6040706@oracle.com>

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

LambdaFormEditor provides an API to transform LambdaForms. Deriving new 
LambdaForms from a base one allows to cache and reuse results of 
repeated transformations.

BMH binding is rewritten to use LambdaFormEditor.

Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ 
"-ea -esa" and COMPILE_THRESHOLD={0,30}.

Reviewed-by: vlivanov, ?
Contributed-by: john.r.rose at oracle.com

Thanks!

Best regards,
Vladimir Ivanov


From vladimir.x.ivanov at oracle.com  Tue Sep  2 13:59:42 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 02 Sep 2014 17:59:42 +0400
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <5405CCDB.6040706@oracle.com>
References: <5405CCDB.6040706@oracle.com>
Message-ID: <5405CD4E.4070409@oracle.com>

Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00

Best regards,
Vladimir Ivanov

On 9/2/14, 5:57 PM, Vladimir Ivanov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8057042
>
> LambdaFormEditor provides an API to transform LambdaForms. Deriving new
> LambdaForms from a base one allows to cache and reuse results of
> repeated transformations.
>
> BMH binding is rewritten to use LambdaFormEditor.
>
> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/
> "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>
> Reviewed-by: vlivanov, ?
> Contributed-by: john.r.rose at oracle.com
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From yasuenag at gmail.com  Tue Sep  2 14:52:23 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 02 Sep 2014 23:52:23 +0900
Subject: JDP broadcaster issue
Message-ID: <5405D9A7.3030405@gmail.com>

Hi all,

I'm trying to use JDP on my Fedora20 machine.
My machine has two NICs and only one NIC is up.

I passed system properties as below, however JDP broadcaster
thread was not started:

  -Dcom.sun.management.jmxremote.port=7091
  -Dcom.sun.management.jmxremote.authenticate=false
  -Dcom.sun.management.jmxremote.ssl=false
  -Dcom.sun.management.jmxremote.autodiscovery=true
  -Dcom.sun.management.jdp.name=TEST

I checked exceptions with jdb, SocketException was occurred in
JDPControllerRunner#run(), and it was caused by another NIC
is down.

Currently, DiagramChannel which is used in JDPBroadcaster
tries to send JDP packet through all "UP" NICs.
However, NIC which is controlled by NetworkManager seems to
be still "UP" when ifdown command is executed.
(It seems to be removed IP address from NIC only.)


This problem may be Fedora, however I think it should be
improved in JDK.
I've created a patch as below, and it works fine in my environment.
(jdk9/dev/jdk)

If this patch may be accepted, I will file this to JBS.

--------------------
diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java
--- a/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java	Mon Sep 01 13:33:28 2014 +0200
+++ b/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java	Tue Sep 02 23:25:50 2014 +0900
@@ -35,6 +35,7 @@
 import java.nio.ByteBuffer;
 import java.nio.channels.DatagramChannel;
 import java.nio.channels.UnsupportedAddressTypeException;
+import java.util.Enumeration;
 
 /**
  * JdpBroadcaster is responsible for sending pre-built JDP packet across a Net
@@ -79,6 +80,15 @@
         if (srcAddress != null) {
             // User requests particular interface to bind to
             NetworkInterface interf = NetworkInterface.getByInetAddress(srcAddress);
+
+            if (interf == null) {
+                throw new JdpException("Unable to get network interface for " + srcAddress.toString());
+            }
+
+            if (!interf.isUp() || !interf.supportsMulticast()) {
+                throw new JdpException(interf.getName() + " does not support multicast.");
+            }
+
             try {
                 channel.bind(new InetSocketAddress(srcAddress, 0));
             } catch (UnsupportedAddressTypeException ex) {
@@ -86,6 +96,23 @@
             }
             channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, interf);
         }
+        else {
+            Enumeration<NetworkInterface> nics = NetworkInterface.getNetworkInterfaces();
+            while (nics.hasMoreElements()) {
+                NetworkInterface nic = nics.nextElement();
+
+                if (nic.isUp() && nic.supportsMulticast()) {
+                    try {
+                        channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
+                    } catch (IOException ex) {
+                        System.err.println("WARNING: JDP broadcaster cannot use " + nic.getName() + ": " + ex.getMessage());
+                    }
+                }
+
+            }
+
+        }
+
     }
 
     /**
--------------------


Thanks,

Yasumasa



From dmitry.samersoff at oracle.com  Tue Sep  2 16:50:09 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 02 Sep 2014 20:50:09 +0400
Subject: JDP broadcaster issue
In-Reply-To: <5405D9A7.3030405@gmail.com>
References: <5405D9A7.3030405@gmail.com>
Message-ID: <5405F541.1090809@oracle.com>

Yasumasa,

Thank you for the patch. I'll create a bug for it.

-Dmitry

On 2014-09-02 18:52, Yasumasa Suenaga wrote:
> Hi all,
> 
> I'm trying to use JDP on my Fedora20 machine.
> My machine has two NICs and only one NIC is up.
> 
> I passed system properties as below, however JDP broadcaster
> thread was not started:
> 
>   -Dcom.sun.management.jmxremote.port=7091
>   -Dcom.sun.management.jmxremote.authenticate=false
>   -Dcom.sun.management.jmxremote.ssl=false
>   -Dcom.sun.management.jmxremote.autodiscovery=true
>   -Dcom.sun.management.jdp.name=TEST
> 
> I checked exceptions with jdb, SocketException was occurred in
> JDPControllerRunner#run(), and it was caused by another NIC
> is down.
> 
> Currently, DiagramChannel which is used in JDPBroadcaster
> tries to send JDP packet through all "UP" NICs.
> However, NIC which is controlled by NetworkManager seems to
> be still "UP" when ifdown command is executed.
> (It seems to be removed IP address from NIC only.)
> 
> 
> This problem may be Fedora, however I think it should be
> improved in JDK.
> I've created a patch as below, and it works fine in my environment.
> (jdk9/dev/jdk)
> 
> If this patch may be accepted, I will file this to JBS.
> 
> --------------------
> diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java
> --- a/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java	Mon Sep 01 13:33:28 2014 +0200
> +++ b/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java	Tue Sep 02 23:25:50 2014 +0900
> @@ -35,6 +35,7 @@
>  import java.nio.ByteBuffer;
>  import java.nio.channels.DatagramChannel;
>  import java.nio.channels.UnsupportedAddressTypeException;
> +import java.util.Enumeration;
>  
>  /**
>   * JdpBroadcaster is responsible for sending pre-built JDP packet across a Net
> @@ -79,6 +80,15 @@
>          if (srcAddress != null) {
>              // User requests particular interface to bind to
>              NetworkInterface interf = NetworkInterface.getByInetAddress(srcAddress);
> +
> +            if (interf == null) {
> +                throw new JdpException("Unable to get network interface for " + srcAddress.toString());
> +            }
> +
> +            if (!interf.isUp() || !interf.supportsMulticast()) {
> +                throw new JdpException(interf.getName() + " does not support multicast.");
> +            }
> +
>              try {
>                  channel.bind(new InetSocketAddress(srcAddress, 0));
>              } catch (UnsupportedAddressTypeException ex) {
> @@ -86,6 +96,23 @@
>              }
>              channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, interf);
>          }
> +        else {
> +            Enumeration<NetworkInterface> nics = NetworkInterface.getNetworkInterfaces();
> +            while (nics.hasMoreElements()) {
> +                NetworkInterface nic = nics.nextElement();
> +
> +                if (nic.isUp() && nic.supportsMulticast()) {
> +                    try {
> +                        channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
> +                    } catch (IOException ex) {
> +                        System.err.println("WARNING: JDP broadcaster cannot use " + nic.getName() + ": " + ex.getMessage());
> +                    }
> +                }
> +
> +            }
> +
> +        }
> +
>      }
>  
>      /**
> --------------------
> 
> 
> Thanks,
> 
> Yasumasa
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


From mike.duigou at oracle.com  Tue Sep  2 17:01:25 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 2 Sep 2014 10:01:25 -0700
Subject: Impact of code difference in Collection#contains() worth
	improving?
In-Reply-To: <CAFNq5NNOWE+2EdWAQtNReD6jWoW7vZm3e9VMFZjveEQCtT_qug@mail.gmail.com>
References: <CAFNq5NN9K5-Z2U-zSFUV7kFd-GVW7V+fyx92+QdWj_oVr1mRMA@mail.gmail.com>
	<CAFNq5NNOWE+2EdWAQtNReD6jWoW7vZm3e9VMFZjveEQCtT_qug@mail.gmail.com>
Message-ID: <85D3F942-E556-4841-B2BC-63CF63BFA0B6@oracle.com>

Hi Fabian;

This has been an excellent discussion and thank you for starting it! Even if there is disagreement on various aspects I don't believe that anyone is upset or angry.


Mike

On Aug 30 2014, at 10:04 , Fabian Lange <lange.fabian at gmail.com> wrote:

> Hello dear list,
> 
> it was not my intention to steal precious developer time by annoying
> you guys with my finding.
> I really wanted to understand why there is a source difference. So I
> went ahead and looked at it from the only aspect I could estimate
> contributing to it.
> I am well aware of the fact that JIT does an amazing job optimizing
> code, so it surprises me how in some replies there is an negative
> undertone and randomness attributed to JIT.
> Right now I assume that my question upset some people, because it is
> of course not nice that people question code which was written over a
> decade ago.
> If not discussing the question on a technical level, I do not know why
> the argument of time wasting on micro level is made in multiple page
> long e-mails, which for sure also took precious time to write.

Having the right perspective is important to know how to handle specific situations. I believe the longer emails are mostly discussion of the general case and considerations involved in deciding what to do in a situation such as this. If they provide future guidance then they have done their job.

> 
> So thanks to everybody who taught me a bit about inner workings of JIT,
> and special thanks to Martin who did have the courage to submit a bug
> and webrev!

Indeed! He even found a few more cases to adjust.

Mike

> 
> Fabian:
> 
> PS: Out of curiosity I looked at the contains implementation here:
> https://android.googlesource.com/platform/libcore/+/master/luni/src/main/java/java/util/LinkedList.java
> it is manually inlined to avoid counting the position at all.
> I wonder if JIT would do that at any point as well.
> 
> On Wed, Aug 27, 2014 at 4:02 PM, Fabian Lange <lange.fabian at gmail.com> wrote:
>> Hi all,
>> I have been involved recently in some theoretical or nonsensical
>> discussions about microbenchmarking, jit compiling assemblies and so
>> fort.
>> One example was LinkedList vs ArrayList.
>> 
>> What I noticed is that those two have a different implementation for contains():
>> 
>> ArrayList:
>> 
>>    public boolean contains(Object o) {
>>        return indexOf(o) >= 0;
>>    }
>> 
>> LinkedList:
>> 
>>    public boolean contains(Object o) {
>>        return indexOf(o) != -1;
>>    }
>> 
>> Logically this is of course identical due to the contract of contains
>> which returns either -1 or the >=0 index of the element.
>> 
>> This code has been like this almost forever, and I was wondering if
>> this actually makes a difference in CPU cycles.
>> 
>> And in fact this code compiles into different assembler instructions.
>> The array list does a test against 0 and conditional move, while the
>> linked list does a jump equals on -1.
>> 
>> Again that is not surprising, because the actual java source is
>> different. But I wonder if both options are equally good in cold
>> performance and when jitted based on parameter values.
>> 
>> Wouldn't one implementation be better than the other? And why is not
>> the "better" implementation taken in both classes (and maybe other
>> Collections which use indexOf) ?
>> 
>> Is the answer that this has always been like this and the benefit is
>> not worth the risk of touching ancient code?
>> 
>> And if not for performance, would code clarify and similarity be an argument?
>> 
>> (this message was posted to jdk8-dev initially, thanks to Dalibor
>> Topic for the pointer to this list)
>> 
>> Fabian



From mike.duigou at oracle.com  Tue Sep  2 17:04:26 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Tue, 2 Sep 2014 10:04:26 -0700
Subject: Impact of code difference in Collection#contains() worth
	improving?
In-Reply-To: <CA+kOe0_sH1HhpMVR4iFj2xH+FmCJywO7n63k8E1v5s9gT65qbA@mail.gmail.com>
References: <CAFNq5NN9K5-Z2U-zSFUV7kFd-GVW7V+fyx92+QdWj_oVr1mRMA@mail.gmail.com>
	<CA+kOe09wi67q7dEiwCSW72qqe55n-X5kmh+Cu+NRpeY2x-57Yw@mail.gmail.com>
	<53FF6680.9000907@CoSoCo.de>
	<CAHjP37F=+j0jRsm6+a-94qgwfXiM4SngM5+odYQKo+BZukNoRA@mail.gmail.com>
	<5400DCF0.6090302@CoSoCo.de>
	<CA+kOe0_sH1HhpMVR4iFj2xH+FmCJywO7n63k8E1v5s9gT65qbA@mail.gmail.com>
Message-ID: <50DAE5A1-930B-403E-8C63-8A1235B3E3F4@oracle.com>

Looks fine (bug updated with noreg-perf). I do think we should consider promoting a copy of this method to AbstractList as it generally allows for a much better implementation than AbstractCollection's contains().

Mike

On Aug 29 2014, at 14:56 , Martin Buchholz <martinrb at google.com> wrote:

> Just think - one whole byte saved for each individual change!
> I have a webrev!
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/pico-optimize-contains/
> https://bugs.openjdk.java.net/browse/JDK-8056951
> 
> Can haz review please?
> 
> 
> On Fri, Aug 29, 2014 at 1:05 PM, Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:
> 
>> 
>> Am 28.08.2014 um 19:46 schrieb Vitaly Davidovich:
>> 
>> 
>>> There's no register pressure - the immediate (I.e. -1) is encoded
>>> directly into the instruction, just like 0 would be.  The time when 0 is
>>> particularly useful is when you test for it in the zero bit of the flags
>>> register (e.g. dec followed by jz, such as when counting a loop down to
>>> 0).  Otherwise, I don't see any advantage from machine code perspective.
>>> 
>>> 
>> Thanks for explaining this, but a very little nit: the immediate (I.e. -1)
>> uses additional 32/64 bits in code which must be loaded from memory and
>> wastes space in CPU cache or am I wrong? This could be saved with >= 0.
>> 
>> So if unifying the code I agree to Martin's opinion.
>> 
>> -Ulf
>> 
>> The aforementioned cmov instruction is not without its own downsides, so
>>> it's unclear which is better when branch probability isn't known a priori.
>>> 
>>> The 1 byte code is unlikely to make any difference, unless jit is turned
>>> off and you're running this through a tight loop in the interpreter (but if
>>> one does that, perf conversation is moot :)).
>>> 
>>> Sent from my phone
>>> 
>>> On Aug 28, 2014 1:28 PM, "Ulf Zibis" <Ulf.Zibis at cosoco.de <mailto:
>>> Ulf.Zibis at cosoco.de>> wrote:
>>> 
>>> 
>>>    Am 27.08.2014 um 17:51 schrieb Martin Buchholz:
>>> 
>>>        The ArrayList version saves one byte of bytecode, and is
>>> therefore very
>>>        slightly better.  We should bless that version and use it
>>> consistently.
>>> 
>>> 
>>>    +1
>>>    Additional argument:
>>>    The LinkedList code requires to load 32/64-Bit -1 into CPU. This may
>>> take some time on some
>>>    CPU and at least wastes memory footprint.
>>>    Additionally register pressure increases.
>>>    Vitaly, please correct me, if I'm wrong, just for learning more.
>>> 
>>>    Another advantage is that there is no problem if some implementation
>>> of indexOf() erroneously
>>>    returns another negative value than -1. I remember some compare()
>>> implementations, which
>>>    sometimes return different values than only -1, 0, +1.
>>> 
>>>    -Ulf
>>> 
>>>            ArrayList:
>>> 
>>>                 public boolean contains(Object o) {
>>>                     return indexOf(o) >= 0;
>>>                 }
>>> 
>>>            LinkedList:
>>> 
>>>                 public boolean contains(Object o) {
>>>                     return indexOf(o) != -1;
>>>                 }
>>> 
>>> 
>>> 
>> 



From stanimir at riflexo.com  Wed Sep  3 00:15:12 2014
From: stanimir at riflexo.com (Stanimir Simeonoff)
Date: Wed, 3 Sep 2014 03:15:12 +0300
Subject: Why is finalize wrong?
In-Reply-To: <24689252.yEYuCUqD1k@logouticek>
References: <2296697.ZmJV3U9KFH@logouticek> <100490444.vZHLe3CSFC@logouticek>
	<53D77C35.9050805@oracle.com> <24689252.yEYuCUqD1k@logouticek>
Message-ID: <CAEJX8oon5teH571S+ZLgg9+aDkkryidnb8aK=7Oqo-rENMqTgw@mail.gmail.com>

Hi Jaroslav,

In my opinion the greatest downside of the finalize() is that involves
enlisting in a shared queue prior to the object creation. The queue is
shared amongst the entire VM and that could be a potential bottleneck.
In practical terms having a finalize method involves a full memory fence
when a new instance is created (or cloned) and removing a finalize() method
can break some racy code.

Like David Lloyd mentioned finalize() can be invoked concurrently to some
methods (if there is no reachability to 'this'). OTOH I see finalize useful
for managing native resources mostly and possibly stopping (signaling)
threads left unmanaged. In that particular case synchronization is a must,
so it comes naturally.

Personally I never use dedicated threads with ReferenceQueue but I poll
(expunge) the queue on add/put. If the there are too many successful
ReferenceQueue.poll() hijacking the Finalizer thread is an option.
Something among the lines:

  public static interface Cleaner<T, Ref extends Reference<? extends T>>{
    void clean(Ref ref);
  }

  public static <T, Ref extends Reference<? extends T>> void
expunge(Cleaner<T, Ref> cleaner, final ReferenceQueue<T> queue, int
expungeThreshold){
    Reference<? extends T> w=queue.poll();
    if (w==null)
      return;//keep the method short, so it's inlined; queue being empty is
the fast lane

    expungeImpl(cleaner, w, queue, expungeThreshold);
  }

  static <T, Ref extends Reference<? extends T>> void expungeImpl(final
Cleaner<T, Ref> cleaner, Reference<? extends T> ref, final
ReferenceQueue<T> queue, int expungeThreshold){
    expunge(cleaner, ref);
    for (;--expungeThreshold>0  && null!=(ref=queue.poll());){
      expunge(cleaner, ref);
    }
    if (expungeThreshold==0){//delegate a full expunge to the finalizer
      //the anon. class stores cleaner and queue in fields, and the c-tor
has happens before with finalize() unlike any other method
      new Object(){//feel free to extend/wrap WeakRefence(cleaner) and also
keep weak ref to queue useful for non-native resources
        protected void finalize(){//keep in mind: the execution of
cleaner.clean(Ref) will not have the right ContextClassLoader, ThreadGroup,
AccessControlContext
          expunge(cleaner, queue, Integer.MAX_VALUE);
        }
      };
    }
  }

  @SuppressWarnings("unchecked")
  private static <T, Ref extends Reference<? extends T>> void
expunge(Cleaner<T, Ref> cleaner, Reference<? extends T> ref){
    cleaner.clean((Ref) ref);
  }

Some colorization:
http://pastebin.com/1V9Jhavz

Of course the finalize method is not guaranteed to execute at all but if
expungeThreshold is greater than 1 and expunge is called on each add/put
operation, still it should be ok.

Cheers
Stanimir



On Mon, Aug 4, 2014 at 4:46 PM, Jaroslav Tulach <jaroslav.tulach at oracle.com>
wrote:

> Hi.
> Last week we touched topic of finalization and what is wrong with it. I
> proposed three
> reasons why Object.finalize is bad. Is it correct and extensive list or
> would you change
> it or expand it? Thanks as ...
>
> > > # 1 - Because of automatic JDK management thread?
> > > # 2 - Or because once finalize() is called, one still has reference to
> the
> > > "gone" object and can re-activate it?
> > > #3 - Or because the finalizer thread is shared between completely
> > > unrelated
> > > objects and misbehavior of one can cause problems for others?
>
> ...I consider #2 the worst idea:
>
> > > My personal top three starts with #2. That is logically invalid. #3
> can be
> > > a problem, but so can be any other misbehaving thread in an
> application.
> > > #1 is completely OK, from my perspective
>
> and I think I got some support...
>
> > Weak references and reference queues were introduced to address some of
> > the short comings of finalization as well as providing other
> > capabilities within a GC'd environment.
>
> ...I just have to say that the Reference&ReferenceQueue as of JDK8 is not
> enough. As
> the case of activeReferenceQueue shows, the fact that each instance of
> ReferenceQueue where one uses remove() needs one dedicated thread is a big
> flaw.
> Fixing the flaw in an external library is not easy (see the summary from
> last week:
>
> https://bugs.openjdk.java.net/browse/JDK-8051843?focusedCommentId=13531670&p
> [1]age=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel#comment-13531670).
>
> Moreover David Holmes finds introductions of new system level threads
> uneasy:
>
> > The threading aspect is somewhat tangential. Any time you choose to
> > introduce a new thread to perform a task you have to be concerned about
> > the lifetime of the task and thus the thread.
>
> But when thinking about it, we can have functionality of
> activeReferenceQueue in JDK
> without introducing any new thread! We can reuse the existing finalizer
> one!
>
> I plan to propose a patch which will look at the activeReferenceQueue
> problem from a
> completely new perspective and offer "lightweight finalize" solution that
> will have
> above discussed properties #1 and #3, but will not suffer from #2 (the
> biggest
> problem with Object.finalize).
>
> I just wanted to ask before I start: Is somebody aware of other problems
> with
> Object.finalize than #1, #2 and #3?
> -jt
>
>
>
> --------
> [1]
>
> https://bugs.openjdk.java.net/browse/JDK-8051843?focusedCommentId=13531670&p
>


From michael.fang at oracle.com  Wed Sep  3 06:07:52 2014
From: michael.fang at oracle.com (Michael Fang)
Date: Tue, 02 Sep 2014 23:07:52 -0700
Subject: RFR: 8049343: (tz) Support tzdata2014g
In-Reply-To: <54047E64.9020206@oracle.com>
References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com>
	<53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com>
	<53F734D8.1000801@oracle.com> <53FD9819.7080000@oracle.com>
	<53FDE2CD.8040709@oracle.com> <53FEA567.9020601@oracle.com>
	<54047E64.9020206@oracle.com>
Message-ID: <5406B038.4070807@oracle.com>

Aleksej,

Yes, I agree the translation update of the time zone names can be 
handled separately as JDK-8057004.

thanks,

-michael

On 14?09?01? 07:10 ??, Aleksej Efimov wrote:
> Masayoshi,
>
> I have addressed all your comments with proposed resolution. Thank you 
> for such thorough analysis of this changes.
>
> Also the new tzdata is out (2014g) - I have updated the JBS bug by 
> adding 2014g related change notes and renamed this bug appropriately + 
> I'm renaming this thread.
> The new webrev contains new changes related to 2014g:
> -            {"America/Grand_Turk", EST},
> +            {"America/Grand_Turk", AST},
>
>
> The 2014e/f related changes, discussed previously, are still in place.
>
> New webrev can be found here: 
> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04
>
> The bug for the incomplete localization of new/updated time zone names 
> was filed: https://bugs.openjdk.java.net/browse/JDK-8057004
>
> With Best Regards,
> Aleksej
>
> On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote:
>>  src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
>>
>>  239         String SLST[] = new String[] {"Greenwich Mean Time", "GMT",
>>  240                                       "Sierra Leone Summer 
>> Time", "SLST",
>>  241                                       "Sierra Leone Time", "SLT"};
>>
>>  251         String WART[] = new String[] {"Western Argentine Time", 
>> "WART",
>>  252                                       "Western Argentine Summer 
>> Time", "WARST",
>>  253                                       "Western Argentine Time", 
>> "WART"};
>>
>> It seems these are no longer used.
>>
>> -            {"Antarctica/Macquarie", new String[] {"Macquarie Island 
>> Time", "MIST",
>> -                                                   "Macquarie Island 
>> Summer Time", "MIST",
>> +            {"Antarctica/Macquarie", new String[] {"Macquarie Island 
>> Standard Time", "MIST",
>> +                                                   "Macquarie Island 
>> Daylight Time", "MIST",
>>
>> The daylight saving time abbreviation should be MIDT.
>>
>> Thanks,
>> Masayoshi
>>
>> On 8/27/2014 10:53 PM, Aleksej Efimov wrote:
>>> Masayoshi,
>>> Thank you for a detailed review - I tried to address all your 
>>> comments. Please, see the updated review: 
>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03
>>> About the workarounds - I will start discussion with Sherman when 
>>> the tzdata2014f (and I suppose the 2014g - it will be available soon 
>>> according to tzdata mail-list [1]) integration will be complete.
>>>
>>> -Aleksej
>>>
>>> [1] tzdata2014g is coming: 
>>> http://mm.icann.org/pipermail/tz/2014-August/021528.html
>>>
>>> On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote:
>>>> Here are additional comments.
>>>>
>>>> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:
>>>>
>>>> I'm concerned about the workarounds. It's not new in this update, 
>>>> but this problem would make tzupdater data void until the 
>>>> workaround is added to the next update release. Could you please 
>>>> work with Sherman to eliminate the workaround (outside of this 
>>>> 2014f update)?
>>>>
>>>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
>>>>
>>>>          String LORD_HOWE[] = new String[] {"Lord Howe Standard 
>>>> Time", "LHST",
>>>> -                                           "Lord Howe Summer 
>>>> Time", "LHST",
>>>> +                                           "Lord Howe Summer 
>>>> Time", "LHDT",
>>>>
>>>> The S-D convention is applied to Lord Howe as well.
>>>>
>>>>  567             {"Antarctica/Macquarie", new String[] {"Macquarie 
>>>> Island Time", "MIST",
>>>>  568 "Macquarie Island Summer Time", "MIST",
>>>>  569 "Macquarie Island Time", "MIST"}},
>>>>
>>>> This one should also follow the S-D convention, although this time 
>>>> zone doesn't observe daylight saving time.
>>>>
>>>>
>>>> +        String XJT[] = new String[] {"China Standard Time", "XJT",
>>>> +                                     "China Daylight Time", "XJDT",
>>>> +                                     "China Time", "XJT"};
>>>>
>>>> Should the long names be based on Xinjiang?
>>>>
>>>> Africa/Freetown is now a link to Africa/Abidjan. Those should be 
>>>> the same time zone.
>>>>
>>>> -            {"America/Metlakatla", new String[] {"Metlakatla 
>>>> Standard Time", "MeST",
>>>> -                                                 "Metlakatla 
>>>> Daylight Time", "MeDT",
>>>> -                                                 "Metlakatla 
>>>> Time", "MeT"}},
>>>> +            {"America/Metlakatla", new String[] {"Metlakatla 
>>>> Standard Time", "PST",
>>>> +                                                 "Metlakatla 
>>>> Daylight Time", "PDT",
>>>> +                                                 "Metlakatla 
>>>> Time", "PT"}},
>>>>
>>>> -            {"Europe/Volgograd", new String[] {"Volgograd Time", 
>>>> "VOLT",
>>>> -                                               "Volgograd Summer 
>>>> Time", "VOLST",
>>>> -                                               "Volgograd Time", 
>>>> "VOLT"}},
>>>> +            {"Europe/Volgograd", new String[] {"Volgograd Time", 
>>>> "MSK",
>>>> +                                               "Volgograd Summer 
>>>> Time", "MSK",
>>>> +                                               "Volgograd Time", 
>>>> "MSK"}},
>>>>
>>>>
>>>> The long names should be changed accordingly.
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 8/22/2014 9:17 PM, Aleksej Efimov wrote:
>>>>> Masayoshi,
>>>>> You're right that the "root names" should be changed as part of 
>>>>> this update. The names were changed according to Australian 
>>>>> official document here: 
>>>>> http://australia.gov.au/about-australia/our-country/time
>>>>> The fixed version of the webrev can be found here: 
>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02
>>>>>
>>>>> Thanks,
>>>>> Aleksej
>>>>>
>>>>>
>>>>> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote:
>>>>>> We used to make name changes in the root (base) bundle as part of 
>>>>>> time zone data maintenance and deter only translations. But if 
>>>>>> you want to handle name changes later, that would be fine. It's 
>>>>>> your call.
>>>>>>
>>>>>> Thanks,
>>>>>> Masayoshi
>>>>>>
>>>>>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote:
>>>>>>> Masayoshi,
>>>>>>> I agree that we should change the long names to match the new 
>>>>>>> short names introduced by tzdata.
>>>>>>> But I suggest to log a different CR for such activity to handle 
>>>>>>> long name changes and their translations (this activity is 
>>>>>>> slightly out of tzdata update scope). Does it make sense?
>>>>>>>
>>>>>>> -Aleksej
>>>>>>>
>>>>>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
>>>>>>>> I think the long names of the Australia time zones should be 
>>>>>>>> revisited to be consistent with the abbreviation changes. The 
>>>>>>>> new abbreviations follow the S[tandard] and D[aylight saving] 
>>>>>>>> convention rather than the S[tandard] and S[ummer time] one. 
>>>>>>>> The long names, such as "Eastern Summer Time (Queensland)", no 
>>>>>>>> longer make sense.
>>>>>>>>
>>>>>>>> On the other hand, you will need to access impact of the name 
>>>>>>>> changes, including abbreviations. Also, if you change the long 
>>>>>>>> names, their translations will need to be changed as well.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Masayoshi
>>>>>>>>
>>>>>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please, review the tzdata2014f integration (with tzdata2014e 
>>>>>>>>> related changes included too) [1] fix to JDK9: 
>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
>>>>>>>>>
>>>>>>>>> The tzdata2014f changes are extensive and relates mostly to 
>>>>>>>>> timezone short names changes + "Asia/Srednekolymsk" time zone 
>>>>>>>>> were added.
>>>>>>>>> Almost complete list of changes can be found in the JBS bug 
>>>>>>>>> description [1], plus some changes wasn't documented in tzdata 
>>>>>>>>> release notes - for such cases raw tzdata diff was used for 
>>>>>>>>> the names modifications.
>>>>>>>>>
>>>>>>>>> Two issues with JSR310 implementation were discovered during 
>>>>>>>>> integration process:
>>>>>>>>> First issue is related to the internal representation of the 
>>>>>>>>> '24:00' value. The JSR310 implementation treats this value as 
>>>>>>>>> a next day 00:00 time. The workaround already exists in JSR310 
>>>>>>>>> code for similar entries and this failure is resolved in 
>>>>>>>>> similar way [2] as part of this update.
>>>>>>>>> For the second issue JDK-8051641 [3] was filled and 
>>>>>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only 
>>>>>>>>> one that fails with this tzdata.
>>>>>>>>> Other time zone related tests [4] passes without failures.
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Aleksej
>>>>>>>>>
>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
>>>>>>>>> [2] 
>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
>>>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
>>>>>>>>> [4] TZ related test sets: test/sun/util/calendar 
>>>>>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone 
>>>>>>>>> test/sun/util/calendar test/java/util/TimeZone test/java/time\ 
>>>>>>>>> test/java/util/Formatter test/closed/java/util/Calendar 
>>>>>>>>> test/closed/java/util/TimeZone
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From aph at redhat.com  Wed Sep  3 09:58:55 2014
From: aph at redhat.com (Andrew Haley)
Date: Wed, 03 Sep 2014 10:58:55 +0100
Subject: Why is finalize wrong?
In-Reply-To: <CAEJX8oon5teH571S+ZLgg9+aDkkryidnb8aK=7Oqo-rENMqTgw@mail.gmail.com>
References: <2296697.ZmJV3U9KFH@logouticek>
	<100490444.vZHLe3CSFC@logouticek>	<53D77C35.9050805@oracle.com>
	<24689252.yEYuCUqD1k@logouticek>
	<CAEJX8oon5teH571S+ZLgg9+aDkkryidnb8aK=7Oqo-rENMqTgw@mail.gmail.com>
Message-ID: <5406E65F.1090100@redhat.com>

On 03/09/14 01:15, Stanimir Simeonoff wrote:

> Like David Lloyd mentioned finalize() can be invoked concurrently to
> some methods (if there is no reachability to 'this'). OTOH I see
> finalize useful for managing native resources mostly and possibly
> stopping (signaling) threads left unmanaged. In that particular case
> synchronization is a must, so it comes naturally.

But finalize isn't useful for managing native resources because
finalizers may or may not run, as you note.  People will test their
programs with one implementation then discover, when their programs
are deployed, that they sometimes mysteriously fail.  In particular,
you might run out of file handles.

As Jarolsav put it, "I don't think this is explainable to regular Java
developers."  As David Lloyd put it, "If you still think that finalize
is a good idea, given that it's basically defective *and* there is
almost always a better solution, then I will be quite astounded."  As
I put it, "finalize is broken."

Andrew.


From sean.coffey at oracle.com  Wed Sep  3 10:05:42 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Wed, 03 Sep 2014 11:05:42 +0100
Subject: RFR : 8044725 :Bug in zlib 1.2.5 prevents inflation of some gzipped
	files (zlib 1.2.8 port)
Message-ID: <5406E7F6.4010904@oracle.com>

I'd like to port the zlib v1.2.8 libraries to JDK 7u. Currently, 7u uses 
zlib v1.2.3 libraries. 8u20 was recently upgraded to 1.2.8. zlib fixes 
since 1.2.3 can be found at 
http://cr.openjdk.java.net/~coffeys/webrev.8044725.7u/webrev/raw_files/new/src/share/native/java/util/zip/zlib-1.2.8/ChangeLog

While porting, I noticed that the Program.gmk had a bad reference in it 
to zlib 1.1.3 (JDK6  version) - I've corrected that to 1.2.8 for now but 
question if the extra INCLUDE directive is even needed.

bug report : https://bugs.openjdk.java.net/browse/JDK-8044725
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8044725.7u/webrev/

regards,
Sean.




From peter.levart at gmail.com  Wed Sep  3 11:24:19 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 03 Sep 2014 13:24:19 +0200
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <5405CD4E.4070409@oracle.com>
References: <5405CCDB.6040706@oracle.com> <5405CD4E.4070409@oracle.com>
Message-ID: <5406FA63.3050602@gmail.com>

On 09/02/2014 03:59 PM, Vladimir Ivanov wrote:
> Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00
>
> Best regards,
> Vladimir Ivanov

Hi Vladimir,

In LambdaFormEditor, where Transform[] is promoted into 
ConcurrentHashMap<Transform, Transform>:

  339                     ConcurrentHashMap<Transform, Transform> m = new ConcurrentHashMap<>(MAX_CACHE_ARRAY_SIZE * 2);
  340                     for (Transform k : ta) {
  341                         if (k != null)  continue;
  342                         m.put(k, k);
  343                     }
  344                     lambdaForm.transformCache = m;
  345                     // The second iteration will update for this query, concurrently.
  346                     continue;


I think line 341 is wrong. It should be:

     if (k == null) break;

shouldn't it?



Regards, Peter


>
> On 9/2/14, 5:57 PM, Vladimir Ivanov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8057042
>>
>> LambdaFormEditor provides an API to transform LambdaForms. Deriving new
>> LambdaForms from a base one allows to cache and reuse results of
>> repeated transformations.
>>
>> BMH binding is rewritten to use LambdaFormEditor.
>>
>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/
>> "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>>
>> Reviewed-by: vlivanov, ?
>> Contributed-by: john.r.rose at oracle.com
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From peter.levart at gmail.com  Wed Sep  3 11:43:37 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 03 Sep 2014 13:43:37 +0200
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <5405CD4E.4070409@oracle.com>
References: <5405CCDB.6040706@oracle.com> <5405CD4E.4070409@oracle.com>
Message-ID: <5406FEE9.6030000@gmail.com>

Hi Vladimir,

I'm sure you and John have thought about it through, but I'll ask 
anyway. Are cached LambdaForms going to stay around forever? What about 
using a WeakReference<LambdaForm> (LambdaFormEditor.Transform could 
extend WeakReference). This way unused LambdaForms would get GCed.

Regards, Peter

On 09/02/2014 03:59 PM, Vladimir Ivanov wrote:
> Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00
>
> Best regards,
> Vladimir Ivanov
>
> On 9/2/14, 5:57 PM, Vladimir Ivanov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8057042
>>
>> LambdaFormEditor provides an API to transform LambdaForms. Deriving new
>> LambdaForms from a base one allows to cache and reuse results of
>> repeated transformations.
>>
>> BMH binding is rewritten to use LambdaFormEditor.
>>
>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/
>> "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>>
>> Reviewed-by: vlivanov, ?
>> Contributed-by: john.r.rose at oracle.com
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From stanimir at riflexo.com  Wed Sep  3 11:48:40 2014
From: stanimir at riflexo.com (Stanimir Simeonoff)
Date: Wed, 3 Sep 2014 14:48:40 +0300
Subject: Why is finalize wrong?
In-Reply-To: <5406E65F.1090100@redhat.com>
References: <2296697.ZmJV3U9KFH@logouticek> <100490444.vZHLe3CSFC@logouticek>
	<53D77C35.9050805@oracle.com> <24689252.yEYuCUqD1k@logouticek>
	<CAEJX8oon5teH571S+ZLgg9+aDkkryidnb8aK=7Oqo-rENMqTgw@mail.gmail.com>
	<5406E65F.1090100@redhat.com>
Message-ID: <CAEJX8opBBARLx-fSOmZaJwyO8xw=5CVFHsBxxvxSSf-MjhYKnA@mail.gmail.com>

Hi Andrew,


On Wed, Sep 3, 2014 at 12:58 PM, Andrew Haley <aph at redhat.com> wrote:

> On 03/09/14 01:15, Stanimir Simeonoff wrote:
>
> > Like David Lloyd mentioned finalize() can be invoked concurrently to
> > some methods (if there is no reachability to 'this'). OTOH I see
> > finalize useful for managing native resources mostly and possibly
> > stopping (signaling) threads left unmanaged. In that particular case
> > synchronization is a must, so it comes naturally.
>
> But finalize isn't useful for managing native resources because
> finalizers may or may not run, as you note.  People will test their
> programs with one implementation then discover, when their programs
> are deployed, that they sometimes mysteriously fail.  In particular,
> you might run out of file handles.
>
> I meant cleaning up rather than managing per se. To make it clear:
finalization is no substitute for proper lifecycle - anything that has
open() should have a following up close(), otherwise it's a bug.
Finalization still helps as safenet vs leaving native resources totally
unallocated and leaking. Yet, finalizers have to run somehow since the
direct (and mapped) buffers very heavily rely on them. The direct/mapped
buffers are ones that don't have proper lifecycle, esp. the mapped ones
The latter don't offer munmap.
I believe the java.nio.Bits still includes a notorious call in a

static void reserveMemory(long size, int cap) {
//check if above the direct memory threashold and...
        System.gc();
        try {
            Thread.sleep(100);
        } catch (InterruptedException x) {
            // Restore interrupt status
            Thread.currentThread().interrupt();
        }
}
in an attempt to cope with the lack of proper and timely finalization.
Prior the fix the OOM when using DirectBuffers was quite guaranteed unless
pooling the buffers on your own.
On a flip note, I think it's kind of a bug as it has to manually call run
System.runFinalization() prior throwing the OOM, but it opts to sleep 100ms
instead.

If the finalizers don't run prior the process termination, that's ok as the
OS should be able to clean up any native resources allocated on its own.
However finalizers not running is not that different from a weak/phantom
reference not being enqueued, practically the odds are quite the same. The
impl. of the finalization is actually a high priority dedicated thread that
processes a ReferenceQueue.



> As Jarolsav put it, "I don't think this is explainable to regular Java
> developers."  As David Lloyd put it, "If you still think that finalize
> is a good idea, given that it's basically defective *and* there is
> almost always a better solution, then I will be quite astounded."  As
> I put it, "finalize is broken."
>
>
I'd not say "broken", as it works exactly as specified. Still I utterly
agree it requires pretty deep knowledge on the inner works to make it
somewhat useful.

Stanimir


From peter.levart at gmail.com  Wed Sep  3 12:41:01 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 03 Sep 2014 14:41:01 +0200
Subject: Why is finalize wrong?
In-Reply-To: <CAEJX8opBBARLx-fSOmZaJwyO8xw=5CVFHsBxxvxSSf-MjhYKnA@mail.gmail.com>
References: <2296697.ZmJV3U9KFH@logouticek>
	<100490444.vZHLe3CSFC@logouticek>	<53D77C35.9050805@oracle.com>
	<24689252.yEYuCUqD1k@logouticek>	<CAEJX8oon5teH571S+ZLgg9+aDkkryidnb8aK=7Oqo-rENMqTgw@mail.gmail.com>	<5406E65F.1090100@redhat.com>
	<CAEJX8opBBARLx-fSOmZaJwyO8xw=5CVFHsBxxvxSSf-MjhYKnA@mail.gmail.com>
Message-ID: <54070C5D.7030607@gmail.com>

Hi Stanimir, Andrew,

On 09/03/2014 01:48 PM, Stanimir Simeonoff wrote:
> Hi Andrew,
>
>
> On Wed, Sep 3, 2014 at 12:58 PM, Andrew Haley <aph at redhat.com> wrote:
>
>> On 03/09/14 01:15, Stanimir Simeonoff wrote:
>>
>>> Like David Lloyd mentioned finalize() can be invoked concurrently to
>>> some methods (if there is no reachability to 'this'). OTOH I see
>>> finalize useful for managing native resources mostly and possibly
>>> stopping (signaling) threads left unmanaged. In that particular case
>>> synchronization is a must, so it comes naturally.
>> But finalize isn't useful for managing native resources because
>> finalizers may or may not run, as you note.  People will test their
>> programs with one implementation then discover, when their programs
>> are deployed, that they sometimes mysteriously fail.  In particular,
>> you might run out of file handles.

Finalizers will eventually run, but they may not run on time. This could 
be fixed though (see below).

>>
>> I meant cleaning up rather than managing per se. To make it clear:
> finalization is no substitute for proper lifecycle - anything that has
> open() should have a following up close(), otherwise it's a bug.
> Finalization still helps as safenet vs leaving native resources totally
> unallocated and leaking. Yet, finalizers have to run somehow since the
> direct (and mapped) buffers very heavily rely on them.

DirectByteBuffers rely on Cleaner(s), which are PhanthomReferences and 
are managed (invoked) by the ReferenceHandler thread directly. 
Finalizers are just enqueued by ReferenceHandler thread, but they are 
invoked by the special FinalizerThread. That's because Cleaner(s) are 
internal JDK mechanism, while finalizers invoke client code so they can 
stall the FinalizerThread. A bug in a client code can bring 
FinalizerThread to a halt.

But there might be a cure for that at least for internal usage (for 
example: file handles)...

>   The direct/mapped
> buffers are ones that don't have proper lifecycle, esp. the mapped ones
> The latter don't offer munmap.
> I believe the java.nio.Bits still includes a notorious call in a
>
> static void reserveMemory(long size, int cap) {
> //check if above the direct memory threashold and...
>          System.gc();
>          try {
>              Thread.sleep(100);
>          } catch (InterruptedException x) {
>              // Restore interrupt status
>              Thread.currentThread().interrupt();
>          }
> }
> in an attempt to cope with the lack of proper and timely finalization.
> Prior the fix the OOM when using DirectBuffers was quite guaranteed unless
> pooling the buffers on your own.
> On a flip note, I think it's kind of a bug as it has to manually call run
> System.runFinalization() prior throwing the OOM, but it opts to sleep 100ms
> instead.

As said, DirectByteBuffer(s) use Cleaner(s), which are more predictable. 
But even with Cleaner(s), a multithreaded test could be constructed 
which reserves direct memory with greater rate than single 
ReferenceHandler thread can unreserve it. Until this was fixed:

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


An internal mechanism similar to that used in this patch could be 
devised for finalizers too. Allocation of native resources (like file 
handles) that are cleaned up by finalizers could use it to retry 
allocation if it fails, helping with cleanup on the way...

Peter

>
> If the finalizers don't run prior the process termination, that's ok as the
> OS should be able to clean up any native resources allocated on its own.
> However finalizers not running is not that different from a weak/phantom
> reference not being enqueued, practically the odds are quite the same. The
> impl. of the finalization is actually a high priority dedicated thread that
> processes a ReferenceQueue.
>
>
>
>> As Jarolsav put it, "I don't think this is explainable to regular Java
>> developers."  As David Lloyd put it, "If you still think that finalize
>> is a good idea, given that it's basically defective *and* there is
>> almost always a better solution, then I will be quite astounded."  As
>> I put it, "finalize is broken."
>>
>>
> I'd not say "broken", as it works exactly as specified. Still I utterly
> agree it requires pretty deep knowledge on the inner works to make it
> somewhat useful.
>
> Stanimir



From david.lloyd at redhat.com  Wed Sep  3 12:56:27 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 03 Sep 2014 07:56:27 -0500
Subject: Why is finalize wrong?
In-Reply-To: <CAEJX8opBBARLx-fSOmZaJwyO8xw=5CVFHsBxxvxSSf-MjhYKnA@mail.gmail.com>
References: <2296697.ZmJV3U9KFH@logouticek>
	<100490444.vZHLe3CSFC@logouticek>	<53D77C35.9050805@oracle.com>
	<24689252.yEYuCUqD1k@logouticek>	<CAEJX8oon5teH571S+ZLgg9+aDkkryidnb8aK=7Oqo-rENMqTgw@mail.gmail.com>	<5406E65F.1090100@redhat.com>
	<CAEJX8opBBARLx-fSOmZaJwyO8xw=5CVFHsBxxvxSSf-MjhYKnA@mail.gmail.com>
Message-ID: <54070FFB.9070404@redhat.com>

On 09/03/2014 06:48 AM, Stanimir Simeonoff wrote:
> Hi Andrew,
>
>
> On Wed, Sep 3, 2014 at 12:58 PM, Andrew Haley <aph at redhat.com> wrote:
>
>> On 03/09/14 01:15, Stanimir Simeonoff wrote:
>>
>>> Like David Lloyd mentioned finalize() can be invoked concurrently to
>>> some methods (if there is no reachability to 'this'). OTOH I see
>>> finalize useful for managing native resources mostly and possibly
>>> stopping (signaling) threads left unmanaged. In that particular case
>>> synchronization is a must, so it comes naturally.
>>
>> But finalize isn't useful for managing native resources because
>> finalizers may or may not run, as you note.  People will test their
>> programs with one implementation then discover, when their programs
>> are deployed, that they sometimes mysteriously fail.  In particular,
>> you might run out of file handles.
>>
>> I meant cleaning up rather than managing per se. To make it clear:
> finalization is no substitute for proper lifecycle - anything that has
> open() should have a following up close(), otherwise it's a bug.
> Finalization still helps as safenet vs leaving native resources totally
> unallocated and leaking. Yet, finalizers have to run somehow since the
> direct (and mapped) buffers very heavily rely on them. The direct/mapped
> buffers are ones that don't have proper lifecycle, esp. the mapped ones
> The latter don't offer munmap.

This is why everyone pools buffers.  The following code:

> static void reserveMemory(long size, int cap) {
> //check if above the direct memory threashold and...
>          System.gc();
>          try {
>              Thread.sleep(100);
>          } catch (InterruptedException x) {
>              // Restore interrupt status
>              Thread.currentThread().interrupt();
>          }
> }

is basically crap, and the first thing any serious NIO developer will do 
is defeat it with buffer pooling.

-- 
- DML


From peter.levart at gmail.com  Wed Sep  3 13:05:52 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 03 Sep 2014 15:05:52 +0200
Subject: Why is finalize wrong?
In-Reply-To: <54070FFB.9070404@redhat.com>
References: <2296697.ZmJV3U9KFH@logouticek>	<100490444.vZHLe3CSFC@logouticek>	<53D77C35.9050805@oracle.com>	<24689252.yEYuCUqD1k@logouticek>	<CAEJX8oon5teH571S+ZLgg9+aDkkryidnb8aK=7Oqo-rENMqTgw@mail.gmail.com>	<5406E65F.1090100@redhat.com>	<CAEJX8opBBARLx-fSOmZaJwyO8xw=5CVFHsBxxvxSSf-MjhYKnA@mail.gmail.com>
	<54070FFB.9070404@redhat.com>
Message-ID: <54071230.1030709@gmail.com>

On 09/03/2014 02:56 PM, David M. Lloyd wrote:
> On 09/03/2014 06:48 AM, Stanimir Simeonoff wrote:
>> Hi Andrew,
>>
>>
>> On Wed, Sep 3, 2014 at 12:58 PM, Andrew Haley <aph at redhat.com> wrote:
>>
>>> On 03/09/14 01:15, Stanimir Simeonoff wrote:
>>>
>>>> Like David Lloyd mentioned finalize() can be invoked concurrently to
>>>> some methods (if there is no reachability to 'this'). OTOH I see
>>>> finalize useful for managing native resources mostly and possibly
>>>> stopping (signaling) threads left unmanaged. In that particular case
>>>> synchronization is a must, so it comes naturally.
>>>
>>> But finalize isn't useful for managing native resources because
>>> finalizers may or may not run, as you note.  People will test their
>>> programs with one implementation then discover, when their programs
>>> are deployed, that they sometimes mysteriously fail.  In particular,
>>> you might run out of file handles.
>>>
>>> I meant cleaning up rather than managing per se. To make it clear:
>> finalization is no substitute for proper lifecycle - anything that has
>> open() should have a following up close(), otherwise it's a bug.
>> Finalization still helps as safenet vs leaving native resources totally
>> unallocated and leaking. Yet, finalizers have to run somehow since the
>> direct (and mapped) buffers very heavily rely on them. The direct/mapped
>> buffers are ones that don't have proper lifecycle, esp. the mapped ones
>> The latter don't offer munmap.
>
> This is why everyone pools buffers.  The following code:
>
>> static void reserveMemory(long size, int cap) {
>> //check if above the direct memory threashold and...
>>          System.gc();
>>          try {
>>              Thread.sleep(100);
>>          } catch (InterruptedException x) {
>>              // Restore interrupt status
>>              Thread.currentThread().interrupt();
>>          }
>> }
>
> is basically crap, and the first thing any serious NIO developer will 
> do is defeat it with buffer pooling.
>

I think I should backport the fix for it to 8u...

Regards, Peter



From vladimir.x.ivanov at oracle.com  Wed Sep  3 13:25:56 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 03 Sep 2014 17:25:56 +0400
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <5406FA63.3050602@gmail.com>
References: <5405CCDB.6040706@oracle.com> <5405CD4E.4070409@oracle.com>
	<5406FA63.3050602@gmail.com>
Message-ID: <540716E4.5080208@oracle.com>

Peter,

Thanks for the feedback.

 > In LambdaFormEditor, where Transform[] is promoted into
> ConcurrentHashMap<Transform, Transform>:
>
>   339                     ConcurrentHashMap<Transform, Transform> m =
> new ConcurrentHashMap<>(MAX_CACHE_ARRAY_SIZE * 2);
>   340                     for (Transform k : ta) {
>   341                         if (k != null)  continue;
>   342                         m.put(k, k);
>   343                     }
>   344                     lambdaForm.transformCache = m;
>   345                     // The second iteration will update for this
> query, concurrently.
>   346                     continue;
>
>
> I think line 341 is wrong. It should be:
>
>      if (k == null) break;
>
> shouldn't it?
Good catch! Fixed.

Best regards,
Vladimir Ivanov
>
>
>
> Regards, Peter
>
>
>>
>> On 9/2/14, 5:57 PM, Vladimir Ivanov wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8057042
>>>
>>> LambdaFormEditor provides an API to transform LambdaForms. Deriving new
>>> LambdaForms from a base one allows to cache and reuse results of
>>> repeated transformations.
>>>
>>> BMH binding is rewritten to use LambdaFormEditor.
>>>
>>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/
>>> "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>>>
>>> Reviewed-by: vlivanov, ?
>>> Contributed-by: john.r.rose at oracle.com
>>>
>>> Thanks!
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From vladimir.x.ivanov at oracle.com  Wed Sep  3 13:29:24 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 03 Sep 2014 17:29:24 +0400
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <5406FEE9.6030000@gmail.com>
References: <5405CCDB.6040706@oracle.com> <5405CD4E.4070409@oracle.com>
	<5406FEE9.6030000@gmail.com>
Message-ID: <540717B4.5010705@oracle.com>

Peter,

Yes, it's a known problem [1].
There are other caches (in MethodTypeForm, for example), which shouldn't 
retain their elements.

Best regards,
Vladimir Ivanov

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

On 9/3/14, 3:43 PM, Peter Levart wrote:
> Hi Vladimir,
>
> I'm sure you and John have thought about it through, but I'll ask
> anyway. Are cached LambdaForms going to stay around forever? What about
> using a WeakReference<LambdaForm> (LambdaFormEditor.Transform could
> extend WeakReference). This way unused LambdaForms would get GCed.
>
> Regards, Peter
>
> On 09/02/2014 03:59 PM, Vladimir Ivanov wrote:
>> Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 9/2/14, 5:57 PM, Vladimir Ivanov wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8057042
>>>
>>> LambdaFormEditor provides an API to transform LambdaForms. Deriving new
>>> LambdaForms from a base one allows to cache and reuse results of
>>> repeated transformations.
>>>
>>> BMH binding is rewritten to use LambdaFormEditor.
>>>
>>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/
>>> "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>>>
>>> Reviewed-by: vlivanov, ?
>>> Contributed-by: john.r.rose at oracle.com
>>>
>>> Thanks!
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


From Alan.Bateman at oracle.com  Wed Sep  3 13:29:41 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 03 Sep 2014 14:29:41 +0100
Subject: Why is finalize wrong?
In-Reply-To: <54070C5D.7030607@gmail.com>
References: <2296697.ZmJV3U9KFH@logouticek>	<100490444.vZHLe3CSFC@logouticek>	<53D77C35.9050805@oracle.com>	<24689252.yEYuCUqD1k@logouticek>	<CAEJX8oon5teH571S+ZLgg9+aDkkryidnb8aK=7Oqo-rENMqTgw@mail.gmail.com>	<5406E65F.1090100@redhat.com>	<CAEJX8opBBARLx-fSOmZaJwyO8xw=5CVFHsBxxvxSSf-MjhYKnA@mail.gmail.com>
	<54070C5D.7030607@gmail.com>
Message-ID: <540717C5.7040206@oracle.com>

On 03/09/2014 13:41, Peter Levart wrote:
>
> DirectByteBuffers rely on Cleaner(s), which are PhanthomReferences and 
> are managed (invoked) by the ReferenceHandler thread directly. 
> Finalizers are just enqueued by ReferenceHandler thread, but they are 
> invoked by the special FinalizerThread. That's because Cleaner(s) are 
> internal JDK mechanism, while finalizers invoke client code so they 
> can stall the FinalizerThread. A bug in a client code can bring 
> FinalizerThread to a halt.
>
Indeed and there is many a war story of badly written finalizers.

On direct buffers the recommendation has always been to cache those as 
there is a significant cost to allocation (there is wording on this in 
javadoc). Sometimes you can find code that repeatedly allocates, uses 
once and discards and this can certainly cause performance issues (and 
potentially OOME prior to your changes in this area).

-Alan


From aph at redhat.com  Wed Sep  3 13:57:57 2014
From: aph at redhat.com (Andrew Haley)
Date: Wed, 03 Sep 2014 14:57:57 +0100
Subject: Why is finalize wrong?
In-Reply-To: <CAEJX8opBBARLx-fSOmZaJwyO8xw=5CVFHsBxxvxSSf-MjhYKnA@mail.gmail.com>
References: <2296697.ZmJV3U9KFH@logouticek>	<100490444.vZHLe3CSFC@logouticek>	<53D77C35.9050805@oracle.com>	<24689252.yEYuCUqD1k@logouticek>	<CAEJX8oon5teH571S+ZLgg9+aDkkryidnb8aK=7Oqo-rENMqTgw@mail.gmail.com>	<5406E65F.1090100@redhat.com>
	<CAEJX8opBBARLx-fSOmZaJwyO8xw=5CVFHsBxxvxSSf-MjhYKnA@mail.gmail.com>
Message-ID: <54071E65.9040205@redhat.com>

Hi,

On 09/03/2014 12:48 PM, Stanimir Simeonoff wrote:
> Hi Andrew,
> 
> On Wed, Sep 3, 2014 at 12:58 PM, Andrew Haley <aph at redhat.com> wrote:
> 
>> On 03/09/14 01:15, Stanimir Simeonoff wrote:
>>
>>> Like David Lloyd mentioned finalize() can be invoked concurrently to
>>> some methods (if there is no reachability to 'this'). OTOH I see
>>> finalize useful for managing native resources mostly and possibly
>>> stopping (signaling) threads left unmanaged. In that particular case
>>> synchronization is a must, so it comes naturally.
>>
>> But finalize isn't useful for managing native resources because
>> finalizers may or may not run, as you note.  People will test their
>> programs with one implementation then discover, when their programs
>> are deployed, that they sometimes mysteriously fail.  In particular,
>> you might run out of file handles.
>>
> I meant cleaning up rather than managing per se. To make it clear:
> finalization is no substitute for proper lifecycle - anything that has
> open() should have a following up close(), otherwise it's a bug.
> Finalization still helps as safenet vs leaving native resources totally
> unallocated and leaking. 

But it doesn't help: as I discovered when trying to debug the PKCS1
crypto provider, long-lived objects move into the old gen, and until
there is a real shortage of heap memory, there is no old gen
collection, so native memory becomes exhausted.  It is impossible to
do it correctly; and we programmers comfort ourselves with the idea
that we're doing our best.

> Yet, finalizers have to run somehow since the direct (and mapped)
> buffers very heavily rely on them. The direct/mapped buffers are
> ones that don't have proper lifecycle, esp. the mapped ones
> The latter don't offer munmap.

True enough, but I suspect we only get away with it because it's not
always necessary to munmap a file: if it's not in use it'll all be
swapped out of memory, and the only significant resource leak will be
a file handle.  On 64-bit systems we still have plenty of address
space for this.  For now, anyway.

I admit that it's quite hard to solve the MappedByteBuffer.close()
problem efficiently while still providing security guarantees.

To some extent this discussion comes down to personal preference: I
don't think that incorrect solutions to the problem of resource
management help, because they give a false sense of security.  And I
think some people are in denial about finalization.

On a more positive note, I've had an idea.  How about we change the
generational collectors so that no object with a finalizer is ever
moved into the old gen?  this seems reasonable to me, given that the
primary purpose of finalizers is to free resources.

Andrew.


From stanimir at riflexo.com  Wed Sep  3 14:13:57 2014
From: stanimir at riflexo.com (Stanimir Simeonoff)
Date: Wed, 3 Sep 2014 17:13:57 +0300
Subject: Why is finalize wrong?
In-Reply-To: <54070C5D.7030607@gmail.com>
References: <2296697.ZmJV3U9KFH@logouticek> <100490444.vZHLe3CSFC@logouticek>
	<53D77C35.9050805@oracle.com> <24689252.yEYuCUqD1k@logouticek>
	<CAEJX8oon5teH571S+ZLgg9+aDkkryidnb8aK=7Oqo-rENMqTgw@mail.gmail.com>
	<5406E65F.1090100@redhat.com>
	<CAEJX8opBBARLx-fSOmZaJwyO8xw=5CVFHsBxxvxSSf-MjhYKnA@mail.gmail.com>
	<54070C5D.7030607@gmail.com>
Message-ID: <CAEJX8oqPvE-+nMNTQU1HtRPWzO4OY4-_EwqmntW=Cu_KDTROTQ@mail.gmail.com>

>
>
>>> I meant cleaning up rather than managing per se. To make it clear:
>>>
>> finalization is no substitute for proper lifecycle - anything that has
>> open() should have a following up close(), otherwise it's a bug.
>> Finalization still helps as safenet vs leaving native resources totally
>> unallocated and leaking. Yet, finalizers have to run somehow since the
>> direct (and mapped) buffers very heavily rely on them.
>>
>
> DirectByteBuffers rely on Cleaner(s), which are PhanthomReferences and are
> managed (invoked) by the ReferenceHandler thread directly. Finalizers are
> just enqueued by ReferenceHandler thread, but they are invoked by the
> special FinalizerThread. That's because Cleaner(s) are internal JDK
> mechanism, while finalizers invoke client code so they can stall the
> FinalizerThread. A bug in a client code can bring FinalizerThread to a halt.
>

Cleansers totally slipped my mind regarding DirectBuffers(almost feel
ashamed about). Yes, all the nio is using them.unlike
java.io.FIleInputStream, java.util.zip.Deflater/Inflater. I remember a
process getting justice by the oom_killer b/c a Deflater was not end()'d
properly. I am not sure if Deflater (which a memory hog) could use Cleaner,
though. .

Again halting the Finalizer is a slow leak. The memory will fill with tons
of java.lang.ref.Finalizer instances, so either way it'd be OOM, just takes
more time and blows up unexpectedly.


 As said, DirectByteBuffer(s) use Cleaner(s), which are more predictable.
> But even with Cleaner(s), a multithreaded test could be constructed which
> reserves direct memory with greater rate than single ReferenceHandler
> thread can unreserve it. Until this was fixed:
> https://bugs.openjdk.java.net/browse/JDK-6857566
>
> Thanks again for the Cleaner reminder.

 @David,
Pooling doesn't help 32bit processes running out of address space due to
lack of munmap. FileChannelImpl employs the same tactic to call System.gc()
and wait.

Stanimir


From mark.reinhold at oracle.com  Wed Sep  3 14:49:05 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 03 Sep 2014 07:49:05 -0700
Subject: Why is finalize wrong?
In-Reply-To: <5406E65F.1090100@redhat.com>
References: <2296697.ZmJV3U9KFH@logouticek>, <100490444.vZHLe3CSFC@logouticek>,
	<53D77C35.9050805@oracle.com>, <24689252.yEYuCUqD1k@logouticek>,
	<CAEJX8oon5teH571S+ZLgg9+aDkkryidnb8aK=7Oqo-rENMqTgw@mail.gmail.com>,
	<5406E65F.1090100@redhat.com>
Message-ID: <20140903074905.374987@eggemoggin.niobe.net>

2014/9/3 2:58 -0700, aph at redhat.com:
> ...
> 
> As Jarolsav put it, "I don't think this is explainable to regular Java
> developers."  As David Lloyd put it, "If you still think that finalize
> is a good idea, given that it's basically defective *and* there is
> almost always a better solution, then I will be quite astounded."  As
> I put it, "finalize is broken."

Indeed -- I couldn't have said it better myself!

- Mark


From lance.andersen at oracle.com  Wed Sep  3 19:04:49 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 3 Sep 2014 15:04:49 -0400
Subject: RFR: 8055776,
	Add tests to exercise SQLPermissions for DriverManager & SyncFactory
In-Reply-To: <5D837606-7440-4F0E-9731-79C1EC976333@oracle.com>
References: <5D837606-7440-4F0E-9731-79C1EC976333@oracle.com>
Message-ID: <A9FAEC9C-28FA-4165-9DB7-1C9C59E0AE8A@oracle.com>

HI,

Still looking for a reviewer for the testNG tests

Best,
Lance
On Aug 21, 2014, at 2:48 PM, Lance Andersen <lance.andersen at oracle.com> wrote:

> Hi all,
> 
> This is a request for review for
> 
> This adds tests which exercise SQLPermissions for DriverManager and SyncFactory.
> 
> The webrev can be found at http://cr.openjdk.java.net/~lancea/8055776/webrev.00/
> 
> Best,
> Lance
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> 
> 
> 



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From roger.riggs at oracle.com  Wed Sep  3 19:20:04 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Wed, 03 Sep 2014 15:20:04 -0400
Subject: RFR: 8055776,
	Add tests to exercise SQLPermissions for DriverManager & SyncFactory
In-Reply-To: <A9FAEC9C-28FA-4165-9DB7-1C9C59E0AE8A@oracle.com>
References: <5D837606-7440-4F0E-9731-79C1EC976333@oracle.com>
	<A9FAEC9C-28FA-4165-9DB7-1C9C59E0AE8A@oracle.com>
Message-ID: <540769E4.1030808@oracle.com>

Hi Lance,

Looks fine.

The commented out printlns in the BaseTest classes could be removed; 
looks like left over debugging info.

Roger

On 9/3/2014 3:04 PM, Lance Andersen wrote:
> HI,
>
> Still looking for a reviewer for the testNG tests
>
> Best,
> Lance
> On Aug 21, 2014, at 2:48 PM, Lance Andersen <lance.andersen at oracle.com> wrote:
>
>> Hi all,
>>
>> This is a request for review for
>>
>> This adds tests which exercise SQLPermissions for DriverManager and SyncFactory.
>>
>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8055776/webrev.00/
>>
>> Best,
>> Lance
>>
>>
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>>
>>
>>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>



From lance.andersen at oracle.com  Wed Sep  3 19:47:58 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 3 Sep 2014 15:47:58 -0400
Subject: RFR: 8055776,
	Add tests to exercise SQLPermissions for DriverManager & SyncFactory
In-Reply-To: <540769E4.1030808@oracle.com>
References: <5D837606-7440-4F0E-9731-79C1EC976333@oracle.com>
	<A9FAEC9C-28FA-4165-9DB7-1C9C59E0AE8A@oracle.com>
	<540769E4.1030808@oracle.com>
Message-ID: <1CDBB739-7829-44E9-B59D-5A133B631F01@oracle.com>

Hi Roger
On Sep 3, 2014, at 3:20 PM, roger riggs <roger.riggs at oracle.com> wrote:

> Hi Lance,
> 
> Looks fine.
> 
Thank you.
> The commented out printlns in the BaseTest classes could be removed; looks like left over debugging info.

I can remove it it, I had left it there as a minor time saver in case I wanted to use it again.  I could put it under a flag to enable it.

Best,
Lance
> 
> Roger
> 
> On 9/3/2014 3:04 PM, Lance Andersen wrote:
>> HI,
>> 
>> Still looking for a reviewer for the testNG tests
>> 
>> Best,
>> Lance
>> On Aug 21, 2014, at 2:48 PM, Lance Andersen <lance.andersen at oracle.com> wrote:
>> 
>>> Hi all,
>>> 
>>> This is a request for review for
>>> 
>>> This adds tests which exercise SQLPermissions for DriverManager and SyncFactory.
>>> 
>>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8055776/webrev.00/
>>> 
>>> Best,
>>> Lance
>>> 
>>> 
>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com
>>> 
>>> 
>>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 
> 



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From masayoshi.okutsu at oracle.com  Thu Sep  4 06:33:36 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 04 Sep 2014 15:33:36 +0900
Subject: RFR: 8049343: (tz) Support tzdata2014g
In-Reply-To: <5405C8F9.7090606@oracle.com>
References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com>
	<53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com>
	<53F734D8.1000801@oracle.com> <53FD9819.7080000@oracle.com>
	<53FDE2CD.8040709@oracle.com> <53FEA567.9020601@oracle.com>
	<54047E64.9020206@oracle.com> <54055DBE.3060804@oracle.com>
	<5405C8F9.7090606@oracle.com>
Message-ID: <540807C0.9000204@oracle.com>

The fix looks OK to me.

Thanks,
Masayoshi

On 9/2/2014 10:41 PM, Aleksej Efimov wrote:
> Masayoshi,
> Sorry for the confusion - for some reason (most probably this change 
> was added after webrev generation) I forgot to include it. Now it's in 
> place: http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04
>
> Thank you,
> Aleksej
>
> On 09/02/2014 10:03 AM, Masayoshi Okutsu wrote:
>> Aleksej,
>>
>> I don't see the America/Grand_Turk change in webrev.04. I wonder if 
>> the webrev wasn't updated correctly.
>>
>> Thanks,
>> Masayoshi
>>
>> On 9/1/2014 11:10 PM, Aleksej Efimov wrote:
>>> Masayoshi,
>>>
>>> I have addressed all your comments with proposed resolution. Thank 
>>> you for such thorough analysis of this changes.
>>>
>>> Also the new tzdata is out (2014g) - I have updated the JBS bug by 
>>> adding 2014g related change notes and renamed this bug appropriately 
>>> + I'm renaming this thread.
>>> The new webrev contains new changes related to 2014g:
>>> -            {"America/Grand_Turk", EST},
>>> +            {"America/Grand_Turk", AST},
>>>
>>>
>>> The 2014e/f related changes, discussed previously, are still in place.
>>>
>>> New webrev can be found here: 
>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.04
>>>
>>> The bug for the incomplete localization of new/updated time zone 
>>> names was filed: https://bugs.openjdk.java.net/browse/JDK-8057004
>>>
>>> With Best Regards,
>>> Aleksej
>>>
>>> On 08/28/2014 07:43 AM, Masayoshi Okutsu wrote:
>>>>  src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
>>>>
>>>>  239         String SLST[] = new String[] {"Greenwich Mean Time", 
>>>> "GMT",
>>>>  240                                       "Sierra Leone Summer 
>>>> Time", "SLST",
>>>>  241                                       "Sierra Leone Time", 
>>>> "SLT"};
>>>>
>>>>  251         String WART[] = new String[] {"Western Argentine 
>>>> Time", "WART",
>>>>  252                                       "Western Argentine 
>>>> Summer Time", "WARST",
>>>>  253                                       "Western Argentine 
>>>> Time", "WART"};
>>>>
>>>> It seems these are no longer used.
>>>>
>>>> -            {"Antarctica/Macquarie", new String[] {"Macquarie 
>>>> Island Time", "MIST",
>>>> - "Macquarie Island Summer Time", "MIST",
>>>> +            {"Antarctica/Macquarie", new String[] {"Macquarie 
>>>> Island Standard Time", "MIST",
>>>> + "Macquarie Island Daylight Time", "MIST",
>>>>
>>>> The daylight saving time abbreviation should be MIDT.
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 8/27/2014 10:53 PM, Aleksej Efimov wrote:
>>>>> Masayoshi,
>>>>> Thank you for a detailed review - I tried to address all your 
>>>>> comments. Please, see the updated review: 
>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03
>>>>> About the workarounds - I will start discussion with Sherman when 
>>>>> the tzdata2014f (and I suppose the 2014g - it will be available 
>>>>> soon according to tzdata mail-list [1]) integration will be complete.
>>>>>
>>>>> -Aleksej
>>>>>
>>>>> [1] tzdata2014g is coming: 
>>>>> http://mm.icann.org/pipermail/tz/2014-August/021528.html
>>>>>
>>>>> On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote:
>>>>>> Here are additional comments.
>>>>>>
>>>>>> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:
>>>>>>
>>>>>> I'm concerned about the workarounds. It's not new in this update, 
>>>>>> but this problem would make tzupdater data void until the 
>>>>>> workaround is added to the next update release. Could you please 
>>>>>> work with Sherman to eliminate the workaround (outside of this 
>>>>>> 2014f update)?
>>>>>>
>>>>>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
>>>>>>
>>>>>>          String LORD_HOWE[] = new String[] {"Lord Howe Standard 
>>>>>> Time", "LHST",
>>>>>> -                                           "Lord Howe Summer 
>>>>>> Time", "LHST",
>>>>>> +                                           "Lord Howe Summer 
>>>>>> Time", "LHDT",
>>>>>>
>>>>>> The S-D convention is applied to Lord Howe as well.
>>>>>>
>>>>>>  567             {"Antarctica/Macquarie", new String[] 
>>>>>> {"Macquarie Island Time", "MIST",
>>>>>>  568 "Macquarie Island Summer Time", "MIST",
>>>>>>  569 "Macquarie Island Time", "MIST"}},
>>>>>>
>>>>>> This one should also follow the S-D convention, although this 
>>>>>> time zone doesn't observe daylight saving time.
>>>>>>
>>>>>>
>>>>>> +        String XJT[] = new String[] {"China Standard Time", "XJT",
>>>>>> +                                     "China Daylight Time", "XJDT",
>>>>>> +                                     "China Time", "XJT"};
>>>>>>
>>>>>> Should the long names be based on Xinjiang?
>>>>>>
>>>>>> Africa/Freetown is now a link to Africa/Abidjan. Those should be 
>>>>>> the same time zone.
>>>>>>
>>>>>> -            {"America/Metlakatla", new String[] {"Metlakatla 
>>>>>> Standard Time", "MeST",
>>>>>> - "Metlakatla Daylight Time", "MeDT",
>>>>>> - "Metlakatla Time", "MeT"}},
>>>>>> +            {"America/Metlakatla", new String[] {"Metlakatla 
>>>>>> Standard Time", "PST",
>>>>>> + "Metlakatla Daylight Time", "PDT",
>>>>>> + "Metlakatla Time", "PT"}},
>>>>>>
>>>>>> -            {"Europe/Volgograd", new String[] {"Volgograd Time", 
>>>>>> "VOLT",
>>>>>> - "Volgograd Summer Time", "VOLST",
>>>>>> - "Volgograd Time", "VOLT"}},
>>>>>> +            {"Europe/Volgograd", new String[] {"Volgograd Time", 
>>>>>> "MSK",
>>>>>> + "Volgograd Summer Time", "MSK",
>>>>>> + "Volgograd Time", "MSK"}},
>>>>>>
>>>>>>
>>>>>> The long names should be changed accordingly.
>>>>>>
>>>>>> Thanks,
>>>>>> Masayoshi
>>>>>>
>>>>>> On 8/22/2014 9:17 PM, Aleksej Efimov wrote:
>>>>>>> Masayoshi,
>>>>>>> You're right that the "root names" should be changed as part of 
>>>>>>> this update. The names were changed according to Australian 
>>>>>>> official document here: 
>>>>>>> http://australia.gov.au/about-australia/our-country/time
>>>>>>> The fixed version of the webrev can be found here: 
>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Aleksej
>>>>>>>
>>>>>>>
>>>>>>> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote:
>>>>>>>> We used to make name changes in the root (base) bundle as part 
>>>>>>>> of time zone data maintenance and deter only translations. But 
>>>>>>>> if you want to handle name changes later, that would be fine. 
>>>>>>>> It's your call.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Masayoshi
>>>>>>>>
>>>>>>>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote:
>>>>>>>>> Masayoshi,
>>>>>>>>> I agree that we should change the long names to match the new 
>>>>>>>>> short names introduced by tzdata.
>>>>>>>>> But I suggest to log a different CR for such activity to 
>>>>>>>>> handle long name changes and their translations (this activity 
>>>>>>>>> is slightly out of tzdata update scope). Does it make sense?
>>>>>>>>>
>>>>>>>>> -Aleksej
>>>>>>>>>
>>>>>>>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
>>>>>>>>>> I think the long names of the Australia time zones should be 
>>>>>>>>>> revisited to be consistent with the abbreviation changes. The 
>>>>>>>>>> new abbreviations follow the S[tandard] and D[aylight saving] 
>>>>>>>>>> convention rather than the S[tandard] and S[ummer time] one. 
>>>>>>>>>> The long names, such as "Eastern Summer Time (Queensland)", 
>>>>>>>>>> no longer make sense.
>>>>>>>>>>
>>>>>>>>>> On the other hand, you will need to access impact of the name 
>>>>>>>>>> changes, including abbreviations. Also, if you change the 
>>>>>>>>>> long names, their translations will need to be changed as well.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Masayoshi
>>>>>>>>>>
>>>>>>>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Please, review the tzdata2014f integration (with tzdata2014e 
>>>>>>>>>>> related changes included too) [1] fix to JDK9: 
>>>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>> The tzdata2014f changes are extensive and relates mostly to 
>>>>>>>>>>> timezone short names changes + "Asia/Srednekolymsk" time 
>>>>>>>>>>> zone were added.
>>>>>>>>>>> Almost complete list of changes can be found in the JBS bug 
>>>>>>>>>>> description [1], plus some changes wasn't documented in 
>>>>>>>>>>> tzdata release notes - for such cases raw tzdata diff was 
>>>>>>>>>>> used for the names modifications.
>>>>>>>>>>>
>>>>>>>>>>> Two issues with JSR310 implementation were discovered during 
>>>>>>>>>>> integration process:
>>>>>>>>>>> First issue is related to the internal representation of the 
>>>>>>>>>>> '24:00' value. The JSR310 implementation treats this value 
>>>>>>>>>>> as a next day 00:00 time. The workaround already exists in 
>>>>>>>>>>> JSR310 code for similar entries and this failure is resolved 
>>>>>>>>>>> in similar way [2] as part of this update.
>>>>>>>>>>> For the second issue JDK-8051641 [3] was filled and 
>>>>>>>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only 
>>>>>>>>>>> one that fails with this tzdata.
>>>>>>>>>>> Other time zone related tests [4] passes without failures.
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Aleksej
>>>>>>>>>>>
>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
>>>>>>>>>>> [2] 
>>>>>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
>>>>>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
>>>>>>>>>>> [4] TZ related test sets: test/sun/util/calendar 
>>>>>>>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone 
>>>>>>>>>>> test/sun/util/calendar test/java/util/TimeZone 
>>>>>>>>>>> test/java/time\ test/java/util/Formatter 
>>>>>>>>>>> test/closed/java/util/Calendar test/closed/java/util/TimeZone
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From claes.redestad at oracle.com  Thu Sep  4 08:13:34 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 04 Sep 2014 10:13:34 +0200
Subject: RFR(S): 8055055: Improve numeric parsing in java.sql
In-Reply-To: <41C11643-EB9A-4EC4-BB79-2C847DC73C28@oracle.com>
References: <53EB970D.80801@oracle.com>
	<4B9A9590-7EA4-45B3-B9DB-8C0EECFC4664@oracle.com>
	<53EBBFA9.6020307@oracle.com>
	<41C11643-EB9A-4EC4-BB79-2C847DC73C28@oracle.com>
Message-ID: <54081F2E.7060409@oracle.com>

Hi,

  I took the liberty to shuffle around the patch to the new structure 
and add a few tests, particularly testing subtly different invalid 
formats and better exercising the logic around Timestamp nanos (tested 
using both old and new code):

  http://cr.openjdk.java.net/~redestad/8055055/webrev.5

/Claes


On 2014-08-21 21:06, Lance Andersen wrote:
> I think this is OK.  However, I want to write some additional tests to 
> reduce the chance of regression and add this as part of the putback
>
> I am going to be out of the office for a few days so doubt I will get 
> to this for another week or so
>
> Best,
> Lance
> On Aug 13, 2014, at 3:42 PM, Claes Redestad <claes.redestad at oracle.com 
> <mailto:claes.redestad at oracle.com>> wrote:
>
>> Thanks, Lance!
>>
>> I only ran the jtreg tests under jdk/test/java/sql locally for this 
>> (29 passed).
>>
>> /Claes
>>
>> On 2014-08-13 20:14, Lance Andersen wrote:
>>> I will take a look this week.  Did you run the unit tests to make 
>>> sure they still pass?
>>>
>>>
>>> On Aug 13, 2014, at 12:49 PM, Claes Redestad 
>>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com> 
>>> <mailto:claes.redestad at oracle.com>> wrote:
>>>
>>>> Hi,
>>>>
>>>> can I have a review of this small patch which improves performance 
>>>> of java.sql.Time::valueOf (~1.3x) and java.sql.Timestamp::valueOf 
>>>> (~1.9x).
>>>>
>>>> Uses Integer.parseInt with offset to make intermediary substrings 
>>>> unnecessary and improves the nanosecond fraction calculation to not 
>>>> use String concatenation.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8055055
>>>> webrev: http://cr.openjdk.java.net/~redestad/8055055/webrev.0/ 
>>>> <http://cr.openjdk.java.net/%7Eredestad/8055055/webrev.0/> 
>>>> <http://cr.openjdk.java.net/%7Eredestad/8055055/webrev.0/>
>>>>
>>>> Thanks!
>>>>
>>>> /Claes
>>>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> 
>>> <mailto:Lance.Andersen at oracle.com>
>>>
>>>
>>>
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From paul.sandoz at oracle.com  Thu Sep  4 08:43:16 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 4 Sep 2014 10:43:16 +0200
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <5405CD4E.4070409@oracle.com>
References: <5405CCDB.6040706@oracle.com> <5405CD4E.4070409@oracle.com>
Message-ID: <686A0A9F-BA62-4BA9-A7FA-EF76AF40A2A4@oracle.com>


On Sep 2, 2014, at 3:59 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00
> 

Generally looks good (re: Peter's observation of continue/break).

- LambdaFormEditor

  61     private static final class Transform {
  62         final long packedBytes;
  63         final byte[] fullBytes;
  64         final LambdaForm result;  // result of transform, or null, if there is none available
  65 
  66         private enum Kind {

More an oddity really, Transform.Kind is private but exposed via package private methods.

 187         static Transform of(Kind k, int b1, byte[] b234) {


It might be worthwhile investing in a unit test for LambdaFormEditor to exercise the transform types and transitions, otherwise edge cases might bite us later.


I was thinking Transform could be greatly simplified if one just uses byte[], but IIUC (via JOL) that increases the instance size by 16 bytes, although that may be small compared to the LambdaForm result and if say a WekRef is also used to hold that result. Plus if that is the case the transformCache could be simplified by just supporting Transform[] and ConcurrentHashMap. I guess the underlying question i am asking here is do these space savings really give us much over some less complicated code?

Paul.


From dmitry.samersoff at oracle.com  Thu Sep  4 12:26:32 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 04 Sep 2014 16:26:32 +0400
Subject: JDP broadcaster issue
In-Reply-To: <5405D9A7.3030405@gmail.com>
References: <5405D9A7.3030405@gmail.com>
Message-ID: <54085A78.7030205@oracle.com>

Yasumasa,

The CR number is JDK-8057556

I'll care about it's integration.

-Dmitry

On 2014-09-02 18:52, Yasumasa Suenaga wrote:
> Hi all,
> 
> I'm trying to use JDP on my Fedora20 machine.
> My machine has two NICs and only one NIC is up.
> 
> I passed system properties as below, however JDP broadcaster
> thread was not started:
> 
>   -Dcom.sun.management.jmxremote.port=7091
>   -Dcom.sun.management.jmxremote.authenticate=false
>   -Dcom.sun.management.jmxremote.ssl=false
>   -Dcom.sun.management.jmxremote.autodiscovery=true
>   -Dcom.sun.management.jdp.name=TEST
> 
> I checked exceptions with jdb, SocketException was occurred in
> JDPControllerRunner#run(), and it was caused by another NIC
> is down.
> 
> Currently, DiagramChannel which is used in JDPBroadcaster
> tries to send JDP packet through all "UP" NICs.
> However, NIC which is controlled by NetworkManager seems to
> be still "UP" when ifdown command is executed.
> (It seems to be removed IP address from NIC only.)
> 
> 
> This problem may be Fedora, however I think it should be
> improved in JDK.
> I've created a patch as below, and it works fine in my environment.
> (jdk9/dev/jdk)
> 
> If this patch may be accepted, I will file this to JBS.
> 
> --------------------
> diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java
> --- a/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java	Mon Sep 01 13:33:28 2014 +0200
> +++ b/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java	Tue Sep 02 23:25:50 2014 +0900
> @@ -35,6 +35,7 @@
>  import java.nio.ByteBuffer;
>  import java.nio.channels.DatagramChannel;
>  import java.nio.channels.UnsupportedAddressTypeException;
> +import java.util.Enumeration;
>  
>  /**
>   * JdpBroadcaster is responsible for sending pre-built JDP packet across a Net
> @@ -79,6 +80,15 @@
>          if (srcAddress != null) {
>              // User requests particular interface to bind to
>              NetworkInterface interf = NetworkInterface.getByInetAddress(srcAddress);
> +
> +            if (interf == null) {
> +                throw new JdpException("Unable to get network interface for " + srcAddress.toString());
> +            }
> +
> +            if (!interf.isUp() || !interf.supportsMulticast()) {
> +                throw new JdpException(interf.getName() + " does not support multicast.");
> +            }
> +
>              try {
>                  channel.bind(new InetSocketAddress(srcAddress, 0));
>              } catch (UnsupportedAddressTypeException ex) {
> @@ -86,6 +96,23 @@
>              }
>              channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, interf);
>          }
> +        else {
> +            Enumeration<NetworkInterface> nics = NetworkInterface.getNetworkInterfaces();
> +            while (nics.hasMoreElements()) {
> +                NetworkInterface nic = nics.nextElement();
> +
> +                if (nic.isUp() && nic.supportsMulticast()) {
> +                    try {
> +                        channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
> +                    } catch (IOException ex) {
> +                        System.err.println("WARNING: JDP broadcaster cannot use " + nic.getName() + ": " + ex.getMessage());
> +                    }
> +                }
> +
> +            }
> +
> +        }
> +
>      }
>  
>      /**
> --------------------
> 
> 
> Thanks,
> 
> Yasumasa
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


From yasuenag at gmail.com  Thu Sep  4 15:59:11 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Fri, 05 Sep 2014 00:59:11 +0900
Subject: RFR: JDK-8057556: JDP should better handle non-active interfaces
In-Reply-To: <54085A78.7030205@oracle.com>
References: <5405D9A7.3030405@gmail.com> <54085A78.7030205@oracle.com>
Message-ID: <54088C4F.10204@gmail.com>

Hi all,

Thank you so much, Dmitry!

I've created webrev for it.
http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.0/

Please review.


Thanks,

Yasumasa


(2014/09/04 21:26), Dmitry Samersoff wrote:
> Yasumasa,
> 
> The CR number is JDK-8057556
> 
> I'll care about it's integration.
> 
> -Dmitry
> 
> On 2014-09-02 18:52, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> I'm trying to use JDP on my Fedora20 machine.
>> My machine has two NICs and only one NIC is up.
>>
>> I passed system properties as below, however JDP broadcaster
>> thread was not started:
>>
>>    -Dcom.sun.management.jmxremote.port=7091
>>    -Dcom.sun.management.jmxremote.authenticate=false
>>    -Dcom.sun.management.jmxremote.ssl=false
>>    -Dcom.sun.management.jmxremote.autodiscovery=true
>>    -Dcom.sun.management.jdp.name=TEST
>>
>> I checked exceptions with jdb, SocketException was occurred in
>> JDPControllerRunner#run(), and it was caused by another NIC
>> is down.
>>
>> Currently, DiagramChannel which is used in JDPBroadcaster
>> tries to send JDP packet through all "UP" NICs.
>> However, NIC which is controlled by NetworkManager seems to
>> be still "UP" when ifdown command is executed.
>> (It seems to be removed IP address from NIC only.)
>>
>>
>> This problem may be Fedora, however I think it should be
>> improved in JDK.
>> I've created a patch as below, and it works fine in my environment.
>> (jdk9/dev/jdk)
>>
>> If this patch may be accepted, I will file this to JBS.
>>
>> --------------------
>> diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java
>> --- a/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java	Mon Sep 01 13:33:28 2014 +0200
>> +++ b/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java	Tue Sep 02 23:25:50 2014 +0900
>> @@ -35,6 +35,7 @@
>>   import java.nio.ByteBuffer;
>>   import java.nio.channels.DatagramChannel;
>>   import java.nio.channels.UnsupportedAddressTypeException;
>> +import java.util.Enumeration;
>>   
>>   /**
>>    * JdpBroadcaster is responsible for sending pre-built JDP packet across a Net
>> @@ -79,6 +80,15 @@
>>           if (srcAddress != null) {
>>               // User requests particular interface to bind to
>>               NetworkInterface interf = NetworkInterface.getByInetAddress(srcAddress);
>> +
>> +            if (interf == null) {
>> +                throw new JdpException("Unable to get network interface for " + srcAddress.toString());
>> +            }
>> +
>> +            if (!interf.isUp() || !interf.supportsMulticast()) {
>> +                throw new JdpException(interf.getName() + " does not support multicast.");
>> +            }
>> +
>>               try {
>>                   channel.bind(new InetSocketAddress(srcAddress, 0));
>>               } catch (UnsupportedAddressTypeException ex) {
>> @@ -86,6 +96,23 @@
>>               }
>>               channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, interf);
>>           }
>> +        else {
>> +            Enumeration<NetworkInterface> nics = NetworkInterface.getNetworkInterfaces();
>> +            while (nics.hasMoreElements()) {
>> +                NetworkInterface nic = nics.nextElement();
>> +
>> +                if (nic.isUp() && nic.supportsMulticast()) {
>> +                    try {
>> +                        channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
>> +                    } catch (IOException ex) {
>> +                        System.err.println("WARNING: JDP broadcaster cannot use " + nic.getName() + ": " + ex.getMessage());
>> +                    }
>> +                }
>> +
>> +            }
>> +
>> +        }
>> +
>>       }
>>   
>>       /**
>> --------------------
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
> 
> 


From dmitry.samersoff at oracle.com  Thu Sep  4 16:14:17 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 04 Sep 2014 20:14:17 +0400
Subject: RFR: JDK-8057556: JDP should better handle non-active interfaces
In-Reply-To: <54088C4F.10204@gmail.com>
References: <5405D9A7.3030405@gmail.com> <54085A78.7030205@oracle.com>
	<54088C4F.10204@gmail.com>
Message-ID: <54088FD9.2060408@oracle.com>

Looks good for me!

On 2014-09-04 19:59, Yasumasa Suenaga wrote:
> Hi all,
> 
> Thank you so much, Dmitry!
> 
> I've created webrev for it.
> http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.0/
> 
> Please review.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> (2014/09/04 21:26), Dmitry Samersoff wrote:
>> Yasumasa,
>>
>> The CR number is JDK-8057556
>>
>> I'll care about it's integration.
>>
>> -Dmitry
>>
>> On 2014-09-02 18:52, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> I'm trying to use JDP on my Fedora20 machine.
>>> My machine has two NICs and only one NIC is up.
>>>
>>> I passed system properties as below, however JDP broadcaster
>>> thread was not started:
>>>
>>>    -Dcom.sun.management.jmxremote.port=7091
>>>    -Dcom.sun.management.jmxremote.authenticate=false
>>>    -Dcom.sun.management.jmxremote.ssl=false
>>>    -Dcom.sun.management.jmxremote.autodiscovery=true
>>>    -Dcom.sun.management.jdp.name=TEST
>>>
>>> I checked exceptions with jdb, SocketException was occurred in
>>> JDPControllerRunner#run(), and it was caused by another NIC
>>> is down.
>>>
>>> Currently, DiagramChannel which is used in JDPBroadcaster
>>> tries to send JDP packet through all "UP" NICs.
>>> However, NIC which is controlled by NetworkManager seems to
>>> be still "UP" when ifdown command is executed.
>>> (It seems to be removed IP address from NIC only.)
>>>
>>>
>>> This problem may be Fedora, however I think it should be
>>> improved in JDK.
>>> I've created a patch as below, and it works fine in my environment.
>>> (jdk9/dev/jdk)
>>>
>>> If this patch may be accepted, I will file this to JBS.
>>>
>>> --------------------
>>> diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java
>>> --- a/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java	Mon Sep 01 13:33:28 2014 +0200
>>> +++ b/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java	Tue Sep 02 23:25:50 2014 +0900
>>> @@ -35,6 +35,7 @@
>>>   import java.nio.ByteBuffer;
>>>   import java.nio.channels.DatagramChannel;
>>>   import java.nio.channels.UnsupportedAddressTypeException;
>>> +import java.util.Enumeration;
>>>   
>>>   /**
>>>    * JdpBroadcaster is responsible for sending pre-built JDP packet across a Net
>>> @@ -79,6 +80,15 @@
>>>           if (srcAddress != null) {
>>>               // User requests particular interface to bind to
>>>               NetworkInterface interf = NetworkInterface.getByInetAddress(srcAddress);
>>> +
>>> +            if (interf == null) {
>>> +                throw new JdpException("Unable to get network interface for " + srcAddress.toString());
>>> +            }
>>> +
>>> +            if (!interf.isUp() || !interf.supportsMulticast()) {
>>> +                throw new JdpException(interf.getName() + " does not support multicast.");
>>> +            }
>>> +
>>>               try {
>>>                   channel.bind(new InetSocketAddress(srcAddress, 0));
>>>               } catch (UnsupportedAddressTypeException ex) {
>>> @@ -86,6 +96,23 @@
>>>               }
>>>               channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, interf);
>>>           }
>>> +        else {
>>> +            Enumeration<NetworkInterface> nics = NetworkInterface.getNetworkInterfaces();
>>> +            while (nics.hasMoreElements()) {
>>> +                NetworkInterface nic = nics.nextElement();
>>> +
>>> +                if (nic.isUp() && nic.supportsMulticast()) {
>>> +                    try {
>>> +                        channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
>>> +                    } catch (IOException ex) {
>>> +                        System.err.println("WARNING: JDP broadcaster cannot use " + nic.getName() + ": " + ex.getMessage());
>>> +                    }
>>> +                }
>>> +
>>> +            }
>>> +
>>> +        }
>>> +
>>>       }
>>>   
>>>       /**
>>> --------------------
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.


From lance.andersen at oracle.com  Thu Sep  4 19:20:04 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 4 Sep 2014 15:20:04 -0400
Subject: RFR(S): 8055055: Improve numeric parsing in java.sql
In-Reply-To: <54081F2E.7060409@oracle.com>
References: <53EB970D.80801@oracle.com>
	<4B9A9590-7EA4-45B3-B9DB-8C0EECFC4664@oracle.com>
	<53EBBFA9.6020307@oracle.com>
	<41C11643-EB9A-4EC4-BB79-2C847DC73C28@oracle.com>
	<54081F2E.7060409@oracle.com>
Message-ID: <AD6A894E-A7B9-4EA6-96E4-4D2E6BF1A4B2@oracle.com>

Hi Claes,

I am assuming the changes to the Time and Timestamp have not changed, you just moved them to the new structure.

WRT the tests, I actually want to add more value testing.  I am in the process of updating Time and Timestamp tests to use a DataProvider.  Once I finish this, I will send it out for review as it will make it easier to update these tests for additional scenarios

Best
Lance
On Sep 4, 2014, at 4:13 AM, Claes Redestad <claes.redestad at oracle.com> wrote:

> Hi,
> 
> I took the liberty to shuffle around the patch to the new structure and add a few tests, particularly testing subtly different invalid formats and better exercising the logic around Timestamp nanos (tested using both old and new code):
> 
> http://cr.openjdk.java.net/~redestad/8055055/webrev.5
> 
> /Claes
> 
> 
> On 2014-08-21 21:06, Lance Andersen wrote:
>> I think this is OK.  However, I want to write some additional tests to reduce the chance of regression and add this as part of the putback
>> 
>> I am going to be out of the office for a few days so doubt I will get to this for another week or so
>> 
>> Best,
>> Lance
>> On Aug 13, 2014, at 3:42 PM, Claes Redestad <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>> 
>>> Thanks, Lance!
>>> 
>>> I only ran the jtreg tests under jdk/test/java/sql locally for this (29 passed).
>>> 
>>> /Claes
>>> 
>>> On 2014-08-13 20:14, Lance Andersen wrote:
>>>> I will take a look this week.  Did you run the unit tests to make sure they still pass?
>>>> 
>>>> 
>>>> On Aug 13, 2014, at 12:49 PM, Claes Redestad <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com> <mailto:claes.redestad at oracle.com>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> can I have a review of this small patch which improves performance of java.sql.Time::valueOf (~1.3x) and java.sql.Timestamp::valueOf (~1.9x).
>>>>> 
>>>>> Uses Integer.parseInt with offset to make intermediary substrings unnecessary and improves the nanosecond fraction calculation to not use String concatenation.
>>>>> 
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8055055
>>>>> webrev: http://cr.openjdk.java.net/~redestad/8055055/webrev.0/ <http://cr.openjdk.java.net/%7Eredestad/8055055/webrev.0/> <http://cr.openjdk.java.net/%7Eredestad/8055055/webrev.0/>
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> /Claes
>>>> 
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering
>>>> 1 Network Drive
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com>
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>> 
>> 
>> 
> 



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From claes.redestad at oracle.com  Thu Sep  4 19:37:07 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 04 Sep 2014 21:37:07 +0200
Subject: RFR(S): 8055055: Improve numeric parsing in java.sql
In-Reply-To: <AD6A894E-A7B9-4EA6-96E4-4D2E6BF1A4B2@oracle.com>
References: <53EB970D.80801@oracle.com>
	<4B9A9590-7EA4-45B3-B9DB-8C0EECFC4664@oracle.com>
	<53EBBFA9.6020307@oracle.com>
	<41C11643-EB9A-4EC4-BB79-2C847DC73C28@oracle.com>
	<54081F2E.7060409@oracle.com>
	<AD6A894E-A7B9-4EA6-96E4-4D2E6BF1A4B2@oracle.com>
Message-ID: <5408BF63.7040409@oracle.com>


On 2014-09-04 21:20, Lance Andersen wrote:
> Hi Claes,
>
> I am assuming the changes to the Time and Timestamp have not changed, 
> you just moved them to the new structure.

Yes, unchanged otherwise.

>
> WRT the tests, I actually want to add more value testing.  I am in the 
> process of updating Time and Timestamp tests to use a DataProvider. 
>  Once I finish this, I will send it out for review as it will make it 
> easier to update these tests for additional scenarios

Sounds good!

/Claes
>
> Best
> Lance
> On Sep 4, 2014, at 4:13 AM, Claes Redestad <claes.redestad at oracle.com 
> <mailto:claes.redestad at oracle.com>> wrote:
>
>> Hi,
>>
>> I took the liberty to shuffle around the patch to the new structure 
>> and add a few tests, particularly testing subtly different invalid 
>> formats and better exercising the logic around Timestamp nanos 
>> (tested using both old and new code):
>>
>> http://cr.openjdk.java.net/~redestad/8055055/webrev.5 
>> <http://cr.openjdk.java.net/%7Eredestad/8055055/webrev.5>
>>
>> /Claes
>>
>>
>> On 2014-08-21 21:06, Lance Andersen wrote:
>>> I think this is OK.  However, I want to write some additional tests 
>>> to reduce the chance of regression and add this as part of the putback
>>>
>>> I am going to be out of the office for a few days so doubt I will 
>>> get to this for another week or so
>>>
>>> Best,
>>> Lance
>>> On Aug 13, 2014, at 3:42 PM, Claes Redestad 
>>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com> 
>>> <mailto:claes.redestad at oracle.com>> wrote:
>>>
>>>> Thanks, Lance!
>>>>
>>>> I only ran the jtreg tests under jdk/test/java/sql locally for this 
>>>> (29 passed).
>>>>
>>>> /Claes
>>>>
>>>> On 2014-08-13 20:14, Lance Andersen wrote:
>>>>> I will take a look this week.  Did you run the unit tests to make 
>>>>> sure they still pass?
>>>>>
>>>>>
>>>>> On Aug 13, 2014, at 12:49 PM, Claes Redestad 
>>>>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com> 
>>>>> <mailto:claes.redestad at oracle.com> 
>>>>> <mailto:claes.redestad at oracle.com>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> can I have a review of this small patch which improves 
>>>>>> performance of java.sql.Time::valueOf (~1.3x) and 
>>>>>> java.sql.Timestamp::valueOf (~1.9x).
>>>>>>
>>>>>> Uses Integer.parseInt with offset to make intermediary substrings 
>>>>>> unnecessary and improves the nanosecond fraction calculation to 
>>>>>> not use String concatenation.
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8055055
>>>>>> webrev: http://cr.openjdk.java.net/~redestad/8055055/webrev.0/ 
>>>>>> <http://cr.openjdk.java.net/%7Eredestad/8055055/webrev.0/> 
>>>>>> <http://cr.openjdk.java.net/%7Eredestad/8055055/webrev.0/> 
>>>>>> <http://cr.openjdk.java.net/%7Eredestad/8055055/webrev.0/>
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> /Claes
>>>>>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>>>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>> Oracle Java Engineering
>>>>> 1 Network Drive
>>>>> Burlington, MA 01803
>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> 
>>>>> <mailto:Lance.Andersen at oracle.com> <mailto:Lance.Andersen at oracle.com>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> 
>>> <mailto:Lance.Andersen at oracle.com>
>>>
>>>
>>>
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From john.r.rose at oracle.com  Thu Sep  4 19:55:39 2014
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 4 Sep 2014 12:55:39 -0700
Subject: test paths in repo
Message-ID: <0CD21077-9DB2-4E9D-9600-4FC69B820773@oracle.com>

David Chase and I just noticed files like this in the JDK:
  http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/test/java/util/stream/test/org/openjdk/tests/java/util/stream/

The package for the test code is "org.openjdk.tests.java.util.stream".  Although that's long, it is completely unambiguous.

Generally, grammar of such paths appears to be:
  $REPO / test / $TEST_PACKAGE_PREFIX / $API_PACKAGE
where TEST_PACKAGE_PREFIX is fixed as "org/openjdk/tests", and API_PACKAGE is "java/util/stream" or some such.

Has this organization for tests worn well?  Would you do it again that way?

Also, What is the reason for the close correspondence between the file system pathname and the Java package declaration?  Is it so that IDEs can easily find the test files?  (If so, which IDEs?)

For David's Arrays 2.0 work, which in some ways resembles the streams work, we want a good organization for tests, so we are looking at the streams tests as a template.

Thanks for any insights...
? John

From mark.reinhold at oracle.com  Thu Sep  4 21:02:09 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Thu, 04 Sep 2014 14:02:09 -0700
Subject: test paths in repo
In-Reply-To: <0CD21077-9DB2-4E9D-9600-4FC69B820773@oracle.com>
References: <0CD21077-9DB2-4E9D-9600-4FC69B820773@oracle.com>
Message-ID: <20140904140209.949462@eggemoggin.niobe.net>

2014/9/4 12:55 -0700, john.r.rose at oracle.com:
> ...
> 
> Generally, grammar of such paths appears to be:
>   $REPO / test / $TEST_PACKAGE_PREFIX / $API_PACKAGE
> where TEST_PACKAGE_PREFIX is fixed as "org/openjdk/tests", and
> API_PACKAGE is "java/util/stream" or some such.
> 
> Has this organization for tests worn well?  Would you do it again that
> way?

Someone who actually worked on these tests will have to comment.  Using
long package names for test code (or, really, any package name at all
unless actually needed) is overkill in my opinion, and a relatively new
thing in our collection of unit and regression tests.

- Mark


From vladimir.x.ivanov at oracle.com  Fri Sep  5 08:09:52 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 05 Sep 2014 12:09:52 +0400
Subject: [9] RFR (S) 8057654: Extract checks performed during MethodHandle
	construction into separate methods
Message-ID: <54096FD0.1060600@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057654

The idea is to separate construction logic and different checks 
performed before/during method handle construction.

For example: move checks from MHs.foldArguments into MHs.foldArgumentChecks.

Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ 
"-ea -esa" and COMPILE_THRESHOLD={0,30}.

Reviewed-by: vlivanov, ?
Contributed-by: john.r.rose at oracle.com

Thanks!

Best regards,
Vladimir Ivanov


From peter.allwin at oracle.com  Fri Sep  5 08:20:35 2014
From: peter.allwin at oracle.com (Peter Allwin)
Date: Fri, 5 Sep 2014 10:20:35 +0200
Subject: RFR: JDK-8057556: JDP should better handle non-active interfaces
In-Reply-To: <54088C4F.10204@gmail.com>
References: <5405D9A7.3030405@gmail.com> <54085A78.7030205@oracle.com>
	<54088C4F.10204@gmail.com>
Message-ID: <099DBC50-7324-49D1-8E10-36DE2EBB4962@oracle.com>

Looks like only the first Interface will be considered if no srcAddress is provided (succeeded will be false and we will throw to exit the while loop). Is this intended?

Thanks!
/peter

> On 4 sep 2014, at 17:59, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
> 
> Hi all,
> 
> Thank you so much, Dmitry!
> 
> I've created webrev for it.
> http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.0/
> 
> Please review.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> (2014/09/04 21:26), Dmitry Samersoff wrote:
>> Yasumasa,
>> 
>> The CR number is JDK-8057556
>> 
>> I'll care about it's integration.
>> 
>> -Dmitry
>> 
>>> On 2014-09-02 18:52, Yasumasa Suenaga wrote:
>>> Hi all,
>>> 
>>> I'm trying to use JDP on my Fedora20 machine.
>>> My machine has two NICs and only one NIC is up.
>>> 
>>> I passed system properties as below, however JDP broadcaster
>>> thread was not started:
>>> 
>>>   -Dcom.sun.management.jmxremote.port=7091
>>>   -Dcom.sun.management.jmxremote.authenticate=false
>>>   -Dcom.sun.management.jmxremote.ssl=false
>>>   -Dcom.sun.management.jmxremote.autodiscovery=true
>>>   -Dcom.sun.management.jdp.name=TEST
>>> 
>>> I checked exceptions with jdb, SocketException was occurred in
>>> JDPControllerRunner#run(), and it was caused by another NIC
>>> is down.
>>> 
>>> Currently, DiagramChannel which is used in JDPBroadcaster
>>> tries to send JDP packet through all "UP" NICs.
>>> However, NIC which is controlled by NetworkManager seems to
>>> be still "UP" when ifdown command is executed.
>>> (It seems to be removed IP address from NIC only.)
>>> 
>>> 
>>> This problem may be Fedora, however I think it should be
>>> improved in JDK.
>>> I've created a patch as below, and it works fine in my environment.
>>> (jdk9/dev/jdk)
>>> 
>>> If this patch may be accepted, I will file this to JBS.
>>> 
>>> --------------------
>>> diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java
>>> --- a/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java    Mon Sep 01 13:33:28 2014 +0200
>>> +++ b/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java    Tue Sep 02 23:25:50 2014 +0900
>>> @@ -35,6 +35,7 @@
>>>  import java.nio.ByteBuffer;
>>>  import java.nio.channels.DatagramChannel;
>>>  import java.nio.channels.UnsupportedAddressTypeException;
>>> +import java.util.Enumeration;
>>> 
>>>  /**
>>>   * JdpBroadcaster is responsible for sending pre-built JDP packet across a Net
>>> @@ -79,6 +80,15 @@
>>>          if (srcAddress != null) {
>>>              // User requests particular interface to bind to
>>>              NetworkInterface interf = NetworkInterface.getByInetAddress(srcAddress);
>>> +
>>> +            if (interf == null) {
>>> +                throw new JdpException("Unable to get network interface for " + srcAddress.toString());
>>> +            }
>>> +
>>> +            if (!interf.isUp() || !interf.supportsMulticast()) {
>>> +                throw new JdpException(interf.getName() + " does not support multicast.");
>>> +            }
>>> +
>>>              try {
>>>                  channel.bind(new InetSocketAddress(srcAddress, 0));
>>>              } catch (UnsupportedAddressTypeException ex) {
>>> @@ -86,6 +96,23 @@
>>>              }
>>>              channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, interf);
>>>          }
>>> +        else {
>>> +            Enumeration<NetworkInterface> nics = NetworkInterface.getNetworkInterfaces();
>>> +            while (nics.hasMoreElements()) {
>>> +                NetworkInterface nic = nics.nextElement();
>>> +
>>> +                if (nic.isUp() && nic.supportsMulticast()) {
>>> +                    try {
>>> +                        channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
>>> +                    } catch (IOException ex) {
>>> +                        System.err.println("WARNING: JDP broadcaster cannot use " + nic.getName() + ": " + ex.getMessage());
>>> +                    }
>>> +                }
>>> +
>>> +            }
>>> +
>>> +        }
>>> +
>>>      }
>>> 
>>>      /**
>>> --------------------
>>> 
>>> 
>>> Thanks,
>>> 
>>> Yasumasa
>> 
>> 


From vladimir.x.ivanov at oracle.com  Fri Sep  5 08:23:53 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 05 Sep 2014 12:23:53 +0400
Subject: [9] RFR (S) 8057656: Improve MethodType.isCastableTo() &
	MethodType.isConvertibleTo() checks
Message-ID: <54097319.2090601@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057656

There are some corner cases which MT.isCastableTo() & 
MT.isConvertibleTo() don't treat right (e.g. int->String converstion of 
return type in MT.isCastableTo()).

Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ 
"-ea -esa" and COMPILE_THRESHOLD={0,30}.

Reviewed-by: vlivanov, ?
Contributed-by: john.r.rose at oracle.com

Thanks!


Best regards,
Vladimir Ivanov


From paul.sandoz at oracle.com  Fri Sep  5 08:28:02 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 5 Sep 2014 10:28:02 +0200
Subject: test paths in repo
In-Reply-To: <0CD21077-9DB2-4E9D-9600-4FC69B820773@oracle.com>
References: <0CD21077-9DB2-4E9D-9600-4FC69B820773@oracle.com>
Message-ID: <3A565EC3-CF55-400E-9325-28E85E050953@oracle.com>

On Sep 4, 2014, at 9:55 PM, John Rose <john.r.rose at oracle.com> wrote:
> David Chase and I just noticed files like this in the JDK:
>  http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/test/java/util/stream/test/org/openjdk/tests/java/util/stream/
> 
> The package for the test code is "org.openjdk.tests.java.util.stream".  Although that's long, it is completely unambiguous.
> 
> Generally, grammar of such paths appears to be:
>  $REPO / test / $TEST_PACKAGE_PREFIX / $API_PACKAGE
> where TEST_PACKAGE_PREFIX is fixed as "org/openjdk/tests", and API_PACKAGE is "java/util/stream" or some such.
> 

Further more, two other sets of classes are required to be on the bootclasspath and in the j.u.stream package: test framework classes; and white box tests.

For the tests you mention, that don't need to be on the bootclass path we chose something different. It's named as if, perhaps in a better world?, most pure JDK java-based tests could be compiled and packaged into one jar file. FWIW there also happen to be a few other tests in other packages (e.g. SplittableRandomTest, that tests streams leveraging the test framework).

These tests started out as pure testng tests and we used to run 'em via ant in the lambda repo, so i think that has influenced it's structure too (since IIRC it may have also contained more tests corresponding to other packages).

FWIW a similar type of naming structure is used for JCK tests e.g.:

  package javasoft.sqe.tests.api.java.util.stream.IntStream;


> Has this organization for tests worn well?  Would you do it again that way?
> 

I think it has worked out well so far, even if the naming is a little verbose (which is fine when using a compact package view in an IDE). I would do it again :-)


> Also, What is the reason for the close correspondence between the file system pathname and the Java package declaration?  Is it so that IDEs can easily find the test files?  (If so, which IDEs?)
> 

It definitely makes it easy for to tell an IDE, such as IntelliJ, "these are my test source roots". We refactored the tests as least as much as we refactored the API/impl. When i refactor the API by making a name change i want my tests (+ supporting framework) to be automatically updated too, when i refactor the test framework i want my tests to automatically update.

IMHO it is tricky to develop and maintain the JDK tests since it is hard to get a holistic view of all tests so one can crunch on 'em as a whole and doing useful analysis via IDEs that is possible on the JDK code itself (e.g. see recent cleanups for StringBuilder/Buffer).  In this respect i would argue the current structure is actively hostile for maintaining tests, which i think should be given the same care and attention as the code they are testing. This is perhaps one reason why many tests duplicate assertion logic, there is some supporting help, but it's kind of a minor pain to use it and find it (perhaps that is just me being lazy?).

Hth,
Paul.

> For David's Arrays 2.0 work, which in some ways resembles the streams work, we want a good organization for tests, so we are looking at the streams tests as a template.
> 
> Thanks for any insights...
> ? John



From vladimir.x.ivanov at oracle.com  Fri Sep  5 10:12:40 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 05 Sep 2014 14:12:40 +0400
Subject: [9] RFR (S): 8057657: Annotate LambdaForm parameters with types
Message-ID: <54098C98.90009@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8057657/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057657

Add ability to annotate LambdaForm parameters with their types.
Type info could be useful during LambdaForm compilation to produce 
better bytecode.

Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ 
"-ea -esa" and COMPILE_THRESHOLD={0,30}.

Reviewed-by: vlivanov, ?
Contributed-by: john.r.rose at oracle.com

Thanks!

Best regards,
Vladimir Ivanov


From yasuenag at gmail.com  Fri Sep  5 10:28:16 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Fri, 05 Sep 2014 19:28:16 +0900
Subject: RFR: JDK-8057556: JDP should better handle non-active interfaces
In-Reply-To: <099DBC50-7324-49D1-8E10-36DE2EBB4962@oracle.com>
References: <5405D9A7.3030405@gmail.com> <54085A78.7030205@oracle.com>
	<54088C4F.10204@gmail.com>
	<099DBC50-7324-49D1-8E10-36DE2EBB4962@oracle.com>
Message-ID: <54099040.4040100@gmail.com>

Hi Peter,

I fixed it and created new webrev.
http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.1/

Could you review it again?


Thanks,

Yasumasa


(2014/09/05 17:20), Peter Allwin wrote:
> Looks like only the first Interface will be considered if no srcAddress is provided (succeeded will be false and we will throw to exit the while loop). Is this intended?
>
> Thanks!
> /peter
>
>> On 4 sep 2014, at 17:59, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>
>> Hi all,
>>
>> Thank you so much, Dmitry!
>>
>> I've created webrev for it.
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.0/
>>
>> Please review.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> (2014/09/04 21:26), Dmitry Samersoff wrote:
>>> Yasumasa,
>>>
>>> The CR number is JDK-8057556
>>>
>>> I'll care about it's integration.
>>>
>>> -Dmitry
>>>
>>>> On 2014-09-02 18:52, Yasumasa Suenaga wrote:
>>>> Hi all,
>>>>
>>>> I'm trying to use JDP on my Fedora20 machine.
>>>> My machine has two NICs and only one NIC is up.
>>>>
>>>> I passed system properties as below, however JDP broadcaster
>>>> thread was not started:
>>>>
>>>>    -Dcom.sun.management.jmxremote.port=7091
>>>>    -Dcom.sun.management.jmxremote.authenticate=false
>>>>    -Dcom.sun.management.jmxremote.ssl=false
>>>>    -Dcom.sun.management.jmxremote.autodiscovery=true
>>>>    -Dcom.sun.management.jdp.name=TEST
>>>>
>>>> I checked exceptions with jdb, SocketException was occurred in
>>>> JDPControllerRunner#run(), and it was caused by another NIC
>>>> is down.
>>>>
>>>> Currently, DiagramChannel which is used in JDPBroadcaster
>>>> tries to send JDP packet through all "UP" NICs.
>>>> However, NIC which is controlled by NetworkManager seems to
>>>> be still "UP" when ifdown command is executed.
>>>> (It seems to be removed IP address from NIC only.)
>>>>
>>>>
>>>> This problem may be Fedora, however I think it should be
>>>> improved in JDK.
>>>> I've created a patch as below, and it works fine in my environment.
>>>> (jdk9/dev/jdk)
>>>>
>>>> If this patch may be accepted, I will file this to JBS.
>>>>
>>>> --------------------
>>>> diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java
>>>> --- a/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java    Mon Sep 01 13:33:28 2014 +0200
>>>> +++ b/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java    Tue Sep 02 23:25:50 2014 +0900
>>>> @@ -35,6 +35,7 @@
>>>>   import java.nio.ByteBuffer;
>>>>   import java.nio.channels.DatagramChannel;
>>>>   import java.nio.channels.UnsupportedAddressTypeException;
>>>> +import java.util.Enumeration;
>>>>
>>>>   /**
>>>>    * JdpBroadcaster is responsible for sending pre-built JDP packet across a Net
>>>> @@ -79,6 +80,15 @@
>>>>           if (srcAddress != null) {
>>>>               // User requests particular interface to bind to
>>>>               NetworkInterface interf = NetworkInterface.getByInetAddress(srcAddress);
>>>> +
>>>> +            if (interf == null) {
>>>> +                throw new JdpException("Unable to get network interface for " + srcAddress.toString());
>>>> +            }
>>>> +
>>>> +            if (!interf.isUp() || !interf.supportsMulticast()) {
>>>> +                throw new JdpException(interf.getName() + " does not support multicast.");
>>>> +            }
>>>> +
>>>>               try {
>>>>                   channel.bind(new InetSocketAddress(srcAddress, 0));
>>>>               } catch (UnsupportedAddressTypeException ex) {
>>>> @@ -86,6 +96,23 @@
>>>>               }
>>>>               channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, interf);
>>>>           }
>>>> +        else {
>>>> +            Enumeration<NetworkInterface> nics = NetworkInterface.getNetworkInterfaces();
>>>> +            while (nics.hasMoreElements()) {
>>>> +                NetworkInterface nic = nics.nextElement();
>>>> +
>>>> +                if (nic.isUp() && nic.supportsMulticast()) {
>>>> +                    try {
>>>> +                        channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
>>>> +                    } catch (IOException ex) {
>>>> +                        System.err.println("WARNING: JDP broadcaster cannot use " + nic.getName() + ": " + ex.getMessage());
>>>> +                    }
>>>> +                }
>>>> +
>>>> +            }
>>>> +
>>>> +        }
>>>> +
>>>>       }
>>>>
>>>>       /**
>>>> --------------------
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>
>>>


From paul.sandoz at oracle.com  Fri Sep  5 10:31:56 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 5 Sep 2014 12:31:56 +0200
Subject: [9] RFR (S) 8057654: Extract checks performed during MethodHandle
	construction into separate methods
In-Reply-To: <54096FD0.1060600@oracle.com>
References: <54096FD0.1060600@oracle.com>
Message-ID: <E51234CD-9234-4126-9C2D-94724C85B7A8@oracle.com>


On Sep 5, 2014, at 10:09 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8057654
> 

+1

Paul.


From aleksey.shipilev at oracle.com  Fri Sep  5 10:46:54 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 05 Sep 2014 14:46:54 +0400
Subject: [9] RFR (S) 8057654: Extract checks performed during MethodHandle
	construction into separate methods
In-Reply-To: <54096FD0.1060600@oracle.com>
References: <54096FD0.1060600@oracle.com>
Message-ID: <5409949E.90606@oracle.com>

On 09/05/2014 12:09 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8057654

Random style rant of the week, not particularly about this concrete
patch. Can we please try to systematically use more
readable/robust/secure idioms? E.g.:

 a) Always have curly braces around the blocks?

     if (ok && ...) {
       ok = false;
     }
     if (!ok) {
       throw misMatchedTypes(...);
     }
     return rtype;

   vs.

     if (ok && ...)
       ok = false;
     if (!ok)
       throw misMatchedTypes(...);
     return rtype;

   Apple's "goto fail;" bug, anyone?

 b) Have only a single initialization per line?

       boolean match = true;
       boolean fail = false;
   vs.
       boolean match = true, fail = false;

 c) Always have parentheses in ternary operators predicates?

       int foldVals = (rtype == void.class) ? 0 : 1;
    vs.
       int foldVals = rtype == void.class ? 0 : 1;

Thanks,
-Aleksey.




From paul.sandoz at oracle.com  Fri Sep  5 10:51:51 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 5 Sep 2014 12:51:51 +0200
Subject: [9] RFR (S) 8057656: Improve MethodType.isCastableTo() &
	MethodType.isConvertibleTo() checks
In-Reply-To: <54097319.2090601@oracle.com>
References: <54097319.2090601@oracle.com>
Message-ID: <4AFFDFA0-386D-4D73-8046-284C188FEF0D@oracle.com>


On Sep 5, 2014, at 10:23 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8057656
> 

 854         if (!canConvert(returnType(), newType.returnType()))
 855             return false;
 856         Class<?>[] srcTypes = newType.ptypes;
 857         Class<?>[] dstTypes = ptypes;

Are the src and dst the wrong way around?

   srcTypes = ptypes
   dstTypes = newType.ptypes


 896     private static boolean canCast(Class<?> src, Class<?> dst) {
 897         if (src.isPrimitive() && !dst.isPrimitive()) {
 898             if (dst == Object.class || dst.isInterface())  return true;

How come if the src is primitive and the dst is an interface it returns true for any interface? I guess there are subtly different rules here for casting and conversion.

Paul.

> There are some corner cases which MT.isCastableTo() & MT.isConvertibleTo() don't treat right (e.g. int->String converstion of return type in MT.isCastableTo()).
> 
> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}.
> 
> Reviewed-by: vlivanov, ?
> Contributed-by: john.r.rose at oracle.com
> 
> Thanks!
> 
> 
> Best regards,
> Vladimir Ivanov



From vladimir.x.ivanov at oracle.com  Fri Sep  5 11:25:14 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 05 Sep 2014 15:25:14 +0400
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <686A0A9F-BA62-4BA9-A7FA-EF76AF40A2A4@oracle.com>
References: <5405CCDB.6040706@oracle.com> <5405CD4E.4070409@oracle.com>
	<686A0A9F-BA62-4BA9-A7FA-EF76AF40A2A4@oracle.com>
Message-ID: <54099D9A.4080707@oracle.com>

Paul, thanks for review.

> Generally looks good (re: Peter's observation of continue/break).
>
> - LambdaFormEditor
>
>    61     private static final class Transform {
>    62         final long packedBytes;
>    63         final byte[] fullBytes;
>    64         final LambdaForm result;  // result of transform, or null, if there is none available
>    65
>    66         private enum Kind {
>
> More an oddity really, Transform.Kind is private but exposed via package private methods.
Good point. I'll fix that.

>
>   187         static Transform of(Kind k, int b1, byte[] b234) {
>
>
> It might be worthwhile investing in a unit test for LambdaFormEditor to exercise the transform types and transitions, otherwise edge cases might bite us later.
Tests for JEP 210 (SQE is working on them) should cover that.

> I was thinking Transform could be greatly simplified if one just uses byte[], but IIUC (via JOL) that increases the instance size by 16 bytes, although that may be small compared to the LambdaForm result and if say a WekRef is also used to hold that result. Plus if that is the case the transformCache could be simplified by just supporting Transform[] and ConcurrentHashMap. I guess the underlying question i am asking here is do these space savings really give us much over some less complicated code?
All these specializations can be considered overoptimizations, but I'd 
prefer to leave them. Complexity is manageable, encapsulated, and 
localized ([1],[2]).

And these specializations are for the common case. The numbers I got for 
Octane shows that:
   (1) large transforms are very rare:
	98-99% of Transforms fit into packed representation;
   (2) for LF caches
       (a) 70-80% are single-element;
       (b) 20-30% fit into array (<16 elements)
       (c) CHM is needed very rarely (<<1%)

Best regards,
Vladimir Ivanov

[1] http://cr.openjdk.java.net/~vlivanov/lfc/editor.no_packed
[2] http://cr.openjdk.java.net/~vlivanov/lfc/editor.no_single_cache


From marcus.lagergren at oracle.com  Fri Sep  5 11:40:06 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Fri, 5 Sep 2014 13:40:06 +0200
Subject: [9] RFR (S) 8057654: Extract checks performed during MethodHandle
	construction into separate methods
In-Reply-To: <5409949E.90606@oracle.com>
References: <54096FD0.1060600@oracle.com> <5409949E.90606@oracle.com>
Message-ID: <2A8162DB-E9F0-44CD-8B86-13F11BD0BF1E@oracle.com>

+1

On 05 Sep 2014, at 12:46, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> On 09/05/2014 12:09 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8057654
> 
> Random style rant of the week, not particularly about this concrete
> patch. Can we please try to systematically use more
> readable/robust/secure idioms? E.g.:
> 
> a) Always have curly braces around the blocks?
> 
>     if (ok && ...) {
>       ok = false;
>     }
>     if (!ok) {
>       throw misMatchedTypes(...);
>     }
>     return rtype;
> 
>   vs.
> 
>     if (ok && ...)
>       ok = false;
>     if (!ok)
>       throw misMatchedTypes(...);
>     return rtype;
> 
>   Apple's "goto fail;" bug, anyone?
> 
> b) Have only a single initialization per line?
> 
>       boolean match = true;
>       boolean fail = false;
>   vs.
>       boolean match = true, fail = false;
> 
> c) Always have parentheses in ternary operators predicates?
> 
>       int foldVals = (rtype == void.class) ? 0 : 1;
>    vs.
>       int foldVals = rtype == void.class ? 0 : 1;
> 
> Thanks,
> -Aleksey.
> 
> 



From marcus.lagergren at oracle.com  Fri Sep  5 11:41:27 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Fri, 5 Sep 2014 13:41:27 +0200
Subject: [9] RFR (S) 8057654: Extract checks performed during MethodHandle
	construction into separate methods
In-Reply-To: <2A8162DB-E9F0-44CD-8B86-13F11BD0BF1E@oracle.com>
References: <54096FD0.1060600@oracle.com> <5409949E.90606@oracle.com>
	<2A8162DB-E9F0-44CD-8B86-13F11BD0BF1E@oracle.com>
Message-ID: <F55FB23A-8FE6-40CE-8C55-9D7473911328@oracle.com>

To the style rant, I mean.

On 05 Sep 2014, at 13:40, Marcus Lagergren <marcus.lagergren at oracle.com> wrote:

> +1
> 
> On 05 Sep 2014, at 12:46, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
>> On 09/05/2014 12:09 PM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8057654
>> 
>> Random style rant of the week, not particularly about this concrete
>> patch. Can we please try to systematically use more
>> readable/robust/secure idioms? E.g.:
>> 
>> a) Always have curly braces around the blocks?
>> 
>>    if (ok && ...) {
>>      ok = false;
>>    }
>>    if (!ok) {
>>      throw misMatchedTypes(...);
>>    }
>>    return rtype;
>> 
>>  vs.
>> 
>>    if (ok && ...)
>>      ok = false;
>>    if (!ok)
>>      throw misMatchedTypes(...);
>>    return rtype;
>> 
>>  Apple's "goto fail;" bug, anyone?
>> 
>> b) Have only a single initialization per line?
>> 
>>      boolean match = true;
>>      boolean fail = false;
>>  vs.
>>      boolean match = true, fail = false;
>> 
>> c) Always have parentheses in ternary operators predicates?
>> 
>>      int foldVals = (rtype == void.class) ? 0 : 1;
>>   vs.
>>      int foldVals = rtype == void.class ? 0 : 1;
>> 
>> Thanks,
>> -Aleksey.
>> 
>> 
> 



From paul.sandoz at oracle.com  Fri Sep  5 11:51:16 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 5 Sep 2014 13:51:16 +0200
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <54099D9A.4080707@oracle.com>
References: <5405CCDB.6040706@oracle.com> <5405CD4E.4070409@oracle.com>
	<686A0A9F-BA62-4BA9-A7FA-EF76AF40A2A4@oracle.com>
	<54099D9A.4080707@oracle.com>
Message-ID: <749F4F77-99B4-4F7C-B976-7346BD52103C@oracle.com>


On Sep 5, 2014, at 1:25 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> Paul, thanks for review.
> 
>> Generally looks good (re: Peter's observation of continue/break).
>> 
>> - LambdaFormEditor
>> 
>>   61     private static final class Transform {
>>   62         final long packedBytes;
>>   63         final byte[] fullBytes;
>>   64         final LambdaForm result;  // result of transform, or null, if there is none available
>>   65
>>   66         private enum Kind {
>> 
>> More an oddity really, Transform.Kind is private but exposed via package private methods.
> Good point. I'll fix that.
> 

+1 on review.


>> 
>>  187         static Transform of(Kind k, int b1, byte[] b234) {
>> 
>> 
>> It might be worthwhile investing in a unit test for LambdaFormEditor to exercise the transform types and transitions, otherwise edge cases might bite us later.
> Tests for JEP 210 (SQE is working on them) should cover that.
> 

Ok.


>> I was thinking Transform could be greatly simplified if one just uses byte[], but IIUC (via JOL) that increases the instance size by 16 bytes, although that may be small compared to the LambdaForm result and if say a WekRef is also used to hold that result. Plus if that is the case the transformCache could be simplified by just supporting Transform[] and ConcurrentHashMap. I guess the underlying question i am asking here is do these space savings really give us much over some less complicated code?
> All these specializations can be considered overoptimizations, but I'd prefer to leave them. Complexity is manageable, encapsulated, and localized ([1],[2]).
> 

> And these specializations are for the common case. The numbers I got for Octane shows that:
>  (1) large transforms are very rare:
> 	98-99% of Transforms fit into packed representation;
>  (2) for LF caches
>      (a) 70-80% are single-element;
>      (b) 20-30% fit into array (<16 elements)
>      (c) CHM is needed very rarely (<<1%)
> 

OK, good to see some numbers on this, quite reassuring.

Paul.


From forax at univ-mlv.fr  Fri Sep  5 12:30:52 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 05 Sep 2014 14:30:52 +0200
Subject: [9] RFR (S) 8057654: Extract checks performed during MethodHandle
	construction into separate methods
In-Reply-To: <E51234CD-9234-4126-9C2D-94724C85B7A8@oracle.com>
References: <54096FD0.1060600@oracle.com>
	<E51234CD-9234-4126-9C2D-94724C85B7A8@oracle.com>
Message-ID: <5409ACFC.1010205@univ-mlv.fr>


On 09/05/2014 12:31 PM, Paul Sandoz wrote:
> On Sep 5, 2014, at 10:09 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8057654
>>
> +1
>
> Paul.

*@SuppressWarnings("LocalVariableHidesMemberVariable")*

AFAIK, this is not a standard suppress warnings name,
i would prefer not having this kind of annotation in the code because 
IMO, it doesn't pull it's own weight.

cheers;
R?mi



From vladimir.x.ivanov at oracle.com  Fri Sep  5 12:44:05 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 05 Sep 2014 16:44:05 +0400
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <749F4F77-99B4-4F7C-B976-7346BD52103C@oracle.com>
References: <5405CCDB.6040706@oracle.com>
	<5405CD4E.4070409@oracle.com>	<686A0A9F-BA62-4BA9-A7FA-EF76AF40A2A4@oracle.com>	<54099D9A.4080707@oracle.com>
	<749F4F77-99B4-4F7C-B976-7346BD52103C@oracle.com>
Message-ID: <5409B015.1060804@oracle.com>

Paul, Peter, Morris, thanks for review.

Best regards,
Vladimir Ivanov

On 9/5/14, 3:51 PM, Paul Sandoz wrote:
>
> On Sep 5, 2014, at 1:25 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> Paul, thanks for review.
>>
>>> Generally looks good (re: Peter's observation of continue/break).
>>>
>>> - LambdaFormEditor
>>>
>>>    61     private static final class Transform {
>>>    62         final long packedBytes;
>>>    63         final byte[] fullBytes;
>>>    64         final LambdaForm result;  // result of transform, or null, if there is none available
>>>    65
>>>    66         private enum Kind {
>>>
>>> More an oddity really, Transform.Kind is private but exposed via package private methods.
>> Good point. I'll fix that.
>>
>
> +1 on review.
>
>
>>>
>>>   187         static Transform of(Kind k, int b1, byte[] b234) {
>>>
>>>
>>> It might be worthwhile investing in a unit test for LambdaFormEditor to exercise the transform types and transitions, otherwise edge cases might bite us later.
>> Tests for JEP 210 (SQE is working on them) should cover that.
>>
>
> Ok.
>
>
>>> I was thinking Transform could be greatly simplified if one just uses byte[], but IIUC (via JOL) that increases the instance size by 16 bytes, although that may be small compared to the LambdaForm result and if say a WekRef is also used to hold that result. Plus if that is the case the transformCache could be simplified by just supporting Transform[] and ConcurrentHashMap. I guess the underlying question i am asking here is do these space savings really give us much over some less complicated code?
>> All these specializations can be considered overoptimizations, but I'd prefer to leave them. Complexity is manageable, encapsulated, and localized ([1],[2]).
>>
>
>> And these specializations are for the common case. The numbers I got for Octane shows that:
>>   (1) large transforms are very rare:
>> 	98-99% of Transforms fit into packed representation;
>>   (2) for LF caches
>>       (a) 70-80% are single-element;
>>       (b) 20-30% fit into array (<16 elements)
>>       (c) CHM is needed very rarely (<<1%)
>>
>
> OK, good to see some numbers on this, quite reassuring.
>
> Paul.
>


From claes.redestad at oracle.com  Fri Sep  5 13:03:33 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 05 Sep 2014 15:03:33 +0200
Subject: [9] RFR 8055251: Re-examine Integer.parseInt and Long.parseLong
	methods
Message-ID: <5409B4A5.20604@oracle.com>

Hi,

I'm requesting reviews and a sponsor for these changes to the recently
added parse methods (8041972), suggested during discussions on net-dev:

bug: https://bugs.openjdk.java.net/browse/JDK-8055251
webrev: http://cr.openjdk.java.net/~redestad/8055251/webrev.1/
discussion:http://mail.openjdk.java.net/pipermail/net-dev/2014-August/008625.html

Changes:
- Removethe following methods:
Integer::parseInt(CharSequence s, int radix, int beginIndex)
Integer::parseUnsignedInt(CharSequence s, int radix, int beginIndex)
Long::parseLong(CharSequence s, int radix, int beginIndex)
Long::parseUnsignedLong(CharSequence s, int radix, int beginIndex)

- Move radix parameter to the end in the following methods:
Integer::parseInt(CharSequence s, int radix, int beginIndex, int endIndex)
Integer::parseUnsignedInt(CharSequence s, int radix, int beginIndex, int 
endIndex)
Long::parseLong(CharSequence s, int radix, int beginIndex, int endIndex)
Long::parseUnsignedLong(CharSequence s, int radix, int beginIndex, int 
endIndex)

- Change all places in the code where the methods already have been adopted
- Add some tests for parseUnsignedInt/-Long
- Ensure that when parsing fails the correct index is reported in the 
exception

/Claes


From paul.sandoz at oracle.com  Fri Sep  5 13:13:13 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 5 Sep 2014 15:13:13 +0200
Subject: [9] RFR (S) 8057654: Extract checks performed during MethodHandle
	construction into separate methods
In-Reply-To: <5409ACFC.1010205@univ-mlv.fr>
References: <54096FD0.1060600@oracle.com>
	<E51234CD-9234-4126-9C2D-94724C85B7A8@oracle.com>
	<5409ACFC.1010205@univ-mlv.fr>
Message-ID: <A7541A27-8017-4A07-BAEE-DE963EA6F8B5@oracle.com>


On Sep 5, 2014, at 2:30 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> 
> On 09/05/2014 12:31 PM, Paul Sandoz wrote:
>> On Sep 5, 2014, at 10:09 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>> 
>>> http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8057654
>>> 
>> +1
>> 
>> Paul.
> 
> *@SuppressWarnings("LocalVariableHidesMemberVariable")*
> 
> AFAIK, this is not a standard suppress warnings name,
> i would prefer not having this kind of annotation in the code because IMO, it doesn't pull it's own weight.
> 

I nearly called that out too (sitting on the fence a little in this respect). Might be worth doing as a separate pass.

Paul.


From vladimir.x.ivanov at oracle.com  Fri Sep  5 13:15:47 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 05 Sep 2014 17:15:47 +0400
Subject: [9] RFR (S) 8050173: Generalize BMH.copyWith API to all method
	handles
In-Reply-To: <5D69CF8C-01C8-43BC-9D9D-60063484899B@oracle.com>
References: <53C3EB3B.8080103@oracle.com>
	<5D69CF8C-01C8-43BC-9D9D-60063484899B@oracle.com>
Message-ID: <5409B783.1090502@oracle.com>

>> http://cr.openjdk.java.net/~vlivanov/8050173/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8050173
>>
>> Added j.l.i.MethodHandle.copyWith(MethodType, LambdaForm) and provided implementation for all subclasses.
>>
>> Also, some cleanups:
>>   * rewrote MH.viewAsType on top of MH.copyWith;
>>   * extended MH.viewAsType to do strict checks w/ assertions turned on (new parameter: boolean strict);
>>   * extended MT.isViewableAs to accept both interface preserving and interface erasing conversions (new parameter: boolean keepInterfaces).
>>
>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>>
>> Reviewed-by: vlivanov, ?
>> Contributed-by: john.r.rose at oracle.com
>>
>
> Looks good, just one comment.
>
> MethodHandles.restrictReceiver
>
> This method has:
>
> 1578         private MethodHandle restrictReceiver(MemberName method, MethodHandle mh, Class<?> caller) throws IllegalAccessException {
> ...
> 1589             assert(mh instanceof DirectMethodHandle);  // DirectMethodHandle.copyWith
>
> Why not make the second parameter be "DirectMethodHandle mh" ?
Good point! While prototyping this I spotted uncovered corner case 
(restrict a receiver on a MH with bound caller).

Updated webrev:
   http://cr.openjdk.java.net/~vlivanov/8050173/webrev.01/
Diff:
   http://cr.openjdk.java.net/~vlivanov/8050173/webrev.00.01/

Reordered restrictReceiver and maybeBindCaller operations.

Best regards,
Vladimir Ivanov


From vladimir.x.ivanov at oracle.com  Fri Sep  5 13:37:14 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 05 Sep 2014 17:37:14 +0400
Subject: [9] RFR (S) 8057654: Extract checks performed during MethodHandle
	construction into separate methods
In-Reply-To: <A7541A27-8017-4A07-BAEE-DE963EA6F8B5@oracle.com>
References: <54096FD0.1060600@oracle.com>	<E51234CD-9234-4126-9C2D-94724C85B7A8@oracle.com>	<5409ACFC.1010205@univ-mlv.fr>
	<A7541A27-8017-4A07-BAEE-DE963EA6F8B5@oracle.com>
Message-ID: <5409BC8A.4060506@oracle.com>

Paul, Remi, thanks for review.

Renamed type -> mtype & removed @SuppressWarnings.

Updated webrev in place.

Best regards,
Vladimir Ivanov

On 9/5/14, 5:13 PM, Paul Sandoz wrote:
>
> On Sep 5, 2014, at 2:30 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>>
>> On 09/05/2014 12:31 PM, Paul Sandoz wrote:
>>> On Sep 5, 2014, at 10:09 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>>
>>>> http://cr.openjdk.java.net/~vlivanov/8057654/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8057654
>>>>
>>> +1
>>>
>>> Paul.
>>
>> *@SuppressWarnings("LocalVariableHidesMemberVariable")*
>>
>> AFAIK, this is not a standard suppress warnings name,
>> i would prefer not having this kind of annotation in the code because IMO, it doesn't pull it's own weight.
>>
>
> I nearly called that out too (sitting on the fence a little in this respect). Might be worth doing as a separate pass.
>
> Paul.
>


From paul.sandoz at oracle.com  Fri Sep  5 13:46:38 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 5 Sep 2014 15:46:38 +0200
Subject: [9] RFR (S) 8050173: Generalize BMH.copyWith API to all method
	handles
In-Reply-To: <5409B783.1090502@oracle.com>
References: <53C3EB3B.8080103@oracle.com>
	<5D69CF8C-01C8-43BC-9D9D-60063484899B@oracle.com>
	<5409B783.1090502@oracle.com>
Message-ID: <F76FE646-14A7-468B-A11C-FE4706F498C9@oracle.com>

On Sep 5, 2014, at 3:15 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>> 
>> Looks good, just one comment.
>> 
>> MethodHandles.restrictReceiver
>> 
>> This method has:
>> 
>> 1578         private MethodHandle restrictReceiver(MemberName method, MethodHandle mh, Class<?> caller) throws IllegalAccessException {
>> ...
>> 1589             assert(mh instanceof DirectMethodHandle);  // DirectMethodHandle.copyWith
>> 
>> Why not make the second parameter be "DirectMethodHandle mh" ?
> Good point! While prototyping this I spotted uncovered corner case (restrict a receiver on a MH with bound caller).
> 
> Updated webrev:
>  http://cr.openjdk.java.net/~vlivanov/8050173/webrev.01/
> Diff:
>  http://cr.openjdk.java.net/~vlivanov/8050173/webrev.00.01/
> 
> Reordered restrictReceiver and maybeBindCaller operations.
> 

Looks good,
Paul.


From Alan.Bateman at oracle.com  Fri Sep  5 13:49:31 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 05 Sep 2014 14:49:31 +0100
Subject: [9] RFR 8055251: Re-examine Integer.parseInt and Long.parseLong
	methods
In-Reply-To: <5409B4A5.20604@oracle.com>
References: <5409B4A5.20604@oracle.com>
Message-ID: <5409BF6B.6010609@oracle.com>

On 05/09/2014 14:03, Claes Redestad wrote:
> Hi,
>
> I'm requesting reviews and a sponsor for these changes to the recently
> added parse methods (8041972), suggested during discussions on net-dev:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8055251
> webrev: http://cr.openjdk.java.net/~redestad/8055251/webrev.1/
Thanks for doing this, I think the API is much better now and much less 
error prone.

The drive-by fix to the index in the NumberFormatException also looks good.

-Alan.


From vladimir.x.ivanov at oracle.com  Fri Sep  5 16:42:58 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 05 Sep 2014 20:42:58 +0400
Subject: [9] RFR (S) 8057656: Improve MethodType.isCastableTo() &
	MethodType.isConvertibleTo() checks
In-Reply-To: <4AFFDFA0-386D-4D73-8046-284C188FEF0D@oracle.com>
References: <54097319.2090601@oracle.com>
	<4AFFDFA0-386D-4D73-8046-284C188FEF0D@oracle.com>
Message-ID: <5409E812.50302@oracle.com>

 >> http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8057656
>>
>
>   854         if (!canConvert(returnType(), newType.returnType()))
>   855             return false;
>   856         Class<?>[] srcTypes = newType.ptypes;
>   857         Class<?>[] dstTypes = ptypes;
>
> Are the src and dst the wrong way around?
>
>     srcTypes = ptypes
>     dstTypes = newType.ptypes
No, they are right. Parameters and return type conversions have opposite 
directions.

>   896     private static boolean canCast(Class<?> src, Class<?> dst) {
>   897         if (src.isPrimitive() && !dst.isPrimitive()) {
>   898             if (dst == Object.class || dst.isInterface())  return true;
>
> How come if the src is primitive and the dst is an interface it returns true for any interface? I guess there are subtly different rules here for casting and conversion.
There are 2 types of converstions: MH.asType() and 
MHs.explicitCastArguemnts() with more relaxed semantics.
One of the differences is that interfaces are coerced to Object, since 
verifier allows any interface to be treated as Object.

Your questions reminded me about related changes waiting in the queue 
and I decided to include then here.

Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8057656/webrev.01/

Got rid of MT.isCastableTo(). MHs.explicitCastEquivalentToAsType() is 
used instead. Also, it has detailed overview of differences between 
MT.asType() and MHs.explicitCastArguments().

Best regards,
Vladimir Ivanov

>
> Paul.
>
>> There are some corner cases which MT.isCastableTo() & MT.isConvertibleTo() don't treat right (e.g. int->String converstion of return type in MT.isCastableTo()).
>>
>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>>
>> Reviewed-by: vlivanov, ?
>> Contributed-by: john.r.rose at oracle.com
>>
>> Thanks!
>>
>>
>> Best regards,
>> Vladimir Ivanov
>


From john.r.rose at oracle.com  Fri Sep  5 17:26:29 2014
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 5 Sep 2014 10:26:29 -0700
Subject: [9] RFR (S) 8050173: Generalize BMH.copyWith API to all method
	handles
In-Reply-To: <5D69CF8C-01C8-43BC-9D9D-60063484899B@oracle.com>
References: <53C3EB3B.8080103@oracle.com>
	<5D69CF8C-01C8-43BC-9D9D-60063484899B@oracle.com>
Message-ID: <6209D663-ABC8-4739-A267-BA6436F8D85A@oracle.com>

On Jul 16, 2014, at 1:50 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Why not make the second parameter be "DirectMethodHandle mh" ?

Good suggestion; thanks.  Makes the restrictReceiver logic less magic.  ? John



From konstantin.shefov at oracle.com  Fri Sep  5 17:52:45 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 05 Sep 2014 21:52:45 +0400
Subject: [9] Review request : JDK-8057719: Develop new tests for LambdaForm
	Reduction and Caching feature
Message-ID: <5409F86D.8040200@oracle.com>

Hello,

Please review the new tests for the feature "Lambda Form Reduction and 
Caching" https://bugs.openjdk.java.net/browse/JDK-8046703

JBS task: https://bugs.openjdk.java.net/browse/JDK-8057719

Webrev: http://cr.openjdk.java.net/~kshefov/8057719/webrev.00/

These tests also depend on testlibrary change: 
https://bugs.openjdk.java.net/browse/JDK-8057707
Webrev of the testlib change: 
http://cr.openjdk.java.net/~kshefov/8057707/webrev.00/

Thanks

-Konstantin


From konstantin.shefov at oracle.com  Fri Sep  5 17:57:59 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 05 Sep 2014 21:57:59 +0400
Subject: [9] Review request : JDK-8057707: TEST library enhancement: copy
	sun.hotspot.whitebox classes from hotspot repo and enhance
	lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java
Message-ID: <5409F9A7.9070208@oracle.com>

Hello,

Please review the change in testlibrary 
https://bugs.openjdk.java.net/browse/JDK-8057707
This change is needed for new tests for the feature "Lambda Form 
Reduction and Caching" https://bugs.openjdk.java.net/browse/JDK-8046703

Webrev of the testlibrary change: 
http://cr.openjdk.java.net/~kshefov/8057707/webrev.00/

JBS entry for new test dev is 
https://bugs.openjdk.java.net/browse/JDK-8057719
Webrev for new tests is 
http://cr.openjdk.java.net/~kshefov/8057719/webrev.00/

Thanks

-Konstantin


From martinrb at google.com  Fri Sep  5 19:51:30 2014
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 5 Sep 2014 12:51:30 -0700
Subject: Impact of code difference in Collection#contains() worth
	improving?
In-Reply-To: <911C95F8-70D5-4F36-A7D6-D3564CA8B324@oracle.com>
References: <CAFNq5NN9K5-Z2U-zSFUV7kFd-GVW7V+fyx92+QdWj_oVr1mRMA@mail.gmail.com>
	<CA+kOe09wi67q7dEiwCSW72qqe55n-X5kmh+Cu+NRpeY2x-57Yw@mail.gmail.com>
	<53FF6680.9000907@CoSoCo.de>
	<CAHjP37F=+j0jRsm6+a-94qgwfXiM4SngM5+odYQKo+BZukNoRA@mail.gmail.com>
	<5400DCF0.6090302@CoSoCo.de>
	<56359349-BC8F-4EFE-8260-D118E5312873@oracle.com>
	<911C95F8-70D5-4F36-A7D6-D3564CA8B324@oracle.com>
Message-ID: <CA+kOe090KisCGTnDU=tTwgFNCpi=WuE=E+rO9kxjnDrZefyN=Q@mail.gmail.com>

On Fri, Aug 29, 2014 at 7:53 PM, Guy Steele <guy.steele at oracle.com> wrote:

>
> But I cannot resist recalling that one of the earliest pieces of software
> in the implementation of EMACS (back when the implementation language was
> TECO, a text-editing language) was a routine that, when it loaded TECO
> macros from a file, would carefully remove comments and excess whitespace
> in order to improve the execution speed of the macros (and therefore the
> response time of the EMACS keystrokes)!  We have come a long, long way in
> 38 years.
>

I often think we haven't made enough progress on the basic things. Worrying
about comments in our TECO macros is a lot like worrying about dead
assertion code in our compiled bytecode.

And we are still plagued by fixed size native stacks, the 64k bytecode size
limit, unreliable Unix signals, and of course, unavailability of tail
recursion.


From coleen.phillimore at oracle.com  Fri Sep  5 19:55:26 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 05 Sep 2014 15:55:26 -0400
Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader()
Message-ID: <540A152E.9020507@oracle.com>

Summary: Add classLoader to java/lang/Class instance for fast access

This is a backport request for 8u40.   This change has been in the jdk9 
code for 3 months without any problems.

The JDK changes hg imported cleanly.  The Hotspot change needed a hand 
merge for create_mirror call in klass.cpp.

http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/
http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/

bug link https://bugs.openjdk.java.net/browse/JDK-6642881

Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. Also ran 
jck java_lang tests with only the hotspot change.  The hotspot change 
can be tested separately from the jdk change (but not the other way around).

Thanks,
Coleen


From Alan.Bateman at oracle.com  Fri Sep  5 20:38:36 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 05 Sep 2014 21:38:36 +0100
Subject: [9] Review request : JDK-8057707: TEST library enhancement: copy
	sun.hotspot.whitebox classes from hotspot repo and enhance
	lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java
In-Reply-To: <5409F9A7.9070208@oracle.com>
References: <5409F9A7.9070208@oracle.com>
Message-ID: <540A1F4C.8080007@oracle.com>

On 05/09/2014 18:57, Konstantin Shefov wrote:
> Hello,
>
> Please review the change in testlibrary 
> https://bugs.openjdk.java.net/browse/JDK-8057707
> This change is needed for new tests for the feature "Lambda Form 
> Reduction and Caching" https://bugs.openjdk.java.net/browse/JDK-8046703
>
> Webrev of the testlibrary change: 
> http://cr.openjdk.java.net/~kshefov/8057707/webrev.00/
It seems a bit strange, are you sure this is right thing to do? I would 
have thought that tests using the hotspot whitebox library would be 
pushed to the hotspot/test tree.

-Alan


From lance.andersen at oracle.com  Fri Sep  5 20:44:12 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 5 Sep 2014 16:44:12 -0400
Subject: RFR (JAXP) 8056202: Xerces Update: Catalog Resolver
In-Reply-To: <53FFE982.7080408@oracle.com>
References: <53FFE982.7080408@oracle.com>
Message-ID: <06AE9C7A-760C-4A70-8FBA-9A852421FB81@oracle.com>

Hi Joe,

This seems OK

Best,
Lance
On Aug 28, 2014, at 10:46 PM, huizhe wang <huizhe.wang at oracle.com> wrote:

> Hi,
> 
> This is an update to Xerces' Catalog Resolver implementation. The changes were mostly performance related, for example the changes to the normalizeURI method in Catalog.java to avoid creating new Strings if the input is already in normalized form.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8056202
> Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8056202/webrev/
> 
> Thanks,
> Joe
> 



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From huizhe.wang at oracle.com  Fri Sep  5 20:55:57 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 05 Sep 2014 13:55:57 -0700
Subject: RFR (JAXP) 8056202: Xerces Update: Catalog Resolver
In-Reply-To: <06AE9C7A-760C-4A70-8FBA-9A852421FB81@oracle.com>
References: <53FFE982.7080408@oracle.com>
	<06AE9C7A-760C-4A70-8FBA-9A852421FB81@oracle.com>
Message-ID: <540A235D.5030702@oracle.com>

Thanks Lance!

Joe

On 9/5/2014 1:44 PM, Lance Andersen wrote:
> Hi Joe,
>
> This seems OK
>
> Best,
> Lance
> On Aug 28, 2014, at 10:46 PM, huizhe wang <huizhe.wang at oracle.com 
> <mailto:huizhe.wang at oracle.com>> wrote:
>
>> Hi,
>>
>> This is an update to Xerces' Catalog Resolver implementation. The 
>> changes were mostly performance related, for example the changes to 
>> the normalizeURI method in Catalog.java to avoid creating new Strings 
>> if the input is already in normalized form.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056202
>> Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8056202/webrev/ 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8056202/webrev/>
>>
>> Thanks,
>> Joe
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From konstantin.shefov at oracle.com  Fri Sep  5 21:18:21 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Sat, 06 Sep 2014 01:18:21 +0400
Subject: =?US-ASCII?Q?Re:_[9]_Review_request_:_JDK-8057707:_TEST_libr?=
	=?US-ASCII?Q?ary_enhancement:_copy=0D__sun.hotspot.whitebox_clas?=
	=?US-ASCII?Q?ses_from_hotspot_repo_and_enhance_lib/testlibrar?=
	=?US-ASCII?Q?y/jsr292/com/oracle/testlibrary/jsr292/Helper.java?=
Message-ID: <r250moyxlivucw7ric41p77s.1409951901022@email.android.com>

These test are for core-libs feature, but we want to test that unused lambda forms are garbage collected using WhiteBox.fullGC() method. There are three tests that use one common class, only one of them uses whitebox api. So it is hard to move one of tests to hotspot repo.


- Konstantin

-------- ???????? ????????? --------
??: Alan Bateman <Alan.Bateman at oracle.com> 
????:06.09.2014  0:38  (GMT+04:00) 
????: Konstantin Shefov <konstantin.shefov at oracle.com>,"VLADIMIR.X.IVANOV" <vladimir.x.ivanov at oracle.com>,core-libs-dev at openjdk.java.net,mlvm-dev at openjdk.java.net 
????: Re: [9] Review request : JDK-8057707: TEST library enhancement: copy
  sun.hotspot.whitebox classes from hotspot repo and enhance lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java 

On 05/09/2014 18:57, Konstantin Shefov wrote:
> Hello,
>
> Please review the change in testlibrary 
> https://bugs.openjdk.java.net/browse/JDK-8057707
> This change is needed for new tests for the feature "Lambda Form 
> Reduction and Caching" https://bugs.openjdk.java.net/browse/JDK-8046703
>
> Webrev of the testlibrary change: 
> http://cr.openjdk.java.net/~kshefov/8057707/webrev.00/
It seems a bit strange, are you sure this is right thing to do? I would 
have thought that tests using the hotspot whitebox library would be 
pushed to the hotspot/test tree.

-Alan

From john.r.rose at oracle.com  Fri Sep  5 23:25:24 2014
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 5 Sep 2014 16:25:24 -0700
Subject: Impact of code difference in Collection#contains() worth
	improving?
In-Reply-To: <5401DD04.6050802@CoSoCo.de>
References: <CAFNq5NN9K5-Z2U-zSFUV7kFd-GVW7V+fyx92+QdWj_oVr1mRMA@mail.gmail.com>	<CA+kOe09wi67q7dEiwCSW72qqe55n-X5kmh+Cu+NRpeY2x-57Yw@mail.gmail.com>	<53FF6680.9000907@CoSoCo.de>
	<CAHjP37F=+j0jRsm6+a-94qgwfXiM4SngM5+odYQKo+BZukNoRA@mail.gmail.com>
	<5400DCF0.6090302@CoSoCo.de>
	<56359349-BC8F-4EFE-8260-D118E5312873@oracle.com>
	<5401DD04.6050802@CoSoCo.de>
Message-ID: <9F31BE9F-0E77-43CD-A693-659008E3E3C0@oracle.com>

On Aug 30, 2014, at 7:17 AM, Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:

> Am 30.08.2014 um 01:33 schrieb John Rose:
>> On Aug 29, 2014, at 1:05 PM, Ulf Zibis <Ulf.Zibis at cosoco.de <mailto:Ulf.Zibis at cosoco.de>> wrote:
>> 
>>> Thanks for explaining this, but a very little nit: the immediate (I.e. -1) uses additional 32/64 bits in code which must be loaded from memory and wastes space in CPU cache or am I wrong? This could be saved with >= 0.
>> 
>> I have to say you're more wrong than right about this.  Optimizers routinely change the form of constants.  For example, a constant 0 will often show up as something like "xor eax,eax", not a 32-bit literal zero that loads from somewhere in memory.  A comparison of the form "x > -1" will be freely changed to "x >= 0" and back again; the latter form may (or may not, depending on chip version) transform to "test eax", with no "-1" or "0" in sight.
> 
> 1. Thanks for the hint about "x > -1" ===> "x >= 0". But I'm afraid this would apply on the "x != -1" case we are discussing here.

The equality comparison would be less likely to transform to a non-equality comparison.  But it is still possible in principle, if the JIT could prove that values "x < -1" are impossible.

> 2. Are you really sure this optimization is always implemented, as following bug is still open:
> JDK-6984886 : Transform comparisons against odd border to even border <http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6984886>

Well, I'm pretty sure that no optimizations is "always" implemented; there are usually corner cases which prevent optimizations.  There is always a possibility of deoptimization to the interpreter, for example.  And there are lots of nice-to-have optimizations that don't make a difference to real applications.  Much of compiler development is driven by observing actual speed bottlenecks and removing them.

But the bug reference is useful; thanks!  I added a comment to show where the optimization occurs now?disappointingly little I grant you?and where to start looking to improve it.  The bug is rated P5 (lowest rating) probably because the reporter said "it should be faster"; "wouldn't this be nice" is a far weaker argument than "I'm spending too much on hardware because this loop is slow".

My comments about the unpredictability of optimizers still stand.  The most robust way to manage such problems is, first confirm it is a real performance problem (not a micro-nano thing), and second get the optimizer to make all equivalent inputs produce good code.  The tiny place where this optimization is done in HotSpot suggests that that was a place where the transform actually mattered the most.

? John

From john.r.rose at oracle.com  Fri Sep  5 23:32:36 2014
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 5 Sep 2014 16:32:36 -0700
Subject: Impact of code difference in Collection#contains() worth
	improving?
In-Reply-To: <540210CB.3050402@cs.oswego.edu>
References: <CAFNq5NN9K5-Z2U-zSFUV7kFd-GVW7V+fyx92+QdWj_oVr1mRMA@mail.gmail.com>	<CA+kOe09wi67q7dEiwCSW72qqe55n-X5kmh+Cu+NRpeY2x-57Yw@mail.gmail.com>	<53FF6680.9000907@CoSoCo.de>	<CAHjP37F=+j0jRsm6+a-94qgwfXiM4SngM5+odYQKo+BZukNoRA@mail.gmail.com>	<5400DCF0.6090302@CoSoCo.de>	<56359349-BC8F-4EFE-8260-D118E5312873@oracle.com>	<CA+kOe0-Z_dNvn0T-K-81GMpcwqsS=Rv+qPDLTrWZt3aaz4XcFw@mail.gmail.com>
	<C63148E4-BFD6-460C-B295-54F8588E956C@oracle.com>
	<540210CB.3050402@cs.oswego.edu>
Message-ID: <2223E11A-DDEF-4209-9ED7-883496D05135@oracle.com>

On Aug 30, 2014, at 10:58 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> In the present case, I'm with Martin about short-circuiting
> this with a simple approximate answer: Rather than flip a coin
> choosing between solutions A and B, pick the one with smaller bytecode.
> This has a decent enough correlation with actual performance
> factors to better than chance. And even if the effects are small,
> sometimes the only path to making things substantially faster
> is a few percent at a time.

I grant you that's better than a coin flip.

Contributions from the constant pool and various attributes are going to be pretty noisy and unrelated to instruction traces.

You'll get somewhat less random information from measuring the affected method's bytecodes.

(Which is hard to do without writing an ASM-based tool, and compared with "wc -c Foo.class".)

? John

From yasuenag at gmail.com  Sat Sep  6 15:05:35 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Sun, 07 Sep 2014 00:05:35 +0900
Subject: RFR: JDK-8057556: JDP should better handle non-active interfaces
In-Reply-To: <54099040.4040100@gmail.com>
References: <5405D9A7.3030405@gmail.com> <54085A78.7030205@oracle.com>
	<54088C4F.10204@gmail.com>
	<099DBC50-7324-49D1-8E10-36DE2EBB4962@oracle.com>
	<54099040.4040100@gmail.com>
Message-ID: <540B22BF.3010409@gmail.com>

Hi all,

My patch works fine in my environment, however, JMX agent will be terminated
silently when I run command as following:

java -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.authenticate=false
      -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.autodiscovery=true
      -Dcom.sun.management.jdp.source_addr=255.255.255.255 -version

Curently, sun.management.Agent#startDiscoveryService() throws AgentConfigurationError
when JdpException is occurred. However, argument of AgentConfiguratonError constructor
is incorrected. So NPE will be occurred. (I checked it with jdb.)

I think that we should fix it as following.

-----------
diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/Agent.java
--- a/src/java.management/share/classes/sun/management/Agent.java       Mon Sep 01 13:33:28 2014 +0200
+++ b/src/java.management/share/classes/sun/management/Agent.java       Sat Sep 06 23:50:58 2014 +0900
@@ -210,6 +210,8 @@
              } else {
                  throw new AgentConfigurationError(INVALID_JMXREMOTE_PORT, "No port specified");
              }
+        } catch (JdpException e) {
+            error(e);
          } catch (AgentConfigurationError err) {
              error(err.getError(), err.getParams());
          }
@@ -273,7 +275,7 @@
      }

      private static void startDiscoveryService(Properties props)
-            throws IOException {
+            throws IOException, JdpException {
          // Start discovery service if requested
          String discoveryPort = props.getProperty("com.sun.management.jdp.port");
          String discoveryAddress = props.getProperty("com.sun.management.jdp.address");
@@ -291,7 +293,7 @@
              try{
                 shouldStart = Boolean.parseBoolean(discoveryShouldStart);
              } catch (NumberFormatException e) {
-                throw new AgentConfigurationError("Couldn't parse autodiscovery argument");
+                throw new AgentConfigurationError(AGENT_EXCEPTION, "Couldn't parse autodiscovery argument");
              }
          }

@@ -302,7 +304,7 @@
                  address = (discoveryAddress == null) ?
                          InetAddress.getByName(JDP_DEFAULT_ADDRESS) : InetAddress.getByName(discoveryAddress);
              } catch (UnknownHostException e) {
-                throw new AgentConfigurationError("Unable to broadcast to requested address", e);
+                throw new AgentConfigurationError(AGENT_EXCEPTION, e, "Unable to broadcast to requested address");
              }

              int port = JDP_DEFAULT_PORT;
@@ -310,7 +312,7 @@
                 try {
                    port = Integer.parseInt(discoveryPort);
                 } catch (NumberFormatException e) {
-                 throw new AgentConfigurationError("Couldn't parse JDP port argument");
+                 throw new AgentConfigurationError(AGENT_EXCEPTION, "Couldn't parse JDP port argument");
                 }
              }

@@ -330,12 +332,7 @@

              String instanceName = props.getProperty("com.sun.management.jdp.name");

-            try{
-               JdpController.startDiscoveryService(address, port, instanceName, jmxUrlStr);
-            }
-            catch(JdpException e){
-                throw new AgentConfigurationError("Couldn't start JDP service", e);
-            }
+            JdpController.startDiscoveryService(address, port, instanceName, jmxUrlStr);
          }
      }

-----------


I want also to contribute it.
Should I merge it to JDK-8057556? Or should I file to JBS as new issue?


Thanks,

Yasumasa


(2014/09/05 19:28), Yasumasa Suenaga wrote:
> Hi Peter,
>
> I fixed it and created new webrev.
> http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.1/
>
> Could you review it again?
>
>
> Thanks,
>
> Yasumasa
>
>
> (2014/09/05 17:20), Peter Allwin wrote:
>> Looks like only the first Interface will be considered if no srcAddress is provided (succeeded will be false and we will throw to exit the while loop). Is this intended?
>>
>> Thanks!
>> /peter
>>
>>> On 4 sep 2014, at 17:59, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> Thank you so much, Dmitry!
>>>
>>> I've created webrev for it.
>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.0/
>>>
>>> Please review.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> (2014/09/04 21:26), Dmitry Samersoff wrote:
>>>> Yasumasa,
>>>>
>>>> The CR number is JDK-8057556
>>>>
>>>> I'll care about it's integration.
>>>>
>>>> -Dmitry
>>>>
>>>>> On 2014-09-02 18:52, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm trying to use JDP on my Fedora20 machine.
>>>>> My machine has two NICs and only one NIC is up.
>>>>>
>>>>> I passed system properties as below, however JDP broadcaster
>>>>> thread was not started:
>>>>>
>>>>>    -Dcom.sun.management.jmxremote.port=7091
>>>>>    -Dcom.sun.management.jmxremote.authenticate=false
>>>>>    -Dcom.sun.management.jmxremote.ssl=false
>>>>>    -Dcom.sun.management.jmxremote.autodiscovery=true
>>>>>    -Dcom.sun.management.jdp.name=TEST
>>>>>
>>>>> I checked exceptions with jdb, SocketException was occurred in
>>>>> JDPControllerRunner#run(), and it was caused by another NIC
>>>>> is down.
>>>>>
>>>>> Currently, DiagramChannel which is used in JDPBroadcaster
>>>>> tries to send JDP packet through all "UP" NICs.
>>>>> However, NIC which is controlled by NetworkManager seems to
>>>>> be still "UP" when ifdown command is executed.
>>>>> (It seems to be removed IP address from NIC only.)
>>>>>
>>>>>
>>>>> This problem may be Fedora, however I think it should be
>>>>> improved in JDK.
>>>>> I've created a patch as below, and it works fine in my environment.
>>>>> (jdk9/dev/jdk)
>>>>>
>>>>> If this patch may be accepted, I will file this to JBS.
>>>>>
>>>>> --------------------
>>>>> diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java
>>>>> --- a/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java    Mon Sep 01 13:33:28 2014 +0200
>>>>> +++ b/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java    Tue Sep 02 23:25:50 2014 +0900
>>>>> @@ -35,6 +35,7 @@
>>>>>   import java.nio.ByteBuffer;
>>>>>   import java.nio.channels.DatagramChannel;
>>>>>   import java.nio.channels.UnsupportedAddressTypeException;
>>>>> +import java.util.Enumeration;
>>>>>
>>>>>   /**
>>>>>    * JdpBroadcaster is responsible for sending pre-built JDP packet across a Net
>>>>> @@ -79,6 +80,15 @@
>>>>>           if (srcAddress != null) {
>>>>>               // User requests particular interface to bind to
>>>>>               NetworkInterface interf = NetworkInterface.getByInetAddress(srcAddress);
>>>>> +
>>>>> +            if (interf == null) {
>>>>> +                throw new JdpException("Unable to get network interface for " + srcAddress.toString());
>>>>> +            }
>>>>> +
>>>>> +            if (!interf.isUp() || !interf.supportsMulticast()) {
>>>>> +                throw new JdpException(interf.getName() + " does not support multicast.");
>>>>> +            }
>>>>> +
>>>>>               try {
>>>>>                   channel.bind(new InetSocketAddress(srcAddress, 0));
>>>>>               } catch (UnsupportedAddressTypeException ex) {
>>>>> @@ -86,6 +96,23 @@
>>>>>               }
>>>>>               channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, interf);
>>>>>           }
>>>>> +        else {
>>>>> +            Enumeration<NetworkInterface> nics = NetworkInterface.getNetworkInterfaces();
>>>>> +            while (nics.hasMoreElements()) {
>>>>> +                NetworkInterface nic = nics.nextElement();
>>>>> +
>>>>> +                if (nic.isUp() && nic.supportsMulticast()) {
>>>>> +                    try {
>>>>> +                        channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
>>>>> +                    } catch (IOException ex) {
>>>>> +                        System.err.println("WARNING: JDP broadcaster cannot use " + nic.getName() + ": " + ex.getMessage());
>>>>> +                    }
>>>>> +                }
>>>>> +
>>>>> +            }
>>>>> +
>>>>> +        }
>>>>> +
>>>>>       }
>>>>>
>>>>>       /**
>>>>> --------------------
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>
>>>>


From dmitry.samersoff at oracle.com  Sat Sep  6 17:53:44 2014
From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com)
Date: Sat, 6 Sep 2014 21:53:44 +0400
Subject: RFR: JDK-8057556: JDP should better handle non-active interfaces
In-Reply-To: <540B22BF.3010409@gmail.com>
References: <5405D9A7.3030405@gmail.com> <54085A78.7030205@oracle.com>
	<54088C4F.10204@gmail.com>
	<099DBC50-7324-49D1-8E10-36DE2EBB4962@oracle.com>
	<54099040.4040100@gmail.com> <540B22BF.3010409@gmail.com>
Message-ID: <b75935e0-28ab-4c52-99f8-b095e6f8d216.maildroid@localhost>

Please, file a separate issue.

--Dmitry



-----Original Message-----
From: Yasumasa Suenaga <yasuenag at gmail.com>
To: Peter Allwin <peter.allwin at oracle.com>
Cc: Dmitry Samersoff <dmitry.samersoff at oracle.com>, "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>, "serviceability-dev at openjdk.java.net" <serviceability-dev at openjdk.java.net>
Sent: Sat, 06 Sep 2014 19:37
Subject: Re: RFR: JDK-8057556: JDP should better handle non-active interfaces

Hi all,

My patch works fine in my environment, however, JMX agent will be terminated
silently when I run command as following:

java -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.authenticate=false
      -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.autodiscovery=true
      -Dcom.sun.management.jdp.source_addr=255.255.255.255 -version

Curently, sun.management.Agent#startDiscoveryService() throws AgentConfigurationError
when JdpException is occurred. However, argument of AgentConfiguratonError constructor
is incorrected. So NPE will be occurred. (I checked it with jdb.)

I think that we should fix it as following.

-----------
diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/Agent.java
--- a/src/java.management/share/classes/sun/management/Agent.java       Mon Sep 01 13:33:28 2014 +0200
+++ b/src/java.management/share/classes/sun/management/Agent.java       Sat Sep 06 23:50:58 2014 +0900
@@ -210,6 +210,8 @@
              } else {
                  throw new AgentConfigurationError(INVALID_JMXREMOTE_PORT, "No port specified");
              }
+        } catch (JdpException e) {
+            error(e);
          } catch (AgentConfigurationError err) {
              error(err.getError(), err.getParams());
          }
@@ -273,7 +275,7 @@
      }

      private static void startDiscoveryService(Properties props)
-            throws IOException {
+            throws IOException, JdpException {
          // Start discovery service if requested
          String discoveryPort = props.getProperty("com.sun.management.jdp.port");
          String discoveryAddress = props.getProperty("com.sun.management.jdp.address");
@@ -291,7 +293,7 @@
              try{
                 shouldStart = Boolean.parseBoolean(discoveryShouldStart);
              } catch (NumberFormatException e) {
-                throw new AgentConfigurationError("Couldn't parse autodiscovery argument");
+                throw new AgentConfigurationError(AGENT_EXCEPTION, "Couldn't parse autodiscovery argument");
              }
          }

@@ -302,7 +304,7 @@
                  address = (discoveryAddress == null) ?
                          InetAddress.getByName(JDP_DEFAULT_ADDRESS) : InetAddress.getByName(discoveryAddress);
              } catch (UnknownHostException e) {
-                throw new AgentConfigurationError("Unable to broadcast to requested address", e);
+                throw new AgentConfigurationError(AGENT_EXCEPTION, e, "Unable to broadcast to requested address");
              }

              int port = JDP_DEFAULT_PORT;
@@ -310,7 +312,7 @@
                 try {
                    port = Integer.parseInt(discoveryPort);
                 } catch (NumberFormatException e) {
-                 throw new AgentConfigurationError("Couldn't parse JDP port argument");
+                 throw new AgentConfigurationError(AGENT_EXCEPTION, "Couldn't parse JDP port argument");
                 }
              }

@@ -330,12 +332,7 @@

              String instanceName = props.getProperty("com.sun.management.jdp.name");

-            try{
-               JdpController.startDiscoveryService(address, port, instanceName, jmxUrlStr);
-            }
-            catch(JdpException e){
-                throw new AgentConfigurationError("Couldn't start JDP service", e);
-            }
+            JdpController.startDiscoveryService(address, port, instanceName, jmxUrlStr);
          }
      }

-----------


I want also to contribute it.
Should I merge it to JDK-8057556? Or should I file to JBS as new issue?


Thanks,

Yasumasa


(2014/09/05 19:28), Yasumasa Suenaga wrote:
> Hi Peter,
>
> I fixed it and created new webrev.
> http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.1/
>
> Could you review it again?
>
>
> Thanks,
>
> Yasumasa
>
>
> (2014/09/05 17:20), Peter Allwin wrote:
>> Looks like only the first Interface will be considered if no srcAddress is provided (succeeded will be false and we will throw to exit the while loop). Is this intended?
>>
>> Thanks!
>> /peter
>>
>>> On 4 sep 2014, at 17:59, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> Thank you so much, Dmitry!
>>>
>>> I've created webrev for it.
>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.0/
>>>
>>> Please review.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> (2014/09/04 21:26), Dmitry Samersoff wrote:
>>>> Yasumasa,
>>>>
>>>> The CR number is JDK-8057556
>>>>
>>>> I'll care about it's integration.
>>>>
>>>> -Dmitry
>>>>
>>>>> On 2014-09-02 18:52, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm trying to use JDP on my Fedora20 machine.
>>>>> My machine has two NICs and only one NIC is up.
>>>>>
>>>>> I passed system properties as below, however JDP broadcaster
>>>>> thread was not started:
>>>>>
>>>>>    -Dcom.sun.management.jmxremote.port=7091
>>>>>    -Dcom.sun.management.jmxremote.authenticate=false
>>>>>    -Dcom.sun.management.jmxremote.ssl=false
>>>>>    -Dcom.sun.management.jmxremote.autodiscovery=true
>>>>>    -Dcom.sun.management.jdp.name=TEST
>>>>>
>>>>> I checked exceptions with jdb, SocketException was occurred in
>>>>> JDPControllerRunner#run(), and it was caused by another NIC
>>>>> is down.
>>>>>
>>>>> Currently, DiagramChannel which is used in JDPBroadcaster
>>>>> tries to send JDP packet through all "UP" NICs.
>>>>> However, NIC which is controlled by NetworkManager seems to
>>>>> be still "UP" when ifdown command is executed.
>>>>> (It seems to be removed IP address from NIC only.)
>>>>>
>>>>>
>>>>> This problem may be Fedora, however I think it should be
>>>>> improved in JDK.
>>>>> I've created a patch as below, and it works fine in my environment.
>>>>> (jdk9/dev/jdk)
>>>>>
>>>>> If this patch may be accepted, I will file this to JBS.
>>>>>
>>>>> --------------------
>>>>> diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java
>>>>> --- a/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java    Mon Sep 01 13:33:28 2014 +0200
>>>>> +++ b/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java    Tue Sep 02 23:25:50 2014 +0900
>>>>> @@ -35,6 +35,7 @@
>>>>>   import java.nio.ByteBuffer;
>>>>>   import java.nio.channels.DatagramChannel;
>>>>>   import java.nio.channels.UnsupportedAddressTypeException;
>>>>> +import java.util.Enumeration;
>>>>>
>>>>>   /**
>>>>>    * JdpBroadcaster is responsible for sending pre-built JDP packet across a Net
>>>>> @@ -79,6 +80,15 @@
>>>>>           if (srcAddress != null) {
>>>>>               // User requests particular interface to bind to
>>>>>               NetworkInterface interf = NetworkInterface.getByInetAddress(srcAddress);
>>>>> +
>>>>> +            if (interf == null) {
>>>>> +                throw new JdpException("Unable to get network interface for " + srcAddress.toString());
>>>>> +            }
>>>>> +
>>>>> +            if (!interf.isUp() || !interf.supportsMulticast()) {
>>>>> +                throw new JdpException(interf.getName() + " does not support multicast.");
>>>>> +            }
>>>>> +
>>>>>               try {
>>>>>                   channel.bind(new InetSocketAddress(srcAddress, 0));
>>>>>               } catch (UnsupportedAddressTypeException ex) {
>>>>> @@ -86,6 +96,23 @@
>>>>>               }
>>>>>               channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, interf);
>>>>>           }
>>>>> +        else {
>>>>> +            Enumeration<NetworkInterface> nics = NetworkInterface.getNetworkInterfaces();
>>>>> +            while (nics.hasMoreElements()) {
>>>>> +                NetworkInterface nic = nics.nextElement();
>>>>> +
>>>>> +                if (nic.isUp() && nic.supportsMulticast()) {
>>>>> +                    try {
>>>>> +                        channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
>>>>> +                    } catch (IOException ex) {
>>>>> +                        System.err.println("WARNING: JDP broadcaster cannot use " + nic.getName() + ": " + ex.getMessage());
>>>>> +                    }
>>>>> +                }
>>>>> +
>>>>> +            }
>>>>> +
>>>>> +        }
>>>>> +
>>>>>       }
>>>>>
>>>>>       /**
>>>>> --------------------
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>
>>>>

From yasuenag at gmail.com  Sun Sep  7 13:04:57 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Sun, 07 Sep 2014 22:04:57 +0900
Subject: RFR: JDK-8057746: Cannot handle JdpException in JMX agent
	initialization.
Message-ID: <540C57F9.3080508@gmail.com>

Hi all,

This issue is related to JDK-8057556: JDP should better handle non-active interfaces
http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-September/015548.html

JMX agent will be terminated silently when I run command as following:

java -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.authenticate=false
     -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.autodiscovery=true
     -Dcom.sun.management.jdp.source_addr=255.255.255.255 -version

I expect JdpException which is caused by "com.sun.management.jdp.source_addr" .

Curently, sun.management.Agent#startDiscoveryService() throws AgentConfigurationError
when JdpException is occurred. However, argument of AgentConfiguratonError constructor
is incorrected. So NPE will be occurred. (I checked it with jdb.)

I've created webrev. Could you review it?
http://cr.openjdk.java.net/~ysuenaga/JDK-8057746/webrev.0/


I would like to contribute this patch.
Please review and sponsoring.


Thanks,

Yasumasa 



From dmitry.samersoff at oracle.com  Sun Sep  7 14:49:31 2014
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Sun, 07 Sep 2014 18:49:31 +0400
Subject: RFR: JDK-8057746: Cannot handle JdpException in JMX agent
	initialization.
In-Reply-To: <540C57F9.3080508@gmail.com>
References: <540C57F9.3080508@gmail.com>
Message-ID: <540C707B.7030808@oracle.com>

Yasumasa,

I'll sponsor the push.

-Dmitry

On 2014-09-07 17:04, Yasumasa Suenaga wrote:
> Hi all,
> 
> This issue is related to JDK-8057556: JDP should better handle non-active interfaces
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-September/015548.html
> 
> JMX agent will be terminated silently when I run command as following:
> 
> java -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.authenticate=false
>      -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.autodiscovery=true
>      -Dcom.sun.management.jdp.source_addr=255.255.255.255 -version
> 
> I expect JdpException which is caused by "com.sun.management.jdp.source_addr" .
> 
> Curently, sun.management.Agent#startDiscoveryService() throws AgentConfigurationError
> when JdpException is occurred. However, argument of AgentConfiguratonError constructor
> is incorrected. So NPE will be occurred. (I checked it with jdb.)
> 
> I've created webrev. Could you review it?
> http://cr.openjdk.java.net/~ysuenaga/JDK-8057746/webrev.0/
> 
> 
> I would like to contribute this patch.
> Please review and sponsoring.
> 
> 
> Thanks,
> 
> Yasumasa 
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the source code.


From yasuenag at gmail.com  Sun Sep  7 14:58:55 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Sun, 07 Sep 2014 23:58:55 +0900
Subject: RFR: JDK-8057746: Cannot handle JdpException in JMX agent
	initialization.
In-Reply-To: <540C707B.7030808@oracle.com>
References: <540C57F9.3080508@gmail.com> <540C707B.7030808@oracle.com>
Message-ID: <540C72AF.4040301@gmail.com>

Thank you so much, Dmitry!

Yasumasa


(2014/09/07 23:49), Dmitry Samersoff wrote:
> Yasumasa,
>
> I'll sponsor the push.
>
> -Dmitry
>
> On 2014-09-07 17:04, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> This issue is related to JDK-8057556: JDP should better handle non-active interfaces
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-September/015548.html
>>
>> JMX agent will be terminated silently when I run command as following:
>>
>> java -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.authenticate=false
>>       -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.autodiscovery=true
>>       -Dcom.sun.management.jdp.source_addr=255.255.255.255 -version
>>
>> I expect JdpException which is caused by "com.sun.management.jdp.source_addr" .
>>
>> Curently, sun.management.Agent#startDiscoveryService() throws AgentConfigurationError
>> when JdpException is occurred. However, argument of AgentConfiguratonError constructor
>> is incorrected. So NPE will be occurred. (I checked it with jdb.)
>>
>> I've created webrev. Could you review it?
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8057746/webrev.0/
>>
>>
>> I would like to contribute this patch.
>> Please review and sponsoring.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>
>


From david.holmes at oracle.com  Mon Sep  8 01:38:33 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Sep 2014 11:38:33 +1000
Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <540A152E.9020507@oracle.com>
References: <540A152E.9020507@oracle.com>
Message-ID: <540D0899.7010303@oracle.com>

Looks okay to me.

David

On 6/09/2014 5:55 AM, Coleen Phillimore wrote:
> Summary: Add classLoader to java/lang/Class instance for fast access
>
> This is a backport request for 8u40.   This change has been in the jdk9
> code for 3 months without any problems.
>
> The JDK changes hg imported cleanly.  The Hotspot change needed a hand
> merge for create_mirror call in klass.cpp.
>
> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/
> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/
>
> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>
> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. Also ran
> jck java_lang tests with only the hotspot change.  The hotspot change
> can be tested separately from the jdk change (but not the other way
> around).
>
> Thanks,
> Coleen


From aleksej.efimov at oracle.com  Mon Sep  8 09:26:09 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Mon, 08 Sep 2014 13:26:09 +0400
Subject: RFR: 8057747: Several test failing after update to tzdata2014g
Message-ID: <540D7631.2030108@oracle.com>

Hello,

There was a problem during tzdata2014g update with JSR310 
implementation. It causes reported test failure: 
jdk/test/sun/util/calendar/zi/TestZoneInfo310.java. The 
https://bugs.openjdk.java.net/browse/JDK-8051641 bug was filled for this 
failure, but the test wasn't added to the ProblemList.txt.
Please, review the addition of this test to ProblemList.txt: 
http://cr.openjdk.java.net/~aefimov/8057747/webrev.00

-Aleksej


From Alan.Bateman at oracle.com  Mon Sep  8 10:38:22 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 08 Sep 2014 11:38:22 +0100
Subject: RFR: 8057747: Several test failing after update to tzdata2014g
In-Reply-To: <540D7631.2030108@oracle.com>
References: <540D7631.2030108@oracle.com>
Message-ID: <540D871E.90905@oracle.com>

On 08/09/2014 10:26, Aleksej Efimov wrote:
> Hello,
>
> There was a problem during tzdata2014g update with JSR310 
> implementation. It causes reported test failure: 
> jdk/test/sun/util/calendar/zi/TestZoneInfo310.java. The 
> https://bugs.openjdk.java.net/browse/JDK-8051641 bug was filled for 
> this failure, but the test wasn't added to the ProblemList.txt.
> Please, review the addition of this test to ProblemList.txt: 
> http://cr.openjdk.java.net/~aefimov/8057747/webrev.00
Looks okay (although "Filed" is not needed in the comment). Hopefully 
the issue with the JSR 310 test can be tracked down quickly. If you do 
push this change then it would be useful to add a note to JDK-8051641 so 
that whoever takes it remembers to remove it from the exclude list.

-Alan


From aleksej.efimov at oracle.com  Mon Sep  8 11:07:28 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Mon, 08 Sep 2014 15:07:28 +0400
Subject: RFR: 8057747: Several test failing after update to tzdata2014g
In-Reply-To: <540D871E.90905@oracle.com>
References: <540D7631.2030108@oracle.com> <540D871E.90905@oracle.com>
Message-ID: <540D8DF0.1040604@oracle.com>

Thank you for review Alan!
Will remove the "Filed" before the push and will add a note.
-Aleksej

On 09/08/2014 02:38 PM, Alan Bateman wrote:
> On 08/09/2014 10:26, Aleksej Efimov wrote:
>> Hello,
>>
>> There was a problem during tzdata2014g update with JSR310 
>> implementation. It causes reported test failure: 
>> jdk/test/sun/util/calendar/zi/TestZoneInfo310.java. The 
>> https://bugs.openjdk.java.net/browse/JDK-8051641 bug was filled for 
>> this failure, but the test wasn't added to the ProblemList.txt.
>> Please, review the addition of this test to ProblemList.txt: 
>> http://cr.openjdk.java.net/~aefimov/8057747/webrev.00
> Looks okay (although "Filed" is not needed in the comment). Hopefully 
> the issue with the JSR 310 test can be tracked down quickly. If you do 
> push this change then it would be useful to add a note to JDK-8051641 
> so that whoever takes it remembers to remove it from the exclude list.
>
> -Alan



From Sergey.Bylokhov at oracle.com  Mon Sep  8 13:34:20 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 08 Sep 2014 17:34:20 +0400
Subject: Optimization 2.0 for composing strings - Was: Replace concat
	String to append in StringBuilder parameters
In-Reply-To: <5400E85E.9030005@CoSoCo.de>
References: <CAPc8kR3duvby+hfpAUQG5Z6rMPq-MzMv=Th7itQZHfkg_YvxDw@mail.gmail.com>	<53E7FA44.9050207@oracle.com>	<CAPc8kR1HPrLMP6qNzSr5Fe0y=eUDioh5BoVNsZ7q2mtgM_dSDQ@mail.gmail.com>	<CAM6ZMz_nz2zWZQLLaKSnv4Z4Aah5MKaNspctn4TFKrciK2yXyg@mail.gmail.com>	<476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com>	<CAPc8kR3Tet4HcxGuMywaLHZLVdkeEVNDkea5GtMjoBWD7X7yPg@mail.gmail.com>	<CAM6ZMz-U5C0mXXcebb84TYq318zSorNrdKHC+h=4JpBO=ma9VA@mail.gmail.com>	<53E8CCD6.2090503@CoSoCo.de>
	<53FDA7C1.6060303@CoSoCo.de>	<902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com>	<53FF7244.2030804@CoSoCo.de>	<C82621D2-D936-4A2F-B0AD-AB39E9EA694D@oracle.com>
	<5400E85E.9030005@CoSoCo.de>
Message-ID: <540DB05C.3010300@oracle.com>

There was related discussions on the past
http://mail.openjdk.java.net/pipermail/compiler-dev/2014-February/008491.html
And related issues:
https://bugs.openjdk.java.net/browse/JDK-4947460
https://bugs.openjdk.java.net/browse/JDK-4059189
https://bugs.openjdk.java.net/browse/JDK-6709423

On 30.08.2014 0:53, Ulf Zibis wrote:
> Hi compiler people,
>
> is there some chance that javac could be enhanced to optimize better 
> as discussed in this thread? Than refactoring of up to now better 
> readable code to ugly StringBuilder at append() code would be superfluous.
> I really like the String concatenation syntax, but unfortunately it 
> often causes slower code and bigger footprint.
> Optimally javac would optimize mixed use of StringBuilder, 
> StringJoiner, concatenation, toString(), append(String), 
> append(Collection) etc. to a single StringBuilder instance, so that 
> the resulting code, JITed or not, will have better performance.
> Additionally javac could guess a reasonable initial capacity from the 
> given source code.
>
>
> Am 29.08.2014 um 10:01 schrieb Wang Weijun:
>> So it's not that the optimization fails but there is no optimization 
>> on them yet.
>>
>> I do see the .append("x") case will be easy to deal with, but it 
>> looks like historically javac has not been a place to do many 
>> optimizations. It mostly converts the java source to byte codes in a 
>> 1-to-1 mapping and let VM do whatever it wants (to optimize). When 
>> you talked about compiling multiple concatenation into using a single 
>> StringBuilder, it's more like choosing the correct implementation 
>> rather than an optimization.
>>
>> I don't expect to see big change on this in the near future, so shall 
>> we go on with the current enhancement?
>>
>> Thanks
>> Max
>>
>> On Aug 29, 2014, at 2:17, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>
>>> I mean:
>>> It does not output byte code that only uses a single char array to 
>>> compose the entire String in question.
>>> With "optimization fails", I also mean, there is used an additional 
>>> "StringComposer" e.g. another StringBuilder or a StringJoiner in 
>>> addition to the 1st StringBuilder.
>>>
>>> -Ulf
>>>
>>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>>>> Could you please explain what you mean by "javac optimization 
>>>> fails" here?
>>>>
>>>> -Pavel
>>>>
>>>> On 27 Aug 2014, at 10:41, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>
>>>>> 4.) Now we see, that javac optimization fails again if 
>>>>> StringBuilder, concatenation, toString(), append(String), 
>>>>> append(Collection) etc. and StringJoiner use is mixed.
>>
>


-- 
Best regards, Sergey.



From coleen.phillimore at oracle.com  Mon Sep  8 13:40:49 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 08 Sep 2014 09:40:49 -0400
Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <540D0899.7010303@oracle.com>
References: <540A152E.9020507@oracle.com> <540D0899.7010303@oracle.com>
Message-ID: <540DB1E1.7060900@oracle.com>


Thanks David!
Coleen

On 9/7/14, 9:38 PM, David Holmes wrote:
> Looks okay to me.
>
> David
>
> On 6/09/2014 5:55 AM, Coleen Phillimore wrote:
>> Summary: Add classLoader to java/lang/Class instance for fast access
>>
>> This is a backport request for 8u40.   This change has been in the jdk9
>> code for 3 months without any problems.
>>
>> The JDK changes hg imported cleanly.  The Hotspot change needed a hand
>> merge for create_mirror call in klass.cpp.
>>
>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/
>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/
>>
>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>
>> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. Also ran
>> jck java_lang tests with only the hotspot change.  The hotspot change
>> can be tested separately from the jdk change (but not the other way
>> around).
>>
>> Thanks,
>> Coleen



From yasuenag at gmail.com  Mon Sep  8 15:40:08 2014
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 09 Sep 2014 00:40:08 +0900
Subject: RFR: JDK-8057556: JDP should better handle non-active interfaces
In-Reply-To: <54099040.4040100@gmail.com>
References: <5405D9A7.3030405@gmail.com> <54085A78.7030205@oracle.com>
	<54088C4F.10204@gmail.com>
	<099DBC50-7324-49D1-8E10-36DE2EBB4962@oracle.com>
	<54099040.4040100@gmail.com>
Message-ID: <540DCDD8.8080600@gmail.com>

Hi Jaroslav,

I could not receive your email.
So I reply from another email.

> L103 Please, move "else" to the previous line

I will fix it.

> L96-100 Do we still need these lines? Isn't
> `channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, interf);`
> enough to listen on the interface?

I think we should remove bind() call.
If we run multiple VM with same com.sun.management.jdp.source_addr value
and on same OS, we may encounter BindException in current implementation
as following:

----------
Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: 7091; nested exception is:
         java.net.BindException: Address already in use
----------

If it should be treated as another issue, I will file it to JBS and
create a new patch.

I will upload new webrev for JDK-8057556 after this discussion.


Thanks,

Yasumasa


(2014/09/05 19:28), Yasumasa Suenaga wrote:
> Hi Peter,
>
> I fixed it and created new webrev.
> http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.1/
>
> Could you review it again?
>
>
> Thanks,
>
> Yasumasa
>
>
> (2014/09/05 17:20), Peter Allwin wrote:
>> Looks like only the first Interface will be considered if no srcAddress is provided (succeeded will be false and we will throw to exit the while loop). Is this intended?
>>
>> Thanks!
>> /peter
>>
>>> On 4 sep 2014, at 17:59, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> Thank you so much, Dmitry!
>>>
>>> I've created webrev for it.
>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8057556/webrev.0/
>>>
>>> Please review.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> (2014/09/04 21:26), Dmitry Samersoff wrote:
>>>> Yasumasa,
>>>>
>>>> The CR number is JDK-8057556
>>>>
>>>> I'll care about it's integration.
>>>>
>>>> -Dmitry
>>>>
>>>>> On 2014-09-02 18:52, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>> I'm trying to use JDP on my Fedora20 machine.
>>>>> My machine has two NICs and only one NIC is up.
>>>>>
>>>>> I passed system properties as below, however JDP broadcaster
>>>>> thread was not started:
>>>>>
>>>>>    -Dcom.sun.management.jmxremote.port=7091
>>>>>    -Dcom.sun.management.jmxremote.authenticate=false
>>>>>    -Dcom.sun.management.jmxremote.ssl=false
>>>>>    -Dcom.sun.management.jmxremote.autodiscovery=true
>>>>>    -Dcom.sun.management.jdp.name=TEST
>>>>>
>>>>> I checked exceptions with jdb, SocketException was occurred in
>>>>> JDPControllerRunner#run(), and it was caused by another NIC
>>>>> is down.
>>>>>
>>>>> Currently, DiagramChannel which is used in JDPBroadcaster
>>>>> tries to send JDP packet through all "UP" NICs.
>>>>> However, NIC which is controlled by NetworkManager seems to
>>>>> be still "UP" when ifdown command is executed.
>>>>> (It seems to be removed IP address from NIC only.)
>>>>>
>>>>>
>>>>> This problem may be Fedora, however I think it should be
>>>>> improved in JDK.
>>>>> I've created a patch as below, and it works fine in my environment.
>>>>> (jdk9/dev/jdk)
>>>>>
>>>>> If this patch may be accepted, I will file this to JBS.
>>>>>
>>>>> --------------------
>>>>> diff -r 68a6bb51cb26 src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java
>>>>> --- a/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java    Mon Sep 01 13:33:28 2014 +0200
>>>>> +++ b/src/java.management/share/classes/sun/management/jdp/JdpBroadcaster.java    Tue Sep 02 23:25:50 2014 +0900
>>>>> @@ -35,6 +35,7 @@
>>>>>   import java.nio.ByteBuffer;
>>>>>   import java.nio.channels.DatagramChannel;
>>>>>   import java.nio.channels.UnsupportedAddressTypeException;
>>>>> +import java.util.Enumeration;
>>>>>
>>>>>   /**
>>>>>    * JdpBroadcaster is responsible for sending pre-built JDP packet across a Net
>>>>> @@ -79,6 +80,15 @@
>>>>>           if (srcAddress != null) {
>>>>>               // User requests particular interface to bind to
>>>>>               NetworkInterface interf = NetworkInterface.getByInetAddress(srcAddress);
>>>>> +
>>>>> +            if (interf == null) {
>>>>> +                throw new JdpException("Unable to get network interface for " + srcAddress.toString());
>>>>> +            }
>>>>> +
>>>>> +            if (!interf.isUp() || !interf.supportsMulticast()) {
>>>>> +                throw new JdpException(interf.getName() + " does not support multicast.");
>>>>> +            }
>>>>> +
>>>>>               try {
>>>>>                   channel.bind(new InetSocketAddress(srcAddress, 0));
>>>>>               } catch (UnsupportedAddressTypeException ex) {
>>>>> @@ -86,6 +96,23 @@
>>>>>               }
>>>>>               channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, interf);
>>>>>           }
>>>>> +        else {
>>>>> +            Enumeration<NetworkInterface> nics = NetworkInterface.getNetworkInterfaces();
>>>>> +            while (nics.hasMoreElements()) {
>>>>> +                NetworkInterface nic = nics.nextElement();
>>>>> +
>>>>> +                if (nic.isUp() && nic.supportsMulticast()) {
>>>>> +                    try {
>>>>> +                        channel.setOption(StandardSocketOptions.IP_MULTICAST_IF, nic);
>>>>> +                    } catch (IOException ex) {
>>>>> +                        System.err.println("WARNING: JDP broadcaster cannot use " + nic.getName() + ": " + ex.getMessage());
>>>>> +                    }
>>>>> +                }
>>>>> +
>>>>> +            }
>>>>> +
>>>>> +        }
>>>>> +
>>>>>       }
>>>>>
>>>>>       /**
>>>>> --------------------
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>
>>>>


From joe.darcy at oracle.com  Mon Sep  8 16:57:42 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 08 Sep 2014 09:57:42 -0700
Subject: RFR: JDK-8054987: (reflect) Add sharing of annotations between
	instances of Executable
In-Reply-To: <20140818082307.GA6217@oracle.com>
References: <20140813122306.GE22209@oracle.com> <53EC0B3E.3020904@oracle.com>
	<20140814064708.GA4360@oracle.com> <53ECE9B9.4070000@gmail.com>
	<20140818082307.GA6217@oracle.com>
Message-ID: <540DE006.4070002@oracle.com>

Looks good Joel; sorry for the delayed review.

Thanks,

-Joe

On 8/18/2014 1:23 AM, Joel Borggren-Franck wrote:
> Hi Peter, Joe,
>
> On 2014-08-14, Peter Levart wrote:
>> On 08/14/2014 08:47 AM, Joel Borggren-Franck wrote:
>>> On 2014-08-13, Joe Darcy wrote:
>>>> Hi Joel,
>>>>
>>>> Does your changeset alter the support (or non-support) of redefining
>>>> an annotation?
>>>>
>>> Hi Joe,
>>>
>>> It does not interact with the current non-support and I am convinced it
>>> wont hinder us in improving the situation.
>>>
>>> cheers
>>> /Joel
>> Hi Joel,
>>
>> Good to see this patch. It improves the efficiency of annotations
>> caching on methods/constructors. What about fields? They too are
>> AccessibleObject(s), contain annotations and are copied from root
>> instances when handed over to the user...
>>
>> The difference of behaviour in the presence of class redefinition
>> could be observed though, but I think this is not a problem. For
>> example:
> Thanks for taking a look at this. You are right about Fields, I added
> caching for Fields too:
>
> http://cr.openjdk.java.net/~jfranck/8054987/webrev.01/
>
> I don't want to rewrite the synchronization in this patch, I'll file a
> followup RFE for the synchronization and a REF/bug for the publication.
>
> cheers
> /Joel



From xueming.shen at oracle.com  Mon Sep  8 17:34:07 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 08 Sep 2014 10:34:07 -0700
Subject: RFR : 8044725 :Bug in zlib 1.2.5 prevents inflation of some
	gzipped files (zlib 1.2.8 port)
In-Reply-To: <5406E7F6.4010904@oracle.com>
References: <5406E7F6.4010904@oracle.com>
Message-ID: <540DE88F.5070606@oracle.com>

On 09/03/2014 03:05 AM, Se?n Coffey wrote:
> I'd like to port the zlib v1.2.8 libraries to JDK 7u. Currently, 7u uses zlib v1.2.3 libraries. 8u20 was recently upgraded to 1.2.8. zlib fixes since 1.2.3 can be found at http://cr.openjdk.java.net/~coffeys/webrev.8044725.7u/webrev/raw_files/new/src/share/native/java/util/zip/zlib-1.2.8/ChangeLog
>
> While porting, I noticed that the Program.gmk had a bad reference in it to zlib 1.1.3 (JDK6  version) - I've corrected that to 1.2.8 for now but question if the extra INCLUDE directive is even needed.
>
> bug report : https://bugs.openjdk.java.net/browse/JDK-8044725
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8044725.7u/webrev/
>
> regards,
> Sean.
>
>
looks fine.

I'm not sure about the program.gmk...in the past the other two places that need the zlib
src reference are the launcher and the splash code.

-sherman


From jonathan.gibbons at oracle.com  Mon Sep  8 17:30:31 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 08 Sep 2014 10:30:31 -0700
Subject: Optimization 2.0 for composing strings - Was: Replace concat
	String to append in StringBuilder parameters
In-Reply-To: <5400E85E.9030005@CoSoCo.de>
References: <CAPc8kR3duvby+hfpAUQG5Z6rMPq-MzMv=Th7itQZHfkg_YvxDw@mail.gmail.com>	<53E7FA44.9050207@oracle.com>	<CAPc8kR1HPrLMP6qNzSr5Fe0y=eUDioh5BoVNsZ7q2mtgM_dSDQ@mail.gmail.com>	<CAM6ZMz_nz2zWZQLLaKSnv4Z4Aah5MKaNspctn4TFKrciK2yXyg@mail.gmail.com>	<476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com>	<CAPc8kR3Tet4HcxGuMywaLHZLVdkeEVNDkea5GtMjoBWD7X7yPg@mail.gmail.com>	<CAM6ZMz-U5C0mXXcebb84TYq318zSorNrdKHC+h=4JpBO=ma9VA@mail.gmail.com>	<53E8CCD6.2090503@CoSoCo.de>
	<53FDA7C1.6060303@CoSoCo.de>	<902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com>	<53FF7244.2030804@CoSoCo.de>	<C82621D2-D936-4A2F-B0AD-AB39E9EA694D@oracle.com>
	<5400E85E.9030005@CoSoCo.de>
Message-ID: <540DE7B7.9070107@oracle.com>

It would be inappropriate/incorrect to apply the optimization as described.

The JLS requires that the argument to a method call should be computed 
before invoking the method.

Consider the case when one of the expressions in the series of string 
concatenations throws an exception. It would be incorrect to have 
already partially modified the string buffer.

-- Jon

On 08/29/2014 01:53 PM, Ulf Zibis wrote:
> Hi compiler people,
>
> is there some chance that javac could be enhanced to optimize better 
> as discussed in this thread? Than refactoring of up to now better 
> readable code to ugly StringBuilder at append() code would be superfluous.
> I really like the String concatenation syntax, but unfortunately it 
> often causes slower code and bigger footprint.
> Optimally javac would optimize mixed use of StringBuilder, 
> StringJoiner, concatenation, toString(), append(String), 
> append(Collection) etc. to a single StringBuilder instance, so that 
> the resulting code, JITed or not, will have better performance.
> Additionally javac could guess a reasonable initial capacity from the 
> given source code.
>
>
> Am 29.08.2014 um 10:01 schrieb Wang Weijun:
>> So it's not that the optimization fails but there is no optimization 
>> on them yet.
>>
>> I do see the .append("x") case will be easy to deal with, but it 
>> looks like historically javac has not been a place to do many 
>> optimizations. It mostly converts the java source to byte codes in a 
>> 1-to-1 mapping and let VM do whatever it wants (to optimize). When 
>> you talked about compiling multiple concatenation into using a single 
>> StringBuilder, it's more like choosing the correct implementation 
>> rather than an optimization.
>>
>> I don't expect to see big change on this in the near future, so shall 
>> we go on with the current enhancement?
>>
>> Thanks
>> Max
>>
>> On Aug 29, 2014, at 2:17, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>
>>> I mean:
>>> It does not output byte code that only uses a single char array to 
>>> compose the entire String in question.
>>> With "optimization fails", I also mean, there is used an additional 
>>> "StringComposer" e.g. another StringBuilder or a StringJoiner in 
>>> addition to the 1st StringBuilder.
>>>
>>> -Ulf
>>>
>>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>>>> Could you please explain what you mean by "javac optimization 
>>>> fails" here?
>>>>
>>>> -Pavel
>>>>
>>>> On 27 Aug 2014, at 10:41, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>
>>>>> 4.) Now we see, that javac optimization fails again if 
>>>>> StringBuilder, concatenation, toString(), append(String), 
>>>>> append(Collection) etc. and StringJoiner use is mixed.
>>
>



From lance.andersen at oracle.com  Mon Sep  8 17:31:43 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 8 Sep 2014 13:31:43 -0400
Subject: RFR: 8057826 minor clean-up to the java.sql Date/Time/Timestamp tests
Message-ID: <19576455-CB80-4BBA-BA09-ADF9C14AB731@oracle.com>

Hi,

Looking for a reviewer for this minor clean-up to the java.sql Date/Time/Timestamp tests which adds support for DataProvider

Webrev can be found here: http://cr.openjdk.java.net/~lancea/8057826/webrev.00/

Best
Lance


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From guy.steele at oracle.com  Mon Sep  8 17:41:55 2014
From: guy.steele at oracle.com (Guy Steele)
Date: Mon, 8 Sep 2014 13:41:55 -0400
Subject: Optimization 2.0 for composing strings - Was: Replace concat
	String to append in StringBuilder parameters
In-Reply-To: <540DE7B7.9070107@oracle.com>
References: <CAPc8kR3duvby+hfpAUQG5Z6rMPq-MzMv=Th7itQZHfkg_YvxDw@mail.gmail.com>	<53E7FA44.9050207@oracle.com>	<CAPc8kR1HPrLMP6qNzSr5Fe0y=eUDioh5BoVNsZ7q2mtgM_dSDQ@mail.gmail.com>	<CAM6ZMz_nz2zWZQLLaKSnv4Z4Aah5MKaNspctn4TFKrciK2yXyg@mail.gmail.com>	<476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com>	<CAPc8kR3Tet4HcxGuMywaLHZLVdkeEVNDkea5GtMjoBWD7X7yPg@mail.gmail.com>	<CAM6ZMz-U5C0mXXcebb84TYq318zSorNrdKHC+h=4JpBO=ma9VA@mail.gmail.com>	<53E8CCD6.2090503@CoSoCo.de>
	<53FDA7C1.6060303@CoSoCo.de>	<902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com>	<53FF7244.2030804@CoSoCo.de>	<C82621D2-D936-4A2F-B0AD-AB39E9EA694D@oracle.com>
	<5400E85E.9030005@CoSoCo.de> <540DE7B7.9070107@oracle.com>
Message-ID: <61C40823-1A23-4A0C-BAFD-D1E5B949F98E@oracle.com>

Good point, but counterpoint: it might be acceptable to have modified the string buffer in situations where throwing an exception would always cause the string buffer to become inaccessible.

?Guy

On Sep 8, 2014, at 1:30 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:

> It would be inappropriate/incorrect to apply the optimization as described.
> 
> The JLS requires that the argument to a method call should be computed before invoking the method.
> 
> Consider the case when one of the expressions in the series of string concatenations throws an exception. It would be incorrect to have already partially modified the string buffer.
> 
> -- Jon
> 
> On 08/29/2014 01:53 PM, Ulf Zibis wrote:
>> Hi compiler people,
>> 
>> is there some chance that javac could be enhanced to optimize better as discussed in this thread? Than refactoring of up to now better readable code to ugly StringBuilder at append() code would be superfluous.
>> I really like the String concatenation syntax, but unfortunately it often causes slower code and bigger footprint.
>> Optimally javac would optimize mixed use of StringBuilder, StringJoiner, concatenation, toString(), append(String), append(Collection) etc. to a single StringBuilder instance, so that the resulting code, JITed or not, will have better performance.
>> Additionally javac could guess a reasonable initial capacity from the given source code.
>> 
>> 
>> Am 29.08.2014 um 10:01 schrieb Wang Weijun:
>>> So it's not that the optimization fails but there is no optimization on them yet.
>>> 
>>> I do see the .append("x") case will be easy to deal with, but it looks like historically javac has not been a place to do many optimizations. It mostly converts the java source to byte codes in a 1-to-1 mapping and let VM do whatever it wants (to optimize). When you talked about compiling multiple concatenation into using a single StringBuilder, it's more like choosing the correct implementation rather than an optimization.
>>> 
>>> I don't expect to see big change on this in the near future, so shall we go on with the current enhancement?
>>> 
>>> Thanks
>>> Max
>>> 
>>> On Aug 29, 2014, at 2:17, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>> 
>>>> I mean:
>>>> It does not output byte code that only uses a single char array to compose the entire String in question.
>>>> With "optimization fails", I also mean, there is used an additional "StringComposer" e.g. another StringBuilder or a StringJoiner in addition to the 1st StringBuilder.
>>>> 
>>>> -Ulf
>>>> 
>>>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>>>>> Could you please explain what you mean by "javac optimization fails" here?
>>>>> 
>>>>> -Pavel
>>>>> 
>>>>> On 27 Aug 2014, at 10:41, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>> 
>>>>>> 4.) Now we see, that javac optimization fails again if StringBuilder, concatenation, toString(), append(String), append(Collection) etc. and StringJoiner use is mixed.
>>> 
>> 
> 



From jonathan.gibbons at oracle.com  Mon Sep  8 17:50:33 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 08 Sep 2014 10:50:33 -0700
Subject: Optimization 2.0 for composing strings - Was: Replace concat
	String to append in StringBuilder parameters
In-Reply-To: <61C40823-1A23-4A0C-BAFD-D1E5B949F98E@oracle.com>
References: <CAPc8kR3duvby+hfpAUQG5Z6rMPq-MzMv=Th7itQZHfkg_YvxDw@mail.gmail.com>	<53E7FA44.9050207@oracle.com>	<CAPc8kR1HPrLMP6qNzSr5Fe0y=eUDioh5BoVNsZ7q2mtgM_dSDQ@mail.gmail.com>	<CAM6ZMz_nz2zWZQLLaKSnv4Z4Aah5MKaNspctn4TFKrciK2yXyg@mail.gmail.com>	<476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com>	<CAPc8kR3Tet4HcxGuMywaLHZLVdkeEVNDkea5GtMjoBWD7X7yPg@mail.gmail.com>	<CAM6ZMz-U5C0mXXcebb84TYq318zSorNrdKHC+h=4JpBO=ma9VA@mail.gmail.com>	<53E8CCD6.2090503@CoSoCo.de>
	<53FDA7C1.6060303@CoSoCo.de>	<902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com>	<53FF7244.2030804@CoSoCo.de>	<C82621D2-D936-4A2F-B0AD-AB39E9EA694D@oracle.com>
	<5400E85E.9030005@CoSoCo.de> <540DE7B7.9070107@oracle.com>
	<61C40823-1A23-4A0C-BAFD-D1E5B949F98E@oracle.com>
Message-ID: <540DEC69.8080600@oracle.com>

Yes, but is this really a big enough performance and footprint pain 
point to be worth addressing in javac itself?

We're now talking about some specific code construction like
     new StringBuilder().append(a + b + c)

Any other case where the string builder can be observed externally 
cannot be subject to the proposed optimization. The use case is now 
really getting pretty specific.

-- Jon

On 09/08/2014 10:41 AM, Guy Steele wrote:
> Good point, but counterpoint: it might be acceptable to have modified the string buffer in situations where throwing an exception would always cause the string buffer to become inaccessible.
>
> ?Guy
>
> On Sep 8, 2014, at 1:30 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>
>> It would be inappropriate/incorrect to apply the optimization as described.
>>
>> The JLS requires that the argument to a method call should be computed before invoking the method.
>>
>> Consider the case when one of the expressions in the series of string concatenations throws an exception. It would be incorrect to have already partially modified the string buffer.
>>
>> -- Jon
>>
>> On 08/29/2014 01:53 PM, Ulf Zibis wrote:
>>> Hi compiler people,
>>>
>>> is there some chance that javac could be enhanced to optimize better as discussed in this thread? Than refactoring of up to now better readable code to ugly StringBuilder at append() code would be superfluous.
>>> I really like the String concatenation syntax, but unfortunately it often causes slower code and bigger footprint.
>>> Optimally javac would optimize mixed use of StringBuilder, StringJoiner, concatenation, toString(), append(String), append(Collection) etc. to a single StringBuilder instance, so that the resulting code, JITed or not, will have better performance.
>>> Additionally javac could guess a reasonable initial capacity from the given source code.
>>>
>>>
>>> Am 29.08.2014 um 10:01 schrieb Wang Weijun:
>>>> So it's not that the optimization fails but there is no optimization on them yet.
>>>>
>>>> I do see the .append("x") case will be easy to deal with, but it looks like historically javac has not been a place to do many optimizations. It mostly converts the java source to byte codes in a 1-to-1 mapping and let VM do whatever it wants (to optimize). When you talked about compiling multiple concatenation into using a single StringBuilder, it's more like choosing the correct implementation rather than an optimization.
>>>>
>>>> I don't expect to see big change on this in the near future, so shall we go on with the current enhancement?
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>> On Aug 29, 2014, at 2:17, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>
>>>>> I mean:
>>>>> It does not output byte code that only uses a single char array to compose the entire String in question.
>>>>> With "optimization fails", I also mean, there is used an additional "StringComposer" e.g. another StringBuilder or a StringJoiner in addition to the 1st StringBuilder.
>>>>>
>>>>> -Ulf
>>>>>
>>>>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>>>>>> Could you please explain what you mean by "javac optimization fails" here?
>>>>>>
>>>>>> -Pavel
>>>>>>
>>>>>> On 27 Aug 2014, at 10:41, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>>
>>>>>>> 4.) Now we see, that javac optimization fails again if StringBuilder, concatenation, toString(), append(String), append(Collection) etc. and StringJoiner use is mixed.



From guy.steele at oracle.com  Mon Sep  8 18:10:22 2014
From: guy.steele at oracle.com (Guy Steele)
Date: Mon, 8 Sep 2014 14:10:22 -0400
Subject: Optimization 2.0 for composing strings - Was: Replace concat
	String to append in StringBuilder parameters
In-Reply-To: <540DEC69.8080600@oracle.com>
References: <CAPc8kR3duvby+hfpAUQG5Z6rMPq-MzMv=Th7itQZHfkg_YvxDw@mail.gmail.com>	<53E7FA44.9050207@oracle.com>	<CAPc8kR1HPrLMP6qNzSr5Fe0y=eUDioh5BoVNsZ7q2mtgM_dSDQ@mail.gmail.com>	<CAM6ZMz_nz2zWZQLLaKSnv4Z4Aah5MKaNspctn4TFKrciK2yXyg@mail.gmail.com>	<476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com>	<CAPc8kR3Tet4HcxGuMywaLHZLVdkeEVNDkea5GtMjoBWD7X7yPg@mail.gmail.com>	<CAM6ZMz-U5C0mXXcebb84TYq318zSorNrdKHC+h=4JpBO=ma9VA@mail.gmail.com>	<53E8CCD6.2090503@CoSoCo.de>
	<53FDA7C1.6060303@CoSoCo.de>	<902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com>	<53FF7244.2030804@CoSoCo.de>	<C82621D2-D936-4A2F-B0AD-AB39E9EA694D@oracle.com>
	<5400E85E.9030005@CoSoCo.de> <540DE7B7.9070107@oracle.com>
	<61C40823-1A23-4A0C-BAFD-D1E5B949F98E@oracle.com>
	<540DEC69.8080600@oracle.com>
Message-ID: <E5BF25A9-010A-4546-940A-8D39F27B8035@oracle.com>

I have no idea.  I was just sticking in my two cents? worth on what is possible.  What is desirable and worthwhile is a much bigger question.

On Sep 8, 2014, at 1:50 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:

> Yes, but is this really a big enough performance and footprint pain point to be worth addressing in javac itself?
> 
> We're now talking about some specific code construction like
>    new StringBuilder().append(a + b + c)
> 
> Any other case where the string builder can be observed externally cannot be subject to the proposed optimization. The use case is now really getting pretty specific.
> 
> -- Jon
> 
> On 09/08/2014 10:41 AM, Guy Steele wrote:
>> Good point, but counterpoint: it might be acceptable to have modified the string buffer in situations where throwing an exception would always cause the string buffer to become inaccessible.
>> 
>> ?Guy
>> 
>> On Sep 8, 2014, at 1:30 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>> 
>>> It would be inappropriate/incorrect to apply the optimization as described.
>>> 
>>> The JLS requires that the argument to a method call should be computed before invoking the method.
>>> 
>>> Consider the case when one of the expressions in the series of string concatenations throws an exception. It would be incorrect to have already partially modified the string buffer.
>>> 
>>> -- Jon
>>> 
>>> On 08/29/2014 01:53 PM, Ulf Zibis wrote:
>>>> Hi compiler people,
>>>> 
>>>> is there some chance that javac could be enhanced to optimize better as discussed in this thread? Than refactoring of up to now better readable code to ugly StringBuilder at append() code would be superfluous.
>>>> I really like the String concatenation syntax, but unfortunately it often causes slower code and bigger footprint.
>>>> Optimally javac would optimize mixed use of StringBuilder, StringJoiner, concatenation, toString(), append(String), append(Collection) etc. to a single StringBuilder instance, so that the resulting code, JITed or not, will have better performance.
>>>> Additionally javac could guess a reasonable initial capacity from the given source code.
>>>> 
>>>> 
>>>> Am 29.08.2014 um 10:01 schrieb Wang Weijun:
>>>>> So it's not that the optimization fails but there is no optimization on them yet.
>>>>> 
>>>>> I do see the .append("x") case will be easy to deal with, but it looks like historically javac has not been a place to do many optimizations. It mostly converts the java source to byte codes in a 1-to-1 mapping and let VM do whatever it wants (to optimize). When you talked about compiling multiple concatenation into using a single StringBuilder, it's more like choosing the correct implementation rather than an optimization.
>>>>> 
>>>>> I don't expect to see big change on this in the near future, so shall we go on with the current enhancement?
>>>>> 
>>>>> Thanks
>>>>> Max
>>>>> 
>>>>> On Aug 29, 2014, at 2:17, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>> 
>>>>>> I mean:
>>>>>> It does not output byte code that only uses a single char array to compose the entire String in question.
>>>>>> With "optimization fails", I also mean, there is used an additional "StringComposer" e.g. another StringBuilder or a StringJoiner in addition to the 1st StringBuilder.
>>>>>> 
>>>>>> -Ulf
>>>>>> 
>>>>>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>>>>>>> Could you please explain what you mean by "javac optimization fails" here?
>>>>>>> 
>>>>>>> -Pavel
>>>>>>> 
>>>>>>> On 27 Aug 2014, at 10:41, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>>> 
>>>>>>>> 4.) Now we see, that javac optimization fails again if StringBuilder, concatenation, toString(), append(String), append(Collection) etc. and StringJoiner use is mixed.
> 



From ivan.gerasimov at oracle.com  Mon Sep  8 18:32:30 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 08 Sep 2014 22:32:30 +0400
Subject: RFR [8046339] sun.rmi.transport.DGCAckHandler leaks memory
In-Reply-To: <53E8C819.10705@oracle.com>
References: <53E8C819.10705@oracle.com>
Message-ID: <540DF63E.7070201@oracle.com>

This is a friendly reminder.

Would anyone please be able to review this fix in RMI area?
We have a few reports about this issue sometimes occurring, though no 
reliable reproducer.
If someone comes up with the reproducer, the regtest can be added later.

Sincerely yours,
Ivan

On 11.08.2014 17:41, Ivan Gerasimov wrote:
> Hello everyone!
>
> It has been reported that under some conditions instances of 
> sun.rmi.transport.DGCAckHandler accumulate and can cause OOM Error.
> This is because they are stored in the global DGCAckHandler.idTable 
> map, and may fail to be removed if a timeout has expired.
>
> The webrev contains a fix proposed by Darryl Mocek back in 2011.
>
> Unfortunately I couldn't come up with a regression test for the fix.
> However, the fix looks obviously correct, especially taking into 
> account the comment to the constructor:
>
>      * References added to this DGCAckHandler will be held strongly
>      * until its "release" method is invoked or (after the
>      * "startTimer" method has been invoked) the timeout has expired.
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8046339
> WEBREV: http://cr.openjdk.java.net/~igerasim/8046339/0/webrev/
>
> Sincerely yours,
> Ivan
>
>
>



From Sergey.Bylokhov at oracle.com  Mon Sep  8 18:39:44 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 08 Sep 2014 22:39:44 +0400
Subject: Optimization 2.0 for composing strings - Was: Replace concat
	String to append in StringBuilder parameters
In-Reply-To: <540DEC69.8080600@oracle.com>
References: <CAPc8kR3duvby+hfpAUQG5Z6rMPq-MzMv=Th7itQZHfkg_YvxDw@mail.gmail.com>	<53E7FA44.9050207@oracle.com>	<CAPc8kR1HPrLMP6qNzSr5Fe0y=eUDioh5BoVNsZ7q2mtgM_dSDQ@mail.gmail.com>	<CAM6ZMz_nz2zWZQLLaKSnv4Z4Aah5MKaNspctn4TFKrciK2yXyg@mail.gmail.com>	<476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com>	<CAPc8kR3Tet4HcxGuMywaLHZLVdkeEVNDkea5GtMjoBWD7X7yPg@mail.gmail.com>	<CAM6ZMz-U5C0mXXcebb84TYq318zSorNrdKHC+h=4JpBO=ma9VA@mail.gmail.com>	<53E8CCD6.2090503@CoSoCo.de>	<53FDA7C1.6060303@CoSoCo.de>	<902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com>	<53FF7244.2030804@CoSoCo.de>	<C82621D2-D936-4A2F-B0AD-AB39E9EA694D@oracle.com>	<5400E85E.9030005@CoSoCo.de>
	<540DE7B7.9070107@oracle.com>	<61C40823-1A23-4A0C-BAFD-D1E5B949F98E@oracle.com>
	<540DEC69.8080600@oracle.com>
Message-ID: <540DF7F0.4090604@oracle.com>

On 08.09.2014 21:50, Jonathan Gibbons wrote:
> Yes, but is this really a big enough performance and footprint pain 
> point to be worth addressing in javac itself?
>
> We're now talking about some specific code construction like
>     new StringBuilder().append(a + b + c)
>
> Any other case where the string builder can be observed externally 
> cannot be subject to the proposed optimization. The use case is now 
> really getting pretty specific.
Not so specific at least in jdk code:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028142.html
>
> -- Jon
>
> On 09/08/2014 10:41 AM, Guy Steele wrote:
>> Good point, but counterpoint: it might be acceptable to have modified 
>> the string buffer in situations where throwing an exception would 
>> always cause the string buffer to become inaccessible.
>>
>> ?Guy
>>
>> On Sep 8, 2014, at 1:30 PM, Jonathan Gibbons 
>> <jonathan.gibbons at oracle.com> wrote:
>>
>>> It would be inappropriate/incorrect to apply the optimization as 
>>> described.
>>>
>>> The JLS requires that the argument to a method call should be 
>>> computed before invoking the method.
>>>
>>> Consider the case when one of the expressions in the series of 
>>> string concatenations throws an exception. It would be incorrect to 
>>> have already partially modified the string buffer.
>>>
>>> -- Jon
>>>
>>> On 08/29/2014 01:53 PM, Ulf Zibis wrote:
>>>> Hi compiler people,
>>>>
>>>> is there some chance that javac could be enhanced to optimize 
>>>> better as discussed in this thread? Than refactoring of up to now 
>>>> better readable code to ugly StringBuilder at append() code would be 
>>>> superfluous.
>>>> I really like the String concatenation syntax, but unfortunately it 
>>>> often causes slower code and bigger footprint.
>>>> Optimally javac would optimize mixed use of StringBuilder, 
>>>> StringJoiner, concatenation, toString(), append(String), 
>>>> append(Collection) etc. to a single StringBuilder instance, so that 
>>>> the resulting code, JITed or not, will have better performance.
>>>> Additionally javac could guess a reasonable initial capacity from 
>>>> the given source code.
>>>>
>>>>
>>>> Am 29.08.2014 um 10:01 schrieb Wang Weijun:
>>>>> So it's not that the optimization fails but there is no 
>>>>> optimization on them yet.
>>>>>
>>>>> I do see the .append("x") case will be easy to deal with, but it 
>>>>> looks like historically javac has not been a place to do many 
>>>>> optimizations. It mostly converts the java source to byte codes in 
>>>>> a 1-to-1 mapping and let VM do whatever it wants (to optimize). 
>>>>> When you talked about compiling multiple concatenation into using 
>>>>> a single StringBuilder, it's more like choosing the correct 
>>>>> implementation rather than an optimization.
>>>>>
>>>>> I don't expect to see big change on this in the near future, so 
>>>>> shall we go on with the current enhancement?
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>> On Aug 29, 2014, at 2:17, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>
>>>>>> I mean:
>>>>>> It does not output byte code that only uses a single char array 
>>>>>> to compose the entire String in question.
>>>>>> With "optimization fails", I also mean, there is used an 
>>>>>> additional "StringComposer" e.g. another StringBuilder or a 
>>>>>> StringJoiner in addition to the 1st StringBuilder.
>>>>>>
>>>>>> -Ulf
>>>>>>
>>>>>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>>>>>>> Could you please explain what you mean by "javac optimization 
>>>>>>> fails" here?
>>>>>>>
>>>>>>> -Pavel
>>>>>>>
>>>>>>> On 27 Aug 2014, at 10:41, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>>>
>>>>>>>> 4.) Now we see, that javac optimization fails again if 
>>>>>>>> StringBuilder, concatenation, toString(), append(String), 
>>>>>>>> append(Collection) etc. and StringJoiner use is mixed.
>


-- 
Best regards, Sergey.



From jonathan.gibbons at oracle.com  Mon Sep  8 18:53:27 2014
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 08 Sep 2014 11:53:27 -0700
Subject: Optimization 2.0 for composing strings - Was: Replace concat
	String to append in StringBuilder parameters
In-Reply-To: <540DF7F0.4090604@oracle.com>
References: <CAPc8kR3duvby+hfpAUQG5Z6rMPq-MzMv=Th7itQZHfkg_YvxDw@mail.gmail.com>	<53E7FA44.9050207@oracle.com>	<CAPc8kR1HPrLMP6qNzSr5Fe0y=eUDioh5BoVNsZ7q2mtgM_dSDQ@mail.gmail.com>	<CAM6ZMz_nz2zWZQLLaKSnv4Z4Aah5MKaNspctn4TFKrciK2yXyg@mail.gmail.com>	<476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com>	<CAPc8kR3Tet4HcxGuMywaLHZLVdkeEVNDkea5GtMjoBWD7X7yPg@mail.gmail.com>	<CAM6ZMz-U5C0mXXcebb84TYq318zSorNrdKHC+h=4JpBO=ma9VA@mail.gmail.com>	<53E8CCD6.2090503@CoSoCo.de>	<53FDA7C1.6060303@CoSoCo.de>	<902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com>	<53FF7244.2030804@CoSoCo.de>	<C82621D2-D936-4A2F-B0AD-AB39E9EA694D@oracle.com>	<5400E85E.9030005@CoSoCo.de>
	<540DE7B7.9070107@oracle.com>	<61C40823-1A23-4A0C-BAFD-D1E5B949F98E@oracle.com>
	<540DEC69.8080600@oracle.com> <540DF7F0.4090604@oracle.com>
Message-ID: <540DFB27.1030901@oracle.com>

Sergey,

Many of the suggestions in the webrev change the semantics of the code, 
and so would not be appropriate for javac to perform automagically.

For example, in the first few lines of the patch, I found this:

diff -r dde9f5cfde5f src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java
--- a/src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java	Tue Aug 05 19:29:00 2014 -0700
+++ b/src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java	Sun Aug 10 18:02:01 2014 -0300
@@ -79,25 +79,24 @@
              String textColor = String.format("%06x",
                                               foreground.getRGB() & 0xFFFFFF);
              StringBuilder sb = new StringBuilder();
-            sb.append("<html><body text=#"+textColor+"><table width=\"100%\">");
+            sb.append("<html><body text=#").append(textColor).append("><table width=\"100%\">");
              for (int i = 0; i < arr.length; i++) {
                  if (i % 2 == 0) {
-                    sb.append("<tr style=\"background-color: " +
-                            evenRowColorStr + "\"><td><pre>" +
-                            (arr[i] == null ?
-                                arr[i] : htmlize(arr[i].toString())) +
-                            "</pre></td></tr>");
+                    sb.append("<tr style=\"background-color: ")
+                            .append(evenRowColorStr).append("\"><td><pre>")
+                            .append(arr[i] == null ?
+                                    arr[i] : htmlize(arr[i].toString()))
+                            .append("</pre></td></tr>");


Analyzing the flow to determine it is safe to mutate sb in the face of 
possible exceptions coming out of methods like htmlize is more than it 
would be reasonable to do in javac.  For example, what if the for loop 
were in a try block and the try block referenced sb?

Also, consider the serviceability implications, if a user is stepping 
through the code with a debugger.

-- Jon


On 09/08/2014 11:39 AM, Sergey Bylokhov wrote:
> On 08.09.2014 21:50, Jonathan Gibbons wrote:
>> Yes, but is this really a big enough performance and footprint pain 
>> point to be worth addressing in javac itself?
>>
>> We're now talking about some specific code construction like
>>     new StringBuilder().append(a + b + c)
>>
>> Any other case where the string builder can be observed externally 
>> cannot be subject to the proposed optimization. The use case is now 
>> really getting pretty specific.
> Not so specific at least in jdk code:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028142.html 
>
>>
>> -- Jon
>>
>> On 09/08/2014 10:41 AM, Guy Steele wrote:
>>> Good point, but counterpoint: it might be acceptable to have 
>>> modified the string buffer in situations where throwing an exception 
>>> would always cause the string buffer to become inaccessible.
>>>
>>> ?Guy
>>>
>>> On Sep 8, 2014, at 1:30 PM, Jonathan Gibbons 
>>> <jonathan.gibbons at oracle.com> wrote:
>>>
>>>> It would be inappropriate/incorrect to apply the optimization as 
>>>> described.
>>>>
>>>> The JLS requires that the argument to a method call should be 
>>>> computed before invoking the method.
>>>>
>>>> Consider the case when one of the expressions in the series of 
>>>> string concatenations throws an exception. It would be incorrect to 
>>>> have already partially modified the string buffer.
>>>>
>>>> -- Jon
>>>>
>>>> On 08/29/2014 01:53 PM, Ulf Zibis wrote:
>>>>> Hi compiler people,
>>>>>
>>>>> is there some chance that javac could be enhanced to optimize 
>>>>> better as discussed in this thread? Than refactoring of up to now 
>>>>> better readable code to ugly StringBuilder at append() code would be 
>>>>> superfluous.
>>>>> I really like the String concatenation syntax, but unfortunately 
>>>>> it often causes slower code and bigger footprint.
>>>>> Optimally javac would optimize mixed use of StringBuilder, 
>>>>> StringJoiner, concatenation, toString(), append(String), 
>>>>> append(Collection) etc. to a single StringBuilder instance, so 
>>>>> that the resulting code, JITed or not, will have better performance.
>>>>> Additionally javac could guess a reasonable initial capacity from 
>>>>> the given source code.
>>>>>
>>>>>
>>>>> Am 29.08.2014 um 10:01 schrieb Wang Weijun:
>>>>>> So it's not that the optimization fails but there is no 
>>>>>> optimization on them yet.
>>>>>>
>>>>>> I do see the .append("x") case will be easy to deal with, but it 
>>>>>> looks like historically javac has not been a place to do many 
>>>>>> optimizations. It mostly converts the java source to byte codes 
>>>>>> in a 1-to-1 mapping and let VM do whatever it wants (to 
>>>>>> optimize). When you talked about compiling multiple concatenation 
>>>>>> into using a single StringBuilder, it's more like choosing the 
>>>>>> correct implementation rather than an optimization.
>>>>>>
>>>>>> I don't expect to see big change on this in the near future, so 
>>>>>> shall we go on with the current enhancement?
>>>>>>
>>>>>> Thanks
>>>>>> Max
>>>>>>
>>>>>> On Aug 29, 2014, at 2:17, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>>
>>>>>>> I mean:
>>>>>>> It does not output byte code that only uses a single char array 
>>>>>>> to compose the entire String in question.
>>>>>>> With "optimization fails", I also mean, there is used an 
>>>>>>> additional "StringComposer" e.g. another StringBuilder or a 
>>>>>>> StringJoiner in addition to the 1st StringBuilder.
>>>>>>>
>>>>>>> -Ulf
>>>>>>>
>>>>>>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>>>>>>>> Could you please explain what you mean by "javac optimization 
>>>>>>>> fails" here?
>>>>>>>>
>>>>>>>> -Pavel
>>>>>>>>
>>>>>>>> On 27 Aug 2014, at 10:41, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>>>>
>>>>>>>>> 4.) Now we see, that javac optimization fails again if 
>>>>>>>>> StringBuilder, concatenation, toString(), append(String), 
>>>>>>>>> append(Collection) etc. and StringJoiner use is mixed.
>>
>
>



From Ulf.Zibis at CoSoCo.de  Mon Sep  8 20:51:01 2014
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Mon, 08 Sep 2014 22:51:01 +0200
Subject: Impact of code difference in Collection#contains() worth
	improving?
In-Reply-To: <50DAE5A1-930B-403E-8C63-8A1235B3E3F4@oracle.com>
References: <CAFNq5NN9K5-Z2U-zSFUV7kFd-GVW7V+fyx92+QdWj_oVr1mRMA@mail.gmail.com>	<CA+kOe09wi67q7dEiwCSW72qqe55n-X5kmh+Cu+NRpeY2x-57Yw@mail.gmail.com>	<53FF6680.9000907@CoSoCo.de>	<CAHjP37F=+j0jRsm6+a-94qgwfXiM4SngM5+odYQKo+BZukNoRA@mail.gmail.com>	<5400DCF0.6090302@CoSoCo.de>	<CA+kOe0_sH1HhpMVR4iFj2xH+FmCJywO7n63k8E1v5s9gT65qbA@mail.gmail.com>
	<50DAE5A1-930B-403E-8C63-8A1235B3E3F4@oracle.com>
Message-ID: <540E16B5.5030801@CoSoCo.de>

Hi Martin,

why you didn't include Mike's suggestion into the fix?

-Ulf

Am 02.09.2014 um 19:04 schrieb Mike Duigou:
> Looks fine (bug updated with noreg-perf). I do think we should consider promoting a copy of this method to AbstractList as it generally allows for a much better implementation than AbstractCollection's contains().
>
> Mike
>
> On Aug 29 2014, at 14:56 , Martin Buchholz <martinrb at google.com> wrote:
>
>> Just think - one whole byte saved for each individual change!
>> I have a webrev!
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/pico-optimize-contains/
>> https://bugs.openjdk.java.net/browse/JDK-8056951
>>
>> Can haz review please?
>>
>>
>> On Fri, Aug 29, 2014 at 1:05 PM, Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:
>>
>>> Am 28.08.2014 um 19:46 schrieb Vitaly Davidovich:
>>>
>>>
>>>> There's no register pressure - the immediate (I.e. -1) is encoded
>>>> directly into the instruction, just like 0 would be.  The time when 0 is
>>>> particularly useful is when you test for it in the zero bit of the flags
>>>> register (e.g. dec followed by jz, such as when counting a loop down to
>>>> 0).  Otherwise, I don't see any advantage from machine code perspective.
>>>>
>>>>
>>> Thanks for explaining this, but a very little nit: the immediate (I.e. -1)
>>> uses additional 32/64 bits in code which must be loaded from memory and
>>> wastes space in CPU cache or am I wrong? This could be saved with >= 0.
>>>
>>> So if unifying the code I agree to Martin's opinion.
>>>
>>> -Ulf
>>>
>>> The aforementioned cmov instruction is not without its own downsides, so
>>>> it's unclear which is better when branch probability isn't known a priori.
>>>>
>>>> The 1 byte code is unlikely to make any difference, unless jit is turned
>>>> off and you're running this through a tight loop in the interpreter (but if
>>>> one does that, perf conversation is moot :)).
>>>>
>>>> Sent from my phone
>>>>
>>>> On Aug 28, 2014 1:28 PM, "Ulf Zibis" <Ulf.Zibis at cosoco.de <mailto:
>>>> Ulf.Zibis at cosoco.de>> wrote:
>>>>
>>>>
>>>>     Am 27.08.2014 um 17:51 schrieb Martin Buchholz:
>>>>
>>>>         The ArrayList version saves one byte of bytecode, and is
>>>> therefore very
>>>>         slightly better.  We should bless that version and use it
>>>> consistently.
>>>>
>>>>
>>>>     +1
>>>>     Additional argument:
>>>>     The LinkedList code requires to load 32/64-Bit -1 into CPU. This may
>>>> take some time on some
>>>>     CPU and at least wastes memory footprint.
>>>>     Additionally register pressure increases.
>>>>     Vitaly, please correct me, if I'm wrong, just for learning more.
>>>>
>>>>     Another advantage is that there is no problem if some implementation
>>>> of indexOf() erroneously
>>>>     returns another negative value than -1. I remember some compare()
>>>> implementations, which
>>>>     sometimes return different values than only -1, 0, +1.
>>>>
>>>>     -Ulf
>>>>
>>>>             ArrayList:
>>>>
>>>>                  public boolean contains(Object o) {
>>>>                      return indexOf(o) >= 0;
>>>>                  }
>>>>
>>>>             LinkedList:
>>>>
>>>>                  public boolean contains(Object o) {
>>>>                      return indexOf(o) != -1;
>>>>                  }
>>>>
>>>>
>>>>
>



From Ulf.Zibis at CoSoCo.de  Mon Sep  8 21:34:35 2014
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Mon, 08 Sep 2014 23:34:35 +0200
Subject: Impact of code difference in Collection#contains() worth
	improving?
In-Reply-To: <9F31BE9F-0E77-43CD-A693-659008E3E3C0@oracle.com>
References: <CAFNq5NN9K5-Z2U-zSFUV7kFd-GVW7V+fyx92+QdWj_oVr1mRMA@mail.gmail.com>	<CA+kOe09wi67q7dEiwCSW72qqe55n-X5kmh+Cu+NRpeY2x-57Yw@mail.gmail.com>	<53FF6680.9000907@CoSoCo.de>
	<CAHjP37F=+j0jRsm6+a-94qgwfXiM4SngM5+odYQKo+BZukNoRA@mail.gmail.com>
	<5400DCF0.6090302@CoSoCo.de>
	<56359349-BC8F-4EFE-8260-D118E5312873@oracle.com>
	<5401DD04.6050802@CoSoCo.de>
	<9F31BE9F-0E77-43CD-A693-659008E3E3C0@oracle.com>
Message-ID: <540E20EB.30306@CoSoCo.de>

Much thanks for your comments John.

The in bug 6984886 mentioned isHigh/LowSurrogate methods are frequently used in small loops of 
charset de/encoders, so I expect a measurable performance improvement there.

-Ulf


Am 06.09.2014 um 01:25 schrieb John Rose:
> On Aug 30, 2014, at 7:17 AM, Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:
>
>> Am 30.08.2014 um 01:33 schrieb John Rose:
>>> On Aug 29, 2014, at 1:05 PM, Ulf Zibis <Ulf.Zibis at cosoco.de <mailto:Ulf.Zibis at cosoco.de>> wrote:
>>>
>>>> Thanks for explaining this, but a very little nit: the immediate (I.e. -1) uses additional 32/64 bits in code which must be loaded from memory and wastes space in CPU cache or am I wrong? This could be saved with >= 0.
>>> I have to say you're more wrong than right about this.  Optimizers routinely change the form of constants.  For example, a constant 0 will often show up as something like "xor eax,eax", not a 32-bit literal zero that loads from somewhere in memory.  A comparison of the form "x > -1" will be freely changed to "x >= 0" and back again; the latter form may (or may not, depending on chip version) transform to "test eax", with no "-1" or "0" in sight.
>> 1. Thanks for the hint about "x > -1" ===> "x >= 0". But I'm afraid this would apply on the "x != -1" case we are discussing here.
> The equality comparison would be less likely to transform to a non-equality comparison.  But it is still possible in principle, if the JIT could prove that values "x < -1" are impossible.
>
>> 2. Are you really sure this optimization is always implemented, as following bug is still open:
>> JDK-6984886 : Transform comparisons against odd border to even border <http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6984886>
> Well, I'm pretty sure that no optimizations is "always" implemented; there are usually corner cases which prevent optimizations.  There is always a possibility of deoptimization to the interpreter, for example.  And there are lots of nice-to-have optimizations that don't make a difference to real applications.  Much of compiler development is driven by observing actual speed bottlenecks and removing them.
>
> But the bug reference is useful; thanks!  I added a comment to show where the optimization occurs now?disappointingly little I grant you?and where to start looking to improve it.  The bug is rated P5 (lowest rating) probably because the reporter said "it should be faster"; "wouldn't this be nice" is a far weaker argument than "I'm spending too much on hardware because this loop is slow".
>
> My comments about the unpredictability of optimizers still stand.  The most robust way to manage such problems is, first confirm it is a real performance problem (not a micro-nano thing), and second get the optimizer to make all equivalent inputs produce good code.  The tiny place where this optimization is done in HotSpot suggests that that was a place where the transform actually mattered the most.
>
> ? John



From lowasser at google.com  Mon Sep  8 22:58:05 2014
From: lowasser at google.com (Louis Wasserman)
Date: Mon, 8 Sep 2014 15:58:05 -0700
Subject: Optimization 2.0 for composing strings - Was: Replace concat
	String to append in StringBuilder parameters
In-Reply-To: <540DEC69.8080600@oracle.com>
References: <CAPc8kR3duvby+hfpAUQG5Z6rMPq-MzMv=Th7itQZHfkg_YvxDw@mail.gmail.com>
	<53E7FA44.9050207@oracle.com>
	<CAPc8kR1HPrLMP6qNzSr5Fe0y=eUDioh5BoVNsZ7q2mtgM_dSDQ@mail.gmail.com>
	<CAM6ZMz_nz2zWZQLLaKSnv4Z4Aah5MKaNspctn4TFKrciK2yXyg@mail.gmail.com>
	<476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com>
	<CAPc8kR3Tet4HcxGuMywaLHZLVdkeEVNDkea5GtMjoBWD7X7yPg@mail.gmail.com>
	<CAM6ZMz-U5C0mXXcebb84TYq318zSorNrdKHC+h=4JpBO=ma9VA@mail.gmail.com>
	<53E8CCD6.2090503@CoSoCo.de> <53FDA7C1.6060303@CoSoCo.de>
	<902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com>
	<53FF7244.2030804@CoSoCo.de>
	<C82621D2-D936-4A2F-B0AD-AB39E9EA694D@oracle.com>
	<5400E85E.9030005@CoSoCo.de> <540DE7B7.9070107@oracle.com>
	<61C40823-1A23-4A0C-BAFD-D1E5B949F98E@oracle.com>
	<540DEC69.8080600@oracle.com>
Message-ID: <CAGB9EW-aYD68=GQzEwfQMseeoqL9A-KEM0ROjwrWA17mVbjsoA@mail.gmail.com>

FWIW, Google has gotten noticeable performance benefits from a change to
javac's compilation of normal + concatenation, to just presize the
StringBuilder.  I haven't had the bandwidth to forward-port that change
yet, unfortunately, but that's a semantics-preserving change that seemed to
us to be within spec.


On Mon, Sep 8, 2014 at 10:50 AM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Yes, but is this really a big enough performance and footprint pain point
> to be worth addressing in javac itself?
>
> We're now talking about some specific code construction like
>     new StringBuilder().append(a + b + c)
>
> Any other case where the string builder can be observed externally cannot
> be subject to the proposed optimization. The use case is now really getting
> pretty specific.
>
> -- Jon
>
>
> On 09/08/2014 10:41 AM, Guy Steele wrote:
>
>> Good point, but counterpoint: it might be acceptable to have modified the
>> string buffer in situations where throwing an exception would always cause
>> the string buffer to become inaccessible.
>>
>> ?Guy
>>
>> On Sep 8, 2014, at 1:30 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com>
>> wrote:
>>
>>  It would be inappropriate/incorrect to apply the optimization as
>>> described.
>>>
>>> The JLS requires that the argument to a method call should be computed
>>> before invoking the method.
>>>
>>> Consider the case when one of the expressions in the series of string
>>> concatenations throws an exception. It would be incorrect to have already
>>> partially modified the string buffer.
>>>
>>> -- Jon
>>>
>>> On 08/29/2014 01:53 PM, Ulf Zibis wrote:
>>>
>>>> Hi compiler people,
>>>>
>>>> is there some chance that javac could be enhanced to optimize better as
>>>> discussed in this thread? Than refactoring of up to now better readable
>>>> code to ugly StringBuilder at append() code would be superfluous.
>>>> I really like the String concatenation syntax, but unfortunately it
>>>> often causes slower code and bigger footprint.
>>>> Optimally javac would optimize mixed use of StringBuilder,
>>>> StringJoiner, concatenation, toString(), append(String), append(Collection)
>>>> etc. to a single StringBuilder instance, so that the resulting code, JITed
>>>> or not, will have better performance.
>>>> Additionally javac could guess a reasonable initial capacity from the
>>>> given source code.
>>>>
>>>>
>>>> Am 29.08.2014 um 10:01 schrieb Wang Weijun:
>>>>
>>>>> So it's not that the optimization fails but there is no optimization
>>>>> on them yet.
>>>>>
>>>>> I do see the .append("x") case will be easy to deal with, but it looks
>>>>> like historically javac has not been a place to do many optimizations. It
>>>>> mostly converts the java source to byte codes in a 1-to-1 mapping and let
>>>>> VM do whatever it wants (to optimize). When you talked about compiling
>>>>> multiple concatenation into using a single StringBuilder, it's more like
>>>>> choosing the correct implementation rather than an optimization.
>>>>>
>>>>> I don't expect to see big change on this in the near future, so shall
>>>>> we go on with the current enhancement?
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>> On Aug 29, 2014, at 2:17, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>
>>>>>  I mean:
>>>>>> It does not output byte code that only uses a single char array to
>>>>>> compose the entire String in question.
>>>>>> With "optimization fails", I also mean, there is used an additional
>>>>>> "StringComposer" e.g. another StringBuilder or a StringJoiner in addition
>>>>>> to the 1st StringBuilder.
>>>>>>
>>>>>> -Ulf
>>>>>>
>>>>>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>>>>>>
>>>>>>> Could you please explain what you mean by "javac optimization fails"
>>>>>>> here?
>>>>>>>
>>>>>>> -Pavel
>>>>>>>
>>>>>>> On 27 Aug 2014, at 10:41, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>>>
>>>>>>>  4.) Now we see, that javac optimization fails again if
>>>>>>>> StringBuilder, concatenation, toString(), append(String),
>>>>>>>> append(Collection) etc. and StringJoiner use is mixed.
>>>>>>>>
>>>>>>>
>


-- 
Louis Wasserman


From Ulf.Zibis at CoSoCo.de  Mon Sep  8 22:58:44 2014
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 09 Sep 2014 00:58:44 +0200
Subject: Optimization 2.0 for composing strings - Was: Replace concat
	String to append in StringBuilder parameters
In-Reply-To: <540DFB27.1030901@oracle.com>
References: <CAPc8kR3duvby+hfpAUQG5Z6rMPq-MzMv=Th7itQZHfkg_YvxDw@mail.gmail.com>	<53E7FA44.9050207@oracle.com>	<CAPc8kR1HPrLMP6qNzSr5Fe0y=eUDioh5BoVNsZ7q2mtgM_dSDQ@mail.gmail.com>	<CAM6ZMz_nz2zWZQLLaKSnv4Z4Aah5MKaNspctn4TFKrciK2yXyg@mail.gmail.com>	<476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com>	<CAPc8kR3Tet4HcxGuMywaLHZLVdkeEVNDkea5GtMjoBWD7X7yPg@mail.gmail.com>	<CAM6ZMz-U5C0mXXcebb84TYq318zSorNrdKHC+h=4JpBO=ma9VA@mail.gmail.com>	<53E8CCD6.2090503@CoSoCo.de>	<53FDA7C1.6060303@CoSoCo.de>	<902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com>	<53FF7244.2030804@CoSoCo.de>	<C82621D2-D936-4A2F-B0AD-AB39E9EA694D@oracle.com>	<5400E85E.9030005@CoSoCo.de>	<540DE7B7.9070107@oracle.com>	<61C40823-1A23-4A0C-BAFD-D1E5B949F98E@oracle.com>	<540DEC69.8080600@oracle.com>
	<540DF7F0.4090604@oracle.com> <540DFB27.1030901@oracle.com>
Message-ID: <540E34A4.5010001@CoSoCo.de>

Much thanks for all your thoughts.

-Ulf

Am 08.09.2014 um 20:53 schrieb Jonathan Gibbons:
> Sergey,
>
> Many of the suggestions in the webrev change the semantics of the code, and so would not be 
> appropriate for javac to perform automagically.
>
> For example, in the first few lines of the patch, I found this:
>
> diff -r dde9f5cfde5f src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java
> --- a/src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java Tue Aug 05 19:29:00 
> 2014 -0700
> +++ b/src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java Sun Aug 10 18:02:01 
> 2014 -0300
> @@ -79,25 +79,24 @@
>              String textColor = String.format("%06x",
>                                               foreground.getRGB() & 0xFFFFFF);
>              StringBuilder sb = new StringBuilder();
> -            sb.append("<html><body text=#"+textColor+"><table width=\"100%\">");
> +            sb.append("<html><body text=#").append(textColor).append("><table width=\"100%\">");
>              for (int i = 0; i < arr.length; i++) {
>                  if (i % 2 == 0) {
> -                    sb.append("<tr style=\"background-color: " +
> -                            evenRowColorStr + "\"><td><pre>" +
> -                            (arr[i] == null ?
> -                                arr[i] : htmlize(arr[i].toString())) +
> - "</pre></td></tr>");
> +                    sb.append("<tr style=\"background-color: ")
> + .append(evenRowColorStr).append("\"><td><pre>")
> +                            .append(arr[i] == null ?
> +                                    arr[i] : htmlize(arr[i].toString()))
> + .append("</pre></td></tr>");
>
>
> Analyzing the flow to determine it is safe to mutate sb in the face of possible exceptions coming 
> out of methods like htmlize is more than it would be reasonable to do in javac.  For example, what 
> if the for loop were in a try block and the try block referenced sb?
>
> Also, consider the serviceability implications, if a user is stepping through the code with a 
> debugger.
>
> -- Jon
>
>
> On 09/08/2014 11:39 AM, Sergey Bylokhov wrote:
>> On 08.09.2014 21:50, Jonathan Gibbons wrote:
>>> Yes, but is this really a big enough performance and footprint pain point to be worth addressing 
>>> in javac itself?
>>>
>>> We're now talking about some specific code construction like
>>>     new StringBuilder().append(a + b + c)
>>>
>>> Any other case where the string builder can be observed externally cannot be subject to the 
>>> proposed optimization. The use case is now really getting pretty specific.
>> Not so specific at least in jdk code:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028142.html
>>>
>>> -- Jon
>>>
>>> On 09/08/2014 10:41 AM, Guy Steele wrote:
>>>> Good point, but counterpoint: it might be acceptable to have modified the string buffer in 
>>>> situations where throwing an exception would always cause the string buffer to become 
>>>> inaccessible.
>>>>
>>>> ?Guy
>>>>
>>>> On Sep 8, 2014, at 1:30 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>>>
>>>>> It would be inappropriate/incorrect to apply the optimization as described.
>>>>>
>>>>> The JLS requires that the argument to a method call should be computed before invoking the 
>>>>> method.
>>>>>
>>>>> Consider the case when one of the expressions in the series of string concatenations throws an 
>>>>> exception. It would be incorrect to have already partially modified the string buffer.
>>>>>
>>>>> -- Jon
>>>>>
>>>>> On 08/29/2014 01:53 PM, Ulf Zibis wrote:
>>>>>> Hi compiler people,
>>>>>>
>>>>>> is there some chance that javac could be enhanced to optimize better as discussed in this 
>>>>>> thread? Than refactoring of up to now better readable code to ugly StringBuilder at append() 
>>>>>> code would be superfluous.
>>>>>> I really like the String concatenation syntax, but unfortunately it often causes slower code 
>>>>>> and bigger footprint.
>>>>>> Optimally javac would optimize mixed use of StringBuilder, StringJoiner, concatenation, 
>>>>>> toString(), append(String), append(Collection) etc. to a single StringBuilder instance, so 
>>>>>> that the resulting code, JITed or not, will have better performance.
>>>>>> Additionally javac could guess a reasonable initial capacity from the given source code.
>>>>>>
>>>>>>
>>>>>> Am 29.08.2014 um 10:01 schrieb Wang Weijun:
>>>>>>> So it's not that the optimization fails but there is no optimization on them yet.
>>>>>>>
>>>>>>> I do see the .append("x") case will be easy to deal with, but it looks like historically 
>>>>>>> javac has not been a place to do many optimizations. It mostly converts the java source to 
>>>>>>> byte codes in a 1-to-1 mapping and let VM do whatever it wants (to optimize). When you 
>>>>>>> talked about compiling multiple concatenation into using a single StringBuilder, it's more 
>>>>>>> like choosing the correct implementation rather than an optimization.
>>>>>>>
>>>>>>> I don't expect to see big change on this in the near future, so shall we go on with the 
>>>>>>> current enhancement?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Max
>>>>>>>
>>>>>>> On Aug 29, 2014, at 2:17, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>>>
>>>>>>>> I mean:
>>>>>>>> It does not output byte code that only uses a single char array to compose the entire 
>>>>>>>> String in question.
>>>>>>>> With "optimization fails", I also mean, there is used an additional "StringComposer" e.g. 
>>>>>>>> another StringBuilder or a StringJoiner in addition to the 1st StringBuilder.
>>>>>>>>
>>>>>>>> -Ulf
>>>>>>>>
>>>>>>>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>>>>>>>>> Could you please explain what you mean by "javac optimization fails" here?
>>>>>>>>>
>>>>>>>>> -Pavel
>>>>>>>>>
>>>>>>>>> On 27 Aug 2014, at 10:41, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>>>>>
>>>>>>>>>> 4.) Now we see, that javac optimization fails again if StringBuilder, concatenation, 
>>>>>>>>>> toString(), append(String), append(Collection) etc. and StringJoiner use is mixed.
>>>
>>
>>
>
>



From mandy.chung at oracle.com  Mon Sep  8 22:59:15 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 08 Sep 2014 15:59:15 -0700
Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <540A152E.9020507@oracle.com>
References: <540A152E.9020507@oracle.com>
Message-ID: <540E34C3.4070203@oracle.com>

Thumbs up.

Mandy

On 9/5/2014 12:55 PM, Coleen Phillimore wrote:
> Summary: Add classLoader to java/lang/Class instance for fast access
>
> This is a backport request for 8u40.   This change has been in the 
> jdk9 code for 3 months without any problems.
>
> The JDK changes hg imported cleanly.  The Hotspot change needed a hand 
> merge for create_mirror call in klass.cpp.
>
> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/
> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/
>
> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>
> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. Also 
> ran jck java_lang tests with only the hotspot change.  The hotspot 
> change can be tested separately from the jdk change (but not the other 
> way around).
>
> Thanks,
> Coleen



From coleen.phillimore at oracle.com  Tue Sep  9 02:05:16 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 08 Sep 2014 22:05:16 -0400
Subject: [8u40] RFR 6642881: Improve performance of Class.getClassLoader()
In-Reply-To: <540E34C3.4070203@oracle.com>
References: <540A152E.9020507@oracle.com> <540E34C3.4070203@oracle.com>
Message-ID: <540E605C.8020707@oracle.com>


Thanks, Mandy!

Coleen

On 9/8/14, 6:59 PM, Mandy Chung wrote:
> Thumbs up.
>
> Mandy
>
> On 9/5/2014 12:55 PM, Coleen Phillimore wrote:
>> Summary: Add classLoader to java/lang/Class instance for fast access
>>
>> This is a backport request for 8u40.   This change has been in the 
>> jdk9 code for 3 months without any problems.
>>
>> The JDK changes hg imported cleanly.  The Hotspot change needed a 
>> hand merge for create_mirror call in klass.cpp.
>>
>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/
>> http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/
>>
>> bug link https://bugs.openjdk.java.net/browse/JDK-6642881
>>
>> Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. Also 
>> ran jck java_lang tests with only the hotspot change.  The hotspot 
>> change can be tested separately from the jdk change (but not the 
>> other way around).
>>
>> Thanks,
>> Coleen
>



From robbiexgibson at yahoo.com  Tue Sep  9 08:30:56 2014
From: robbiexgibson at yahoo.com (Robert Gibson)
Date: Tue, 9 Sep 2014 01:30:56 -0700
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com> 
Message-ID: <1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>




Hi there,

I came across a case in BigDecimal division where the dividend ends up getting mutated, which is rather strange for a seemingly immutable class! (It's a subset of the cases where the Burnikel-Ziegler algorithm is used, I haven't done the analysis to find out under which exact conditions it's triggered.)

The attached patch - against the JDK8 version - should fix the problem, at the cost of an extra array copy.  Could somebody review and/or comment please?

Thanks,
Robert

--- MutableBigInteger.java      2014-09-04 09:42:23.426815000 +0200
+++ MutableBigInteger.java.patched      2014-09-04 09:46:21.344132000 +0200
@@ -1261,19 +1261,20 @@
             int sigma = (int) Math.max(0, n32 - b.bitLength());   // step 3: sigma = max{T | (2^T)*B < beta^n}
             MutableBigInteger bShifted = new MutableBigInteger(b);
             bShifted.safeLeftShift(sigma);   // step 4a: shift b so its length is a multiple of n
-            safeLeftShift(sigma);     // step 4b: shift this by the same amount
+            MutableBigInteger aShifted = new MutableBigInteger (this);
+            aShifted.safeLeftShift(sigma);     // step 4b: shift a by the same amount
-            // step 5: t is the number of blocks needed to accommodate this plus one additional bit
-            int t = (int) ((bitLength()+n32) / n32);
+            // step 5: t is the number of blocks needed to accommodate a plus one additional bit
+            int t = (int) ((aShifted.bitLength()+n32) / n32);
             if (t < 2) {
                 t = 2;
             }
-            // step 6: conceptually split this into blocks a[t-1], ..., a[0]
-            MutableBigInteger a1 = getBlock(t-1, t, n);   // the most significant block of this
+            // step 6: conceptually split a into blocks a[t-1], ..., a[0]
+            MutableBigInteger a1 = aShifted.getBlock(t-1, t, n);   // the most significant block of a
             // step 7: z[t-2] = [a[t-1], a[t-2]]
-            MutableBigInteger z = getBlock(t-2, t, n);    // the second to most significant block
+            MutableBigInteger z = aShifted.getBlock(t-2, t, n);    // the second to most significant block
             z.addDisjoint(a1, n);   // z[t-2]
             // do schoolbook division on blocks, dividing 2-block numbers by 1-block numbers
@@ -1284,7 +1285,7 @@
                 ri = z.divide2n1n(bShifted, qi);
                 // step 8b: z = [ri, a[i-1]]
-                z = getBlock(i-1, t, n);   // a[i-1]
+                z = aShifted.getBlock(i-1, t, n);   // a[i-1]
                 z.addDisjoint(ri, n);
                 quotient.addShifted(qi, i*n);   // update q (part of step 9)
             }
@@ -1292,7 +1293,7 @@
             ri = z.divide2n1n(bShifted, qi);
             quotient.add(qi);
-           ri.rightShift(sigma);   // step 9: this and b were shifted, so shift back
+           ri.rightShift(sigma);   // step 9: a and b were shifted, so shift back
             return ri;
         }
     }


From joel.franck at oracle.com  Tue Sep  9 09:21:47 2014
From: joel.franck at oracle.com (Joel =?utf-8?Q?Borggr=C3=A9n-Franck?=)
Date: Tue, 9 Sep 2014 11:21:47 +0200
Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection
In-Reply-To: <D85E6ACE-028D-48BF-88F3-75888EC63B49@gmail.com>
References: <F36715BC-B186-4157-BB61-AE2897F6B685@oracle.com>
	<C1CC52F0-9770-4A30-9EDD-267C29193376@gmail.com>
	<55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com>
	<2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com>
	<237340BB-AD86-443D-BFFC-A1E601E44BDF@oracle.com>
	<CAM6ZMz8wGhNT+QbxPKt46Zpv34cPLe4GwMiheqk1GnKnj=f5Vw@mail.gmail.com>
	<20140613084650.GA24337@oracle.com>
	<CAM6ZMz-xoObKSVU8mGN0q3xyOQTZJZYxMNp92F9mPJsf3akjFQ@mail.gmail.com>
	<C9BCB35D-5F09-49D2-8F43-D0039B8D388F@oracle.com>
	<D85E6ACE-028D-48BF-88F3-75888EC63B49@gmail.com>
Message-ID: <20140909092147.GA16236@oracle.com>

Hi Andrej,

Can you resend the latest patch attached to a mail to this list?

cheers
/Joel

On 2014-08-29, Andrej Golovnin wrote:
> Hi Joel,
> 
> >> I have changed the test TestMethodReflectValueOf as you suggested and I have changed the summary of both tests too. You will find the changes in the attached patch. Here is the new webrev: https://db.tt/wQBLVceA
> >> 
> >> And here is the coverage report in the HTML format:
> >> 
> >> https://db.tt/JTZjpnMM
> >> 
> > 
> > Out of curiosity, did you generate the coverage report running the jdk_lang test suite?
> 
> Yes and I used the following config for JCov:
> 
> include_list=jcov_jdk_lang.txt,field=on,abstract=on,native=on,type=all,file=$JCOV_OUT,merge=merge
> 
> where jcov_jdk_lang.txt contains the single line:
> 
> sun.reflect.*
> 
> 
> > I think this patch is good to go. I need to file some Oracle internal requests, should take about a week, then I can sponsor this.
> 
> I am very pleased to hear that and I hope to contribute more.
> 
> Best regards,
> Andrej Golovnin

-- 


From paul.sandoz at oracle.com  Tue Sep  9 10:05:52 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 9 Sep 2014 12:05:52 +0200
Subject: [9] RFR (S) 8057656: Improve MethodType.isCastableTo() &
	MethodType.isConvertibleTo() checks
In-Reply-To: <5409E812.50302@oracle.com>
References: <54097319.2090601@oracle.com>
	<4AFFDFA0-386D-4D73-8046-284C188FEF0D@oracle.com>
	<5409E812.50302@oracle.com>
Message-ID: <D9AC611D-5223-44E5-AACC-EA7FB801B752@oracle.com>

On Sep 5, 2014, at 6:42 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> >> http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8057656
>>> 
>> 
>>  854         if (!canConvert(returnType(), newType.returnType()))
>>  855             return false;
>>  856         Class<?>[] srcTypes = newType.ptypes;
>>  857         Class<?>[] dstTypes = ptypes;
>> 
>> Are the src and dst the wrong way around?
>> 
>>    srcTypes = ptypes
>>    dstTypes = newType.ptypes
> No, they are right. Parameters and return type conversions have opposite directions.
> 

Doh! of course, silly me.


>>  896     private static boolean canCast(Class<?> src, Class<?> dst) {
>>  897         if (src.isPrimitive() && !dst.isPrimitive()) {
>>  898             if (dst == Object.class || dst.isInterface())  return true;
>> 
>> How come if the src is primitive and the dst is an interface it returns true for any interface? I guess there are subtly different rules here for casting and conversion.
> There are 2 types of converstions: MH.asType() and MHs.explicitCastArguemnts() with more relaxed semantics.
> One of the differences is that interfaces are coerced to Object, since verifier allows any interface to be treated as Object.
> 
> Your questions reminded me about related changes waiting in the queue and I decided to include then here.
> 
> Updated webrev:
> http://cr.openjdk.java.net/~vlivanov/8057656/webrev.01/
> 
> Got rid of MT.isCastableTo(). MHs.explicitCastEquivalentToAsType() is used instead. Also, it has detailed overview of differences between MT.asType() and MHs.explicitCastArguments().
> 

Much clearer IMO.

+1

Paul.



From vladimir.x.ivanov at oracle.com  Tue Sep  9 10:10:26 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 09 Sep 2014 14:10:26 +0400
Subject: [9] RFR (S) 8057656: Improve MethodType.isCastableTo() &
	MethodType.isConvertibleTo() checks
In-Reply-To: <D9AC611D-5223-44E5-AACC-EA7FB801B752@oracle.com>
References: <54097319.2090601@oracle.com>	<4AFFDFA0-386D-4D73-8046-284C188FEF0D@oracle.com>	<5409E812.50302@oracle.com>
	<D9AC611D-5223-44E5-AACC-EA7FB801B752@oracle.com>
Message-ID: <540ED212.3030101@oracle.com>

Thank you, Paul.

Best regards,
Vladimir Ivanov

On 9/9/14, 2:05 PM, Paul Sandoz wrote:
> On Sep 5, 2014, at 6:42 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>>> http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8057656
>>>>
>>>
>>>   854         if (!canConvert(returnType(), newType.returnType()))
>>>   855             return false;
>>>   856         Class<?>[] srcTypes = newType.ptypes;
>>>   857         Class<?>[] dstTypes = ptypes;
>>>
>>> Are the src and dst the wrong way around?
>>>
>>>     srcTypes = ptypes
>>>     dstTypes = newType.ptypes
>> No, they are right. Parameters and return type conversions have opposite directions.
>>
>
> Doh! of course, silly me.
>
>
>>>   896     private static boolean canCast(Class<?> src, Class<?> dst) {
>>>   897         if (src.isPrimitive() && !dst.isPrimitive()) {
>>>   898             if (dst == Object.class || dst.isInterface())  return true;
>>>
>>> How come if the src is primitive and the dst is an interface it returns true for any interface? I guess there are subtly different rules here for casting and conversion.
>> There are 2 types of converstions: MH.asType() and MHs.explicitCastArguemnts() with more relaxed semantics.
>> One of the differences is that interfaces are coerced to Object, since verifier allows any interface to be treated as Object.
>>
>> Your questions reminded me about related changes waiting in the queue and I decided to include then here.
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~vlivanov/8057656/webrev.01/
>>
>> Got rid of MT.isCastableTo(). MHs.explicitCastEquivalentToAsType() is used instead. Also, it has detailed overview of differences between MT.asType() and MHs.explicitCastArguments().
>>
>
> Much clearer IMO.
>
> +1
>
> Paul.
>


From Ulf.Zibis at CoSoCo.de  Tue Sep  9 10:28:47 2014
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 09 Sep 2014 12:28:47 +0200
Subject: Optimization 2.0 for composing strings - Was: Replace concat
	String to append in StringBuilder parameters
In-Reply-To: <540DFB27.1030901@oracle.com>
References: <CAPc8kR3duvby+hfpAUQG5Z6rMPq-MzMv=Th7itQZHfkg_YvxDw@mail.gmail.com>	<53E7FA44.9050207@oracle.com>	<CAPc8kR1HPrLMP6qNzSr5Fe0y=eUDioh5BoVNsZ7q2mtgM_dSDQ@mail.gmail.com>	<CAM6ZMz_nz2zWZQLLaKSnv4Z4Aah5MKaNspctn4TFKrciK2yXyg@mail.gmail.com>	<476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com>	<CAPc8kR3Tet4HcxGuMywaLHZLVdkeEVNDkea5GtMjoBWD7X7yPg@mail.gmail.com>	<CAM6ZMz-U5C0mXXcebb84TYq318zSorNrdKHC+h=4JpBO=ma9VA@mail.gmail.com>	<53E8CCD6.2090503@CoSoCo.de>	<53FDA7C1.6060303@CoSoCo.de>	<902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com>	<53FF7244.2030804@CoSoCo.de>	<C82621D2-D936-4A2F-B0AD-AB39E9EA694D@oracle.com>	<5400E85E.9030005@CoSoCo.de>	<540DE7B7.9070107@oracle.com>	<61C40823-1A23-4A0C-BAFD-D1E5B949F98E@oracle.com>	<540DEC69.8080600@oracle.com>
	<540DF7F0.4090604@oracle.com> <540DFB27.1030901@oracle.com>
Message-ID: <540ED65F.9010808@CoSoCo.de>

Am 08.09.2014 um 20:53 schrieb Jonathan Gibbons:
> For example, in the first few lines of the patch, I found this:
Do you see any semantics change here?

> diff -r dde9f5cfde5f src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java
> --- a/src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java Tue Aug 05 19:29:00 
> 2014 -0700
> +++ b/src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java Sun Aug 10 18:02:01 
> 2014 -0300
> @@ -79,25 +79,24 @@
>              String textColor = String.format("%06x",
>                                               foreground.getRGB() & 0xFFFFFF);
>              StringBuilder sb = new StringBuilder();
> -            sb.append("<html><body text=#"+textColor+"><table width=\"100%\">");
> +            sb.append("<html><body text=#").append(textColor).append("><table width=\"100%\">");
>              for (int i = 0; i < arr.length; i++) {
>                  if (i % 2 == 0) {
> -                    sb.append("<tr style=\"background-color: " +
> -                            evenRowColorStr + "\"><td><pre>" +
> -                            (arr[i] == null ?
> -                                arr[i] : htmlize(arr[i].toString())) +
> - "</pre></td></tr>");
> +                    sb.append("<tr style=\"background-color: ")
> + .append(evenRowColorStr).append("\"><td><pre>")
> +                            .append(arr[i] == null ?
> +                                    arr[i] : htmlize(arr[i].toString()))
> + .append("</pre></td></tr>");

In this special case javac optimizer could first interpret as (as same as we could help it by just 
coding like that):
              StringBuilder sb = new StringBuilder(
                      "<html><body text=#"+textColor+"><table width=\"100%\">");
so no need for an additional implicit StringBuilder. Additionally javac could guess a reasonable 
capacity first.

> Analyzing the flow to determine it is safe to mutate sb in the face of possible exceptions coming 
> out of methods like htmlize is more than it would be reasonable to do in javac.  For example, what 
> if the for loop were in a try block and the try block referenced sb?
Good example where such optimization would fail. But:
- manual optimization would fail either
- try catch block anyway would have it's own performance cost, maybe more than the additional 
StringBuilder.

Maybe it's not such complicated as we guess to find out if the affected StringBuilder becomes 
reliably unreachable in case of exception, and therefore securely could be "mutated".

> Also, consider the serviceability implications, if a user is stepping through the code with a 
> debugger.
Good point. But I think, we are already used with this when stepping through simple String 
concatenation or wondering on a StringBuilder in exception stack trace, even there is no 
StringBuilder in our code.


-Ulf



From vladimir.x.ivanov at oracle.com  Tue Sep  9 10:51:26 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 09 Sep 2014 14:51:26 +0400
Subject: [9] RFR (L): Improve LambdaForm sharing by using LambdaFormEditor
	more extensively
Message-ID: <540EDBAE.3010300@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8057922/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8057922

Introduce more sharing on LambdaForm level by rewriting most of the MH 
combinators using LambdaFormEditor.

The new code is guarded by USE_LAMBDA_FORM_EDITOR flag and turned off by 
default because it introduces significant peak performance regression on 
Octane benchmark. I'm working on the fix. Original implementation will 
be removed once performance degradation is fixed.

Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ 
"-ea -esa", COMPILE_THRESHOLD={0,30}, and 
USE_LAMBDA_FORM_EDITOR={true,false}.

Reviewed-by: vlivanov, ?
Contributed-by: john.r.rose at oracle.com

Thanks!

Best regards,
Vladimir Ivanov


From Sergey.Bylokhov at oracle.com  Tue Sep  9 11:47:50 2014
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 09 Sep 2014 15:47:50 +0400
Subject: Optimization 2.0 for composing strings - Was: Replace concat
	String to append in StringBuilder parameters
In-Reply-To: <540DFB27.1030901@oracle.com>
References: <CAPc8kR3duvby+hfpAUQG5Z6rMPq-MzMv=Th7itQZHfkg_YvxDw@mail.gmail.com>	<53E7FA44.9050207@oracle.com>	<CAPc8kR1HPrLMP6qNzSr5Fe0y=eUDioh5BoVNsZ7q2mtgM_dSDQ@mail.gmail.com>	<CAM6ZMz_nz2zWZQLLaKSnv4Z4Aah5MKaNspctn4TFKrciK2yXyg@mail.gmail.com>	<476830A4-7A8E-4652-A0C7-805687155F4A@oracle.com>	<CAPc8kR3Tet4HcxGuMywaLHZLVdkeEVNDkea5GtMjoBWD7X7yPg@mail.gmail.com>	<CAM6ZMz-U5C0mXXcebb84TYq318zSorNrdKHC+h=4JpBO=ma9VA@mail.gmail.com>	<53E8CCD6.2090503@CoSoCo.de>	<53FDA7C1.6060303@CoSoCo.de>	<902B0B7A-32BE-498A-B9DD-8937960430A2@oracle.com>	<53FF7244.2030804@CoSoCo.de>	<C82621D2-D936-4A2F-B0AD-AB39E9EA694D@oracle.com>	<5400E85E.9030005@CoSoCo.de>
	<540DE7B7.9070107@oracle.com>	<61C40823-1A23-4A0C-BAFD-D1E5B949F98E@oracle.com>
	<540DEC69.8080600@oracle.com> <540DF7F0.4090604@oracle.com>
	<540DFB27.1030901@oracle.com>
Message-ID: <540EE8E6.3040801@oracle.com>

On 08.09.2014 22:53, Jonathan Gibbons wrote:
> Sergey,
>
> Many of the suggestions in the webrev change the semantics of the 
> code, and so would not be appropriate for javac to perform automagically.
It is changed but I guess it is safe otherwise this ccan be a problem in 
the fix, but the fix still under review.
> Analyzing the flow to determine it is safe to mutate sb in the face of 
> possible exceptions coming out of methods like htmlize is more than it 
> would be reasonable to do in javac.  For example, what if the for loop 
> were in a try block and the try block referenced sb?
It depends how many man's time spend on such changes, which can be done 
by the javac itself. I see that there is a lot of review requests to 
make some small micro/size optimizations, which can be done automatically.
>
> Also, consider the serviceability implications, if a user is stepping 
> through the code with a debugger.
>
> -- Jon
>
>
> On 09/08/2014 11:39 AM, Sergey Bylokhov wrote:
>> On 08.09.2014 21:50, Jonathan Gibbons wrote:
>>> Yes, but is this really a big enough performance and footprint pain 
>>> point to be worth addressing in javac itself?
>>>
>>> We're now talking about some specific code construction like
>>>     new StringBuilder().append(a + b + c)
>>>
>>> Any other case where the string builder can be observed externally 
>>> cannot be subject to the proposed optimization. The use case is now 
>>> really getting pretty specific.
>> Not so specific at least in jdk code:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028142.html 
>>
>>>
>>> -- Jon
>>>
>>> On 09/08/2014 10:41 AM, Guy Steele wrote:
>>>> Good point, but counterpoint: it might be acceptable to have 
>>>> modified the string buffer in situations where throwing an 
>>>> exception would always cause the string buffer to become inaccessible.
>>>>
>>>> ?Guy
>>>>
>>>> On Sep 8, 2014, at 1:30 PM, Jonathan Gibbons 
>>>> <jonathan.gibbons at oracle.com> wrote:
>>>>
>>>>> It would be inappropriate/incorrect to apply the optimization as 
>>>>> described.
>>>>>
>>>>> The JLS requires that the argument to a method call should be 
>>>>> computed before invoking the method.
>>>>>
>>>>> Consider the case when one of the expressions in the series of 
>>>>> string concatenations throws an exception. It would be incorrect 
>>>>> to have already partially modified the string buffer.
>>>>>
>>>>> -- Jon
>>>>>
>>>>> On 08/29/2014 01:53 PM, Ulf Zibis wrote:
>>>>>> Hi compiler people,
>>>>>>
>>>>>> is there some chance that javac could be enhanced to optimize 
>>>>>> better as discussed in this thread? Than refactoring of up to now 
>>>>>> better readable code to ugly StringBuilder at append() code would be 
>>>>>> superfluous.
>>>>>> I really like the String concatenation syntax, but unfortunately 
>>>>>> it often causes slower code and bigger footprint.
>>>>>> Optimally javac would optimize mixed use of StringBuilder, 
>>>>>> StringJoiner, concatenation, toString(), append(String), 
>>>>>> append(Collection) etc. to a single StringBuilder instance, so 
>>>>>> that the resulting code, JITed or not, will have better performance.
>>>>>> Additionally javac could guess a reasonable initial capacity from 
>>>>>> the given source code.
>>>>>>
>>>>>>
>>>>>> Am 29.08.2014 um 10:01 schrieb Wang Weijun:
>>>>>>> So it's not that the optimization fails but there is no 
>>>>>>> optimization on them yet.
>>>>>>>
>>>>>>> I do see the .append("x") case will be easy to deal with, but it 
>>>>>>> looks like historically javac has not been a place to do many 
>>>>>>> optimizations. It mostly converts the java source to byte codes 
>>>>>>> in a 1-to-1 mapping and let VM do whatever it wants (to 
>>>>>>> optimize). When you talked about compiling multiple 
>>>>>>> concatenation into using a single StringBuilder, it's more like 
>>>>>>> choosing the correct implementation rather than an optimization.
>>>>>>>
>>>>>>> I don't expect to see big change on this in the near future, so 
>>>>>>> shall we go on with the current enhancement?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Max
>>>>>>>
>>>>>>> On Aug 29, 2014, at 2:17, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>>>
>>>>>>>> I mean:
>>>>>>>> It does not output byte code that only uses a single char array 
>>>>>>>> to compose the entire String in question.
>>>>>>>> With "optimization fails", I also mean, there is used an 
>>>>>>>> additional "StringComposer" e.g. another StringBuilder or a 
>>>>>>>> StringJoiner in addition to the 1st StringBuilder.
>>>>>>>>
>>>>>>>> -Ulf
>>>>>>>>
>>>>>>>> Am 27.08.2014 um 14:02 schrieb Pavel Rappo:
>>>>>>>>> Could you please explain what you mean by "javac optimization 
>>>>>>>>> fails" here?
>>>>>>>>>
>>>>>>>>> -Pavel
>>>>>>>>>
>>>>>>>>> On 27 Aug 2014, at 10:41, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>>>>>>>>>
>>>>>>>>>> 4.) Now we see, that javac optimization fails again if 
>>>>>>>>>> StringBuilder, concatenation, toString(), append(String), 
>>>>>>>>>> append(Collection) etc. and StringJoiner use is mixed.
>>>
>>
>>
>


-- 
Best regards, Sergey.



From paul.sandoz at oracle.com  Tue Sep  9 12:12:38 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 9 Sep 2014 14:12:38 +0200
Subject: [9] RFR (S): 8057657: Annotate LambdaForm parameters with types
In-Reply-To: <54098C98.90009@oracle.com>
References: <54098C98.90009@oracle.com>
Message-ID: <44983AE4-63D2-4991-89F6-9BEB55F857ED@oracle.com>


On Sep 5, 2014, at 12:12 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8057657/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8057657
> 

- BoundMethodHandle

  57         assert(speciesData() == speciesData(form));

I am missing some context here as to how that assert would pass for anything other than Species_L, namely for sub-classes of BoundMethodHandle generated by generateConcreteBMHClass how does that assert return true?


 153     public static SpeciesData speciesData(LambdaForm form) {

Minor point. Could be private (since only used by the assert in the constructor), or package private if the intention is for it to be used by other j.l.i classes in the future.

Paul.


> Add ability to annotate LambdaForm parameters with their types.
> Type info could be useful during LambdaForm compilation to produce better bytecode.
> 
> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}.
> 
> Reviewed-by: vlivanov, ?
> Contributed-by: john.r.rose at oracle.com
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov



From paul.sandoz at oracle.com  Tue Sep  9 13:16:41 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 9 Sep 2014 15:16:41 +0200
Subject: [9] RFR (L): Improve LambdaForm sharing by using LambdaFormEditor
	more extensively
In-Reply-To: <540EDBAE.3010300@oracle.com>
References: <540EDBAE.3010300@oracle.com>
Message-ID: <198D8588-AEBB-406E-B69D-83A953456568@oracle.com>


On Sep 9, 2014, at 12:51 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8057922/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8057922
> 
> Introduce more sharing on LambdaForm level by rewriting most of the MH combinators using LambdaFormEditor.
> 
> The new code is guarded by USE_LAMBDA_FORM_EDITOR flag and turned off by default because it introduces significant peak performance regression on Octane benchmark. I'm working on the fix. Original implementation will be removed once performance degradation is fixed.
> 

Generally looks ok.


- LambdaFormEditor

 465         buf.endEdit();
 466         form = buf.lambdaForm();
 467         return putInCache(key, form);

A suggestion (feel free to ignore), that pattern repeats quite a bit. With some tweaks one could do:

  return putIntCache(but.endEdit()); // or buf.toLambdaForm()


- MethodHandles

2869     public static
2870     MethodHandle filterReturnValue(MethodHandle target, MethodHandle filter) {
2871         MethodType targetType = target.type();
2872         MethodType filterType = filter.type();
2873         filterReturnValueChecks(targetType, filterType);
2874         BoundMethodHandle result = target.rebind();
2875         BasicType rtype = BasicType.basicType(filterType.returnType());
2876         LambdaForm lform = result.editor().filterReturnForm(rtype, false);
2877         MethodType newType = targetType.changeReturnType(filterType.returnType());
2878         result = result.copyWithExtendL(newType, lform, filter);
2879         return result;
2880     }

Missing "if (USE_LAMBDA_FORM_EDITOR)".

Paul.


From vladimir.x.ivanov at oracle.com  Tue Sep  9 13:22:02 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 09 Sep 2014 17:22:02 +0400
Subject: [9] RFR (S): 8057657: Annotate LambdaForm parameters with types
In-Reply-To: <44983AE4-63D2-4991-89F6-9BEB55F857ED@oracle.com>
References: <54098C98.90009@oracle.com>
	<44983AE4-63D2-4991-89F6-9BEB55F857ED@oracle.com>
Message-ID: <540EFEFA.20507@oracle.com>

>> http://cr.openjdk.java.net/~vlivanov/8057657/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8057657
>>
>
> - BoundMethodHandle
>
>    57         assert(speciesData() == speciesData(form));
>
> I am missing some context here as to how that assert would pass for anything other than Species_L, namely for sub-classes of BoundMethodHandle generated by generateConcreteBMHClass how does that assert return true?
Good catch, Paul. This assert should go with new bind implementation. 
Moved the assert & speciesData(LambdaForm) from this change to 8057042 
[1]. Updated webrev in place.

>   153     public static SpeciesData speciesData(LambdaForm form) {
>
> Minor point. Could be private (since only used by the assert in the constructor), or package private if the intention is for it to be used by other j.l.i classes in the future.
Made the method package-private. It is also used in LambdaFormEditor ( 
see oldSpeciesData() [1]).

Best regards,
Vladimir Ivanov

[1] http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00/

>
> Paul.
>
>
>> Add ability to annotate LambdaForm parameters with their types.
>> Type info could be useful during LambdaForm compilation to produce better bytecode.
>>
>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, octane w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>>
>> Reviewed-by: vlivanov, ?
>> Contributed-by: john.r.rose at oracle.com
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


From vladimir.x.ivanov at oracle.com  Tue Sep  9 13:39:11 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 09 Sep 2014 17:39:11 +0400
Subject: [9] RFR (L): Improve LambdaForm sharing by using LambdaFormEditor
	more extensively
In-Reply-To: <198D8588-AEBB-406E-B69D-83A953456568@oracle.com>
References: <540EDBAE.3010300@oracle.com>
	<198D8588-AEBB-406E-B69D-83A953456568@oracle.com>
Message-ID: <540F02FF.7090503@oracle.com>

Paul, thanks for review!

Updated webrev in place.

>> http://cr.openjdk.java.net/~vlivanov/8057922/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8057922
>>
>> Introduce more sharing on LambdaForm level by rewriting most of the MH combinators using LambdaFormEditor.
>>
>> The new code is guarded by USE_LAMBDA_FORM_EDITOR flag and turned off by default because it introduces significant peak performance regression on Octane benchmark. I'm working on the fix. Original implementation will be removed once performance degradation is fixed.
>>
>
> Generally looks ok.
>
>
> - LambdaFormEditor
>
>   465         buf.endEdit();
>   466         form = buf.lambdaForm();
>   467         return putInCache(key, form);
>
> A suggestion (feel free to ignore), that pattern repeats quite a bit. With some tweaks one could do:
>
>    return putIntCache(but.endEdit()); // or buf.toLambdaForm()
I decided to make LambdaFormBuffer.lambdaForm() private and return 
constructed LambdaForm from LFB.endEdit(). I didn't combine endEdit() & 
putInCache() into a single statement, because I find current shape more 
convenient for debugging.

> - MethodHandles
>
> 2869     public static
> 2870     MethodHandle filterReturnValue(MethodHandle target, MethodHandle filter) {
> 2871         MethodType targetType = target.type();
> 2872         MethodType filterType = filter.type();
> 2873         filterReturnValueChecks(targetType, filterType);
> 2874         BoundMethodHandle result = target.rebind();
> 2875         BasicType rtype = BasicType.basicType(filterType.returnType());
> 2876         LambdaForm lform = result.editor().filterReturnForm(rtype, false);
> 2877         MethodType newType = targetType.changeReturnType(filterType.returnType());
> 2878         result = result.copyWithExtendL(newType, lform, filter);
> 2879         return result;
> 2880     }
>
> Missing "if (USE_LAMBDA_FORM_EDITOR)".
Fixed.

Best regards,
Vladimir Ivanov
>
> Paul.
>


From paul.sandoz at oracle.com  Tue Sep  9 13:51:50 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 9 Sep 2014 15:51:50 +0200
Subject: [9] RFR (L): Improve LambdaForm sharing by using LambdaFormEditor
	more extensively
In-Reply-To: <540F02FF.7090503@oracle.com>
References: <540EDBAE.3010300@oracle.com>
	<198D8588-AEBB-406E-B69D-83A953456568@oracle.com>
	<540F02FF.7090503@oracle.com>
Message-ID: <1FE4A72B-43DC-4B0C-B192-5451D789170F@oracle.com>


On Sep 9, 2014, at 3:39 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> Paul, thanks for review!
> 

+1

Paul.


> Updated webrev in place.
> 
>>> http://cr.openjdk.java.net/~vlivanov/8057922/webrev.00
>>> https://bugs.openjdk.java.net/browse/JDK-8057922
>>> 
>>> Introduce more sharing on LambdaForm level by rewriting most of the MH combinators using LambdaFormEditor.
>>> 
>>> The new code is guarded by USE_LAMBDA_FORM_EDITOR flag and turned off by default because it introduces significant peak performance regression on Octane benchmark. I'm working on the fix. Original implementation will be removed once performance degradation is fixed.
>>> 
>> 
>> Generally looks ok.
>> 
>> 
>> - LambdaFormEditor
>> 
>>  465         buf.endEdit();
>>  466         form = buf.lambdaForm();
>>  467         return putInCache(key, form);
>> 
>> A suggestion (feel free to ignore), that pattern repeats quite a bit. With some tweaks one could do:
>> 
>>   return putIntCache(but.endEdit()); // or buf.toLambdaForm()
> I decided to make LambdaFormBuffer.lambdaForm() private and return constructed LambdaForm from LFB.endEdit(). I didn't combine endEdit() & putInCache() into a single statement, because I find current shape more convenient for debugging.
> 
>> - MethodHandles
>> 
>> 2869     public static
>> 2870     MethodHandle filterReturnValue(MethodHandle target, MethodHandle filter) {
>> 2871         MethodType targetType = target.type();
>> 2872         MethodType filterType = filter.type();
>> 2873         filterReturnValueChecks(targetType, filterType);
>> 2874         BoundMethodHandle result = target.rebind();
>> 2875         BasicType rtype = BasicType.basicType(filterType.returnType());
>> 2876         LambdaForm lform = result.editor().filterReturnForm(rtype, false);
>> 2877         MethodType newType = targetType.changeReturnType(filterType.returnType());
>> 2878         result = result.copyWithExtendL(newType, lform, filter);
>> 2879         return result;
>> 2880     }
>> 
>> Missing "if (USE_LAMBDA_FORM_EDITOR)".
> Fixed.
> 
> Best regards,
> Vladimir Ivanov
>> 
>> Paul.
>> 



From paul.sandoz at oracle.com  Tue Sep  9 14:13:15 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 9 Sep 2014 16:13:15 +0200
Subject: [9] RFR (S): 8057657: Annotate LambdaForm parameters with types
In-Reply-To: <540EFEFA.20507@oracle.com>
References: <54098C98.90009@oracle.com>
	<44983AE4-63D2-4991-89F6-9BEB55F857ED@oracle.com>
	<540EFEFA.20507@oracle.com>
Message-ID: <5267CC1B-2110-4EB9-9A10-50C12208AA7A@oracle.com>

+1 to both.

On Sep 9, 2014, at 3:22 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

>>> http://cr.openjdk.java.net/~vlivanov/8057657/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8057657
>>> 
>> 
>> - BoundMethodHandle
>> 
>>   57         assert(speciesData() == speciesData(form));
>> 
>> I am missing some context here as to how that assert would pass for anything other than Species_L, namely for sub-classes of BoundMethodHandle generated by generateConcreteBMHClass how does that assert return true?
> Good catch, Paul. This assert should go with new bind implementation. Moved the assert & speciesData(LambdaForm) from this change to 8057042 [1]. Updated webrev in place.
> 

Ok, i see how it wires up now, plus i suspected it might be some patch cross talk.

Paul.

>>  153     public static SpeciesData speciesData(LambdaForm form) {
>> 
>> Minor point. Could be private (since only used by the assert in the constructor), or package private if the intention is for it to be used by other j.l.i classes in the future.
> Made the method package-private. It is also used in LambdaFormEditor ( see oldSpeciesData() [1]).
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00/



From sean.coffey at oracle.com  Tue Sep  9 17:14:15 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Tue, 09 Sep 2014 18:14:15 +0100
Subject: RFR : 8044725 :Bug in zlib 1.2.5 prevents inflation of some
	gzipped files (zlib 1.2.8 port)
In-Reply-To: <540DE88F.5070606@oracle.com>
References: <5406E7F6.4010904@oracle.com> <540DE88F.5070606@oracle.com>
Message-ID: <540F3567.30908@oracle.com>

Thanks for review Sherman. I'll go ahead and push current changes. Not 
sure what to do with the zlib launcher reference. Most likely not needed 
but we can rip that code out under a new bug ID if necessary.

regards,
Sean.

On 08/09/2014 18:34, Xueming Shen wrote:
> On 09/03/2014 03:05 AM, Se?n Coffey wrote:
>> I'd like to port the zlib v1.2.8 libraries to JDK 7u. Currently, 7u 
>> uses zlib v1.2.3 libraries. 8u20 was recently upgraded to 1.2.8. zlib 
>> fixes since 1.2.3 can be found at 
>> http://cr.openjdk.java.net/~coffeys/webrev.8044725.7u/webrev/raw_files/new/src/share/native/java/util/zip/zlib-1.2.8/ChangeLog
>>
>> While porting, I noticed that the Program.gmk had a bad reference in 
>> it to zlib 1.1.3 (JDK6  version) - I've corrected that to 1.2.8 for 
>> now but question if the extra INCLUDE directive is even needed.
>>
>> bug report : https://bugs.openjdk.java.net/browse/JDK-8044725
>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8044725.7u/webrev/
>>
>> regards,
>> Sean.
>>
>>
> looks fine.
>
> I'm not sure about the program.gmk...in the past the other two places 
> that need the zlib
> src reference are the launcher and the splash code.
>
> -sherman



From olivier.lagneau at oracle.com  Tue Sep  9 20:44:36 2014
From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com)
Date: Tue, 09 Sep 2014 22:44:36 +0200
Subject: [9] RFR (S) : JDK-8039915 NumberFormat.format() does not consider
	required no. of fraction digits properly
Message-ID: <540F66B4.1080400@oracle.com>

Please review this fix in for wrong rounding-mode mode behavior of 
NumberFormat.format(double) in HALF_UP case.

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

webrev: http://cr.openjdk.java.net/~olagneau/8039915/webrev.00 
<http://cr.openjdk.java.net/%7Eolagneau/8039915/webrev.00>

Bug came from a mix of a '5' and 'greater than 5' last digit, when this 
digit was the last one.

Fix consists in properly separating the two cases and cleanly test all 
possible cases (see JDK-8039915 comments) for the HALF_UP rounding-mode.

TieRoundingTest test has been extended with a few cases to check such 
cases (last digit at the rounding position and != '5')

testing: jtreg, jck8, jprt

Best regards,
Olivier Lagneau



From otaviojava at java.net  Wed Sep 10 01:10:22 2014
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Tue, 9 Sep 2014 22:10:22 -0300
Subject: Replace uses of StringBuffer with StringBuilder[JAXP]
Message-ID: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>

Similar to: https://bugs.openjdk.java.net/browse/JDK-8041679

But in JAXP project:

https://dl.dropboxusercontent.com/u/16109193/open_jdk/jax%E1%B9%95/string_buffer_2_string_builder.zip

-- 

Ot?vio Gon?alves de Santana

blog:     http://otaviosantana.blogspot.com.br/
twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
55 (11) 98255-3513
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 638_updated.patch
Type: text/x-patch
Size: 178158 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20140909/74c64ad9/638_updated.patch>

From daniel.fuchs at oracle.com  Wed Sep 10 09:49:51 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 10 Sep 2014 11:49:51 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed to
	listen for LogManager configuration changes
Message-ID: <54101EBF.7000003@oracle.com>

Hi,

Please find below a proposed patch for

8043306 - Provide a replacement for the API that allowed to listen
           for LogManager configuration changes
https://bugs.openjdk.java.net/browse/JDK-8043306

Proposed Patch:
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/

JDK-8029805 Removed LogManager addPropertyChangeListener
and removePropertyChangeListener methods which were
deprecated. These methods were deprecated in Java SE 8 and
flagged  for removal because they were problematic for
modularity efforts.
The idea was that an application needing to be informed of
configuration changes could subclass LogManager and override
readConfiguration.

The proposed patch adds to new methods to LogManager:

public void 
LogManager.addConfigurationListener(LogManager.ConfigurationListener 
listener);
public void 
LogManager.removeConfigurationListener(LogManager.ConfigurationListener 
listener);

These methods can be used by those applications for which subclassing
LogManager would be too impractical.

best regards,

-- daniel


From claes.redestad at oracle.com  Wed Sep 10 10:11:55 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 10 Sep 2014 12:11:55 +0200
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
Message-ID: <541023EB.10501@oracle.com>

Hi,

please review this simple patch to avoid raising PrivilegedActionExceptions
when failing to find a class in URLClassLoader.

  bug: https://bugs.openjdk.java.net/browse/JDK-8057936
  webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/

/Claes


From aleksey.shipilev at oracle.com  Wed Sep 10 10:30:53 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 10 Sep 2014 14:30:53 +0400
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <541023EB.10501@oracle.com>
References: <541023EB.10501@oracle.com>
Message-ID: <5410285D.8080706@oracle.com>

On 09/10/2014 02:11 PM, Claes Redestad wrote:
> please review this simple patch to avoid raising PrivilegedActionExceptions
> when failing to find a class in URLClassLoader.
> 
>  bug: https://bugs.openjdk.java.net/browse/JDK-8057936
>  webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/

Looks good. Any performance data for this abbreviated patch? I see only
the improvement for the stackless version of it.

Thanks,
-Aleksey.




From Alan.Bateman at oracle.com  Wed Sep 10 10:49:49 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 10 Sep 2014 11:49:49 +0100
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <541023EB.10501@oracle.com>
References: <541023EB.10501@oracle.com>
Message-ID: <54102CCD.6050401@oracle.com>

On 10/09/2014 11:11, Claes Redestad wrote:
> Hi,
>
> please review this simple patch to avoid raising 
> PrivilegedActionExceptions
> when failing to find a class in URLClassLoader.
>
>  bug: https://bugs.openjdk.java.net/browse/JDK-8057936
>  webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/
I think this looks okay. I assume FoundClassResult doesn't strictly need 
to encapsulate the class name.

-Alan.


From ivan.gerasimov at oracle.com  Wed Sep 10 10:55:35 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 10 Sep 2014 14:55:35 +0400
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <541023EB.10501@oracle.com>
References: <541023EB.10501@oracle.com>
Message-ID: <54102E27.3040508@oracle.com>


If a lambda were used instead of an anonymous class, it would save us 
one line of code :-)

Sincerely yours,
Ivan

On 10.09.2014 14:11, Claes Redestad wrote:
> Hi,
>
> please review this simple patch to avoid raising 
> PrivilegedActionExceptions
> when failing to find a class in URLClassLoader.
>
>  bug: https://bugs.openjdk.java.net/browse/JDK-8057936
>  webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/
> /Claes
>
>



From aleksey.shipilev at oracle.com  Wed Sep 10 10:58:57 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 10 Sep 2014 14:58:57 +0400
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <54102E27.3040508@oracle.com>
References: <541023EB.10501@oracle.com> <54102E27.3040508@oracle.com>
Message-ID: <54102EF1.3000709@oracle.com>

I think lambda would not help much since target type is ambiguous
(PrivilegedAction vs PrivilegedExceptionAction)?

-Aleksey.

On 09/10/2014 02:55 PM, Ivan Gerasimov wrote:
> 
> If a lambda were used instead of an anonymous class, it would save us
> one line of code :-)
> 
> Sincerely yours,
> Ivan
> 
> On 10.09.2014 14:11, Claes Redestad wrote:
>> Hi,
>>
>> please review this simple patch to avoid raising
>> PrivilegedActionExceptions
>> when failing to find a class in URLClassLoader.
>>
>>  bug: https://bugs.openjdk.java.net/browse/JDK-8057936
>>  webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/
>> /Claes
>>
>>
> 




From ivan.gerasimov at oracle.com  Wed Sep 10 11:02:19 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 10 Sep 2014 15:02:19 +0400
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <54102EF1.3000709@oracle.com>
References: <541023EB.10501@oracle.com> <54102E27.3040508@oracle.com>
	<54102EF1.3000709@oracle.com>
Message-ID: <54102FBB.70501@oracle.com>


On 10.09.2014 14:58, Aleksey Shipilev wrote:
> I think lambda would not help much since target type is ambiguous
> (PrivilegedAction vs PrivilegedExceptionAction)?

It could be explicitly cast as (PrivilegedAction<FindClassResult>) () -> 
{...}
Would still be on the same line :-)

Ivan

> -Aleksey.
>
> On 09/10/2014 02:55 PM, Ivan Gerasimov wrote:
>> If a lambda were used instead of an anonymous class, it would save us
>> one line of code :-)
>>
>> Sincerely yours,
>> Ivan
>>
>> On 10.09.2014 14:11, Claes Redestad wrote:
>>> Hi,
>>>
>>> please review this simple patch to avoid raising
>>> PrivilegedActionExceptions
>>> when failing to find a class in URLClassLoader.
>>>
>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8057936
>>>   webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/
>>> /Claes
>>>
>>>
>



From Alan.Bateman at oracle.com  Wed Sep 10 11:07:20 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 10 Sep 2014 12:07:20 +0100
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <54102E27.3040508@oracle.com>
References: <541023EB.10501@oracle.com> <54102E27.3040508@oracle.com>
Message-ID: <541030E8.8070100@oracle.com>

On 10/09/2014 11:55, Ivan Gerasimov wrote:
>
> If a lambda were used instead of an anonymous class, it would save us 
> one line of code :-)
>
I don't know if a lambda would help here but I think changing would 
require a lot of testing to make sure that there aren't any side 
effects. We've had a couple of cases where code using lambdas early in 
the startup has lead to recursive initialization issues (due to various 
code paths in the lambda meta factory code). In this case, the system 
and extensions class loaders are URLClassLoader so this code is likely 
to be executed early. So if the intention is to push this to jdk8u-dev 
(which I think it is) then we would just need to make sure that it is 
well tested.

-Alan.



From michael.x.mcmahon at oracle.com  Wed Sep 10 11:21:53 2014
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 10 Sep 2014 12:21:53 +0100
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <54102E27.3040508@oracle.com>
References: <541023EB.10501@oracle.com> <54102E27.3040508@oracle.com>
Message-ID: <54103451.5020509@oracle.com>

or how about just returning a null Class<?> from the privileged block
instead of the new result type only in the case where 
URLClassPath.getResource() returns null?
That's the main "normal" case where the resource doesn't exist, I think.

If defineClass() throws an IOException, then that is more likely to be a 
"genuine" exception

- Michael

diff --git a/src/java.base/share/classes/java/net/URLClassLoader.java 
b/src/java.base/share/classes/java/net/URLClassLoader.java
--- a/src/java.base/share/classes/java/net/URLClassLoader.java
+++ b/src/java.base/share/classes/java/net/URLClassLoader.java
@@ -356,8 +356,9 @@
      protected Class<?> findClass(final String name)
           throws ClassNotFoundException
      {
+    final Class<?> result;
          try {
-            return AccessController.doPrivileged(
+            result = AccessController.doPrivileged(
                  new PrivilegedExceptionAction<Class<?>>() {
                      public Class<?> run() throws ClassNotFoundException {
                          String path = name.replace('.', 
'/').concat(".class");
@@ -369,13 +370,17 @@
                                  throw new ClassNotFoundException(name, e);
                              }
                          } else {
-                            throw new ClassNotFoundException(name);
+                return null;
                          }
                      }
                  }, acc);
          } catch (java.security.PrivilegedActionException pae) {
              throw (ClassNotFoundException) pae.getException();
          }
+    if (result == null) {
+        throw new ClassNotFoundException(name);
+    }
+    return result;
      }

      /*

On 10/09/14 11:55, Ivan Gerasimov wrote:
>
> If a lambda were used instead of an anonymous class, it would save us 
> one line of code :-)
>
> Sincerely yours,
> Ivan
>
> On 10.09.2014 14:11, Claes Redestad wrote:
>> Hi,
>>
>> please review this simple patch to avoid raising 
>> PrivilegedActionExceptions
>> when failing to find a class in URLClassLoader.
>>
>>  bug: https://bugs.openjdk.java.net/browse/JDK-8057936
>>  webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/
>> /Claes
>>
>>
>



From Alan.Bateman at oracle.com  Wed Sep 10 11:25:48 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 10 Sep 2014 12:25:48 +0100
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <54101EBF.7000003@oracle.com>
References: <54101EBF.7000003@oracle.com>
Message-ID: <5410353C.3070705@oracle.com>

On 10/09/2014 10:49, Daniel Fuchs wrote:
> Hi,
>
> Please find below a proposed patch for
>
> 8043306 - Provide a replacement for the API that allowed to listen
>           for LogManager configuration changes
> https://bugs.openjdk.java.net/browse/JDK-8043306
>
> Proposed Patch:
> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
>
It would be nice if ConfigurationListener could be an interface. I 
realize this might mean looking again at the security concerns in this 
area again to see if we could get away without requiring a construction 
time permission check. Clearly if it could be an interface then it begs 
the question as to why it's just not a Runnable but that probably means 
yet more effort to figure out the right security and whether the access 
control context should be recorded when registering.

Assuming ConfigurationListener remains as an abstract class then the 
no-arg constructor will need a one-line javadoc comment.

A small suggestion for addConfigurationListener to return LogManager to 
facilitate method invocation chaining when configuring the LogManager. 
It could be done for remove too but that is probably less interesting.

Another comment on addConfigurationListener is that about the wording 
"re-read and the configuration is changed". I think the configuration 
listeners are invoked when ever the configuration is read even if there 
aren't any changes.

The javadoc links in the readConfiguration methods make the line length 
a bit inconsistent with the existing javadoc, maybe the package name 
could be just dropped from the links or the link moved to the next line.

-Alan.




From daniel.fuchs at oracle.com  Wed Sep 10 11:42:20 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 10 Sep 2014 13:42:20 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5410353C.3070705@oracle.com>
References: <54101EBF.7000003@oracle.com> <5410353C.3070705@oracle.com>
Message-ID: <5410391C.8050406@oracle.com>

On 9/10/14 1:25 PM, Alan Bateman wrote:
> On 10/09/2014 10:49, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a proposed patch for
>>
>> 8043306 - Provide a replacement for the API that allowed to listen
>>           for LogManager configuration changes
>> https://bugs.openjdk.java.net/browse/JDK-8043306
>>
>> Proposed Patch:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
>>
> It would be nice if ConfigurationListener could be an interface. I
> realize this might mean looking again at the security concerns in this
> area again to see if we could get away without requiring a construction
> time permission check. Clearly if it could be an interface then it begs
> the question as to why it's just not a Runnable but that probably means
> yet more effort to figure out the right security and whether the access
> control context should be recorded when registering.

One nice thing about ConfigurationListener being an abstract class is
that I don't need to invent an 'IdentityCopyOnWriteArrayList' which
is what I would prefer to use if equals() could be overriden by
implementations.

Also I like it that you need to have the LoggingPermission("Control")
to subclass ConfigurationListener.

In practice - I believe that there aren't that many application
which need this functionality - and I also believe that for those
that need it then there will be a single ConfigurationListener
that will be registered only once, and therefore having an
abstract class for ConfigurationListener shouldn't be that much of
a hassle for them.

> Assuming ConfigurationListener remains as an abstract class then the
> no-arg constructor will need a one-line javadoc comment.

Oh - right - thanks for catching that.


> A small suggestion for addConfigurationListener to return LogManager to
> facilitate method invocation chaining when configuring the LogManager.
> It could be done for remove too but that is probably less interesting.

Good suggestion.

> Another comment on addConfigurationListener is that about the wording
> "re-read and the configuration is changed". I think the configuration
> listeners are invoked when ever the configuration is read even if there
> aren't any changes.

Right. Although I believe it would be difficult (though maybe not
impossible) to manage to register a configuration listener before
the configuration is read for the first time ;-)

> The javadoc links in the readConfiguration methods make the line length
> a bit inconsistent with the existing javadoc, maybe the package name
> could be just dropped from the links or the link moved to the next line.

OK - I'll see what I can do.

Thanks Alan!

-- daniel

>
> -Alan.
>
>



From peter.levart at gmail.com  Wed Sep 10 11:57:36 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 10 Sep 2014 13:57:36 +0200
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <540716E4.5080208@oracle.com>
References: <5405CCDB.6040706@oracle.com>
	<5405CD4E.4070409@oracle.com>	<5406FA63.3050602@gmail.com>
	<540716E4.5080208@oracle.com>
Message-ID: <54103CB0.50504@gmail.com>

On 09/03/2014 03:25 PM, Vladimir Ivanov wrote:
> Peter,
>
> Thanks for the feedback.
>
> > In LambdaFormEditor, where Transform[] is promoted into
>> ConcurrentHashMap<Transform, Transform>:
>>
>>   339                     ConcurrentHashMap<Transform, Transform> m =
>> new ConcurrentHashMap<>(MAX_CACHE_ARRAY_SIZE * 2);
>>   340                     for (Transform k : ta) {
>>   341                         if (k != null)  continue;
>>   342                         m.put(k, k);
>>   343                     }
>>   344                     lambdaForm.transformCache = m;
>>   345                     // The second iteration will update for this
>> query, concurrently.
>>   346                     continue;
>>
>>
>> I think line 341 is wrong. It should be:
>>
>>      if (k == null) break;
>>
>> shouldn't it?
> Good catch! Fixed.
>

I think it can even be removed or replaced with something like:

     assert k != null;

...since null entry in array is not possible in this situation - 
promotion to CHM happens only when array is full.


Regards, Peter

> Best regards,
> Vladimir Ivanov
>>
>>
>>
>> Regards, Peter
>>
>>
>>>
>>> On 9/2/14, 5:57 PM, Vladimir Ivanov wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8057042
>>>>
>>>> LambdaFormEditor provides an API to transform LambdaForms. Deriving 
>>>> new
>>>> LambdaForms from a base one allows to cache and reuse results of
>>>> repeated transformations.
>>>>
>>>> BMH binding is rewritten to use LambdaFormEditor.
>>>>
>>>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, 
>>>> octane w/
>>>> "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>>>>
>>>> Reviewed-by: vlivanov, ?
>>>> Contributed-by: john.r.rose at oracle.com
>>>>
>>>> Thanks!
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From claes.redestad at oracle.com  Wed Sep 10 11:53:44 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 10 Sep 2014 13:53:44 +0200
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <54103451.5020509@oracle.com>
References: <541023EB.10501@oracle.com> <54102E27.3040508@oracle.com>
	<54103451.5020509@oracle.com>
Message-ID: <54103BC8.1020409@oracle.com>

Yes, this saves creating the type and wrapper object altogether, while 
testing suggest it's only the
getResource() == null cases wecommonly seehurting startup in our tests. 
I'd say let's go with your patch.

New webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.4/

Benchmark referred to in bug (java -jar benchmarks.jar -f 4 -wi 5 -i 10 
-p file=classes.jar)show
similar benefits (somewhere in the 4-12% range, statistically):

Benchmark                                (file)  Mode Samples  Score  
Score error  Units
baseline:
o.o.ClassLoaderBenchmark.loadAll    classes.jar  avgt       40 
0.679        0.037   s/op
patched:
o.o.ClassLoaderBenchmark.loadAll    classes.jar avgt       40  
0.598        0.007   s/op

/Claes

ps. I think lambdas give little or no benefit here, and as Alan points 
out it could lead to tricky
classloading bugs.

On 09/10/2014 01:21 PM, Michael McMahon wrote:
> or how about just returning a null Class<?> from the privileged block
> instead of the new result type only in the case where 
> URLClassPath.getResource() returns null?
> That's the main "normal" case where the resource doesn't exist, I think.
>
> If defineClass() throws an IOException, then that is more likely to be 
> a "genuine" exception
>
> - Michael
>
> diff --git a/src/java.base/share/classes/java/net/URLClassLoader.java 
> b/src/java.base/share/classes/java/net/URLClassLoader.java
> --- a/src/java.base/share/classes/java/net/URLClassLoader.java
> +++ b/src/java.base/share/classes/java/net/URLClassLoader.java
> @@ -356,8 +356,9 @@
>      protected Class<?> findClass(final String name)
>           throws ClassNotFoundException
>      {
> +    final Class<?> result;
>          try {
> -            return AccessController.doPrivileged(
> +            result = AccessController.doPrivileged(
>                  new PrivilegedExceptionAction<Class<?>>() {
>                      public Class<?> run() throws 
> ClassNotFoundException {
>                          String path = name.replace('.', 
> '/').concat(".class");
> @@ -369,13 +370,17 @@
>                                  throw new 
> ClassNotFoundException(name, e);
>                              }
>                          } else {
> -                            throw new ClassNotFoundException(name);
> +                return null;
>                          }
>                      }
>                  }, acc);
>          } catch (java.security.PrivilegedActionException pae) {
>              throw (ClassNotFoundException) pae.getException();
>          }
> +    if (result == null) {
> +        throw new ClassNotFoundException(name);
> +    }
> +    return result;
>      }
>
>      /*
>
> On 10/09/14 11:55, Ivan Gerasimov wrote:
>>
>> If a lambda were used instead of an anonymous class, it would save us 
>> one line of code :-)
>>
>> Sincerely yours,
>> Ivan
>>
>> On 10.09.2014 14:11, Claes Redestad wrote:
>>> Hi,
>>>
>>> please review this simple patch to avoid raising 
>>> PrivilegedActionExceptions
>>> when failing to find a class in URLClassLoader.
>>>
>>>  bug: https://bugs.openjdk.java.net/browse/JDK-8057936
>>>  webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/
>>> /Claes
>>>
>>>
>>
>



From daniel.fuchs at oracle.com  Wed Sep 10 11:58:31 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 10 Sep 2014 13:58:31 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5410391C.8050406@oracle.com>
References: <54101EBF.7000003@oracle.com> <5410353C.3070705@oracle.com>
	<5410391C.8050406@oracle.com>
Message-ID: <54103CE7.9060202@oracle.com>

New webrev:

http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.01

-- daniel

On 9/10/14 1:42 PM, Daniel Fuchs wrote:
> On 9/10/14 1:25 PM, Alan Bateman wrote:
>> On 10/09/2014 10:49, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a proposed patch for
>>>
>>> 8043306 - Provide a replacement for the API that allowed to listen
>>>           for LogManager configuration changes
>>> https://bugs.openjdk.java.net/browse/JDK-8043306
>>>
>>> Proposed Patch:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
>>>
>> It would be nice if ConfigurationListener could be an interface. I
>> realize this might mean looking again at the security concerns in this
>> area again to see if we could get away without requiring a construction
>> time permission check. Clearly if it could be an interface then it begs
>> the question as to why it's just not a Runnable but that probably means
>> yet more effort to figure out the right security and whether the access
>> control context should be recorded when registering.
>
> One nice thing about ConfigurationListener being an abstract class is
> that I don't need to invent an 'IdentityCopyOnWriteArrayList' which
> is what I would prefer to use if equals() could be overriden by
> implementations.
>
> Also I like it that you need to have the LoggingPermission("Control")
> to subclass ConfigurationListener.
>
> In practice - I believe that there aren't that many application
> which need this functionality - and I also believe that for those
> that need it then there will be a single ConfigurationListener
> that will be registered only once, and therefore having an
> abstract class for ConfigurationListener shouldn't be that much of
> a hassle for them.
>
>> Assuming ConfigurationListener remains as an abstract class then the
>> no-arg constructor will need a one-line javadoc comment.
>
> Oh - right - thanks for catching that.
>
>
>> A small suggestion for addConfigurationListener to return LogManager to
>> facilitate method invocation chaining when configuring the LogManager.
>> It could be done for remove too but that is probably less interesting.
>
> Good suggestion.
>
>> Another comment on addConfigurationListener is that about the wording
>> "re-read and the configuration is changed". I think the configuration
>> listeners are invoked when ever the configuration is read even if there
>> aren't any changes.
>
> Right. Although I believe it would be difficult (though maybe not
> impossible) to manage to register a configuration listener before
> the configuration is read for the first time ;-)
>
>> The javadoc links in the readConfiguration methods make the line length
>> a bit inconsistent with the existing javadoc, maybe the package name
>> could be just dropped from the links or the link moved to the next line.
>
> OK - I'll see what I can do.
>
> Thanks Alan!
>
> -- daniel
>
>>
>> -Alan.
>>
>>
>



From claes.redestad at oracle.com  Wed Sep 10 11:55:09 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 10 Sep 2014 13:55:09 +0200
Subject: [9] RFR 8055251: Re-examine Integer.parseInt and Long.parseLong
	methods
In-Reply-To: <5409BF6B.6010609@oracle.com>
References: <5409B4A5.20604@oracle.com> <5409BF6B.6010609@oracle.com>
Message-ID: <54103C1D.7040401@oracle.com>

On 09/05/2014 03:49 PM, Alan Bateman wrote:
> On 05/09/2014 14:03, Claes Redestad wrote:
>> Hi,
>>
>> I'm requesting reviews and a sponsor for these changes to the recently
>> added parse methods (8041972), suggested during discussions on net-dev:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8055251
>> webrev: http://cr.openjdk.java.net/~redestad/8055251/webrev.1/
> Thanks for doing this, I think the API is much better now and much 
> less error prone.
>
> The drive-by fix to the index in the NumberFormatException also looks 
> good.

Thanks!

/Claes

>
> -Alan.



From paul.sandoz at oracle.com  Wed Sep 10 12:25:22 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 10 Sep 2014 14:25:22 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed to
	listen for LogManager configuration changes
In-Reply-To: <5410391C.8050406@oracle.com>
References: <54101EBF.7000003@oracle.com> <5410353C.3070705@oracle.com>
	<5410391C.8050406@oracle.com>
Message-ID: <E76F3186-A8A7-45D0-8CF8-944F7441A9E0@oracle.com>


On Sep 10, 2014, at 1:42 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> On 9/10/14 1:25 PM, Alan Bateman wrote:
>> On 10/09/2014 10:49, Daniel Fuchs wrote:
>>> Hi,
>>> 
>>> Please find below a proposed patch for
>>> 
>>> 8043306 - Provide a replacement for the API that allowed to listen
>>>          for LogManager configuration changes
>>> https://bugs.openjdk.java.net/browse/JDK-8043306
>>> 
>>> Proposed Patch:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
>>> 
>> It would be nice if ConfigurationListener could be an interface. I
>> realize this might mean looking again at the security concerns in this
>> area again to see if we could get away without requiring a construction
>> time permission check. Clearly if it could be an interface then it begs
>> the question as to why it's just not a Runnable but that probably means
>> yet more effort to figure out the right security and whether the access
>> control context should be recorded when registering.
> 
> One nice thing about ConfigurationListener being an abstract class is
> that I don't need to invent an 'IdentityCopyOnWriteArrayList' which
> is what I would prefer to use if equals() could be overriden by
> implementations.
> 

FWIW i think you could do:

  removeIf(e -> listener == e);

Idiomatically callback methods are often prefixed with on:

  onConfigurationLoaded.

My inclination is this should be an interface if at all possible. The permission check on construction seems odd to me but i don't understand the security requirements here. It's very tempting to suggest not defining any new interface and reuse Runnable, since as you indicate below this is not expected to be common functionality and there is likely to be a single instance registered. 

Paul.


> Also I like it that you need to have the LoggingPermission("Control")
> to subclass ConfigurationListener.
> 
> In practice - I believe that there aren't that many application
> which need this functionality - and I also believe that for those
> that need it then there will be a single ConfigurationListener
> that will be registered only once, and therefore having an
> abstract class for ConfigurationListener shouldn't be that much of
> a hassle for them.
> 




From david.holmes at oracle.com  Wed Sep 10 12:30:01 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Sep 2014 22:30:01 +1000
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <541023EB.10501@oracle.com>
References: <541023EB.10501@oracle.com>
Message-ID: <54104449.1080602@oracle.com>

Hi Claes,

On 10/09/2014 8:11 PM, Claes Redestad wrote:
> Hi,
>
> please review this simple patch to avoid raising PrivilegedActionExceptions
> when failing to find a class in URLClassLoader.
>
>   bug: https://bugs.openjdk.java.net/browse/JDK-8057936
>   webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/

I read the bug report and looked at the patch. I'm all for reducing the 
exception overhead, but why not just return the exception object 
directly and avoid the need to create a wrapper? Return object and check 
for a Class or Throwable - and rethrow the Throwable.

David




> /Claes


From aleksey.shipilev at oracle.com  Wed Sep 10 12:35:01 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 10 Sep 2014 16:35:01 +0400
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <54103BC8.1020409@oracle.com>
References: <541023EB.10501@oracle.com>
	<54102E27.3040508@oracle.com>	<54103451.5020509@oracle.com>
	<54103BC8.1020409@oracle.com>
Message-ID: <54104575.4050405@oracle.com>

On 09/10/2014 03:53 PM, Claes Redestad wrote:
> Yes, this saves creating the type and wrapper object altogether,
> while testing suggest it's only the getResource() == null cases we
> commonly see hurting startup in our tests. I'd say let's go with your
> patch.

> New webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.4/

+1. This is much cleaner.

Thanks,
-Aleksey.




From david.holmes at oracle.com  Wed Sep 10 12:39:49 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Sep 2014 22:39:49 +1000
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <54104449.1080602@oracle.com>
References: <541023EB.10501@oracle.com> <54104449.1080602@oracle.com>
Message-ID: <54104695.8060202@oracle.com>

On 10/09/2014 10:30 PM, David Holmes wrote:
> Hi Claes,
>
> On 10/09/2014 8:11 PM, Claes Redestad wrote:
>> Hi,
>>
>> please review this simple patch to avoid raising
>> PrivilegedActionExceptions
>> when failing to find a class in URLClassLoader.
>>
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8057936
>>   webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/
>
> I read the bug report and looked at the patch. I'm all for reducing the
> exception overhead, but why not just return the exception object
> directly and avoid the need to create a wrapper? Return object and check
> for a Class or Throwable - and rethrow the Throwable.

Sorry email lag - just saw the later version. If the null resource case 
buys you enough then fine. Otherwise next step is to return the 
Throwables :)

David

> David
>
>
>
>
>> /Claes


From forax at univ-mlv.fr  Wed Sep 10 12:41:34 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 10 Sep 2014 14:41:34 +0200
Subject: [9] RFR 8055251: Re-examine Integer.parseInt and Long.parseLong
	methods
In-Reply-To: <54103C1D.7040401@oracle.com>
References: <5409B4A5.20604@oracle.com> <5409BF6B.6010609@oracle.com>
	<54103C1D.7040401@oracle.com>
Message-ID: <541046FE.2020508@univ-mlv.fr>


On 09/10/2014 01:55 PM, Claes Redestad wrote:
> On 09/05/2014 03:49 PM, Alan Bateman wrote:
>> On 05/09/2014 14:03, Claes Redestad wrote:
>>> Hi,
>>>
>>> I'm requesting reviews and a sponsor for these changes to the recently
>>> added parse methods (8041972), suggested during discussions on net-dev:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8055251
>>> webrev: http://cr.openjdk.java.net/~redestad/8055251/webrev.1/
>> Thanks for doing this, I think the API is much better now and much 
>> less error prone.
>>
>> The drive-by fix to the index in the NumberFormatException also looks 
>> good.
>
> Thanks!
>
> /Claes

Looks good to me,
nitpicking, line 672 of Long.java, I think it's better to use a for 
instead of a while,
the incrementation will be more obvious.

Also, but it's not fully related to this patch, the first line of 
parseInt/parseLong(CharSequence, int, int, int)
is uncommon,
   s = Objects.requireNonNull(s);
can be simplified to
   Objects.requireNonNull(s);

regards,
R?mi

>
>>
>> -Alan.
>



From daniel.fuchs at oracle.com  Wed Sep 10 13:02:40 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 10 Sep 2014 15:02:40 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <E76F3186-A8A7-45D0-8CF8-944F7441A9E0@oracle.com>
References: <54101EBF.7000003@oracle.com>
	<5410353C.3070705@oracle.com>	<5410391C.8050406@oracle.com>
	<E76F3186-A8A7-45D0-8CF8-944F7441A9E0@oracle.com>
Message-ID: <54104BF0.2020303@oracle.com>

On 9/10/14 2:25 PM, Paul Sandoz wrote:
>
> FWIW i think you could do:
>
>    removeIf(e -> listener == e);

Ah ah. Interesting!

> Idiomatically callback methods are often prefixed with on:
>
>    onConfigurationLoaded.

Thanks! Exactly what I was looking for :-)
I'll wait for more comments before updating the webrev, but
I like your suggestion. I should have remembered the idiom - it's
been too long since I have code my last 'onMouseClicked()' :-)

> My inclination is this should be an interface if at all possible. The permission check on construction seems odd to me but i don't understand the security requirements here. It's very tempting to suggest not defining any new interface and reuse Runnable, since as you indicate below this is not expected to be common functionality and there is likely to be a single instance registered.

I'd actually prefer not to use Runnable here if it could
be avoided...

-- daniel

>
> Paul.
>
>
>> Also I like it that you need to have the LoggingPermission("Control")
>> to subclass ConfigurationListener.
>>
>> In practice - I believe that there aren't that many application
>> which need this functionality - and I also believe that for those
>> that need it then there will be a single ConfigurationListener
>> that will be registered only once, and therefore having an
>> abstract class for ConfigurationListener shouldn't be that much of
>> a hassle for them.
>>
>
>



From vladimir.x.ivanov at oracle.com  Wed Sep 10 13:31:55 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 10 Sep 2014 17:31:55 +0400
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <54103CB0.50504@gmail.com>
References: <5405CCDB.6040706@oracle.com>
	<5405CD4E.4070409@oracle.com>	<5406FA63.3050602@gmail.com>
	<540716E4.5080208@oracle.com> <54103CB0.50504@gmail.com>
Message-ID: <541052CB.5030402@oracle.com>

Peter,

>>> I think line 341 is wrong. It should be:
>>>
>>>      if (k == null) break;
>>>
>>> shouldn't it?
>> Good catch! Fixed.
>>
>
> I think it can even be removed or replaced with something like:
>
>      assert k != null;
>
> ...since null entry in array is not possible in this situation -
> promotion to CHM happens only when array is full.
Good point. I've removed the check altogether.
CHM.put() throws NPE for null key/value anyway.

Updated webrev inplace:
http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00/

Best regards,
Vladimir Ivanov


From jason_mehrens at hotmail.com  Wed Sep 10 14:28:49 2014
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Wed, 10 Sep 2014 09:28:49 -0500
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <54101EBF.7000003@oracle.com>
References: <54101EBF.7000003@oracle.com>
Message-ID: <BLU175-W47B685942A91FF963A848083CF0@phx.gbl>

Daniel


I think you should be able to remove the 'other instanceof ConfigurationListener' branch in the ConfigurationListener.equals method.  Should work the same with or without that branch.



Jason



----------------------------------------
> Date: Wed, 10 Sep 2014 11:49:51 +0200
> From: daniel.fuchs at oracle.com
> To: core-libs-dev at openjdk.java.net
> Subject: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
>
> Hi,
>
> Please find below a proposed patch for
>
> 8043306 - Provide a replacement for the API that allowed to listen
> for LogManager configuration changes
> https://bugs.openjdk.java.net/browse/JDK-8043306
>
> Proposed Patch:
> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
>
> JDK-8029805 Removed LogManager addPropertyChangeListener
> and removePropertyChangeListener methods which were
> deprecated. These methods were deprecated in Java SE 8 and
> flagged for removal because they were problematic for
> modularity efforts.
> The idea was that an application needing to be informed of
> configuration changes could subclass LogManager and override
> readConfiguration.
>
> The proposed patch adds to new methods to LogManager:
>
> public void
> LogManager.addConfigurationListener(LogManager.ConfigurationListener
> listener);
> public void
> LogManager.removeConfigurationListener(LogManager.ConfigurationListener
> listener);
>
> These methods can be used by those applications for which subclassing
> LogManager would be too impractical.
>
> best regards,
>
> -- daniel 		 	   		  

From daniel.fuchs at oracle.com  Wed Sep 10 14:41:15 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 10 Sep 2014 16:41:15 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <BLU175-W47B685942A91FF963A848083CF0@phx.gbl>
References: <54101EBF.7000003@oracle.com>
	<BLU175-W47B685942A91FF963A848083CF0@phx.gbl>
Message-ID: <5410630B.4050100@oracle.com>

On 9/10/14 4:28 PM, Jason Mehrens wrote:
> Daniel
>
>
> I think you should be able to remove the 'other instanceof ConfigurationListener' branch in the ConfigurationListener.equals method.  Should work the same with or without that branch.

Oh yes. I put it there just to avoid it being flagged by
NetBeans:
   'equals() method not checking type of its parameters'
I guess it would be better to just return this == other;
(which unfortunately doesn't remove the warning)
but at least the intent would be clear.

Thanks Jason!

-- daniel

>
>
>
> Jason
>
>
>
> ----------------------------------------
>> Date: Wed, 10 Sep 2014 11:49:51 +0200
>> From: daniel.fuchs at oracle.com
>> To: core-libs-dev at openjdk.java.net
>> Subject: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
>>
>> Hi,
>>
>> Please find below a proposed patch for
>>
>> 8043306 - Provide a replacement for the API that allowed to listen
>> for LogManager configuration changes
>> https://bugs.openjdk.java.net/browse/JDK-8043306
>>
>> Proposed Patch:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
>>
>> JDK-8029805 Removed LogManager addPropertyChangeListener
>> and removePropertyChangeListener methods which were
>> deprecated. These methods were deprecated in Java SE 8 and
>> flagged for removal because they were problematic for
>> modularity efforts.
>> The idea was that an application needing to be informed of
>> configuration changes could subclass LogManager and override
>> readConfiguration.
>>
>> The proposed patch adds to new methods to LogManager:
>>
>> public void
>> LogManager.addConfigurationListener(LogManager.ConfigurationListener
>> listener);
>> public void
>> LogManager.removeConfigurationListener(LogManager.ConfigurationListener
>> listener);
>>
>> These methods can be used by those applications for which subclassing
>> LogManager would be too impractical.
>>
>> best regards,
>>
>> -- daniel 		 	   		



From claes.redestad at oracle.com  Wed Sep 10 14:41:27 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 10 Sep 2014 16:41:27 +0200
Subject: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net
In-Reply-To: <53FAF2FE.7010903@oracle.com>
References: <53EB6FF5.1050103@oracle.com>	<53EC6752.6000601@oracle.com>	<53EC822E.6000602@oracle.com>	<53EC9DE7.3070007@oracle.com>	<53ECA0BC.4070206@oracle.com>	<53ECA4DE.5040300@oracle.com>	<53ECB662.9030501@oracle.com>	<53ECB838.3070201@oracle.com>	<53ECBC0F.7060604@oracle.com>	<0E6D5E4D-0A47-4E39-A9B5-5F664093AF66@oracle.com>
	<53FAF2FE.7010903@oracle.com>
Message-ID: <54106317.1030804@oracle.com>

Hi,

the parseInt/parseLong API was changed[1] in accordance with the 
discussion in this thread. That
big shuffling around of modules also happened, so I've updated this patch:

http://cr.openjdk.java.net/~redestad/8055032/webrev.1/

/Claes

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

On 08/25/2014 10:25 AM, Alan Bateman wrote:
> On 18/08/2014 22:12, Mike Duigou wrote:
>> On Aug 14 2014, at 06:39 , Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>>> On 14/08/2014 14:23, Claes Redestad wrote:
>>>> How about methods only taking beginIndex? Integer.parseInt("x: 
>>>> 10000000", 3, 10)? I guess these could to be dropped
>>>> to avoid ambiguity and instead allow for variations where radix can 
>>>> be left out.
>>>>
>>>> I think there are two alternatives to the current implementation:
>>>> - only keep parseInt(CharSequence s, int beginIndex, int endIndex, 
>>>> int radix)
>>> That's my preference
>> Looking at the examples I agree that providing only this one method 
>> is probably the least error prone option.
>>
> I think we mostly got agreement on net-dev to re-examine the newly 
> introduced methods. I've created JDK-8055032 to track it and I'm sure 
> Claes will pick it up once he gets back.
>
> -Alan.



From claes.redestad at oracle.com  Wed Sep 10 15:04:31 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 10 Sep 2014 17:04:31 +0200
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <20140910073856.494244@eggemoggin.niobe.net>
References: <541023EB.10501@oracle.com>, <54102E27.3040508@oracle.com>,
	<54103451.5020509@oracle.com>, <54103BC8.1020409@oracle.com>
	<20140910073856.494244@eggemoggin.niobe.net>
Message-ID: <5410687F.9030705@oracle.com>

On 09/10/2014 04:38 PM, mark.reinhold at oracle.com wrote:
>> New webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.4/
> Looks fine, but when an exception declaration is on its own line then
> the opening brace of the method should be on its own line too, as in
> the original:
>
>      protected Class<?> findClass(final String name)
>          throws ClassNotFoundException
>      {

Original had weird 5 space indentation though:

http://cr.openjdk.java.net/~redestad/8057936/webrev.6/

Will need a sponsor for this, if it looks good to everyone.

/Claes

>
> - Mark



From michael.x.mcmahon at oracle.com  Wed Sep 10 15:27:35 2014
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 10 Sep 2014 16:27:35 +0100
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <5410687F.9030705@oracle.com>
References: <541023EB.10501@oracle.com>, <54102E27.3040508@oracle.com>,
	<54103451.5020509@oracle.com>,
	<54103BC8.1020409@oracle.com>	<20140910073856.494244@eggemoggin.niobe.net>
	<5410687F.9030705@oracle.com>
Message-ID: <54106DE7.3010107@oracle.com>

On 10/09/14 16:04, Claes Redestad wrote:
> On 09/10/2014 04:38 PM, mark.reinhold at oracle.com wrote:
>>> New webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.4/
>> Looks fine, but when an exception declaration is on its own line then
>> the opening brace of the method should be on its own line too, as in
>> the original:
>>
>>      protected Class<?> findClass(final String name)
>>          throws ClassNotFoundException
>>      {
>
> Original had weird 5 space indentation though:
>
> http://cr.openjdk.java.net/~redestad/8057936/webrev.6/
>
> Will need a sponsor for this, if it looks good to everyone.
>
> /Claes
>

I'll sponsor that for you.

Michael

>>
>> - Mark
>



From Alan.Bateman at oracle.com  Wed Sep 10 15:28:31 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 10 Sep 2014 16:28:31 +0100
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <5410687F.9030705@oracle.com>
References: <541023EB.10501@oracle.com>, <54102E27.3040508@oracle.com>,
	<54103451.5020509@oracle.com>,
	<54103BC8.1020409@oracle.com>	<20140910073856.494244@eggemoggin.niobe.net>
	<5410687F.9030705@oracle.com>
Message-ID: <54106E1F.6090605@oracle.com>

On 10/09/2014 16:04, Claes Redestad wrote:
>
> Original had weird 5 space indentation though:
>
> http://cr.openjdk.java.net/~redestad/8057936/webrev.6/
>
> Will need a sponsor for this, if it looks good to everyone.
Michael's suggestion was good, it much simpler now.

-Alan.


From peter.levart at gmail.com  Wed Sep 10 15:30:05 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 10 Sep 2014 17:30:05 +0200
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <540717B4.5010705@oracle.com>
References: <5405CCDB.6040706@oracle.com> <5405CD4E.4070409@oracle.com>
	<5406FEE9.6030000@gmail.com> <540717B4.5010705@oracle.com>
Message-ID: <54106E7D.30201@gmail.com>

On 09/03/2014 03:29 PM, Vladimir Ivanov wrote:
> Peter,
>
> Yes, it's a known problem [1].
> There are other caches (in MethodTypeForm, for example), which 
> shouldn't retain their elements.

Hi Vladimir,

I was tempted to see what it would take to use weakly referenced 
LambdaForms from cache entries (LambdaFormEditor.Transform objects).

This is what I came up with:

http://cr.openjdk.java.net/~plevart/misc/LambdaFormEditor.WeakCache/webrev.01/

In this modification on top of your patch, a reference to LambdaForm 
from Transform is not a final field any more (WeakReference has a normal 
field), so I had to change LambdaForm.transformCacheto be volatile field 
to enable safe publication of Transform objects and transiently 
LambdaForm objects. I also used ordered writes with volatile reads for 
Transform[] array elements where necessary. CHM already does what's 
necessary. If LambdaForm objects are unsafe-publication-tolerable, this 
can be simplified.

I have made a little effort to re-use slots occupied by cleared 
Transform objects, but nothing fancy like using ReferenceQueue(s) or 
such, since there would have to be a queue per LambdaForm and this would 
bring some overhead with it. Transform objects are very compact (even 
when they extend a WeakReference) and majority of heap is released by 
free-ing weakly reachable LambdaForm objects which can be quite big and 
deep sometimes.

A cache forms a tree of LambdaForm objects. Child LFs are derived from 
base (parent) LFs. parent -> child references are weak, but I added 
child -> parent references which are strong. If there is a strong 
reference to some cached LF from the application, the whole path leading 
from the root LF to the cached LF is kept alive this way, so that any 
code that wishes to follow that path can get to the cached LF.

So do you think that cached LambdaForm(s) are so general that they are 
better cached for the life of JVM even in long-running application 
servers that re-deploy apps on the fly and using WeakReference(s) is not 
necessary?

Regards, Peter

>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8057020
>
> On 9/3/14, 3:43 PM, Peter Levart wrote:
>> Hi Vladimir,
>>
>> I'm sure you and John have thought about it through, but I'll ask
>> anyway. Are cached LambdaForms going to stay around forever? What about
>> using a WeakReference<LambdaForm> (LambdaFormEditor.Transform could
>> extend WeakReference). This way unused LambdaForms would get GCed.
>>
>> Regards, Peter
>>
>> On 09/02/2014 03:59 PM, Vladimir Ivanov wrote:
>>> Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> On 9/2/14, 5:57 PM, Vladimir Ivanov wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8057042
>>>>
>>>> LambdaFormEditor provides an API to transform LambdaForms. Deriving 
>>>> new
>>>> LambdaForms from a base one allows to cache and reuse results of
>>>> repeated transformations.
>>>>
>>>> BMH binding is rewritten to use LambdaFormEditor.
>>>>
>>>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn, 
>>>> octane w/
>>>> "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>>>>
>>>> Reviewed-by: vlivanov, ?
>>>> Contributed-by: john.r.rose at oracle.com
>>>>
>>>> Thanks!
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>



From mandy.chung at oracle.com  Wed Sep 10 15:44:07 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 10 Sep 2014 08:44:07 -0700
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <5410687F.9030705@oracle.com>
References: <541023EB.10501@oracle.com>, <54102E27.3040508@oracle.com>,
	<54103451.5020509@oracle.com>,
	<54103BC8.1020409@oracle.com>	<20140910073856.494244@eggemoggin.niobe.net>
	<5410687F.9030705@oracle.com>
Message-ID: <541071C7.50508@oracle.com>


On 9/10/2014 8:04 AM, Claes Redestad wrote:
> http://cr.openjdk.java.net/~redestad/8057936/webrev.6/

Looks good.  A simple change gives 4-12% gains from your microbenchmark 
- pretty good.

Mandy


From huizhe.wang at oracle.com  Wed Sep 10 17:11:12 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 10 Sep 2014 10:11:12 -0700
Subject: Replace uses of StringBuffer with StringBuilder[JAXP]
In-Reply-To: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>
References: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>
Message-ID: <54108630.1000907@oracle.com>

Hi Otavio,

I'm glad to know you're interested in contributing to the JAXP project. 
The JAXP standalone itself has reached end-of-life. We're now 
concentrating on JAXP in OpenJDK. The repo is here: 
http://hg.openjdk.java.net/jdk9/dev/jaxp

If you are interested in contributing to OpenJDK/jaxp, please read 'How 
to contribute' and sign the OCA:
http://openjdk.java.net/contribute/

Thanks,
Joe

On 9/9/2014 6:10 PM, Ot?vio Gon?alves de Santana wrote:
> Similar to: https://bugs.openjdk.java.net/browse/JDK-8041679
>
> But in JAXP project:
>
> https://dl.dropboxusercontent.com/u/16109193/open_jdk/jax%E1%B9%95/string_buffer_2_string_builder.zip
>



From otaviojava at java.net  Wed Sep 10 17:40:25 2014
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Wed, 10 Sep 2014 14:40:25 -0300
Subject: Replace uses of StringBuffer with StringBuilder[JAXP]
In-Reply-To: <54108630.1000907@oracle.com>
References: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>
	<54108630.1000907@oracle.com>
Message-ID: <CAPc8kR2v7OzXGGAmRo9TCOC8CLcNrpiLi0PEU_8L=syihmy_Ng@mail.gmail.com>

Hi Wang.
Thank you for this information.
I have the OCA
On Sep 10, 2014 2:11 PM, "huizhe wang" <huizhe.wang at oracle.com> wrote:

> Hi Otavio,
>
> I'm glad to know you're interested in contributing to the JAXP project.
> The JAXP standalone itself has reached end-of-life. We're now concentrating
> on JAXP in OpenJDK. The repo is here: http://hg.openjdk.java.net/
> jdk9/dev/jaxp
>
> If you are interested in contributing to OpenJDK/jaxp, please read 'How to
> contribute' and sign the OCA:
> http://openjdk.java.net/contribute/
>
> Thanks,
> Joe
>
> On 9/9/2014 6:10 PM, Ot?vio Gon?alves de Santana wrote:
>
>> Similar to: https://bugs.openjdk.java.net/browse/JDK-8041679
>>
>> But in JAXP project:
>>
>> https://dl.dropboxusercontent.com/u/16109193/open_jdk/jax%
>> E1%B9%95/string_buffer_2_string_builder.zip
>>
>>
>


From harshad.rj at gmail.com  Sat Sep  6 15:50:42 2014
From: harshad.rj at gmail.com (Harshad RJ)
Date: Sat, 6 Sep 2014 21:20:42 +0530
Subject: About JDK-8042694
In-Reply-To: <53FBC77B.6060805@oracle.com>
References: <CA+fe1V_fP8vtGttBuYxbH=98g5SsN-P8-oyiFU6SViaZunTprg@mail.gmail.com>
	<53FBC77B.6060805@oracle.com>
Message-ID: <CA+fe1V8QREuy2xtk8T=1yOgidv4HkpUjAGH6TJSEwtJOJi_vqg@mail.gmail.com>

David,

Thanks for the response. In my case, the class loading that fails is for
loading the hook's class itself. The hook is not doing anything fancy as
far as I can see. For a database trying to make a best effort at saving
data, shutdown ability seems like a highly desirable feature to me.

?best,?
-- 
*Harshad RJ <http://lavadip.com>*


From martinrb at google.com  Wed Sep 10 20:01:17 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 Sep 2014 13:01:17 -0700
Subject: XMLScanner-supplementary-characters
Message-ID: <CA+kOe09Ncrm5fWeGiKf4nB6eRPDnw3tShAo0i--GVUDnZM6v9A@mail.gmail.com>

Hi Huizhe,

I have a strange contribution to share.

Webrev:
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/XMLScanner-supplementary-characters/

But I don't have a bug or a test case that I can share and I don't
understand the code, except that it's a fix for supporting supplementary
characters.  Perhaps you can reverse engineer the bug fix to a bug report?
 Also, maybe this is fixed in "real" xerces?  I have no idea...

At google we've been carrying this patch around for a while.

Martin


From huizhe.wang at oracle.com  Wed Sep 10 22:11:51 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 10 Sep 2014 15:11:51 -0700
Subject: XMLScanner-supplementary-characters
In-Reply-To: <CA+kOe09Ncrm5fWeGiKf4nB6eRPDnw3tShAo0i--GVUDnZM6v9A@mail.gmail.com>
References: <CA+kOe09Ncrm5fWeGiKf4nB6eRPDnw3tShAo0i--GVUDnZM6v9A@mail.gmail.com>
Message-ID: <5410CCA7.3000200@oracle.com>

Thanks Martin!

Looks like the initial version of the jaxp port (from Xerces 2.7.1) 
missed the patch for reasons I don't know. I created a bug based on the 
very original bug report:
https://bugs.openjdk.java.net/browse/JDK-8058175

Would you want to push the change into jdk9's jaxp repo?

Thanks,
Joe

On 9/10/2014 1:01 PM, Martin Buchholz wrote:
> Hi Huizhe,
>
> I have a strange contribution to share.
>
> Webrev:
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/XMLScanner-supplementary-characters/ 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/XMLScanner-supplementary-characters/>
>
> But I don't have a bug or a test case that I can share and I don't 
> understand the code, except that it's a fix for supporting 
> supplementary characters.  Perhaps you can reverse engineer the bug 
> fix to a bug report?  Also, maybe this is fixed in "real" xerces?  I 
> have no idea...
>
> At google we've been carrying this patch around for a while.
>
> Martin



From huizhe.wang at oracle.com  Wed Sep 10 22:13:12 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 10 Sep 2014 15:13:12 -0700
Subject: Replace uses of StringBuffer with StringBuilder[JAXP]
In-Reply-To: <CAPc8kR2v7OzXGGAmRo9TCOC8CLcNrpiLi0PEU_8L=syihmy_Ng@mail.gmail.com>
References: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>
	<54108630.1000907@oracle.com>
	<CAPc8kR2v7OzXGGAmRo9TCOC8CLcNrpiLi0PEU_8L=syihmy_Ng@mail.gmail.com>
Message-ID: <5410CCF8.2030708@oracle.com>

Hi Otavio,

Please let me know once you've submitted it.

Best,
Joe

On 9/10/2014 10:40 AM, Ot?vio Gon?alves de Santana wrote:
>
> Hi Wang.
> Thank you for this information.
> I have the OCA
>
> On Sep 10, 2014 2:11 PM, "huizhe wang" <huizhe.wang at oracle.com 
> <mailto:huizhe.wang at oracle.com>> wrote:
>
>     Hi Otavio,
>
>     I'm glad to know you're interested in contributing to the JAXP
>     project. The JAXP standalone itself has reached end-of-life. We're
>     now concentrating on JAXP in OpenJDK. The repo is here:
>     http://hg.openjdk.java.net/jdk9/dev/jaxp
>
>     If you are interested in contributing to OpenJDK/jaxp, please read
>     'How to contribute' and sign the OCA:
>     http://openjdk.java.net/contribute/
>
>     Thanks,
>     Joe
>
>     On 9/9/2014 6:10 PM, Ot?vio Gon?alves de Santana wrote:
>
>         Similar to: https://bugs.openjdk.java.net/browse/JDK-8041679
>
>         But in JAXP project:
>
>         https://dl.dropboxusercontent.com/u/16109193/open_jdk/jax%E1%B9%95/string_buffer_2_string_builder.zip
>
>



From martinrb at google.com  Wed Sep 10 22:20:11 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 Sep 2014 15:20:11 -0700
Subject: XMLScanner-supplementary-characters
In-Reply-To: <5410CCA7.3000200@oracle.com>
References: <CA+kOe09Ncrm5fWeGiKf4nB6eRPDnw3tShAo0i--GVUDnZM6v9A@mail.gmail.com>
	<5410CCA7.3000200@oracle.com>
Message-ID: <CA+kOe094C_=-kYF62rO5S-aM3Gbg6rbmnL8hZO5R1wVhQBk3uw@mail.gmail.com>

On Wed, Sep 10, 2014 at 3:11 PM, huizhe wang <huizhe.wang at oracle.com> wrote:

> Thanks Martin!
>
> Looks like the initial version of the jaxp port (from Xerces 2.7.1) missed
> the patch for reasons I don't know. I created a bug based on the very
> original bug report:
> https://bugs.openjdk.java.net/browse/JDK-8058175
>
> Would you want to push the change into jdk9's jaxp repo?
>
>
Yes I would!

I've updated the webrev and bug report to match.


From huizhe.wang at oracle.com  Wed Sep 10 23:14:48 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 10 Sep 2014 16:14:48 -0700
Subject: XMLScanner-supplementary-characters
In-Reply-To: <CA+kOe094C_=-kYF62rO5S-aM3Gbg6rbmnL8hZO5R1wVhQBk3uw@mail.gmail.com>
References: <CA+kOe09Ncrm5fWeGiKf4nB6eRPDnw3tShAo0i--GVUDnZM6v9A@mail.gmail.com>
	<5410CCA7.3000200@oracle.com>
	<CA+kOe094C_=-kYF62rO5S-aM3Gbg6rbmnL8hZO5R1wVhQBk3uw@mail.gmail.com>
Message-ID: <5410DB68.8060004@oracle.com>


On 9/10/2014 3:20 PM, Martin Buchholz wrote:
>
>
> On Wed, Sep 10, 2014 at 3:11 PM, huizhe wang <huizhe.wang at oracle.com 
> <mailto:huizhe.wang at oracle.com>> wrote:
>
>     Thanks Martin!
>
>     Looks like the initial version of the jaxp port (from Xerces
>     2.7.1) missed the patch for reasons I don't know. I created a bug
>     based on the very original bug report:
>     https://bugs.openjdk.java.net/browse/JDK-8058175
>
>     Would you want to push the change into jdk9's jaxp repo?
>
>
> Yes I would!
>
> I've updated the webrev and bug report to match.

Awesome!  Thanks again.

Joe




From martinrb at google.com  Wed Sep 10 23:29:04 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 Sep 2014 16:29:04 -0700
Subject: XMLScanner-supplementary-characters
In-Reply-To: <5410DB68.8060004@oracle.com>
References: <CA+kOe09Ncrm5fWeGiKf4nB6eRPDnw3tShAo0i--GVUDnZM6v9A@mail.gmail.com>
	<5410CCA7.3000200@oracle.com>
	<CA+kOe094C_=-kYF62rO5S-aM3Gbg6rbmnL8hZO5R1wVhQBk3uw@mail.gmail.com>
	<5410DB68.8060004@oracle.com>
Message-ID: <CA+kOe0_crSQhiJLYavB7QP_qCKdkj9Up5sA0tZeR5fnZRrS9RA@mail.gmail.com>

Thanks!  Pushed.

On Wed, Sep 10, 2014 at 4:14 PM, huizhe wang <huizhe.wang at oracle.com> wrote:

>
> On 9/10/2014 3:20 PM, Martin Buchholz wrote:
>
>
>
> On Wed, Sep 10, 2014 at 3:11 PM, huizhe wang <huizhe.wang at oracle.com>
> wrote:
>
>> Thanks Martin!
>>
>> Looks like the initial version of the jaxp port (from Xerces 2.7.1)
>> missed the patch for reasons I don't know. I created a bug based on the
>> very original bug report:
>> https://bugs.openjdk.java.net/browse/JDK-8058175
>>
>> Would you want to push the change into jdk9's jaxp repo?
>>
>>
>  Yes I would!
>
>  I've updated the webrev and bug report to match.
>
>
> Awesome!  Thanks again.
>
> Joe
>
>
>
>
>


From martinrb at google.com  Thu Sep 11 00:21:05 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 Sep 2014 17:21:05 -0700
Subject: RFR: JDK-8056934: ZipInputStream does not correctly handle local
	header data descriptors with the optional signature missing
In-Reply-To: <54049938.3040507@oracle.com>
References: <CA+kOe0_56ahydPyi0TJZWn5fhh-3Ss5bP=PaRqYGitwsy4EbwA@mail.gmail.com>
	<54049938.3040507@oracle.com>
Message-ID: <CA+kOe0_1ngZYAM3w-fqmbww6T8h0ia_hd+Gzi50q8cJrp11o=g@mail.gmail.com>

>
>
> For the comment in ZipInputStream then it might be better to move that to
> readEnd. My preference would be to not include the part starting "As of
> 2014-08, phyton ..." as that might not interesting in years to come.


I moved the comment into readEnd's javadoc.  I think laying out the
compatibility landscape is sufficiently useful that the comment about
python's implementation should stay, especially given that python has no
plans to "fix" theirs.


From martinrb at google.com  Thu Sep 11 00:24:33 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 Sep 2014 17:24:33 -0700
Subject: RFR: JDK-8056934: ZipInputStream does not correctly handle local
	header data descriptors with the optional signature missing
In-Reply-To: <5404C343.6060408@oracle.com>
References: <CA+kOe0_56ahydPyi0TJZWn5fhh-3Ss5bP=PaRqYGitwsy4EbwA@mail.gmail.com>
	<54049938.3040507@oracle.com> <5404C343.6060408@oracle.com>
Message-ID: <CA+kOe08y55-3jopQSec01Rjzx=Wg9sTXtsejGB4KnT8M0FcWcg@mail.gmail.com>

I tried and failed to expand the test to do ZIP64 as well - I ran into
32-bit limitations in python.
The test is useful, but too brittle to be a permanent jtreg test, so I
@ignored it.

I'm ready to submit this.


From Alan.Bateman at oracle.com  Thu Sep 11 07:34:35 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Sep 2014 08:34:35 +0100
Subject: RFR: JDK-8056934: ZipInputStream does not correctly handle local
	header data descriptors with the optional signature missing
In-Reply-To: <CA+kOe0_1ngZYAM3w-fqmbww6T8h0ia_hd+Gzi50q8cJrp11o=g@mail.gmail.com>
References: <CA+kOe0_56ahydPyi0TJZWn5fhh-3Ss5bP=PaRqYGitwsy4EbwA@mail.gmail.com>	<54049938.3040507@oracle.com>
	<CA+kOe0_1ngZYAM3w-fqmbww6T8h0ia_hd+Gzi50q8cJrp11o=g@mail.gmail.com>
Message-ID: <5411508B.8090009@oracle.com>

On 11/09/2014 01:21, Martin Buchholz wrote:
>
>
>     For the comment in ZipInputStream then it might be better to move
>     that to readEnd. My preference would be to not include the part
>     starting "As of 2014-08, phyton ..." as that might not interesting
>     in years to come.
>
>
> I moved the comment into readEnd's javadoc.  I think laying out the 
> compatibility landscape is sufficiently useful that the comment about 
> python's implementation should stay, especially given that python has 
> no plans to "fix" theirs.
Having the first 3 paragraphs in readEnd should be good (thanks), I 
would think that the notes on python and the link to its issue tracker 
might be better put into the JIRA issue for anyone that wants to dig 
into more of the history.

-Alan.


From Alan.Bateman at oracle.com  Thu Sep 11 07:43:13 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Sep 2014 08:43:13 +0100
Subject: XMLScanner-supplementary-characters
In-Reply-To: <5410CCA7.3000200@oracle.com>
References: <CA+kOe09Ncrm5fWeGiKf4nB6eRPDnw3tShAo0i--GVUDnZM6v9A@mail.gmail.com>
	<5410CCA7.3000200@oracle.com>
Message-ID: <54115291.6010403@oracle.com>

On 10/09/2014 23:11, huizhe wang wrote:
> Thanks Martin!
>
> Looks like the initial version of the jaxp port (from Xerces 2.7.1) 
> missed the patch for reasons I don't know. I created a bug based on 
> the very original bug report:
> https://bugs.openjdk.java.net/browse/JDK-8058175
Joe - what's the test coverage like of this area in OpenJDK? I see 
Martin has pushed this change but I just wonder if there is an 
opportunity to add or improve tests, particularly for subtle cases like 
this.

-Alan


From chris.hegarty at oracle.com  Thu Sep 11 08:43:54 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 11 Sep 2014 09:43:54 +0100
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses
	exceptions in control flow
In-Reply-To: <5410687F.9030705@oracle.com>
References: <541023EB.10501@oracle.com>, <54102E27.3040508@oracle.com>,
	<54103451.5020509@oracle.com>, <54103BC8.1020409@oracle.com>
	<20140910073856.494244@eggemoggin.niobe.net>
	<5410687F.9030705@oracle.com>
Message-ID: <083E3D9F-B4EE-41DA-915B-444D6DE671D6@oracle.com>


On 10 Sep 2014, at 16:04, Claes Redestad <claes.redestad at oracle.com> wrote:

> On 09/10/2014 04:38 PM, mark.reinhold at oracle.com wrote:
>>> New webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.4/
>> Looks fine, but when an exception declaration is on its own line then
>> the opening brace of the method should be on its own line too, as in
>> the original:
>> 
>>     protected Class<?> findClass(final String name)
>>         throws ClassNotFoundException
>>     {
> 
> Original had weird 5 space indentation though:
> 
> http://cr.openjdk.java.net/~redestad/8057936/webrev.6/

This latest version looks good.

-Chris.

> 
> Will need a sponsor for this, if it looks good to everyone.
> 
> /Claes
> 
>> 
>> - Mark
> 



From vladimir.x.ivanov at oracle.com  Thu Sep 11 09:02:08 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 11 Sep 2014 13:02:08 +0400
Subject: [9] Review request : JDK-8057719: Develop new tests for LambdaForm
	Reduction and Caching feature
In-Reply-To: <5409F86D.8040200@oracle.com>
References: <5409F86D.8040200@oracle.com>
Message-ID: <54116510.3080801@oracle.com>

Konstantin,

Looks good!
Thank you for working on the tests.

Best regards,
Vladimir Ivanov

On 9/5/14, 9:52 PM, Konstantin Shefov wrote:
> Hello,
>
> Please review the new tests for the feature "Lambda Form Reduction and
> Caching" https://bugs.openjdk.java.net/browse/JDK-8046703
>
> JBS task: https://bugs.openjdk.java.net/browse/JDK-8057719
>
> Webrev: http://cr.openjdk.java.net/~kshefov/8057719/webrev.00/
>
> These tests also depend on testlibrary change:
> https://bugs.openjdk.java.net/browse/JDK-8057707
> Webrev of the testlib change:
> http://cr.openjdk.java.net/~kshefov/8057707/webrev.00/
>
> Thanks
>
> -Konstantin


From Alan.Bateman at oracle.com  Thu Sep 11 09:16:09 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Sep 2014 10:16:09 +0100
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <083E3D9F-B4EE-41DA-915B-444D6DE671D6@oracle.com>
References: <541023EB.10501@oracle.com>, <54102E27.3040508@oracle.com>,
	<54103451.5020509@oracle.com>,
	<54103BC8.1020409@oracle.com>	<20140910073856.494244@eggemoggin.niobe.net>	<5410687F.9030705@oracle.com>
	<083E3D9F-B4EE-41DA-915B-444D6DE671D6@oracle.com>
Message-ID: <54116859.4000308@oracle.com>

On 11/09/2014 09:43, Chris Hegarty wrote:
> On 10 Sep 2014, at 16:04, Claes Redestad <claes.redestad at oracle.com> wrote:
>
>> On 09/10/2014 04:38 PM, mark.reinhold at oracle.com wrote:
>>>> New webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.4/
>>> Looks fine, but when an exception declaration is on its own line then
>>> the opening brace of the method should be on its own line too, as in
>>> the original:
>>>
>>>      protected Class<?> findClass(final String name)
>>>          throws ClassNotFoundException
>>>      {
>> Original had weird 5 space indentation though:
>>
>> http://cr.openjdk.java.net/~redestad/8057936/webrev.6/
> This latest version looks good.
>
I agree and much more readable since the API adjustment.

-Alan


From Alan.Bateman at oracle.com  Thu Sep 11 09:53:13 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Sep 2014 10:53:13 +0100
Subject: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions
	in control flow
In-Reply-To: <54116859.4000308@oracle.com>
References: <541023EB.10501@oracle.com>, <54102E27.3040508@oracle.com>,
	<54103451.5020509@oracle.com>,
	<54103BC8.1020409@oracle.com>	<20140910073856.494244@eggemoggin.niobe.net>	<5410687F.9030705@oracle.com>	<083E3D9F-B4EE-41DA-915B-444D6DE671D6@oracle.com>
	<54116859.4000308@oracle.com>
Message-ID: <54117109.10400@oracle.com>

On 11/09/2014 10:16, Alan Bateman wrote:
>
> I agree and much more readable since the API adjustment.
Ignoring that comment for this thread, my comment was on the parseInt 
changes in your other java.net patch which are looking much better now.

-Alan


From otaviojava at java.net  Thu Sep 11 10:06:00 2014
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Thu, 11 Sep 2014 07:06:00 -0300
Subject: Replace uses of StringBuffer with StringBuilder[JAXP]
In-Reply-To: <5410CCF8.2030708@oracle.com>
References: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>
	<54108630.1000907@oracle.com>
	<CAPc8kR2v7OzXGGAmRo9TCOC8CLcNrpiLi0PEU_8L=syihmy_Ng@mail.gmail.com>
	<5410CCF8.2030708@oracle.com>
Message-ID: <CAPc8kR2EunVOi=kT7AQ7d3ZMacsk2R=yPh59cazbrkB87BeESg@mail.gmail.com>

Hi Huizhe.
Done.

creates new remote head d053915e3689!

On Wed, Sep 10, 2014 at 7:13 PM, huizhe wang <huizhe.wang at oracle.com> wrote:

>  Hi Otavio,
>
> Please let me know once you've submitted it.
>
> Best,
> Joe
>
>
> On 9/10/2014 10:40 AM, Ot?vio Gon?alves de Santana wrote:
>
> Hi Wang.
> Thank you for this information.
> I have the OCA
> On Sep 10, 2014 2:11 PM, "huizhe wang" <huizhe.wang at oracle.com> wrote:
>
>> Hi Otavio,
>>
>> I'm glad to know you're interested in contributing to the JAXP project.
>> The JAXP standalone itself has reached end-of-life. We're now concentrating
>> on JAXP in OpenJDK. The repo is here:
>> http://hg.openjdk.java.net/jdk9/dev/jaxp
>>
>> If you are interested in contributing to OpenJDK/jaxp, please read 'How
>> to contribute' and sign the OCA:
>> http://openjdk.java.net/contribute/
>>
>> Thanks,
>> Joe
>>
>> On 9/9/2014 6:10 PM, Ot?vio Gon?alves de Santana wrote:
>>
>>> Similar to: https://bugs.openjdk.java.net/browse/JDK-8041679
>>>
>>> But in JAXP project:
>>>
>>>
>>> https://dl.dropboxusercontent.com/u/16109193/open_jdk/jax%E1%B9%95/string_buffer_2_string_builder.zip
>>>
>>>
>>
>


-- 
Ot?vio Gon?alves de Santana

blog:     http://otaviosantana.blogspot.com.br/
twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
55 (11) 98255-3513


From otaviojava at java.net  Thu Sep 11 10:49:20 2014
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Thu, 11 Sep 2014 07:49:20 -0300
Subject: Replace uses of StringBuffer with StringBuilder[JAXP]
In-Reply-To: <CAPc8kR2EunVOi=kT7AQ7d3ZMacsk2R=yPh59cazbrkB87BeESg@mail.gmail.com>
References: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>
	<54108630.1000907@oracle.com>
	<CAPc8kR2v7OzXGGAmRo9TCOC8CLcNrpiLi0PEU_8L=syihmy_Ng@mail.gmail.com>
	<5410CCF8.2030708@oracle.com>
	<CAPc8kR2EunVOi=kT7AQ7d3ZMacsk2R=yPh59cazbrkB87BeESg@mail.gmail.com>
Message-ID: <CAPc8kR0ssn167sq+nM5rb+17E8XDr+JMerpKbwMKXgSfo=ZkBg@mail.gmail.com>

Actually it doesn't work.
I can't send a push or create a remote branch.
Can you help me?
When I submit a patch, I normally send a path file how it in attachment and
the webdev:
https://dl.dropboxusercontent.com/u/16109193/open_jdk/jax%E1%B9%95/string_buffer_2_string_builder.zip

On Thu, Sep 11, 2014 at 7:06 AM, Ot?vio Gon?alves de Santana <
otaviojava at java.net> wrote:

> Hi Huizhe.
> Done.
>
> creates new remote head d053915e3689!
>
> On Wed, Sep 10, 2014 at 7:13 PM, huizhe wang <huizhe.wang at oracle.com>
> wrote:
>
>>  Hi Otavio,
>>
>> Please let me know once you've submitted it.
>>
>> Best,
>> Joe
>>
>>
>> On 9/10/2014 10:40 AM, Ot?vio Gon?alves de Santana wrote:
>>
>> Hi Wang.
>> Thank you for this information.
>> I have the OCA
>> On Sep 10, 2014 2:11 PM, "huizhe wang" <huizhe.wang at oracle.com> wrote:
>>
>>> Hi Otavio,
>>>
>>> I'm glad to know you're interested in contributing to the JAXP project.
>>> The JAXP standalone itself has reached end-of-life. We're now concentrating
>>> on JAXP in OpenJDK. The repo is here:
>>> http://hg.openjdk.java.net/jdk9/dev/jaxp
>>>
>>> If you are interested in contributing to OpenJDK/jaxp, please read 'How
>>> to contribute' and sign the OCA:
>>> http://openjdk.java.net/contribute/
>>>
>>> Thanks,
>>> Joe
>>>
>>> On 9/9/2014 6:10 PM, Ot?vio Gon?alves de Santana wrote:
>>>
>>>> Similar to: https://bugs.openjdk.java.net/browse/JDK-8041679
>>>>
>>>> But in JAXP project:
>>>>
>>>>
>>>> https://dl.dropboxusercontent.com/u/16109193/open_jdk/jax%E1%B9%95/string_buffer_2_string_builder.zip
>>>>
>>>>
>>>
>>
>
>
> --
> Ot?vio Gon?alves de Santana
>
> blog:     http://otaviosantana.blogspot.com.br/
> twitter: http://twitter.com/otaviojava
> site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
> 55 (11) 98255-3513
>



-- 
Ot?vio Gon?alves de Santana

blog:     http://otaviosantana.blogspot.com.br/
twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
55 (11) 98255-3513
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 638_updated.patch
Type: text/x-patch
Size: 178158 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20140911/94c86d7d/638_updated.patch>

From joel.franck at oracle.com  Thu Sep 11 11:15:23 2014
From: joel.franck at oracle.com (=?iso-8859-1?Q?Joel_Borggr=E9n-Franck?=)
Date: Thu, 11 Sep 2014 13:15:23 +0200
Subject: RFR: 5043030 (reflect) unnecessary object creation in reflection
In-Reply-To: <20140909092147.GA16236@oracle.com>
References: <F36715BC-B186-4157-BB61-AE2897F6B685@oracle.com>
	<C1CC52F0-9770-4A30-9EDD-267C29193376@gmail.com>
	<55590437-6901-4ED9-BBC5-C96355442AB5@oracle.com>
	<2DD9A9E7-48A5-4EBE-8BF4-3687C3D840C4@gmail.com>
	<237340BB-AD86-443D-BFFC-A1E601E44BDF@oracle.com>
	<CAM6ZMz8wGhNT+QbxPKt46Zpv34cPLe4GwMiheqk1GnKnj=f5Vw@mail.gmail.com>
	<20140613084650.GA24337@oracle.com>
	<CAM6ZMz-xoObKSVU8mGN0q3xyOQTZJZYxMNp92F9mPJsf3akjFQ@mail.gmail.com>
	<C9BCB35D-5F09-49D2-8F43-D0039B8D388F@oracle.com>
	<D85E6ACE-028D-48BF-88F3-75888EC63B49@gmail.com>
	<20140909092147.GA16236@oracle.com>
Message-ID: <1E68175C-D5C1-4BDF-B871-8E29C41DF4DF@oracle.com>

Hi,

I pushed this two days ago. Thank you Andrej for the contribution!

cheers
/Joel

On 9 sep 2014, at 11:21, Joel Borggr?n-Franck <joel.franck at oracle.com> wrote:

> Hi Andrej,
> 
> Can you resend the latest patch attached to a mail to this list?
> 
> cheers
> /Joel
> 
> On 2014-08-29, Andrej Golovnin wrote:
>> Hi Joel,
>> 
>>>> I have changed the test TestMethodReflectValueOf as you suggested and I have changed the summary of both tests too. You will find the changes in the attached patch. Here is the new webrev: https://db.tt/wQBLVceA
>>>> 
>>>> And here is the coverage report in the HTML format:
>>>> 
>>>> https://db.tt/JTZjpnMM
>>>> 
>>> 
>>> Out of curiosity, did you generate the coverage report running the jdk_lang test suite?
>> 
>> Yes and I used the following config for JCov:
>> 
>> include_list=jcov_jdk_lang.txt,field=on,abstract=on,native=on,type=all,file=$JCOV_OUT,merge=merge
>> 
>> where jcov_jdk_lang.txt contains the single line:
>> 
>> sun.reflect.*
>> 
>> 
>>> I think this patch is good to go. I need to file some Oracle internal requests, should take about a week, then I can sponsor this.
>> 
>> I am very pleased to hear that and I hope to contribute more.
>> 
>> Best regards,
>> Andrej Golovnin
> 
> -- 



From miroslav.kos at oracle.com  Thu Sep 11 11:20:34 2014
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Thu, 11 Sep 2014 13:20:34 +0200
Subject: [9] RFR: JDK-8054548: JAX-WS tools need to updated to work with
	modular image
Message-ID: <54118582.3020004@oracle.com>

Hello,
please review following change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8054548
webrev: http://cr.openjdk.java.net/~mkos/8054548/jaxws.00/

It is basically replacing obsolete code using core reflection by 
javax.tools API plus removing old unused code.

I ran the unit tests against both standalone JAX-WS and jdk, no 
regressions occurred.

Thanks
Miran



From claes.redestad at oracle.com  Thu Sep 11 11:46:16 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 11 Sep 2014 13:46:16 +0200
Subject: RFR: 8057826 minor clean-up to the java.sql Date/Time/Timestamp
	tests
In-Reply-To: <19576455-CB80-4BBA-BA09-ADF9C14AB731@oracle.com>
References: <19576455-CB80-4BBA-BA09-ADF9C14AB731@oracle.com>
Message-ID: <54118B88.7090404@oracle.com>

Looks good to me, especially the added nanotime test coverage

/Claes

On 09/08/2014 07:31 PM, Lance Andersen wrote:
> Hi,
>
> Looking for a reviewer for this minor clean-up to the java.sql Date/Time/Timestamp tests which adds support for DataProvider
>
> Webrev can be found here: http://cr.openjdk.java.net/~lancea/8057826/webrev.00/
>
> Best
> Lance
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>



From antoine.mottier at bonitasoft.com  Thu Sep 11 12:05:01 2014
From: antoine.mottier at bonitasoft.com (Antoine Mottier)
Date: Thu, 11 Sep 2014 14:05:01 +0200
Subject: JDK-8057122 also reproduce on Windows Server 2012 r2
Message-ID: <CAKns_XtMZbBVh0=aFqfiUPxFfj9sk7C1-bZf6+G5S6ui3EAALg@mail.gmail.com>

Hi all,

Few days ago I report an issue about os.name value when using jvm.dll on
Windows 8.1 ( JDK-8057122).
Today I reproduce the same issue on Windows Server 2012 r2. Running the
Java class using java.exe will report correct (meaning including r2) os.name
version, using the dll, "r2" will not be part of os.name.

Source code of a custom launcher that load the dll is already available on
the bug report but here is a download link to the full Visual Studio 2013
project: https://www.dropbox.com/s/2fbtili51b7r66a/TestJvm.zip?dl=0

I can do any kind of additional tests if needed, I just have a lack of
knowledges about Windows applications building process.

Thanks,
--
Antoine Mottier


From ivan.gerasimov at oracle.com  Thu Sep 11 12:20:25 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 11 Sep 2014 16:20:25 +0400
Subject: JDK-8057122 also reproduce on Windows Server 2012 r2
In-Reply-To: <CAKns_XtMZbBVh0=aFqfiUPxFfj9sk7C1-bZf6+G5S6ui3EAALg@mail.gmail.com>
References: <CAKns_XtMZbBVh0=aFqfiUPxFfj9sk7C1-bZf6+G5S6ui3EAALg@mail.gmail.com>
Message-ID: <54119389.2080406@oracle.com>

Thanks Antoine!

I've added your update to the bug report.
https://bugs.openjdk.java.net/browse/JDK-8057122

Sincerely yours,
Ivan

On 11.09.2014 16:05, Antoine Mottier wrote:
> Hi all,
>
> Few days ago I report an issue about os.name value when using jvm.dll on
> Windows 8.1 ( JDK-8057122).
> Today I reproduce the same issue on Windows Server 2012 r2. Running the
> Java class using java.exe will report correct (meaning including r2) os.name
> version, using the dll, "r2" will not be part of os.name.
>
> Source code of a custom launcher that load the dll is already available on
> the bug report but here is a download link to the full Visual Studio 2013
> project:https://www.dropbox.com/s/2fbtili51b7r66a/TestJvm.zip?dl=0
>
> I can do any kind of additional tests if needed, I just have a lack of
> knowledges about Windows applications building process.
>
> Thanks,
> --
> Antoine Mottier



From Alan.Bateman at oracle.com  Thu Sep 11 12:39:26 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Sep 2014 13:39:26 +0100
Subject: [9] RFR: JDK-8054548: JAX-WS tools need to updated to work with
	modular image
In-Reply-To: <54118582.3020004@oracle.com>
References: <54118582.3020004@oracle.com>
Message-ID: <541197FE.4060605@oracle.com>

On 11/09/2014 12:20, Miroslav Kos wrote:
> Hello,
> please review following change:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8054548
> webrev: http://cr.openjdk.java.net/~mkos/8054548/jaxws.00/
>
> It is basically replacing obsolete code using core reflection by 
> javax.tools API plus removing old unused code.
Thanks for doing this, it's good to get this cleaned up.

The changes looks reasonable but I wonder if they are complete. I ask 
because I assumed that JavaCompilerHelper.getJarFile would be removed. 
Also there appears to be a bit of skullduggery in both wsimport and 
wsgen involving -Xbootclasspath/p where it might be assuming that the 
JAXB or JAX-WS classes are being loaded from JAR files (I didn't did 
into ParallelWorldClassLoader.toJarUrl so perhaps it can deal with other 
URLs).

In passing, I assume the comments in Invoker should use "ClassLoader" or 
"class loader". Also the comment in createClassLoader mentions JAXB/WS 
2.1 and not clear how this relates to the method description where it 
talked about 2.2

In JavacompilerMessages then noJavaCompilerError() and 
localizedNoJavaCompilerError() might be nicer names (in case you are 
looking for something better).

-Alan.


From claes.redestad at oracle.com  Thu Sep 11 13:03:21 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 11 Sep 2014 15:03:21 +0200
Subject: RFR(S): 8055055: Improve numeric parsing in java.sql
In-Reply-To: <5408BF63.7040409@oracle.com>
References: <53EB970D.80801@oracle.com>	<4B9A9590-7EA4-45B3-B9DB-8C0EECFC4664@oracle.com>	<53EBBFA9.6020307@oracle.com>	<41C11643-EB9A-4EC4-BB79-2C847DC73C28@oracle.com>	<54081F2E.7060409@oracle.com>	<AD6A894E-A7B9-4EA6-96E4-4D2E6BF1A4B2@oracle.com>
	<5408BF63.7040409@oracle.com>
Message-ID: <54119D99.2000809@oracle.com>

Hi,

I've reworked this patch after recent parseInt API updates (8055251) and 
removed the test additions which are being covered by 8057826.

I also discovered a missed opportunity to apply the same optimization to 
java.sql.Date which I missed earlier:

http://cr.openjdk.java.net/~redestad/8055055/webrev.8

Minimal JMH benchmark for the additional java.sql.Date::valueOf changes:

@State(Scope.Thread)
public class DateBench {
     public String date = "2013-01-01";

     @Benchmark
     public java.sql.Date dateValueOf() {
         return java.sql.Date.valueOf(date);
     }
}

Benchmark                 Mode  Samples     Score  Score error   Units
DateBench.dateValueOf    thrpt       20  4659.810 288.019  ops/ms# before
DateBench.dateValueOf    thrpt       20  7554.585 331.703  ops/ms # 
after; ~1.6x

/Claes

On 09/04/2014 09:37 PM, Claes Redestad wrote:
>
> On 2014-09-04 21:20, Lance Andersen wrote:
>> Hi Claes,
>>
>> I am assuming the changes to the Time and Timestamp have not changed, 
>> you just moved them to the new structure.
>
> Yes, unchanged otherwise.
>
>>
>> WRT the tests, I actually want to add more value testing.  I am in 
>> the process of updating Time and Timestamp tests to use a 
>> DataProvider.  Once I finish this, I will send it out for review as 
>> it will make it easier to update these tests for additional scenarios
>
> Sounds good!
>
> /Claes
>>
>> Best
>> Lance
>> On Sep 4, 2014, at 4:13 AM, Claes Redestad <claes.redestad at oracle.com 
>> <mailto:claes.redestad at oracle.com>> wrote:
>>
>>> Hi,
>>>
>>> I took the liberty to shuffle around the patch to the new structure 
>>> and add a few tests, particularly testing subtly different invalid 
>>> formats and better exercising the logic around Timestamp nanos 
>>> (tested using both old and new code):
>>>
>>> http://cr.openjdk.java.net/~redestad/8055055/webrev.5 
>>> <http://cr.openjdk.java.net/%7Eredestad/8055055/webrev.5>
>>>
>>> /Claes
>>>
>>>
>>> On 2014-08-21 21:06, Lance Andersen wrote:
>>>> I think this is OK.  However, I want to write some additional tests 
>>>> to reduce the chance of regression and add this as part of the putback
>>>>
>>>> I am going to be out of the office for a few days so doubt I will 
>>>> get to this for another week or so
>>>>
>>>> Best,
>>>> Lance
>>>> On Aug 13, 2014, at 3:42 PM, Claes Redestad 
>>>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com> 
>>>> <mailto:claes.redestad at oracle.com>> wrote:
>>>>
>>>>> Thanks, Lance!
>>>>>
>>>>> I only ran the jtreg tests under jdk/test/java/sql locally for 
>>>>> this (29 passed).
>>>>>
>>>>> /Claes
>>>>>
>>>>> On 2014-08-13 20:14, Lance Andersen wrote:
>>>>>> I will take a look this week.  Did you run the unit tests to make 
>>>>>> sure they still pass?
>>>>>>
>>>>>>
>>>>>> On Aug 13, 2014, at 12:49 PM, Claes Redestad 
>>>>>> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com> 
>>>>>> <mailto:claes.redestad at oracle.com> 
>>>>>> <mailto:claes.redestad at oracle.com>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> can I have a review of this small patch which improves 
>>>>>>> performance of java.sql.Time::valueOf (~1.3x) and 
>>>>>>> java.sql.Timestamp::valueOf (~1.9x).
>>>>>>>
>>>>>>> Uses Integer.parseInt with offset to make intermediary 
>>>>>>> substrings unnecessary and improves the nanosecond fraction 
>>>>>>> calculation to not use String concatenation.
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8055055
>>>>>>> webrev: http://cr.openjdk.java.net/~redestad/8055055/webrev.0/ 
>>>>>>> <http://cr.openjdk.java.net/%7Eredestad/8055055/webrev.0/> 
>>>>>>> <http://cr.openjdk.java.net/%7Eredestad/8055055/webrev.0/> 
>>>>>>> <http://cr.openjdk.java.net/%7Eredestad/8055055/webrev.0/>
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> /Claes
>>>>>>
>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> 
>>>>>>
>>>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>>>>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>>> Oracle Java Engineering
>>>>>> 1 Network Drive
>>>>>> Burlington, MA 01803
>>>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> 
>>>>>> <mailto:Lance.Andersen at oracle.com> 
>>>>>> <mailto:Lance.Andersen at oracle.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> 
>>>>
>>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering
>>>> 1 Network Drive
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> 
>>>> <mailto:Lance.Andersen at oracle.com>
>>>>
>>>>
>>>>
>>>
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> 
>>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>
>>
>>
>



From paul.sandoz at oracle.com  Thu Sep 11 13:12:27 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 11 Sep 2014 15:12:27 +0200
Subject: [9] Review request : JDK-8057719: Develop new tests for
	LambdaForm Reduction and Caching feature
In-Reply-To: <5409F86D.8040200@oracle.com>
References: <5409F86D.8040200@oracle.com>
Message-ID: <C937A851-BE1B-41B6-B2F0-0A839F65291B@oracle.com>


On Sep 5, 2014, at 7:52 PM, Konstantin Shefov <konstantin.shefov at oracle.com> wrote:

> Hello,
> 
> Please review the new tests for the feature "Lambda Form Reduction and Caching" https://bugs.openjdk.java.net/browse/JDK-8046703
> 
> JBS task: https://bugs.openjdk.java.net/browse/JDK-8057719
> 
> Webrev: http://cr.openjdk.java.net/~kshefov/8057719/webrev.00/
> 
> These tests also depend on testlibrary change: https://bugs.openjdk.java.net/browse/JDK-8057707
> Webrev of the testlib change: http://cr.openjdk.java.net/~kshefov/8057707/webrev.00/
> 

Generally looks good. It would be interesting see code-coverage results.

Are you sure the LFMultiThreadCachingTest is sufficiently testing the thread-safety of j.l.invoke classes? It might be that more threads need to be generated (== #cores), and the test repeatedly performed in a loop to increase the chance of stuff stomping on each other. (I see you have iterations in the outer loop of runTests, that might be sufficient, but you might need a tighter loop specific to each test in LFMultiThreadCachingTest).


A general comment, feel free to ignore. It's easy to use EnumSet to obtain a collection of enum values:

  Set<TestMethods> tms = EnumSet.allOf(TestMethods.class)

and filtered:

  Set<TestMethods> tms = EnumSet.complementOf(EnumSet.of(TestMethods.IDENTITY, TestMethods.CONSTANT))

(Quite concise with a static import.)

Change LambdaFormTestCase.runTests to accept a Collection<TestMethods> and you are good to go :-)

Paul.


From antoine.mottier at bonitasoft.com  Thu Sep 11 13:14:47 2014
From: antoine.mottier at bonitasoft.com (Antoine Mottier)
Date: Thu, 11 Sep 2014 15:14:47 +0200
Subject: JDK-8057122 also reproduce on Windows Server 2012 r2
In-Reply-To: <54119389.2080406@oracle.com>
References: <CAKns_XtMZbBVh0=aFqfiUPxFfj9sk7C1-bZf6+G5S6ui3EAALg@mail.gmail.com>
	<54119389.2080406@oracle.com>
Message-ID: <CAKns_XuALkEHeB1TLV+_scbH-+knh52GJSBV1nX_v2T5emiGKw@mail.gmail.com>

Thanks Ivan!

As suggest by Alan Bateman I did a test with a manifest include in the
launcher and it works!
Adding manifest like the one provided here:
http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074%28v=vs.85%29.aspx
fix the issue and os.name is correctly reported as Windows 8.1 (didn't
tested yet with Windows server).

Regards,
--
Antoine



2014-09-11 14:20 GMT+02:00 Ivan Gerasimov <ivan.gerasimov at oracle.com>:

> Thanks Antoine!
>
> I've added your update to the bug report.
> https://bugs.openjdk.java.net/browse/JDK-8057122
>
> Sincerely yours,
> Ivan
>
>
> On 11.09.2014 16:05, Antoine Mottier wrote:
>
>> Hi all,
>>
>> Few days ago I report an issue about os.name value when using jvm.dll on
>> Windows 8.1 ( JDK-8057122).
>> Today I reproduce the same issue on Windows Server 2012 r2. Running the
>> Java class using java.exe will report correct (meaning including r2)
>> os.name
>> version, using the dll, "r2" will not be part of os.name.
>>
>> Source code of a custom launcher that load the dll is already available on
>> the bug report but here is a download link to the full Visual Studio 2013
>> project:https://www.dropbox.com/s/2fbtili51b7r66a/TestJvm.zip?dl=0
>>
>> I can do any kind of additional tests if needed, I just have a lack of
>> knowledges about Windows applications building process.
>>
>> Thanks,
>> --
>> Antoine Mottier
>>
>
>


From claes.redestad at oracle.com  Thu Sep 11 14:44:05 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 11 Sep 2014 16:44:05 +0200
Subject: RFR: 8058230: Improve java.sql toString formatting
Message-ID: <5411B535.7040903@oracle.com>

Hi,

requesting reviews for this patch which optimizes 
java.sql.Date/Time/Timestamp::toString
by avoiding some unnecessary object allocations. java.sql.Date had 
similar optimizations
applied which this patch improves upon.

bug: https://bugs.openjdk.java.net/browse/JDK-8058230
webrev: http://cr.openjdk.java.net/~redestad/8058230/webrev.00/

Testing: jtreg jdk/test/java/sql with and without 8057826 tests

Before/after performance running a minimal JMH micro[1]:

Benchmark                         Mode  Samples      Score Score error   
Units
t.DateBench.dateToString         thrpt       20 30225.628      623.887  
ops/ms
t.DateBench.dateToString         thrpt       20 38350.173     1349.432  
ops/ms  # 1.3x

t.DateBench.timeToString         thrpt       20 11793.338      232.121  
ops/ms
t.DateBench.timeToString         thrpt       20 47048.344     1969.939  
ops/ms  # 4.0x

t.DateBench.timestampToString    thrpt       20 2529.601       45.990  
ops/ms
t.DateBench.timestampToString    thrpt       20 14143.612      407.351  
ops/ms  # 5.6x

/Claes

[1]

package test;

import org.openjdk.jmh.annotations.*;

@State(Scope.Thread)
public class DateBench {

     public java.sql.Time time = java.sql.Time.valueOf("15:15:25");

     @Benchmark
     public String timeToString() {
         return time.toString();
     }

     public java.sql.Date date = java.sql.Date.valueOf("2013-01-01");

     @Benchmark
     public String dateToString() {
         return date.toString();
     }

     public Timestamp timestamp = Timestamp.valueOf("1999-12-13 
15:15:25.645634");

     @Benchmark
     public String timestampToString() {
         return timestamp.toString();
     }

}


From lance.andersen at oracle.com  Thu Sep 11 15:32:40 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 11 Sep 2014 11:32:40 -0400
Subject: RFR: 8058230: Improve java.sql toString formatting
In-Reply-To: <5411B535.7040903@oracle.com>
References: <5411B535.7040903@oracle.com>
Message-ID: <3AD72EA0-7768-48E0-B209-C8188B22FDD6@oracle.com>

Hi Claes,

I think this is OK,  however, would like to see if others feel if  formatDecimalInt should be located elsewhere so that we just make this change once.

Best,
Lance
On Sep 11, 2014, at 10:44 AM, Claes Redestad <claes.redestad at oracle.com> wrote:

> Hi,
> 
> requesting reviews for this patch which optimizes java.sql.Date/Time/Timestamp::toString
> by avoiding some unnecessary object allocations. java.sql.Date had similar optimizations
> applied which this patch improves upon.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8058230
> webrev: http://cr.openjdk.java.net/~redestad/8058230/webrev.00/
> 
> Testing: jtreg jdk/test/java/sql with and without 8057826 tests
> 
> Before/after performance running a minimal JMH micro[1]:
> 
> Benchmark                         Mode  Samples      Score Score error   Units
> t.DateBench.dateToString         thrpt       20 30225.628      623.887  ops/ms
> t.DateBench.dateToString         thrpt       20 38350.173     1349.432  ops/ms  # 1.3x
> 
> t.DateBench.timeToString         thrpt       20 11793.338      232.121  ops/ms
> t.DateBench.timeToString         thrpt       20 47048.344     1969.939  ops/ms  # 4.0x
> 
> t.DateBench.timestampToString    thrpt       20 2529.601       45.990  ops/ms
> t.DateBench.timestampToString    thrpt       20 14143.612      407.351  ops/ms  # 5.6x
> 
> /Claes
> 
> [1]
> 
> package test;
> 
> import org.openjdk.jmh.annotations.*;
> 
> @State(Scope.Thread)
> public class DateBench {
> 
>    public java.sql.Time time = java.sql.Time.valueOf("15:15:25");
> 
>    @Benchmark
>    public String timeToString() {
>        return time.toString();
>    }
> 
>    public java.sql.Date date = java.sql.Date.valueOf("2013-01-01");
> 
>    @Benchmark
>    public String dateToString() {
>        return date.toString();
>    }
> 
>    public Timestamp timestamp = Timestamp.valueOf("1999-12-13 15:15:25.645634");
> 
>    @Benchmark
>    public String timestampToString() {
>        return timestamp.toString();
>    }
> 
> }



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From Ulf.Zibis at CoSoCo.de  Thu Sep 11 15:39:41 2014
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 11 Sep 2014 17:39:41 +0200
Subject: RFR: 8058230: Improve java.sql toString formatting
In-Reply-To: <5411B535.7040903@oracle.com>
References: <5411B535.7040903@oracle.com>
Message-ID: <5411C23D.6030304@CoSoCo.de>

Maybe consider https://bugs.openjdk.java.net/browse/JDK-6914113
Especially note the last comment there.

-Ulf

Am 11.09.2014 um 16:44 schrieb Claes Redestad:
> Hi,
>
> requesting reviews for this patch which optimizes java.sql.Date/Time/Timestamp::toString
> by avoiding some unnecessary object allocations. java.sql.Date had similar optimizations
> applied which this patch improves upon.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8058230
> webrev: http://cr.openjdk.java.net/~redestad/8058230/webrev.00/
>
> Testing: jtreg jdk/test/java/sql with and without 8057826 tests
>
> Before/after performance running a minimal JMH micro[1]:
>
> Benchmark                         Mode  Samples      Score Score error   Units
> t.DateBench.dateToString         thrpt       20 30225.628 623.887  ops/ms
> t.DateBench.dateToString         thrpt       20 38350.173 1349.432  ops/ms  # 1.3x
>
> t.DateBench.timeToString         thrpt       20 11793.338 232.121  ops/ms
> t.DateBench.timeToString         thrpt       20 47048.344 1969.939  ops/ms  # 4.0x
>
> t.DateBench.timestampToString    thrpt       20 2529.601 45.990  ops/ms
> t.DateBench.timestampToString    thrpt       20 14143.612 407.351  ops/ms  # 5.6x
>
> /Claes
>
> [1]
>
> package test;
>
> import org.openjdk.jmh.annotations.*;
>
> @State(Scope.Thread)
> public class DateBench {
>
>     public java.sql.Time time = java.sql.Time.valueOf("15:15:25");
>
>     @Benchmark
>     public String timeToString() {
>         return time.toString();
>     }
>
>     public java.sql.Date date = java.sql.Date.valueOf("2013-01-01");
>
>     @Benchmark
>     public String dateToString() {
>         return date.toString();
>     }
>
>     public Timestamp timestamp = Timestamp.valueOf("1999-12-13 15:15:25.645634");
>
>     @Benchmark
>     public String timestampToString() {
>         return timestamp.toString();
>     }
>
> }
>



From olivier.lagneau at oracle.com  Thu Sep 11 16:07:37 2014
From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com)
Date: Thu, 11 Sep 2014 18:07:37 +0200
Subject: Please review [9] RFR (S) : JDK-8039915 NumberFormat.format() does
	not consider required no. of fraction digits properly
In-Reply-To: <540F66B4.1080400@oracle.com>
References: <540F66B4.1080400@oracle.com>
Message-ID: <5411C8C9.8000400@oracle.com>

Could someone please review this code change ?

Thanks in advance,
Olivier Lagneau

On 09/09/2014 22:44, olivier.lagneau at oracle.com wrote:
> Please review this fix in for wrong rounding-mode mode behavior of 
> NumberFormat.format(double) in HALF_UP case.
>
> https://bugs.openjdk.java.net/browse/JDK-8039915
>
> webrev: http://cr.openjdk.java.net/~olagneau/8039915/webrev.00 
> <http://cr.openjdk.java.net/%7Eolagneau/8039915/webrev.00>
>
> Bug came from a mix of a '5' and 'greater than 5' last digit, when 
> this digit was the last one.
>
> Fix consists in properly separating the two cases and cleanly test all 
> possible cases (see JDK-8039915 comments) for the HALF_UP rounding-mode.
>
> TieRoundingTest test has been extended with a few cases to check such 
> cases (last digit at the rounding position and != '5')
>
> testing: jtreg, jck8, jprt
>
> Best regards,
> Olivier Lagneau
>



From daniel.fuchs at oracle.com  Thu Sep 11 16:17:18 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 11 Sep 2014 18:17:18 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5410353C.3070705@oracle.com>
References: <54101EBF.7000003@oracle.com> <5410353C.3070705@oracle.com>
Message-ID: <5411CB0E.9060504@oracle.com>

On 9/10/14 1:25 PM, Alan Bateman wrote:
> On 10/09/2014 10:49, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a proposed patch for
>>
>> 8043306 - Provide a replacement for the API that allowed to listen
>>           for LogManager configuration changes
>> https://bugs.openjdk.java.net/browse/JDK-8043306
>>
>> Proposed Patch:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
>>
> It would be nice if ConfigurationListener could be an interface. I
> realize this might mean looking again at the security concerns in this
> area again to see if we could get away without requiring a construction
> time permission check. Clearly if it could be an interface then it begs
> the question as to why it's just not a Runnable but that probably means
> yet more effort to figure out the right security and whether the access
> control context should be recorded when registering.

Given that both Paul & Alan have indicated that they would prefer
to use interfaces for listeners, I have been working on a
version that uses 'Runnable'.

Thanks to Paul & Alan for all the suggestions that went into
this new patch (especially for refining the spec and suggesting
a nice way to rewrite addConfigurationListener() using lambdas)!

http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.03/

best regards,

-- daniel


From pavel.rappo at oracle.com  Thu Sep 11 16:23:08 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 11 Sep 2014 17:23:08 +0100
Subject: extcheck
Message-ID: <DF1BDD7A-AA34-4BC7-AA43-12DAA4BD2935@oracle.com>

Hi everyone,

We are thinking of removing the extcheck tool. For those who doesn't remember what it is, here is an extract from its man page:

extcheck(1)

NAME
      extcheck - jar conflict detection utility

SYNOPSIS
      extcheck [ -verbose ] [ -Joption ] targetfile.jar

DESCRIPTION
      The  extcheck utility checks a specified jar file for title and version conflicts with any extensions installed in the JDK software.  Before installing an
      extension, you can use this utility to see if the same or a more recent version of the extension is already installed...

We don't think it is widely used. And will become even less useful with upcoming modularization. Are there any good reasons to keep this thing in the JDK?

-Pavel



From huizhe.wang at oracle.com  Thu Sep 11 16:30:57 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 11 Sep 2014 09:30:57 -0700
Subject: XMLScanner-supplementary-characters
In-Reply-To: <54115291.6010403@oracle.com>
References: <CA+kOe09Ncrm5fWeGiKf4nB6eRPDnw3tShAo0i--GVUDnZM6v9A@mail.gmail.com>
	<5410CCA7.3000200@oracle.com> <54115291.6010403@oracle.com>
Message-ID: <5411CE41.1060309@oracle.com>


On 9/11/2014 12:43 AM, Alan Bateman wrote:
> On 10/09/2014 23:11, huizhe wang wrote:
>> Thanks Martin!
>>
>> Looks like the initial version of the jaxp port (from Xerces 2.7.1) 
>> missed the patch for reasons I don't know. I created a bug based on 
>> the very original bug report:
>> https://bugs.openjdk.java.net/browse/JDK-8058175
> Joe - what's the test coverage like of this area in OpenJDK? I see 
> Martin has pushed this change but I just wonder if there is an 
> opportunity to add or improve tests, particularly for subtle cases 
> like this.

Yes, it would have been nice if we could find the test. Unfortunately 
the original bug report was on old Apache Bugzilla that was retired a 
long time ago. I couldn't find any more information than I posted in 
JDK-8058175. It may be possible to create a new test, but since the 
patch has been in Apache over 10 years, plus as Martin said, it's been 
used at Google, I took the liberty to trust that the patch is fine so we 
didn't have to spend more time on a quite fix like this.

I took Martin's patch to run existing SQE and Unit tests, they did all pass.

Thanks,
Joe


> -Alan



From vladimir.x.ivanov at oracle.com  Thu Sep 11 16:33:41 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 11 Sep 2014 20:33:41 +0400
Subject: [9] Review request : JDK-8057707: TEST library enhancement: copy
	sun.hotspot.whitebox classes from hotspot repo and enhance
	lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java
In-Reply-To: <5409F9A7.9070208@oracle.com>
References: <5409F9A7.9070208@oracle.com>
Message-ID: <5411CEE5.50101@oracle.com>

Looks ok.

I don't like the idea of having 2 copies of WB API for hotspot and jdk.

But that's tolerable unless we have shared location for test libraries 
in top repository. Having reliable tests is more important IMO.

Best regards,
Vladimir Ivanov

On 9/5/14, 9:57 PM, Konstantin Shefov wrote:
> Hello,
>
> Please review the change in testlibrary
> https://bugs.openjdk.java.net/browse/JDK-8057707
> This change is needed for new tests for the feature "Lambda Form
> Reduction and Caching" https://bugs.openjdk.java.net/browse/JDK-8046703
>
> Webrev of the testlibrary change:
> http://cr.openjdk.java.net/~kshefov/8057707/webrev.00/
>
> JBS entry for new test dev is
> https://bugs.openjdk.java.net/browse/JDK-8057719
> Webrev for new tests is
> http://cr.openjdk.java.net/~kshefov/8057719/webrev.00/
>
> Thanks
>
> -Konstantin


From martinrb at google.com  Thu Sep 11 18:13:43 2014
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 11 Sep 2014 11:13:43 -0700
Subject: RFR: JDK-8056934: ZipInputStream does not correctly handle local
	header data descriptors with the optional signature missing
In-Reply-To: <5411508B.8090009@oracle.com>
References: <CA+kOe0_56ahydPyi0TJZWn5fhh-3Ss5bP=PaRqYGitwsy4EbwA@mail.gmail.com>
	<54049938.3040507@oracle.com>
	<CA+kOe0_1ngZYAM3w-fqmbww6T8h0ia_hd+Gzi50q8cJrp11o=g@mail.gmail.com>
	<5411508B.8090009@oracle.com>
Message-ID: <CA+kOe09d5SRqB8y5EpYfQyHC4E=8v+sY_OOVi3hGs3sxcWNK7Q@mail.gmail.com>

On Thu, Sep 11, 2014 at 12:34 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>  On 11/09/2014 01:21, Martin Buchholz wrote:
>
>
>> For the comment in ZipInputStream then it might be better to move that to
>> readEnd. My preference would be to not include the part starting "As of
>> 2014-08, phyton ..." as that might not interesting in years to come.
>
>
>  I moved the comment into readEnd's javadoc.  I think laying out the
> compatibility landscape is sufficiently useful that the comment about
> python's implementation should stay, especially given that python has no
> plans to "fix" theirs.
>
> Having the first 3 paragraphs in readEnd should be good (thanks), I would
> think that the notes on python and the link to its issue tracker might be
> better put into the JIRA issue for anyone that wants to dig into more of
> the history.
>

As you wish!


From huizhe.wang at oracle.com  Thu Sep 11 20:31:03 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 11 Sep 2014 13:31:03 -0700
Subject: RFR: 8057826 minor clean-up to the java.sql Date/Time/Timestamp
	tests
In-Reply-To: <54118B88.7090404@oracle.com>
References: <19576455-CB80-4BBA-BA09-ADF9C14AB731@oracle.com>
	<54118B88.7090404@oracle.com>
Message-ID: <54120687.9010308@oracle.com>

Looks good, Lance.

Best,
Joe

On 9/11/2014 4:46 AM, Claes Redestad wrote:
> Looks good to me, especially the added nanotime test coverage
>
> /Claes
>
> On 09/08/2014 07:31 PM, Lance Andersen wrote:
>> Hi,
>>
>> Looking for a reviewer for this minor clean-up to the java.sql 
>> Date/Time/Timestamp tests which adds support for DataProvider
>>
>> Webrev can be found here: 
>> http://cr.openjdk.java.net/~lancea/8057826/webrev.00/
>>
>> Best
>> Lance
>>
>>
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>>
>>
>>
>



From joe.darcy at oracle.com  Fri Sep 12 01:35:58 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 11 Sep 2014 18:35:58 -0700
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
Message-ID: <54124DFE.7000706@oracle.com>

Hello,

Hmmm. I haven't dived into the details of the code, but setScale calls 
out to divide functionality so it is plausible a bug in divide could 
cause a problem in setScale.

Thanks for the bug report,

-Joe

On 9/9/2014 1:30 AM, Robert Gibson wrote:
>
>
> Hi there,
>
> I came across a case in BigDecimal division where the dividend ends up getting mutated, which is rather strange for a seemingly immutable class! (It's a subset of the cases where the Burnikel-Ziegler algorithm is used, I haven't done the analysis to find out under which exact conditions it's triggered.)
>
> The attached patch - against the JDK8 version - should fix the problem, at the cost of an extra array copy.  Could somebody review and/or comment please?
>
> Thanks,
> Robert
>
> --- MutableBigInteger.java      2014-09-04 09:42:23.426815000 +0200
> +++ MutableBigInteger.java.patched      2014-09-04 09:46:21.344132000 +0200
> @@ -1261,19 +1261,20 @@
>               int sigma = (int) Math.max(0, n32 - b.bitLength());   // step 3: sigma = max{T | (2^T)*B < beta^n}
>               MutableBigInteger bShifted = new MutableBigInteger(b);
>               bShifted.safeLeftShift(sigma);   // step 4a: shift b so its length is a multiple of n
> -            safeLeftShift(sigma);     // step 4b: shift this by the same amount
> +            MutableBigInteger aShifted = new MutableBigInteger (this);
> +            aShifted.safeLeftShift(sigma);     // step 4b: shift a by the same amount
> -            // step 5: t is the number of blocks needed to accommodate this plus one additional bit
> -            int t = (int) ((bitLength()+n32) / n32);
> +            // step 5: t is the number of blocks needed to accommodate a plus one additional bit
> +            int t = (int) ((aShifted.bitLength()+n32) / n32);
>               if (t < 2) {
>                   t = 2;
>               }
> -            // step 6: conceptually split this into blocks a[t-1], ..., a[0]
> -            MutableBigInteger a1 = getBlock(t-1, t, n);   // the most significant block of this
> +            // step 6: conceptually split a into blocks a[t-1], ..., a[0]
> +            MutableBigInteger a1 = aShifted.getBlock(t-1, t, n);   // the most significant block of a
>               // step 7: z[t-2] = [a[t-1], a[t-2]]
> -            MutableBigInteger z = getBlock(t-2, t, n);    // the second to most significant block
> +            MutableBigInteger z = aShifted.getBlock(t-2, t, n);    // the second to most significant block
>               z.addDisjoint(a1, n);   // z[t-2]
>               // do schoolbook division on blocks, dividing 2-block numbers by 1-block numbers
> @@ -1284,7 +1285,7 @@
>                   ri = z.divide2n1n(bShifted, qi);
>                   // step 8b: z = [ri, a[i-1]]
> -                z = getBlock(i-1, t, n);   // a[i-1]
> +                z = aShifted.getBlock(i-1, t, n);   // a[i-1]
>                   z.addDisjoint(ri, n);
>                   quotient.addShifted(qi, i*n);   // update q (part of step 9)
>               }
> @@ -1292,7 +1293,7 @@
>               ri = z.divide2n1n(bShifted, qi);
>               quotient.add(qi);
> -           ri.rightShift(sigma);   // step 9: this and b were shifted, so shift back
> +           ri.rightShift(sigma);   // step 9: a and b were shifted, so shift back
>               return ri;
>           }
>       }



From stuart.marks at oracle.com  Fri Sep 12 01:48:44 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 11 Sep 2014 18:48:44 -0700
Subject: RFR [8046339] sun.rmi.transport.DGCAckHandler leaks memory
In-Reply-To: <540DF63E.7070201@oracle.com>
References: <53E8C819.10705@oracle.com> <540DF63E.7070201@oracle.com>
Message-ID: <541250FC.8000902@oracle.com>

Hi Ivan,

Sorry for not having gotten back to you earlier about this.

I'm uncomfortable with pushing in such a fix in the absence of a reproducer 
and/or a test case. Although the change itself seems sensible, the fact that we 
lack a reproducer means that we might not actually understand the problem. There 
is a lot of deep history in this area and it's very subtle, so I'd prefer not to 
proceed with fixes in the absence of a full understanding of the situation and a 
test case.

I don't think a test would actually have to run the system out of memory. It 
should be sufficient to use something like weak references or reflection to 
inspect the table to ensure that the reference of interest is no longer present 
after having executed the code path in question. The trick is to ensure that we 
exercise the timeout case instead of the normal release case. It's not obvious 
how to do that (and indeed that may have been the stumbling block in formulating 
the original test when this was first looked at a couple years ago).

Unfortunately I probably won't have time to dig into this until after JavaOne. 
We should pick it up after that, though.

s'marks



On 9/8/14 11:32 AM, Ivan Gerasimov wrote:
> This is a friendly reminder.
>
> Would anyone please be able to review this fix in RMI area?
> We have a few reports about this issue sometimes occurring, though no reliable
> reproducer.
> If someone comes up with the reproducer, the regtest can be added later.
>
> Sincerely yours,
> Ivan
>
> On 11.08.2014 17:41, Ivan Gerasimov wrote:
>> Hello everyone!
>>
>> It has been reported that under some conditions instances of
>> sun.rmi.transport.DGCAckHandler accumulate and can cause OOM Error.
>> This is because they are stored in the global DGCAckHandler.idTable map, and
>> may fail to be removed if a timeout has expired.
>>
>> The webrev contains a fix proposed by Darryl Mocek back in 2011.
>>
>> Unfortunately I couldn't come up with a regression test for the fix.
>> However, the fix looks obviously correct, especially taking into account the
>> comment to the constructor:
>>
>>      * References added to this DGCAckHandler will be held strongly
>>      * until its "release" method is invoked or (after the
>>      * "startTimer" method has been invoked) the timeout has expired.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8046339
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8046339/0/webrev/
>>
>> Sincerely yours,
>> Ivan
>>
>>
>>
>


From huizhe.wang at oracle.com  Fri Sep 12 04:57:20 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 11 Sep 2014 21:57:20 -0700
Subject: Replace uses of StringBuffer with StringBuilder[JAXP]
In-Reply-To: <CAPc8kR0ssn167sq+nM5rb+17E8XDr+JMerpKbwMKXgSfo=ZkBg@mail.gmail.com>
References: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>
	<54108630.1000907@oracle.com>
	<CAPc8kR2v7OzXGGAmRo9TCOC8CLcNrpiLi0PEU_8L=syihmy_Ng@mail.gmail.com>
	<5410CCF8.2030708@oracle.com>
	<CAPc8kR2EunVOi=kT7AQ7d3ZMacsk2R=yPh59cazbrkB87BeESg@mail.gmail.com>
	<CAPc8kR0ssn167sq+nM5rb+17E8XDr+JMerpKbwMKXgSfo=ZkBg@mail.gmail.com>
Message-ID: <54127D30.1060209@oracle.com>

I see. So you're looking for a sponsor. Unfortunately, I personally 
don't have circles.  It would be great if you could find a sponsor.

JAXP sources came from Apache that still supports JDK 1.4. A very large 
amount of code therefore are obsolete with regards to the source level. 
But it's not currently a high priority.  We can clean them up (along 
with many improvement) when we touch those classes for bug fixes or 
update relevant component.

-Joe

On 9/11/2014 3:49 AM, Ot?vio Gon?alves de Santana wrote:
> Actually it doesn't work.
> I can't send a push or create a remote branch.
> Can you help me?
> When I submit a patch, I normally send a path file how it in 
> attachment and the webdev:
> https://dl.dropboxusercontent.com/u/16109193/open_jdk/jax%E1%B9%95/string_buffer_2_string_builder.zip
>
> On Thu, Sep 11, 2014 at 7:06 AM, Ot?vio Gon?alves de Santana 
> <otaviojava at java.net <mailto:otaviojava at java.net>> wrote:
>
>     Hi Huizhe.
>     Done.
>
>     creates new remote head d053915e3689!
>
>     On Wed, Sep 10, 2014 at 7:13 PM, huizhe wang
>     <huizhe.wang at oracle.com <mailto:huizhe.wang at oracle.com>> wrote:
>
>         Hi Otavio,
>
>         Please let me know once you've submitted it.
>
>         Best,
>         Joe
>
>
>         On 9/10/2014 10:40 AM, Ot?vio Gon?alves de Santana wrote:
>>
>>         Hi Wang.
>>         Thank you for this information.
>>         I have the OCA
>>
>>         On Sep 10, 2014 2:11 PM, "huizhe wang"
>>         <huizhe.wang at oracle.com <mailto:huizhe.wang at oracle.com>> wrote:
>>
>>             Hi Otavio,
>>
>>             I'm glad to know you're interested in contributing to the
>>             JAXP project. The JAXP standalone itself has reached
>>             end-of-life. We're now concentrating on JAXP in OpenJDK.
>>             The repo is here: http://hg.openjdk.java.net/jdk9/dev/jaxp
>>
>>             If you are interested in contributing to OpenJDK/jaxp,
>>             please read 'How to contribute' and sign the OCA:
>>             http://openjdk.java.net/contribute/
>>
>>             Thanks,
>>             Joe
>>
>>             On 9/9/2014 6:10 PM, Ot?vio Gon?alves de Santana wrote:
>>
>>                 Similar to:
>>                 https://bugs.openjdk.java.net/browse/JDK-8041679
>>
>>                 But in JAXP project:
>>
>>                 https://dl.dropboxusercontent.com/u/16109193/open_jdk/jax%E1%B9%95/string_buffer_2_string_builder.zip
>>
>>
>
>
>
>
>     -- 
>     Ot?vio Gon?alves de Santana
>
>     blog: http://otaviosantana.blogspot.com.br/
>     twitter: http://twitter.com/otaviojava
>     site: _http://about.me/otaviojava_
>     55 (11) 98255-3513 <tel:55%20%2811%29%2098255-3513>
>
>
>
>
> -- 
> Ot?vio Gon?alves de Santana
>
> blog: http://otaviosantana.blogspot.com.br/
> twitter: http://twitter.com/otaviojava
> site: _http://about.me/otaviojava_
> 55 (11) 98255-3513



From mandy.chung at oracle.com  Fri Sep 12 05:41:01 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 Sep 2014 22:41:01 -0700
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5411CB0E.9060504@oracle.com>
References: <54101EBF.7000003@oracle.com> <5410353C.3070705@oracle.com>
	<5411CB0E.9060504@oracle.com>
Message-ID: <5412876D.90609@oracle.com>


On 9/11/2014 9:17 AM, Daniel Fuchs wrote:
> On 9/10/14 1:25 PM, Alan Bateman wrote:
>> On 10/09/2014 10:49, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a proposed patch for
>>>
>>> 8043306 - Provide a replacement for the API that allowed to listen
>>>           for LogManager configuration changes
>>> https://bugs.openjdk.java.net/browse/JDK-8043306
>>>
>>> Proposed Patch:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
>>>
>> It would be nice if ConfigurationListener could be an interface. I
>> realize this might mean looking again at the security concerns in this
>> area again to see if we could get away without requiring a construction
>> time permission check. Clearly if it could be an interface then it begs
>> the question as to why it's just not a Runnable but that probably means
>> yet more effort to figure out the right security and whether the access
>> control context should be recorded when registering.
>
> Given that both Paul & Alan have indicated that they would prefer
> to use interfaces for listeners, I have been working on a
> version that uses 'Runnable'.
>
> Thanks to Paul & Alan for all the suggestions that went into
> this new patch (especially for refining the spec and suggesting
> a nice way to rewrite addConfigurationListener() using lambdas)!
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.03/

Looks good to me.  It's much cleaner.

Mandy


From peter.levart at gmail.com  Fri Sep 12 06:26:05 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 12 Sep 2014 08:26:05 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5410630B.4050100@oracle.com>
References: <54101EBF.7000003@oracle.com>	<BLU175-W47B685942A91FF963A848083CF0@phx.gbl>
	<5410630B.4050100@oracle.com>
Message-ID: <541291FD.1090600@gmail.com>

On 09/10/2014 04:41 PM, Daniel Fuchs wrote:
> On 9/10/14 4:28 PM, Jason Mehrens wrote:
>> Daniel
>>
>>
>> I think you should be able to remove the 'other instanceof 
>> ConfigurationListener' branch in the ConfigurationListener.equals 
>> method.  Should work the same with or without that branch.
>
> Oh yes. I put it there just to avoid it being flagged by
> NetBeans:
>   'equals() method not checking type of its parameters'
> I guess it would be better to just return this == other;
> (which unfortunately doesn't remove the warning)

What about using: super.equals(o) ? Does it remove the warning?

Peter

> but at least the intent would be clear.
>
> Thanks Jason!
>
> -- daniel
>
>>
>>
>>
>> Jason
>>
>>
>>
>> ----------------------------------------
>>> Date: Wed, 10 Sep 2014 11:49:51 +0200
>>> From: daniel.fuchs at oracle.com
>>> To: core-libs-dev at openjdk.java.net
>>> Subject: RFR: 8043306 - Provide a replacement for the API that 
>>> allowed to listen for LogManager configuration changes
>>>
>>> Hi,
>>>
>>> Please find below a proposed patch for
>>>
>>> 8043306 - Provide a replacement for the API that allowed to listen
>>> for LogManager configuration changes
>>> https://bugs.openjdk.java.net/browse/JDK-8043306
>>>
>>> Proposed Patch:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
>>>
>>> JDK-8029805 Removed LogManager addPropertyChangeListener
>>> and removePropertyChangeListener methods which were
>>> deprecated. These methods were deprecated in Java SE 8 and
>>> flagged for removal because they were problematic for
>>> modularity efforts.
>>> The idea was that an application needing to be informed of
>>> configuration changes could subclass LogManager and override
>>> readConfiguration.
>>>
>>> The proposed patch adds to new methods to LogManager:
>>>
>>> public void
>>> LogManager.addConfigurationListener(LogManager.ConfigurationListener
>>> listener);
>>> public void
>>> LogManager.removeConfigurationListener(LogManager.ConfigurationListener
>>> listener);
>>>
>>> These methods can be used by those applications for which subclassing
>>> LogManager would be too impractical.
>>>
>>> best regards,
>>>
>>> -- daniel
>



From peter.levart at gmail.com  Fri Sep 12 07:14:06 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 12 Sep 2014 09:14:06 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5411CB0E.9060504@oracle.com>
References: <54101EBF.7000003@oracle.com> <5410353C.3070705@oracle.com>
	<5411CB0E.9060504@oracle.com>
Message-ID: <54129D3E.8020200@gmail.com>

On 09/11/2014 06:17 PM, Daniel Fuchs wrote:
> On 9/10/14 1:25 PM, Alan Bateman wrote:
>> On 10/09/2014 10:49, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a proposed patch for
>>>
>>> 8043306 - Provide a replacement for the API that allowed to listen
>>>           for LogManager configuration changes
>>> https://bugs.openjdk.java.net/browse/JDK-8043306
>>>
>>> Proposed Patch:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
>>>
>> It would be nice if ConfigurationListener could be an interface. I
>> realize this might mean looking again at the security concerns in this
>> area again to see if we could get away without requiring a construction
>> time permission check. Clearly if it could be an interface then it begs
>> the question as to why it's just not a Runnable but that probably means
>> yet more effort to figure out the right security and whether the access
>> control context should be recorded when registering.
>
> Given that both Paul & Alan have indicated that they would prefer
> to use interfaces for listeners, I have been working on a
> version that uses 'Runnable'.
>
> Thanks to Paul & Alan for all the suggestions that went into
> this new patch (especially for refining the spec and suggesting
> a nice way to rewrite addConfigurationListener() using lambdas)!
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.03/
>
> best regards,
>
> -- daniel

Hi Daniel,

Just a question about security and delayed execution...

If at the time the configuration listener is added to the LogManager, 
SecurityManager is not set, the listener will be invoked directly even 
if at time the listener is invoked, SM has been set. For example:


         LogManager.getLogManager().addConfigurationListener(...);
         ...
         System.setSecurityManager(...);
         ...
         // then somewhere in privileged context...
         LogManager.getLogManager().readConfiguration(...);


Wouldn't it be cleaner to evaluate SM presence in the lambda wrapper 
which would always be constructed, like that:


     public LogManager addConfigurationListener(Runnable listener) {
         final Runnable r = Objects.requireNonNull(listener);
         checkPermission();
         final AccessControlContext acc = AccessController.getContext();
         final Runnable pr = () -> {
             if (System.getSecurityManager() == null) {
                 r.run();
             } else {
AccessController.doPrivileged((PrivilegedAction<Void>) () -> {
                     r.run();
                     return null;
                 }, acc);
             }
         };
         // Will do nothing if already registered.
         listeners.putIfAbsent(r, pr);
         return this;
     }


Regards, Peter



From stanimir at riflexo.com  Fri Sep 12 07:47:20 2014
From: stanimir at riflexo.com (Stanimir Simeonoff)
Date: Fri, 12 Sep 2014 10:47:20 +0300
Subject: RFR: 8043306 - Provide a replacement for the API that allowed to
	listen for LogManager configuration changes
In-Reply-To: <54129D3E.8020200@gmail.com>
References: <54101EBF.7000003@oracle.com> <5410353C.3070705@oracle.com>
	<5411CB0E.9060504@oracle.com> <54129D3E.8020200@gmail.com>
Message-ID: <CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>

Hello,

Just a note, acc is going to leak the context class loader until the
listener is removed. That should be noted in the documentation.

Also if there is a runtime exception during run() of a listener it will
block any other listeners to be invoked and the exception is going to be
propagated past readConfiguration(). I suppose that's ok however the
listeners are to be invoked in a 'random' order depending on their
identityHashCode. So if there is an exception in the last registered there
is no guarantee to invoke even the 1st added listener. The entire process
is not deterministic which is not ok for listeners invocation.

Stanimir


From Alan.Bateman at oracle.com  Fri Sep 12 07:55:51 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Sep 2014 08:55:51 +0100
Subject: [9] Review request : JDK-8057707: TEST library enhancement: copy
	sun.hotspot.whitebox classes from hotspot repo and enhance
	lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java
In-Reply-To: <5411CEE5.50101@oracle.com>
References: <5409F9A7.9070208@oracle.com> <5411CEE5.50101@oracle.com>
Message-ID: <5412A707.50205@oracle.com>

On 11/09/2014 17:33, Vladimir Ivanov wrote:
> Looks ok.
>
> I don't like the idea of having 2 copies of WB API for hotspot and jdk.
>
> But that's tolerable unless we have shared location for test libraries 
> in top repository. Having reliable tests is more important IMO.
Has there been any thought put in to use the jtreg's multi-root 
capability? For some time it has been possible to run subsets of jdk and 
hotspot tests with a single jtreg command. I don't know if it helps here 
but it would be good to avoid having to duplicate the code.

-Alan


From Alan.Bateman at oracle.com  Fri Sep 12 08:05:42 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Sep 2014 09:05:42 +0100
Subject: Replace uses of StringBuffer with StringBuilder[JAXP]
In-Reply-To: <54127D30.1060209@oracle.com>
References: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>	<54108630.1000907@oracle.com>	<CAPc8kR2v7OzXGGAmRo9TCOC8CLcNrpiLi0PEU_8L=syihmy_Ng@mail.gmail.com>	<5410CCF8.2030708@oracle.com>	<CAPc8kR2EunVOi=kT7AQ7d3ZMacsk2R=yPh59cazbrkB87BeESg@mail.gmail.com>	<CAPc8kR0ssn167sq+nM5rb+17E8XDr+JMerpKbwMKXgSfo=ZkBg@mail.gmail.com>
	<54127D30.1060209@oracle.com>
Message-ID: <5412A956.8030402@oracle.com>

On 12/09/2014 05:57, huizhe wang wrote:
> I see. So you're looking for a sponsor. Unfortunately, I personally 
> don't have circles.  It would be great if you could find a sponsor.
>
> JAXP sources came from Apache that still supports JDK 1.4. A very 
> large amount of code therefore are obsolete with regards to the source 
> level. But it's not currently a high priority.  We can clean them up 
> (along with many improvement) when we touch those classes for bug 
> fixes or update relevant component.
>
> -Joe
I assume Ot?vio is looking to contribute the changes to OpenJDK rather 
than the defunct JAXP project. But perhaps your concern is changing the 
Xerces and Xalan code so that it diverges from the upstream sources? I 
assume there isn't any issue with switching the JAXP API and other 
non-Apache code to use StringBuilder.

-Alan.


From miroslav.kos at oracle.com  Fri Sep 12 08:39:32 2014
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Fri, 12 Sep 2014 10:39:32 +0200
Subject: [9] RFR: JDK-8054548: JAX-WS tools need to updated to work with
	modular image
In-Reply-To: <541197FE.4060605@oracle.com>
References: <54118582.3020004@oracle.com> <541197FE.4060605@oracle.com>
Message-ID: <5412B144.7020407@oracle.com>

On 11/09/14 14:39, Alan Bateman wrote:
> On 11/09/2014 12:20, Miroslav Kos wrote:
>> Hello,
>> please review following change:
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8054548
>> webrev: http://cr.openjdk.java.net/~mkos/8054548/jaxws.00/
>>
>> It is basically replacing obsolete code using core reflection by 
>> javax.tools API plus removing old unused code.
> Thanks for doing this, it's good to get this cleaned up.
>
> The changes looks reasonable but I wonder if they are complete. I ask 
> because I assumed that JavaCompilerHelper.getJarFile would be removed. 
> Also there appears to be a bit of skullduggery in both wsimport and 
> wsgen involving -Xbootclasspath/p where it might be assuming that the 
> JAXB or JAX-WS classes are being loaded from JAR files (I didn't did 
> into ParallelWorldClassLoader.toJarUrl so perhaps it can deal with 
> other URLs).
I agree that the code looks scary, but it's because we have to support 
range of jdk (currently jdk6 to jdk9) and we want to avoid maintaining 
several branches. The standalone project must work even with jdk6. The 
magic here is to make the latest JAX-WS working with jdk6.
1.6 contain old JAX-B/WS API versions (2.1) and this tricky code allows 
to load newer (2.2) javax.xml.* classes from jars on classpath (without 
having to use java endorsed mechanism) when running standalone JAX-WS on 
the top of JDK6. Hope it is not too confusing.

Anyway I found some more code to cleanup - one more class can be removed 
- see version 2:
http://cr.openjdk.java.net/~mkos/8054548/jaxws.01/

> In passing, I assume the comments in Invoker should use "ClassLoader" 
> or "class loader". 
fixed.

> Also the comment in createClassLoader mentions JAXB/WS 2.1 and not 
> clear how this relates to the method description where it talked about 
> 2.2
>
> In JavacompilerMessages then noJavaCompilerError() and 
> localizedNoJavaCompilerError() might be nicer names (in case you are 
> looking for something better).
Those are generated methods from resource bundle using maven plugin. I 
think we own the plugin, but I would need to dive into it little bit, 
not sure if it is worth it.

M.

>
> -Alan.



From daniel.fuchs at oracle.com  Fri Sep 12 08:41:23 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 Sep 2014 10:41:23 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>
	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>
Message-ID: <5412B1B3.4090708@oracle.com>

Hi Stanimir,

On 9/12/14 9:47 AM, Stanimir Simeonoff wrote:
> Hello,
>
> Just a note, acc is going to leak the context class loader until the
> listener is removed. That should be noted in the documentation.

Good point. But I expect the concrete listener class will also be 
usually loaded by the context class loader - so isn't that kind of 
expected anyway?
I didn't want to stuff too many implementation details into the spec.
Maybe that could be an API note however.
Would anyone be able to suggest a good wording?

> Also if there is a runtime exception during run() of a listener it will
> block any other listeners to be invoked and the exception is going to be
> propagated past readConfiguration(). I suppose that's ok however the
> listeners are to be invoked in a 'random' order depending on their
> identityHashCode. So if there is an exception in the last registered
> there is no guarantee to invoke even the 1st added listener. The entire
> process is not deterministic which is not ok for listeners invocation.

The 'old' deprecated code was already like that.
This doesn't mean we shouldn't try to make it better - but I have
to ask whether it's worth the trouble.

Are there applications where there will be several listeners?
And if there are - shouldn't these listener run their code in a
try { } catch ( ) { } to ensure that the exception will be
logged - or rather reported - where it belong?

IMO the only thing we could do here is to silently drop any
runtime/exception or error, which I am a bit reluctant to do;
I believe it's the concrete implementation of the listener
which should take care of that.

best regards,

-- daniel

>
> Stanimir
>



From daniel.fuchs at oracle.com  Fri Sep 12 08:42:10 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 Sep 2014 10:42:10 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <541291FD.1090600@gmail.com>
References: <54101EBF.7000003@oracle.com>	<BLU175-W47B685942A91FF963A848083CF0@phx.gbl>
	<5410630B.4050100@oracle.com> <541291FD.1090600@gmail.com>
Message-ID: <5412B1E2.8050600@oracle.com>

Hi Peter,

On 9/12/14 8:26 AM, Peter Levart wrote:
>> Oh yes. I put it there just to avoid it being flagged by
>> NetBeans:
>>   'equals() method not checking type of its parameters'
>> I guess it would be better to just return this == other;
>> (which unfortunately doesn't remove the warning)
>
> What about using: super.equals(o) ? Does it remove the warning?
>

Well - the latest webrev uses Runnable and IdentityHashMap so
the problem has solved itself ;-)
(http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.03/)

But for the record - no - super.equals(o) was my first implementation,
which triggered the warning in the first place...
Just to be clear: it was not a compiler warning - only an editor
warning.

best regards,

-- daniel


From daniel.fuchs at oracle.com  Fri Sep 12 08:50:17 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 Sep 2014 10:50:17 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <54129D3E.8020200@gmail.com>
References: <54101EBF.7000003@oracle.com> <5410353C.3070705@oracle.com>
	<5411CB0E.9060504@oracle.com> <54129D3E.8020200@gmail.com>
Message-ID: <5412B3C9.9010506@oracle.com>

Hi Peter,

On 9/12/14 9:14 AM, Peter Levart wrote:
 > Wouldn't it be cleaner to evaluate SM presence in the lambda wrapper
 > which would always be constructed, like that:
 >

Well - then we would always be storing the ACC, so
maybe we could just always call
AccessController.doPrivileged, whether there's
a security manager or not.

Do you think it would be cleaner?

best regards,

-- daniel


On 9/12/14 9:14 AM, Peter Levart wrote:
> On 09/11/2014 06:17 PM, Daniel Fuchs wrote:
>> On 9/10/14 1:25 PM, Alan Bateman wrote:
>>> On 10/09/2014 10:49, Daniel Fuchs wrote:
>>>> Hi,
>>>>
>>>> Please find below a proposed patch for
>>>>
>>>> 8043306 - Provide a replacement for the API that allowed to listen
>>>>           for LogManager configuration changes
>>>> https://bugs.openjdk.java.net/browse/JDK-8043306
>>>>
>>>> Proposed Patch:
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.00/
>>>>
>>> It would be nice if ConfigurationListener could be an interface. I
>>> realize this might mean looking again at the security concerns in this
>>> area again to see if we could get away without requiring a construction
>>> time permission check. Clearly if it could be an interface then it begs
>>> the question as to why it's just not a Runnable but that probably means
>>> yet more effort to figure out the right security and whether the access
>>> control context should be recorded when registering.
>>
>> Given that both Paul & Alan have indicated that they would prefer
>> to use interfaces for listeners, I have been working on a
>> version that uses 'Runnable'.
>>
>> Thanks to Paul & Alan for all the suggestions that went into
>> this new patch (especially for refining the spec and suggesting
>> a nice way to rewrite addConfigurationListener() using lambdas)!
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.03/
>>
>> best regards,
>>
>> -- daniel
>
> Hi Daniel,
>
> Just a question about security and delayed execution...
>
> If at the time the configuration listener is added to the LogManager,
> SecurityManager is not set, the listener will be invoked directly even
> if at time the listener is invoked, SM has been set. For example:
>
>
>          LogManager.getLogManager().addConfigurationListener(...);
>          ...
>          System.setSecurityManager(...);
>          ...
>          // then somewhere in privileged context...
>          LogManager.getLogManager().readConfiguration(...);
>
>
> Wouldn't it be cleaner to evaluate SM presence in the lambda wrapper
> which would always be constructed, like that:
>
>
>      public LogManager addConfigurationListener(Runnable listener) {
>          final Runnable r = Objects.requireNonNull(listener);
>          checkPermission();
>          final AccessControlContext acc = AccessController.getContext();
>          final Runnable pr = () -> {
>              if (System.getSecurityManager() == null) {
>                  r.run();
>              } else {
> AccessController.doPrivileged((PrivilegedAction<Void>) () -> {
>                      r.run();
>                      return null;
>                  }, acc);
>              }
>          };
>          // Will do nothing if already registered.
>          listeners.putIfAbsent(r, pr);
>          return this;
>      }
>
>
> Regards, Peter
>



From Alan.Bateman at oracle.com  Fri Sep 12 09:21:25 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Sep 2014 10:21:25 +0100
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <54129D3E.8020200@gmail.com>
References: <54101EBF.7000003@oracle.com> <5410353C.3070705@oracle.com>
	<5411CB0E.9060504@oracle.com> <54129D3E.8020200@gmail.com>
Message-ID: <5412BB15.6040708@oracle.com>

On 12/09/2014 08:14, Peter Levart wrote:
> :
>
> Just a question about security and delayed execution...
>
> If at the time the configuration listener is added to the LogManager, 
> SecurityManager is not set, the listener will be invoked directly even 
> if at time the listener is invoked, SM has been set.
True but we typically don't get concerned about this. That is all bets 
are off if you allow untrusted code to run before setting the security 
manager. So normally the assumption is that you are either running with 
or without a security manager, ignoring the case when it might be set or 
unset mid-flight. Also for the common case (running without a security 
manager) then you avoid needing to stash away the access control context 
as that has a number of side effects (Stanimir has picked up on this). 
Clearly there is a timing issue with code that runs early in the startup 
before the system class loader has fully initialized and the security 
manager set but great care has to be taken in those code paths.

-Alan


From stanimir at riflexo.com  Fri Sep 12 09:24:04 2014
From: stanimir at riflexo.com (Stanimir Simeonoff)
Date: Fri, 12 Sep 2014 12:24:04 +0300
Subject: RFR: 8043306 - Provide a replacement for the API that allowed to
	listen for LogManager configuration changes
In-Reply-To: <5412B1B3.4090708@oracle.com>
References: <54101EBF.7000003@oracle.com> <5410353C.3070705@oracle.com>
	<5411CB0E.9060504@oracle.com> <54129D3E.8020200@gmail.com>
	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>
	<5412B1B3.4090708@oracle.com>
Message-ID: <CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>

>
> Good point. But I expect the concrete listener class will also be usually
> loaded by the context class loader - so isn't that kind of expected anyway?
> I didn't want to stuff too many implementation details into the spec.
> Maybe that could be an API note however.
> Would anyone be able to suggest a good wording?
>


On leaks. The c-tor of LogManager leaks the thread group and the current
AccessControlContext till JVM shutdown. The constructor code should be
something like the one below with Cleaner getting ThreadGroup in its c-tor
as well.


    java.security.AccessController.doPrivileged(//zip
thread.inheritedAccessControlContext
        new java.security.PrivilegedAction<Void>() {
        public Void run() {
            // put the cleaner in the systsm threadgroup
            ThreadGroup grp =
Thread.currentThread().getThreadGroup();
            for(ThreadGroup parent;null!=(parent = grp.getParent());) {
                grp = parent;
            }

            Cleaner cleaner = new Thread(grp);
            cleaner.setContextClassLoader(null);//zip the classloader

            // Add a shutdown hook to close the global handlers.
            try {
                Runtime.getRuntime().addShutdownHook(cleaner);
            } catch (IllegalStateException e) {
                // If the VM is already shutting down,
                // We do not need to register shutdownHook.
            }

            return null;
        }
    });


 Also if there is a runtime exception during run() of a listener it will
>> block any other listeners to be invoked and the exception is going to be
>> propagated past readConfiguration(). I suppose that's ok however the
>> listeners are to be invoked in a 'random' order depending on their
>> identityHashCode. So if there is an exception in the last registered
>> there is no guarantee to invoke even the 1st added listener. The entire
>> process is not deterministic which is not ok for listeners invocation.
>>
>
> The 'old' deprecated code was already like that.
> This doesn't mean we shouldn't try to make it better - but I have
> to ask whether it's worth the trouble.
>
> However the listeners are to be invoked in the same order they have been
added.


> Are there applications where there will be several listeners?
>

Not sure, however listeners can be added at any time.
readConfiguration(InputStream) is public too, so it's plausible.


> And if there are - shouldn't these listener run their code in a
> try { } catch ( ) { } to ensure that the exception will be
> logged - or rather reported - where it belong?
>

IMO, the API can't demand any cooperation from user space code .


> IMO the only thing we could do here is to silently drop any
> runtime/exception or error, which I am a bit reluctant to do;
> I believe it's the concrete implementation of the listener
> which should take care of that.
>
> I'd rather run the listeners in try/catch and throw the 1st exception at
the end.
Defining the 1st however requires obeying the order the listeners have been
added.
As far as I see there is no documentation how the listeners are supposed to
behave or be invoked.


Stanimir


From otaviojava at java.net  Fri Sep 12 09:40:05 2014
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Fri, 12 Sep 2014 06:40:05 -0300
Subject: Replace uses of StringBuffer with StringBuilder[JAXP]
In-Reply-To: <5412A956.8030402@oracle.com>
References: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>
	<54108630.1000907@oracle.com>
	<CAPc8kR2v7OzXGGAmRo9TCOC8CLcNrpiLi0PEU_8L=syihmy_Ng@mail.gmail.com>
	<5410CCF8.2030708@oracle.com>
	<CAPc8kR2EunVOi=kT7AQ7d3ZMacsk2R=yPh59cazbrkB87BeESg@mail.gmail.com>
	<CAPc8kR0ssn167sq+nM5rb+17E8XDr+JMerpKbwMKXgSfo=ZkBg@mail.gmail.com>
	<54127D30.1060209@oracle.com> <5412A956.8030402@oracle.com>
Message-ID: <CAPc8kR3QrkjEDpg9-V1ygTo2LQX7C+VNpxxMLegjJoivuusFtg@mail.gmail.com>

@Alan
Yes, I would like help the jaxp in openjdk project.
But I thought that were different projects, but how are the same.
I believe will the same process.
So I will waiting to a sponsor.

@huizhe
Yes, I see the code is a little deprecated, I will try improve it as I can.

On Fri, Sep 12, 2014 at 5:05 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 12/09/2014 05:57, huizhe wang wrote:
>
>> I see. So you're looking for a sponsor. Unfortunately, I personally don't
>> have circles.  It would be great if you could find a sponsor.
>>
>> JAXP sources came from Apache that still supports JDK 1.4. A very large
>> amount of code therefore are obsolete with regards to the source level. But
>> it's not currently a high priority.  We can clean them up (along with many
>> improvement) when we touch those classes for bug fixes or update relevant
>> component.
>>
>> -Joe
>>
> I assume Ot?vio is looking to contribute the changes to OpenJDK rather
> than the defunct JAXP project. But perhaps your concern is changing the
> Xerces and Xalan code so that it diverges from the upstream sources? I
> assume there isn't any issue with switching the JAXP API and other
> non-Apache code to use StringBuilder.
>
> -Alan.
>



-- 
Ot?vio Gon?alves de Santana

blog:     http://otaviosantana.blogspot.com.br/
twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
55 (11) 98255-3513


From Alan.Bateman at oracle.com  Fri Sep 12 09:51:09 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Sep 2014 10:51:09 +0100
Subject: [9] RFR: JDK-8054548: JAX-WS tools need to updated to work with
	modular image
In-Reply-To: <5412B144.7020407@oracle.com>
References: <54118582.3020004@oracle.com> <541197FE.4060605@oracle.com>
	<5412B144.7020407@oracle.com>
Message-ID: <5412C20D.8080901@oracle.com>

On 12/09/2014 09:39, Miroslav Kos wrote:
> I agree that the code looks scary, but it's because we have to support 
> range of jdk (currently jdk6 to jdk9) and we want to avoid maintaining 
> several branches. The standalone project must work even with jdk6. The 
> magic here is to make the latest JAX-WS working with jdk6.
> 1.6 contain old JAX-B/WS API versions (2.1) and this tricky code 
> allows to load newer (2.2) javax.xml.* classes from jars on classpath 
> (without having to use java endorsed mechanism) when running 
> standalone JAX-WS on the top of JDK6. Hope it is not too confusing.
Once we are further along with modules in the JDK 9 then I expect that 
-Xbootclasspath/p will go away (to be replaced by an alternative 
facility to override the classes in modules that are linked into the 
runtime image).  So is this wsgen and wsimport code only used with JDK 
6? Maybe that is okay but at the same time I would hope these APIs could 
leave JDK 6 behind some day, otherwise it makes it impossible to use 
language features and APIs.

>
> Anyway I found some more code to cleanup - one more class can be 
> removed - see version 2:
> http://cr.openjdk.java.net/~mkos/8054548/jaxws.01/
>
The update looks okay to me. I guess we'll have to see if other changes 
are required as we move forward. Also thanks for the explanation about 
JavacompilerMessages.java being auto-generated, there isn't anything in 
the header that makes this obvious (maybe the plugin that you mentioned 
could be updated to generate something into the header?).

-Alan.



From Alan.Bateman at oracle.com  Fri Sep 12 10:02:48 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Sep 2014 11:02:48 +0100
Subject: Replace uses of StringBuffer with StringBuilder[JAXP]
In-Reply-To: <CAPc8kR3QrkjEDpg9-V1ygTo2LQX7C+VNpxxMLegjJoivuusFtg@mail.gmail.com>
References: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>
	<54108630.1000907@oracle.com>
	<CAPc8kR2v7OzXGGAmRo9TCOC8CLcNrpiLi0PEU_8L=syihmy_Ng@mail.gmail.com>
	<5410CCF8.2030708@oracle.com>
	<CAPc8kR2EunVOi=kT7AQ7d3ZMacsk2R=yPh59cazbrkB87BeESg@mail.gmail.com>
	<CAPc8kR0ssn167sq+nM5rb+17E8XDr+JMerpKbwMKXgSfo=ZkBg@mail.gmail.com>
	<54127D30.1060209@oracle.com> <5412A956.8030402@oracle.com>
	<CAPc8kR3QrkjEDpg9-V1ygTo2LQX7C+VNpxxMLegjJoivuusFtg@mail.gmail.com>
Message-ID: <5412C4C8.3090205@oracle.com>

On 12/09/2014 10:40, Ot?vio Gon?alves de Santana wrote:
> @Alan
> Yes, I would like help the jaxp in openjdk project.
> But I thought that were different projects, but how are the same.
> I believe will the same process.
> So I will waiting to a sponsor.
>
I understand it can be a bit confusing. In summary, the JAXP project on 
java.net is dead and the development is now in OpenJDK.

I can't speak for Joe (Huizhe) but I think part of this point was that 
he didn't want to have the Xerces/Xalan code diverge too much from the 
upstream Apache projects. If so then this shouldn't prevent doing 
clean-up on the non-Apache code in the jaxp repository. Maybe you could 
trim back to the changes and send them to someone that can upload them 
to cr.openjdk.java.net for discussion.

-Alan




From daniel.fuchs at oracle.com  Fri Sep 12 10:45:18 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 Sep 2014 12:45:18 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>
Message-ID: <5412CEBE.3000607@oracle.com>

Thanks Stanimir,

On 9/12/14 11:24 AM, Stanimir Simeonoff wrote:
> On leaks. The c-tor of LogManager leaks the thread group and the current
> AccessControlContext till JVM shutdown. The constructor code should be
> something like the one below with Cleaner getting ThreadGroup in its
> c-tor as well.
>
>
>      java.security.AccessController.doPrivileged(//zip
> thread.inheritedAccessControlContext
>          new java.security.PrivilegedAction<Void>() {
>          public Void run() {
>              // put the cleaner in the systsm threadgroup
>              ThreadGroup grp = Thread.currentThread().getThreadGroup();
>              for(ThreadGroup parent;null!=(parent = grp.getParent());) {
>                  grp = parent;
>              }
>
>              Cleaner cleaner = new Thread(grp);
>              cleaner.setContextClassLoader(null);//zip the classloader
>
>              // Add a shutdown hook to close the global handlers.
>              try {
>                  Runtime.getRuntime().addShutdownHook(cleaner);
>              } catch (IllegalStateException e) {
>                  // If the VM is already shutting down,
>                  // We do not need to register shutdownHook.
>              }
>
>              return null;
>          }
>      });

On Cleaner:
   Good point but this is a different issue.
   I have logged
   https://bugs.openjdk.java.net/browse/JDK-8058296
   Thanks for pointing that out.


>     The 'old' deprecated code was already like that.
>     This doesn't mean we shouldn't try to make it better - but I have
>     to ask whether it's worth the trouble.
>
> However the listeners are to be invoked in the same order they have been
> added.

I am still unconvinced this is worth the additional
complexity it would bring to the implementation.
The deprecated methods were using HashMap to store listeners,
and therefore the order in which listeners were invoked was also
undefined. Nobody has ever complained.

(http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/3ae82f0c6b31/src/share/classes/java/util/logging/LogManager.java#l1431)


> I'd rather run the listeners in try/catch and throw the 1st exception at
> the end.
> Defining the 1st however requires obeying the order the listeners have
> been added.
> As far as I see there is no documentation how the listeners are supposed
> to behave or be invoked.

We could do that - invoke all listeners and rethrow the exception
caught by the first listener that failed (on the basis that if any other
listener subsequently fails it may be because the previous listener
has left the system in an inconsistent state, and that therefore
the first exception caught has 'more value' than the others).

I am not completely convinced this is a better behavior than
simply stopping invoking listeners at the first exception.
I wonder if there would be a good wording to say that listeners
are not supposed to throw, but that if they do, the exceptions
will be propagated...

best regards,

-- daniel


>
>
> Stanimir
>
>
>



From igor.ignatyev at oracle.com  Fri Sep 12 10:45:21 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 12 Sep 2014 14:45:21 +0400
Subject: [9] Review request : JDK-8057719: Develop new tests for LambdaForm
	Reduction and Caching feature
In-Reply-To: <C937A851-BE1B-41B6-B2F0-0A839F65291B@oracle.com>
References: <5409F86D.8040200@oracle.com>
	<C937A851-BE1B-41B6-B2F0-0A839F65291B@oracle.com>
Message-ID: <5412CEC1.8040700@oracle.com>

Paul,

thanks for your review. I'll take care about this change, since 
Konstantin is on vacation.

updated webrev: 
http://cr.openjdk.java.net/~iignatyev/kshefov/8057719/webrev.00/

please see inline answers.

Igor

On 09/11/2014 05:12 PM, Paul Sandoz wrote:
>
> On Sep 5, 2014, at 7:52 PM, Konstantin Shefov <konstantin.shefov at oracle.com> wrote:
>
>> Hello,
>>
>> Please review the new tests for the feature "Lambda Form Reduction and Caching" https://bugs.openjdk.java.net/browse/JDK-8046703
>>
>> JBS task: https://bugs.openjdk.java.net/browse/JDK-8057719
>>
>> Webrev: http://cr.openjdk.java.net/~kshefov/8057719/webrev.00/
>>
>> These tests also depend on testlibrary change: https://bugs.openjdk.java.net/browse/JDK-8057707
>> Webrev of the testlib change: http://cr.openjdk.java.net/~kshefov/8057707/webrev.00/
>>
>
> Generally looks good. It would be interesting see code-coverage results.
>
> Are you sure the LFMultiThreadCachingTest is sufficiently testing the thread-safety of j.l.invoke classes? It might be that more threads need to be generated (== #cores), and the test repeatedly performed in a loop to increase the chance of stuff stomping on each other. (I see you have iterations in the outer loop of runTests, that might be sufficient, but you might need a tighter loop specific to each test in LFMultiThreadCachingTest).
>
good point, I updated LFMultiThreadCachingTest to use more threads, 
however I doubt that we need to add a loop. Writing additional MT-stress 
tests, which can provide more confidence on thread-safety, is out of the 
scope of JDK-8057719.

>
> A general comment, feel free to ignore. It's easy to use EnumSet to obtain a collection of enum values:
>
>    Set<TestMethods> tms = EnumSet.allOf(TestMethods.class)
>
> and filtered:
>
>    Set<TestMethods> tms = EnumSet.complementOf(EnumSet.of(TestMethods.IDENTITY, TestMethods.CONSTANT))
>
> (Quite concise with a static import.)
>
> Change LambdaFormTestCase.runTests to accept a Collection<TestMethods> and you are good to go :-)
done
>
> Paul.
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


From miroslav.kos at oracle.com  Fri Sep 12 10:51:49 2014
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Fri, 12 Sep 2014 12:51:49 +0200
Subject: [9] RFR: JDK-8054548: JAX-WS tools need to updated to work with
	modular image
In-Reply-To: <5412C20D.8080901@oracle.com>
References: <54118582.3020004@oracle.com> <541197FE.4060605@oracle.com>
	<5412B144.7020407@oracle.com> <5412C20D.8080901@oracle.com>
Message-ID: <5412D045.2000400@oracle.com>


On 12/09/14 11:51, Alan Bateman wrote:
> On 12/09/2014 09:39, Miroslav Kos wrote:
>> I agree that the code looks scary, but it's because we have to 
>> support range of jdk (currently jdk6 to jdk9) and we want to avoid 
>> maintaining several branches. The standalone project must work even 
>> with jdk6. The magic here is to make the latest JAX-WS working with 
>> jdk6.
>> 1.6 contain old JAX-B/WS API versions (2.1) and this tricky code 
>> allows to load newer (2.2) javax.xml.* classes from jars on classpath 
>> (without having to use java endorsed mechanism) when running 
>> standalone JAX-WS on the top of JDK6. Hope it is not too confusing.
> Once we are further along with modules in the JDK 9 then I expect that 
> -Xbootclasspath/p will go away (to be replaced by an alternative 
> facility to override the classes in modules that are linked into the 
> runtime image).  So is this wsgen and wsimport code only used with JDK 
> 6? Maybe that is okay but at the same time I would hope these APIs 
> could leave JDK 6 behind some day, otherwise it makes it impossible to 
> use language features and APIs.
This code is currently used for all the jdk versions, but works well 
with all of them (including modularized build) - it should create own 
modified class loader only when necessary. After dropping jdk6 support 
we would simplify the code. Unfortunately we can't simply use the newest 
language features, we may start using them with some delay (several 
steps behind the newest JDK) not to break the older (yet) supported jdks.
>
>>
>> Anyway I found some more code to cleanup - one more class can be 
>> removed - see version 2:
>> http://cr.openjdk.java.net/~mkos/8054548/jaxws.01/
>>
> The update looks okay to me. I guess we'll have to see if other 
> changes are required as we move forward. Also thanks for the 
> explanation about JavacompilerMessages.java being auto-generated, 
> there isn't anything in the header that makes this obvious (maybe the 
> plugin that you mentioned could be updated to generate something into 
> the header?).
Yes, you're right, some javadoc saying that would be helpful. I'll keep 
it in mind and will update the plugin. If you are ok with it, I would 
proceed with this change as it is for now and improved generated classes 
would go into jdk9 with next regular sync integration.

Thanks
Miran
>
> -Alan.
>



From otaviojava at java.net  Fri Sep 12 11:08:33 2014
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Fri, 12 Sep 2014 08:08:33 -0300
Subject: Replace uses of StringBuffer with StringBuilder[JAXP]
In-Reply-To: <5412C4C8.3090205@oracle.com>
References: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>
	<54108630.1000907@oracle.com>
	<CAPc8kR2v7OzXGGAmRo9TCOC8CLcNrpiLi0PEU_8L=syihmy_Ng@mail.gmail.com>
	<5410CCF8.2030708@oracle.com>
	<CAPc8kR2EunVOi=kT7AQ7d3ZMacsk2R=yPh59cazbrkB87BeESg@mail.gmail.com>
	<CAPc8kR0ssn167sq+nM5rb+17E8XDr+JMerpKbwMKXgSfo=ZkBg@mail.gmail.com>
	<54127D30.1060209@oracle.com> <5412A956.8030402@oracle.com>
	<CAPc8kR3QrkjEDpg9-V1ygTo2LQX7C+VNpxxMLegjJoivuusFtg@mail.gmail.com>
	<5412C4C8.3090205@oracle.com>
Message-ID: <CAPc8kR3nHvOXz9BciZf98OvL=_SrD391aYmHg_vW5q6GZmKLdg@mail.gmail.com>

I haven't acess to cr.openjdk.java.net yet.
But I uploaded another way.

https://dl.dropboxusercontent.com/u/16109193/open_jdk/jaxp/string_buffer_2_string_builder/index.html

On Fri, Sep 12, 2014 at 7:02 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 12/09/2014 10:40, Ot?vio Gon?alves de Santana wrote:
>
>> @Alan
>> Yes, I would like help the jaxp in openjdk project.
>> But I thought that were different projects, but how are the same.
>> I believe will the same process.
>> So I will waiting to a sponsor.
>>
>>  I understand it can be a bit confusing. In summary, the JAXP project on
> java.net is dead and the development is now in OpenJDK.
>
> I can't speak for Joe (Huizhe) but I think part of this point was that he
> didn't want to have the Xerces/Xalan code diverge too much from the
> upstream Apache projects. If so then this shouldn't prevent doing clean-up
> on the non-Apache code in the jaxp repository. Maybe you could trim back to
> the changes and send them to someone that can upload them to
> cr.openjdk.java.net for discussion.
>
> -Alan
>
>
>


-- 
Ot?vio Gon?alves de Santana

blog:     http://otaviosantana.blogspot.com.br/
twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
55 (11) 98255-3513


From Alan.Bateman at oracle.com  Fri Sep 12 11:15:54 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Sep 2014 12:15:54 +0100
Subject: [9] RFR: JDK-8054548: JAX-WS tools need to updated to work with
	modular image
In-Reply-To: <5412D045.2000400@oracle.com>
References: <54118582.3020004@oracle.com> <541197FE.4060605@oracle.com>
	<5412B144.7020407@oracle.com> <5412C20D.8080901@oracle.com>
	<5412D045.2000400@oracle.com>
Message-ID: <5412D5EA.3000507@oracle.com>

On 12/09/2014 11:51, Miroslav Kos wrote:
>
> If you are ok with it, I would proceed with this change as it is for 
> now and improved generated classes would go into jdk9 with next 
> regular sync integration.
Yes, I'm okay with this. I do expect that additional changes will be 
needed later but we'll cross that bridge when we get to it.

-Alan


From peter.levart at gmail.com  Fri Sep 12 11:55:17 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 12 Sep 2014 13:55:17 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5412CEBE.3000607@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>
	<5412CEBE.3000607@oracle.com>
Message-ID: <5412DF25.80504@gmail.com>

On 09/12/2014 12:45 PM, Daniel Fuchs wrote:
>> However the listeners are to be invoked in the same order they have been
>> added.
>
> I am still unconvinced this is worth the additional
> complexity it would bring to the implementation.
> The deprecated methods were using HashMap to store listeners,
> and therefore the order in which listeners were invoked was also
> undefined. Nobody has ever complained.

What about using a synchronized LinkedHashMap<ListenerAction, 
ListenerAction>() with the following double-purpose inner class:

     private static final class ListenerAction implements 
PrivilegedAction<Void> {
         private final Runnable listener;
         private final AccessControlContext acc;

         ListenerAction(Runnable listener, AccessControlContext acc) {
             this.listener = listener;
             this.acc = acc;
         }

         void invoke() {
             if (acc == null) {
                 run();
             } else {
                 AccessController.doPrivileged(this, acc);
             }
         }

         // not to be run() directly - use invoke() instead
         @Override
         public Void run() {
             listener.run();
             return null;
         }

         @Override
         public int hashCode() {
             return System.identityHashCode(listener);
         }

         @Override
         public boolean equals(Object obj) {
             return (obj instanceof ListenerAction) &&
                    ((ListenerAction) obj).listener == listener;
         }
     }


>
> (http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/3ae82f0c6b31/src/share/classes/java/util/logging/LogManager.java#l1431) 
>
>
>
>> I'd rather run the listeners in try/catch and throw the 1st exception at
>> the end.
>> Defining the 1st however requires obeying the order the listeners have
>> been added.
>> As far as I see there is no documentation how the listeners are supposed
>> to behave or be invoked.
>
> We could do that - invoke all listeners and rethrow the exception
> caught by the first listener that failed (on the basis that if any other
> listener subsequently fails it may be because the previous listener
> has left the system in an inconsistent state, and that therefore
> the first exception caught has 'more value' than the others).
>
> I am not completely convinced this is a better behavior than
> simply stopping invoking listeners at the first exception.
> I wonder if there would be a good wording to say that listeners
> are not supposed to throw, but that if they do, the exceptions
> will be propagated...

You're probably right. But in case you changed your mind, you could 
rethrow the 1st exception thrown, with possible further exceptions added 
to it a suppressed exceptions...

Regards, Peter

>
> best regards,
>
> -- daniel 



From peter.levart at gmail.com  Fri Sep 12 12:04:39 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 12 Sep 2014 14:04:39 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5412BB15.6040708@oracle.com>
References: <54101EBF.7000003@oracle.com> <5410353C.3070705@oracle.com>
	<5411CB0E.9060504@oracle.com> <54129D3E.8020200@gmail.com>
	<5412BB15.6040708@oracle.com>
Message-ID: <5412E157.6030105@gmail.com>

On 09/12/2014 11:21 AM, Alan Bateman wrote:
> On 12/09/2014 08:14, Peter Levart wrote:
>> :
>>
>> Just a question about security and delayed execution...
>>
>> If at the time the configuration listener is added to the LogManager, 
>> SecurityManager is not set, the listener will be invoked directly 
>> even if at time the listener is invoked, SM has been set.
> True but we typically don't get concerned about this. That is all bets 
> are off if you allow untrusted code to run before setting the security 
> manager. 

I buy that, yes...

Regards, Peter

> So normally the assumption is that you are either running with or 
> without a security manager, ignoring the case when it might be set or 
> unset mid-flight. Also for the common case (running without a security 
> manager) then you avoid needing to stash away the access control 
> context as that has a number of side effects (Stanimir has picked up 
> on this). Clearly there is a timing issue with code that runs early in 
> the startup before the system class loader has fully initialized and 
> the security manager set but great care has to be taken in those code 
> paths.
>
> -Alan



From stanimir at riflexo.com  Fri Sep 12 12:12:16 2014
From: stanimir at riflexo.com (Stanimir Simeonoff)
Date: Fri, 12 Sep 2014 15:12:16 +0300
Subject: RFR: 8043306 - Provide a replacement for the API that allowed to
	listen for LogManager configuration changes
In-Reply-To: <5412DF25.80504@gmail.com>
References: <54101EBF.7000003@oracle.com> <5410353C.3070705@oracle.com>
	<5411CB0E.9060504@oracle.com> <54129D3E.8020200@gmail.com>
	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>
	<5412B1B3.4090708@oracle.com>
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>
	<5412CEBE.3000607@oracle.com> <5412DF25.80504@gmail.com>
Message-ID: <CAEJX8oryLSrO5EC-MpHUOaj77U-jHVGVZ_5nQ4EmUuiC4bjiYg@mail.gmail.com>

Hi Peter,
I like the LHM (personal favorite data structure) approach with the
dual-purpose key.

Stanimir

On Fri, Sep 12, 2014 at 2:55 PM, Peter Levart <peter.levart at gmail.com>
wrote:

> On 09/12/2014 12:45 PM, Daniel Fuchs wrote:
>
>> However the listeners are to be invoked in the same order they have been
>>> added.
>>>
>>
>> I am still unconvinced this is worth the additional
>> complexity it would bring to the implementation.
>> The deprecated methods were using HashMap to store listeners,
>> and therefore the order in which listeners were invoked was also
>> undefined. Nobody has ever complained.
>>
>
> What about using a synchronized LinkedHashMap<ListenerAction,
> ListenerAction>() with the following double-purpose inner class:
>
>     private static final class ListenerAction implements
> PrivilegedAction<Void> {
>         private final Runnable listener;
>         private final AccessControlContext acc;
>
>         ListenerAction(Runnable listener, AccessControlContext acc) {
>             this.listener = listener;
>             this.acc = acc;
>         }
>
>         void invoke() {
>             if (acc == null) {
>                 run();
>             } else {
>                 AccessController.doPrivileged(this, acc);
>             }
>         }
>
>         // not to be run() directly - use invoke() instead
>         @Override
>         public Void run() {
>             listener.run();
>             return null;
>         }
>
>         @Override
>         public int hashCode() {
>             return System.identityHashCode(listener);
>         }
>
>         @Override
>         public boolean equals(Object obj) {
>             return (obj instanceof ListenerAction) &&
>                    ((ListenerAction) obj).listener == listener;
>         }
>     }
>
>
>
>> (http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/
>> 3ae82f0c6b31/src/share/classes/java/util/logging/LogManager.java#l1431)
>>
>>
>>  I'd rather run the listeners in try/catch and throw the 1st exception at
>>> the end.
>>> Defining the 1st however requires obeying the order the listeners have
>>> been added.
>>> As far as I see there is no documentation how the listeners are supposed
>>> to behave or be invoked.
>>>
>>
>> We could do that - invoke all listeners and rethrow the exception
>> caught by the first listener that failed (on the basis that if any other
>> listener subsequently fails it may be because the previous listener
>> has left the system in an inconsistent state, and that therefore
>> the first exception caught has 'more value' than the others).
>>
>> I am not completely convinced this is a better behavior than
>> simply stopping invoking listeners at the first exception.
>> I wonder if there would be a good wording to say that listeners
>> are not supposed to throw, but that if they do, the exceptions
>> will be propagated...
>>
>
> You're probably right. But in case you changed your mind, you could
> rethrow the 1st exception thrown, with possible further exceptions added to
> it a suppressed exceptions...
>
> Regards, Peter
>
>
>> best regards,
>>
>> -- daniel
>>
>
>


From Alan.Bateman at oracle.com  Fri Sep 12 12:37:23 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Sep 2014 13:37:23 +0100
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5412CEBE.3000607@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>
	<5412CEBE.3000607@oracle.com>
Message-ID: <5412E903.5090703@oracle.com>

On 12/09/2014 11:45, Daniel Fuchs wrote:
>
> I am still unconvinced this is worth the additional
> complexity it would bring to the implementation.
> The deprecated methods were using HashMap to store listeners,
> and therefore the order in which listeners were invoked was also
> undefined. Nobody has ever complained.
>
I'm not convinced either. The previous methods were rarely used (prior 
to their deprecation and eventual removal there was a static analysis 
done on tens of thousands of projects to get some data on actual usage 
and there were only a handful of actual usages). The only reason for 
introducing alternative methods is that there is a solution for the tiny 
number of cases where LogManager can't be sub-classes. So I think it's 
best to keep it as simpler as possible.

-Alan


From daniel.fuchs at oracle.com  Fri Sep 12 12:47:15 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 Sep 2014 14:47:15 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5412DF25.80504@gmail.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>
	<5412CEBE.3000607@oracle.com> <5412DF25.80504@gmail.com>
Message-ID: <5412EB53.1020309@oracle.com>

On 9/12/14 1:55 PM, Peter Levart wrote:
> On 09/12/2014 12:45 PM, Daniel Fuchs wrote:
>>> However the listeners are to be invoked in the same order they have been
>>> added.
>>
>> I am still unconvinced this is worth the additional
>> complexity it would bring to the implementation.
>> The deprecated methods were using HashMap to store listeners,
>> and therefore the order in which listeners were invoked was also
>> undefined. Nobody has ever complained.
>
> What about using a synchronized LinkedHashMap<ListenerAction,
> ListenerAction>() with the following double-purpose inner class:
>
>      private static final class ListenerAction implements
> PrivilegedAction<Void> {
>          private final Runnable listener;
>          private final AccessControlContext acc;
>
>          ListenerAction(Runnable listener, AccessControlContext acc) {
>              this.listener = listener;
>              this.acc = acc;
>          }
>
>          void invoke() {
>              if (acc == null) {
>                  run();
>              } else {
>                  AccessController.doPrivileged(this, acc);
>              }
>          }
>
>          // not to be run() directly - use invoke() instead
>          @Override
>          public Void run() {
>              listener.run();
>              return null;
>          }
>
>          @Override
>          public int hashCode() {
>              return System.identityHashCode(listener);
>          }
>
>          @Override
>          public boolean equals(Object obj) {
>              return (obj instanceof ListenerAction) &&
>                     ((ListenerAction) obj).listener == listener;
>          }
>      }

yes - that's what I'm calling the additional complexity ;-)

-- daniel

>
>>
>> (http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/3ae82f0c6b31/src/share/classes/java/util/logging/LogManager.java#l1431)
>>
>>
>>
>>> I'd rather run the listeners in try/catch and throw the 1st exception at
>>> the end.
>>> Defining the 1st however requires obeying the order the listeners have
>>> been added.
>>> As far as I see there is no documentation how the listeners are supposed
>>> to behave or be invoked.
>>
>> We could do that - invoke all listeners and rethrow the exception
>> caught by the first listener that failed (on the basis that if any other
>> listener subsequently fails it may be because the previous listener
>> has left the system in an inconsistent state, and that therefore
>> the first exception caught has 'more value' than the others).
>>
>> I am not completely convinced this is a better behavior than
>> simply stopping invoking listeners at the first exception.
>> I wonder if there would be a good wording to say that listeners
>> are not supposed to throw, but that if they do, the exceptions
>> will be propagated...
>
> You're probably right. But in case you changed your mind, you could
> rethrow the 1st exception thrown, with possible further exceptions added
> to it a suppressed exceptions...
>
> Regards, Peter
>
>>
>> best regards,
>>
>> -- daniel
>



From paul.sandoz at oracle.com  Fri Sep 12 13:37:48 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 12 Sep 2014 15:37:48 +0200
Subject: [9] Review request : JDK-8057719: Develop new tests for
	LambdaForm Reduction and Caching feature
In-Reply-To: <5412CEC1.8040700@oracle.com>
References: <5409F86D.8040200@oracle.com>
	<C937A851-BE1B-41B6-B2F0-0A839F65291B@oracle.com>
	<5412CEC1.8040700@oracle.com>
Message-ID: <7DB325E4-D79E-4E2C-839B-A92A96CD0441@oracle.com>

Hi,

On Sep 12, 2014, at 12:45 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:

> Paul,
> 
> thanks for your review. I'll take care about this change, since Konstantin is on vacation.
> 

Thanks.


> updated webrev: http://cr.openjdk.java.net/~iignatyev/kshefov/8057719/webrev.00/
> 
> please see inline answers.
> 
> Igor
> 
> On 09/11/2014 05:12 PM, Paul Sandoz wrote:
>> 
>> On Sep 5, 2014, at 7:52 PM, Konstantin Shefov <konstantin.shefov at oracle.com> wrote:
>> 
>>> Hello,
>>> 
>>> Please review the new tests for the feature "Lambda Form Reduction and Caching" https://bugs.openjdk.java.net/browse/JDK-8046703
>>> 
>>> JBS task: https://bugs.openjdk.java.net/browse/JDK-8057719
>>> 
>>> Webrev: http://cr.openjdk.java.net/~kshefov/8057719/webrev.00/
>>> 
>>> These tests also depend on testlibrary change: https://bugs.openjdk.java.net/browse/JDK-8057707
>>> Webrev of the testlib change: http://cr.openjdk.java.net/~kshefov/8057707/webrev.00/
>>> 
>> 
>> Generally looks good. It would be interesting see code-coverage results.
>> 
>> Are you sure the LFMultiThreadCachingTest is sufficiently testing the thread-safety of j.l.invoke classes? It might be that more threads need to be generated (== #cores), and the test repeatedly performed in a loop to increase the chance of stuff stomping on each other. (I see you have iterations in the outer loop of runTests, that might be sufficient, but you might need a tighter loop specific to each test in LFMultiThreadCachingTest).
>> 
> good point, I updated LFMultiThreadCachingTest to use more threads, however I doubt that we need to add a loop. Writing additional MT-stress tests, which can provide more confidence on thread-safety, is out of the scope of JDK-8057719.
> 

It does not have to be of jcstress-test-like quality, but if one is trying to test some degree concurrent execution I think it worthwhile having a simple iteration for loop in LFMultiThreadCachingTest:

  for (int iter = 0; i < ITERS; i++) { ... }

balanced by default to not unduly make the test run too long. Plus often it is useful to define a sys prop for ITER so one can manually run it for longer periods.

Up to you, perhaps consider it has a possible enhancement, esp. if you wanna get this in quickly.


>> 
>> A general comment, feel free to ignore. It's easy to use EnumSet to obtain a collection of enum values:
>> 
>>   Set<TestMethods> tms = EnumSet.allOf(TestMethods.class)
>> 
>> and filtered:
>> 
>>   Set<TestMethods> tms = EnumSet.complementOf(EnumSet.of(TestMethods.IDENTITY, TestMethods.CONSTANT))
>> 
>> (Quite concise with a static import.)
>> 
>> Change LambdaFormTestCase.runTests to accept a Collection<TestMethods> and you are good to go :-)
> done

+1, ok to push.

Paul.


From daniel.fuchs at oracle.com  Fri Sep 12 13:38:48 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 Sep 2014 15:38:48 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5412E903.5090703@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>
Message-ID: <5412F768.7050904@oracle.com>

On 9/12/14 2:37 PM, Alan Bateman wrote:
> On 12/09/2014 11:45, Daniel Fuchs wrote:
>>
>> I am still unconvinced this is worth the additional
>> complexity it would bring to the implementation.
>> The deprecated methods were using HashMap to store listeners,
>> and therefore the order in which listeners were invoked was also
>> undefined. Nobody has ever complained.
>>
> I'm not convinced either. The previous methods were rarely used (prior
> to their deprecation and eventual removal there was a static analysis
> done on tens of thousands of projects to get some data on actual usage
> and there were only a handful of actual usages). The only reason for
> introducing alternative methods is that there is a solution for the tiny
> number of cases where LogManager can't be sub-classes. So I think it's
> best to keep it as simpler as possible.

Would modifying the specification of addConfigurationListener()
as follows be sufficient to make the workings of the proposed
implementation clearer?

     /**
      * Adds a configuration listener to be invoked each time the logging
      * properties are read and the configuration is changed.
      * If the listener is already registered the method does nothing.
      * <p>
      * The order in which the listeners are invoked is unspecified.
      * <br>
      * If a security manager is on, each listener will be invoked in the
      * {@linkplain AccessControlContext security context} with which it was
      * registered.
      * <p>
      * It is recommended that listeners do not throw errors or exceptions.
      * Exceptions or errors thrown by listeners will
      * be propagated to the caller of {@link #readConfiguration()} (or 
{@link
      * #readConfiguration(java.io.InputStream)}) preventing those listeners
      * that haven't been invoked yet from being fired.
      *
      * @param listener A configuration listener that will be invoked 
after the
      *        configuration changed.
      * @return This LogManager.
      * @throws SecurityException if a security manager exists and if the
      * caller does not have LoggingPermission("control").
      * @throws NullPointerException if the listener is null.
      *
      * @since 1.9
      */
     public LogManager addConfigurationListener(Runnable listener) {

best regards,

-- daniel

>
> -Alan



From vladimir.x.ivanov at oracle.com  Fri Sep 12 13:41:43 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 12 Sep 2014 17:41:43 +0400
Subject: [9] Review request : JDK-8057707: TEST library enhancement: copy
	sun.hotspot.whitebox classes from hotspot repo and enhance
	lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java
In-Reply-To: <5412A707.50205@oracle.com>
References: <5409F9A7.9070208@oracle.com> <5411CEE5.50101@oracle.com>
	<5412A707.50205@oracle.com>
Message-ID: <5412F817.3000304@oracle.com>

Alan,

I wasn't aware about such capability. Sounds interesting.

Since we are short on time integrating tests for JEP210 into 9 and 8u40, 
I'd suggest to remove dependency on WB API from the tests for now and 
file a followup bug to restore it once a suitable solution is found. As 
I understand, only WB.fullGC() is needed. It can be replaced with 
System.gc() call.

Best regards,
Vladimir Ivanov

On 9/12/14, 11:55 AM, Alan Bateman wrote:
> On 11/09/2014 17:33, Vladimir Ivanov wrote:
>> Looks ok.
>>
>> I don't like the idea of having 2 copies of WB API for hotspot and jdk.
>>
>> But that's tolerable unless we have shared location for test libraries
>> in top repository. Having reliable tests is more important IMO.
> Has there been any thought put in to use the jtreg's multi-root
> capability? For some time it has been possible to run subsets of jdk and
> hotspot tests with a single jtreg command. I don't know if it helps here
> but it would be good to avoid having to duplicate the code.
>
> -Alan


From Alan.Bateman at oracle.com  Fri Sep 12 13:54:17 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Sep 2014 14:54:17 +0100
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5412F768.7050904@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>
	<5412F768.7050904@oracle.com>
Message-ID: <5412FB09.6060804@oracle.com>

On 12/09/2014 14:38, Daniel Fuchs wrote:
>
> Would modifying the specification of addConfigurationListener()
> as follows be sufficient to make the workings of the proposed
> implementation clearer?
>
>     /**
>      * Adds a configuration listener to be invoked each time the logging
>      * properties are read and the configuration is changed.
Would "... each time that the logging configuration is read" be 
sufficient? (just thinking that it might be more technically correct 
because the configuration might not have changed).


> * If the listener is already registered the method does nothing.
>      * <p>
>      * The order in which the listeners are invoked is unspecified.
That is okay, although it is the same as not saying anything :-)


> * <br>
>      * If a security manager is on, each listener will be invoked in the
>      * {@linkplain AccessControlContext security context} with which 
> it was
>      * registered.
An alternative is "The listener is invoked with privileges that are 
restricted by the calling context of this method".


> * <p>
>      * It is recommended that listeners do not throw errors or 
> exceptions.
>      * Exceptions or errors thrown by listeners will
>      * be propagated to the caller of {@link #readConfiguration()} (or 
> {@link
>      * #readConfiguration(java.io.InputStream)}) preventing those 
> listeners
>      * that haven't been invoked yet from being fired.
That seems okay. Here's a variation to consider:

"If a listener terminates with an uncaught error or exception then it 
will be propagated to the caller of readConfiguraiton and prevent other 
listeners from being notified".

-Alan.


From daniel.fuchs at oracle.com  Fri Sep 12 14:16:39 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 Sep 2014 16:16:39 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <5412FB09.6060804@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>
	<5412F768.7050904@oracle.com> <5412FB09.6060804@oracle.com>
Message-ID: <54130047.1030805@oracle.com>

Thanks Alan!

I have updated the webrev with your suggestions:

http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/

-- daniel

On 9/12/14 3:54 PM, Alan Bateman wrote:
> On 12/09/2014 14:38, Daniel Fuchs wrote:
>>
>> Would modifying the specification of addConfigurationListener()
>> as follows be sufficient to make the workings of the proposed
>> implementation clearer?
>>
>>     /**
>>      * Adds a configuration listener to be invoked each time the logging
>>      * properties are read and the configuration is changed.
> Would "... each time that the logging configuration is read" be
> sufficient? (just thinking that it might be more technically correct
> because the configuration might not have changed).
>
>
>> * If the listener is already registered the method does nothing.
>>      * <p>
>>      * The order in which the listeners are invoked is unspecified.
> That is okay, although it is the same as not saying anything :-)
>
>
>> * <br>
>>      * If a security manager is on, each listener will be invoked in the
>>      * {@linkplain AccessControlContext security context} with which
>> it was
>>      * registered.
> An alternative is "The listener is invoked with privileges that are
> restricted by the calling context of this method".
>
>
>> * <p>
>>      * It is recommended that listeners do not throw errors or
>> exceptions.
>>      * Exceptions or errors thrown by listeners will
>>      * be propagated to the caller of {@link #readConfiguration()} (or
>> {@link
>>      * #readConfiguration(java.io.InputStream)}) preventing those
>> listeners
>>      * that haven't been invoked yet from being fired.
> That seems okay. Here's a variation to consider:
>
> "If a listener terminates with an uncaught error or exception then it
> will be propagated to the caller of readConfiguraiton and prevent other
> listeners from being notified".
>
> -Alan.



From Alan.Bateman at oracle.com  Fri Sep 12 14:42:42 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Sep 2014 15:42:42 +0100
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <54130047.1030805@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>
	<5412F768.7050904@oracle.com> <5412FB09.6060804@oracle.com>
	<54130047.1030805@oracle.com>
Message-ID: <54130662.9000803@oracle.com>

On 12/09/2014 15:16, Daniel Fuchs wrote:
> Thanks Alan!
>
> I have updated the webrev with your suggestions:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
>
> -- daniel
>
A minor suggestion for readConfiguration is that "Any register 
configuration listeners .." might be a bit better than "The 
configuration listeners ...".

In addConfigurationListener there is a <br> between the two sentences 
that talk about exceptions, I don't know if you intended that.

Otherwise the javadoc looks good to me.

-Alan.


From daniel.fuchs at oracle.com  Fri Sep 12 14:59:03 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 Sep 2014 16:59:03 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <54130662.9000803@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>
	<5412F768.7050904@oracle.com> <5412FB09.6060804@oracle.com>
	<54130047.1030805@oracle.com> <54130662.9000803@oracle.com>
Message-ID: <54130A37.8070503@oracle.com>

On 9/12/14 4:42 PM, Alan Bateman wrote:
> On 12/09/2014 15:16, Daniel Fuchs wrote:
>> Thanks Alan!
>>
>> I have updated the webrev with your suggestions:
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
>>
>> -- daniel
>>
> A minor suggestion for readConfiguration is that "Any register
> configuration listeners .." might be a bit better than "The
> configuration listeners ...".
>
> In addConfigurationListener there is a <br> between the two sentences
> that talk about exceptions, I don't know if you intended that.

Done. I regenerated the webrev in place.
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/

-- daniel
>
> Otherwise the javadoc looks good to me.
>
> -Alan.



From igor.ignatyev at oracle.com  Fri Sep 12 15:03:31 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 12 Sep 2014 19:03:31 +0400
Subject: [9] Review request : JDK-8057707: TEST library enhancement: copy
	sun.hotspot.whitebox classes from hotspot repo and enhance
	lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java
In-Reply-To: <5412F817.3000304@oracle.com>
References: <5409F9A7.9070208@oracle.com>
	<5411CEE5.50101@oracle.com>	<5412A707.50205@oracle.com>
	<5412F817.3000304@oracle.com>
Message-ID: <54130B43.8060902@oracle.com>

Vladimir/Alan,

Yes, only WB.fullGC() is needed, I replaced it w/ System.gc() and 
removed whitebox from the changes.

updated webrev : 
http://cr.openjdk.java.net/~iignatyev/kshefov/8057707/webrev.00/

Thanks
Igor

On 09/12/2014 05:41 PM, Vladimir Ivanov wrote:
> Alan,
>
> I wasn't aware about such capability. Sounds interesting.
>
> Since we are short on time integrating tests for JEP210 into 9 and 8u40,
> I'd suggest to remove dependency on WB API from the tests for now and
> file a followup bug to restore it once a suitable solution is found. As
> I understand, only WB.fullGC() is needed. It can be replaced with
> System.gc() call.
>
> Best regards,
> Vladimir Ivanov
>
> On 9/12/14, 11:55 AM, Alan Bateman wrote:
>> On 11/09/2014 17:33, Vladimir Ivanov wrote:
>>> Looks ok.
>>>
>>> I don't like the idea of having 2 copies of WB API for hotspot and jdk.
>>>
>>> But that's tolerable unless we have shared location for test libraries
>>> in top repository. Having reliable tests is more important IMO.
>> Has there been any thought put in to use the jtreg's multi-root
>> capability? For some time it has been possible to run subsets of jdk and
>> hotspot tests with a single jtreg command. I don't know if it helps here
>> but it would be good to avoid having to duplicate the code.
>>
>> -Alan
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From vladimir.x.ivanov at oracle.com  Fri Sep 12 15:08:13 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 12 Sep 2014 19:08:13 +0400
Subject: [9] Review request : JDK-8057707: TEST library enhancement: copy
	sun.hotspot.whitebox classes from hotspot repo and enhance
	lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java
In-Reply-To: <54130B43.8060902@oracle.com>
References: <5409F9A7.9070208@oracle.com>	<5411CEE5.50101@oracle.com>	<5412A707.50205@oracle.com>	<5412F817.3000304@oracle.com>
	<54130B43.8060902@oracle.com>
Message-ID: <54130C5D.6060101@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 9/12/14, 7:03 PM, Igor Ignatyev wrote:
> Vladimir/Alan,
>
> Yes, only WB.fullGC() is needed, I replaced it w/ System.gc() and
> removed whitebox from the changes.
>
> updated webrev :
> http://cr.openjdk.java.net/~iignatyev/kshefov/8057707/webrev.00/
>
> Thanks
> Igor
>
> On 09/12/2014 05:41 PM, Vladimir Ivanov wrote:
>> Alan,
>>
>> I wasn't aware about such capability. Sounds interesting.
>>
>> Since we are short on time integrating tests for JEP210 into 9 and 8u40,
>> I'd suggest to remove dependency on WB API from the tests for now and
>> file a followup bug to restore it once a suitable solution is found. As
>> I understand, only WB.fullGC() is needed. It can be replaced with
>> System.gc() call.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 9/12/14, 11:55 AM, Alan Bateman wrote:
>>> On 11/09/2014 17:33, Vladimir Ivanov wrote:
>>>> Looks ok.
>>>>
>>>> I don't like the idea of having 2 copies of WB API for hotspot and jdk.
>>>>
>>>> But that's tolerable unless we have shared location for test libraries
>>>> in top repository. Having reliable tests is more important IMO.
>>> Has there been any thought put in to use the jtreg's multi-root
>>> capability? For some time it has been possible to run subsets of jdk and
>>> hotspot tests with a single jtreg command. I don't know if it helps here
>>> but it would be good to avoid having to duplicate the code.
>>>
>>> -Alan
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From jason_mehrens at hotmail.com  Fri Sep 12 15:39:01 2014
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 12 Sep 2014 10:39:01 -0500
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <54130A37.8070503@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>
	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>
	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>
	<5412B1B3.4090708@oracle.com>,
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>,
	<5412CEBE.3000607@oracle.com>
	<5412E903.5090703@oracle.com>,<5412F768.7050904@oracle.com>
	<5412FB09.6060804@oracle.com>,<54130047.1030805@oracle.com>
	<54130662.9000803@oracle.com>,<54130A37.8070503@oracle.com>
Message-ID: <BLU175-W12259009585054C5ACE4E083CD0@phx.gbl>

Daniel,


I suppose that the propagating uncaught exceptions to the caller was the previous behavior of the old property change methods but it seems out of place for the LogManager.  The LogManager is a global resource so broken listener code in web app A could suppress notifications in web app B and C.  That doesn't seem very nice.  A lot of the LogManager code handles exception via catch, report or ignore, and continue when dealing with handlers etc.  I would think that same strategy applies here too.



Jason


----------------------------------------
> Date: Fri, 12 Sep 2014 16:59:03 +0200
> From: daniel.fuchs at oracle.com
> To: Alan.Bateman at oracle.com
> Subject: Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
> CC: core-libs-dev at openjdk.java.net
>
> On 9/12/14 4:42 PM, Alan Bateman wrote:
>> On 12/09/2014 15:16, Daniel Fuchs wrote:
>>> Thanks Alan!
>>>
>>> I have updated the webrev with your suggestions:
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
>>>
>>> -- daniel
>>>
>> A minor suggestion for readConfiguration is that "Any register
>> configuration listeners .." might be a bit better than "The
>> configuration listeners ...".
>>
>> In addConfigurationListener there is a <br> between the two sentences
>> that talk about exceptions, I don't know if you intended that.
>
> Done. I regenerated the webrev in place.
> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
>
> -- daniel
>>
>> Otherwise the javadoc looks good to me.
>>
>> -Alan.
> 		 	   		  

From huizhe.wang at oracle.com  Fri Sep 12 16:22:30 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 12 Sep 2014 09:22:30 -0700
Subject: Replace uses of StringBuffer with StringBuilder[JAXP]
In-Reply-To: <CAPc8kR3nHvOXz9BciZf98OvL=_SrD391aYmHg_vW5q6GZmKLdg@mail.gmail.com>
References: <CAPc8kR0oYoNBhqCdPHOiJZX0rUHpQzcOdGD5B5ajHPSDeFsJzg@mail.gmail.com>
	<54108630.1000907@oracle.com>
	<CAPc8kR2v7OzXGGAmRo9TCOC8CLcNrpiLi0PEU_8L=syihmy_Ng@mail.gmail.com>
	<5410CCF8.2030708@oracle.com>
	<CAPc8kR2EunVOi=kT7AQ7d3ZMacsk2R=yPh59cazbrkB87BeESg@mail.gmail.com>
	<CAPc8kR0ssn167sq+nM5rb+17E8XDr+JMerpKbwMKXgSfo=ZkBg@mail.gmail.com>
	<54127D30.1060209@oracle.com> <5412A956.8030402@oracle.com>
	<CAPc8kR3QrkjEDpg9-V1ygTo2LQX7C+VNpxxMLegjJoivuusFtg@mail.gmail.com>
	<5412C4C8.3090205@oracle.com>
	<CAPc8kR3nHvOXz9BciZf98OvL=_SrD391aYmHg_vW5q6GZmKLdg@mail.gmail.com>
Message-ID: <54131DC6.90809@oracle.com>

Hi Alan, Otavio,

I'm very delighted that Otavio wants to help! I'm totally fine with 
updating the source to a higher source level, though diverging from the 
upstream projects in the process. I was only saying that it's currently 
not a high priority for me and that I don't have circles. There's a 
plenty of room for improvement in the jaxp sources, the problem then is 
that you'd need to find a sponsor. I see that the discussion on one of 
your previous proposals (e.g. Replace concat String to append in 
StringBuilder parameters) lasted a month, have you found a sponsor for 
that yet?

Thanks,
Joe

On 9/12/2014 4:08 AM, Ot?vio Gon?alves de Santana wrote:
> I haven't acess to cr.openjdk.java.net <http://cr.openjdk.java.net> yet.
> But I uploaded another way.
>
> https://dl.dropboxusercontent.com/u/16109193/open_jdk/jaxp/string_buffer_2_string_builder/index.html
>
> On Fri, Sep 12, 2014 at 7:02 AM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>     On 12/09/2014 10:40, Ot?vio Gon?alves de Santana wrote:
>
>         @Alan
>         Yes, I would like help the jaxp in openjdk project.
>         But I thought that were different projects, but how are the same.
>         I believe will the same process.
>         So I will waiting to a sponsor.
>
>     I understand it can be a bit confusing. In summary, the JAXP
>     project on java.net <http://java.net> is dead and the development
>     is now in OpenJDK.
>
>     I can't speak for Joe (Huizhe) but I think part of this point was
>     that he didn't want to have the Xerces/Xalan code diverge too much
>     from the upstream Apache projects. If so then this shouldn't
>     prevent doing clean-up on the non-Apache code in the jaxp
>     repository. Maybe you could trim back to the changes and send them
>     to someone that can upload them to cr.openjdk.java.net
>     <http://cr.openjdk.java.net> for discussion.
>
>     -Alan
>
>
>
>
>
> -- 
> Ot?vio Gon?alves de Santana
>
> blog: http://otaviosantana.blogspot.com.br/
> twitter: http://twitter.com/otaviojava
> site: _http://about.me/otaviojava_
> 55 (11) 98255-3513



From daniel.fuchs at oracle.com  Fri Sep 12 16:54:12 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 Sep 2014 18:54:12 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <BLU175-W12259009585054C5ACE4E083CD0@phx.gbl>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>,
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>,
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>,
	<5412F768.7050904@oracle.com> <5412FB09.6060804@oracle.com>,
	<54130047.1030805@oracle.com> <54130662.9000803@oracle.com>,
	<54130A37.8070503@oracle.com>
	<BLU175-W12259009585054C5ACE4E083CD0@phx.gbl>
Message-ID: <54132534.407@oracle.com>

On 9/12/14 5:39 PM, Jason Mehrens wrote:
> Daniel,
>
>
> I suppose that the propagating uncaught exceptions to the caller was the previous behavior of the old property change methods but it seems out of place for the LogManager.  The LogManager is a global resource so broken listener code in web app A could suppress notifications in web app B and C.  That doesn't seem very nice.  A lot of the LogManager code handles exception via catch, report or ignore, and continue when dealing with handlers etc.  I would think that same strategy applies here too.

Hi Jason,

Yes - that was also the behavior of the old property change methods.
When the global LogManager calls itself readConfiguration it will
silently ignore exceptions that might be raised.

I'm not too keen in specifying that exceptions raised by listeners will
be silently dropped. We're in the process of reinitializing the 
configuration,
so trying to log  the exceptions through a Logger would have its own
risks too.
Reporting exceptions raised during initialization and configuration is
an area where java.util.logging is clearly lacking.

For this patch - I think that our options are limited to the alternative:
   1. propagate the exception
   2. catch and silentlty drop the exception

What is the 'better' behavior (and I agree neither of the two are ideal)
probably depends on what is the typical use case for these listeners.
My assumption is that in most cases - there will be a single listener, in
which case 1. is probably better. I haven't seen any bug complaining
about how exceptions were handled in the previous implementation,
though I have seen some complaining about swallowed exceptions...

That said - if there is consensus that 2. is better - I have no real
objection except those stated above.

best regards,

-- daniel



>
>
>
> Jason
>
>
> ----------------------------------------
>> Date: Fri, 12 Sep 2014 16:59:03 +0200
>> From: daniel.fuchs at oracle.com
>> To: Alan.Bateman at oracle.com
>> Subject: Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
>> CC: core-libs-dev at openjdk.java.net
>>
>> On 9/12/14 4:42 PM, Alan Bateman wrote:
>>> On 12/09/2014 15:16, Daniel Fuchs wrote:
>>>> Thanks Alan!
>>>>
>>>> I have updated the webrev with your suggestions:
>>>>
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
>>>>
>>>> -- daniel
>>>>
>>> A minor suggestion for readConfiguration is that "Any register
>>> configuration listeners .." might be a bit better than "The
>>> configuration listeners ...".
>>>
>>> In addConfigurationListener there is a <br> between the two sentences
>>> that talk about exceptions, I don't know if you intended that.
>> Done. I regenerated the webrev in place.
>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
>>
>> -- daniel
>>> Otherwise the javadoc looks good to me.
>>>
>>> -Alan.
>> 		 	   		



From jason_mehrens at hotmail.com  Fri Sep 12 17:21:00 2014
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 12 Sep 2014 12:21:00 -0500
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <54132534.407@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>
	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>
	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>
	<5412B1B3.4090708@oracle.com>,
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>,
	<5412CEBE.3000607@oracle.com>
	<5412E903.5090703@oracle.com>,<5412F768.7050904@oracle.com>
	<5412FB09.6060804@oracle.com>,<54130047.1030805@oracle.com>
	<54130662.9000803@oracle.com>,<54130A37.8070503@oracle.com>
	<BLU175-W12259009585054C5ACE4E083CD0@phx.gbl>, <54132534.407@oracle.com>
Message-ID: <BLU175-W471CC4F5FA1389062DC2DC83CD0@phx.gbl>

Daniel,


Agreed.  My preference would be to:

1. Catch and report them to 'System.err'.  That type of code happens in the LogManager and exceptions in this case are not the normal condition.

2. Don't specify how uncaught exceptions are handled in the javadocs.

3. Outside of this issue, make an RFE to allow the LogManager to contain a j.u.l.ErrorManager and use it to replace all calls to System.err to use this new root/default error manager.  Once these exception are captured in a error manager you can alter the behavior (rethrow, write to console, ignore, report to O/S event log, etc.)


I worry that over specification of the exception handling might cripple how the LogManager can evolve with regard to future RFEs.


Jason

----------------------------------------
> Date: Fri, 12 Sep 2014 18:54:12 +0200
> From: daniel.fuchs at oracle.com
> To: jason_mehrens at hotmail.com
> CC: core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
>
> On 9/12/14 5:39 PM, Jason Mehrens wrote:
>> Daniel,
>>
>>
>> I suppose that the propagating uncaught exceptions to the caller was the previous behavior of the old property change methods but it seems out of place for the LogManager. The LogManager is a global resource so broken listener code in web app A could suppress notifications in web app B and C. That doesn't seem very nice. A lot of the LogManager code handles exception via catch, report or ignore, and continue when dealing with handlers etc. I would think that same strategy applies here too.
>
> Hi Jason,
>
> Yes - that was also the behavior of the old property change methods.
> When the global LogManager calls itself readConfiguration it will
> silently ignore exceptions that might be raised.
>
> I'm not too keen in specifying that exceptions raised by listeners will
> be silently dropped. We're in the process of reinitializing the
> configuration,
> so trying to log the exceptions through a Logger would have its own
> risks too.
> Reporting exceptions raised during initialization and configuration is
> an area where java.util.logging is clearly lacking.
>
> For this patch - I think that our options are limited to the alternative:
> 1. propagate the exception
> 2. catch and silentlty drop the exception
>
> What is the 'better' behavior (and I agree neither of the two are ideal)
> probably depends on what is the typical use case for these listeners.
> My assumption is that in most cases - there will be a single listener, in
> which case 1. is probably better. I haven't seen any bug complaining
> about how exceptions were handled in the previous implementation,
> though I have seen some complaining about swallowed exceptions...
>
> That said - if there is consensus that 2. is better - I have no real
> objection except those stated above.
>
> best regards,
>
> -- daniel
>
>
>
>>
>>
>>
>> Jason
>>
>>
>> ----------------------------------------
>>> Date: Fri, 12 Sep 2014 16:59:03 +0200
>>> From: daniel.fuchs at oracle.com
>>> To: Alan.Bateman at oracle.com
>>> Subject: Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
>>> CC: core-libs-dev at openjdk.java.net
>>>
>>> On 9/12/14 4:42 PM, Alan Bateman wrote:
>>>> On 12/09/2014 15:16, Daniel Fuchs wrote:
>>>>> Thanks Alan!
>>>>>
>>>>> I have updated the webrev with your suggestions:
>>>>>
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
>>>>>
>>>>> -- daniel
>>>>>
>>>> A minor suggestion for readConfiguration is that "Any register
>>>> configuration listeners .." might be a bit better than "The
>>>> configuration listeners ...".
>>>>
>>>> In addConfigurationListener there is a <br> between the two sentences
>>>> that talk about exceptions, I don't know if you intended that.
>>> Done. I regenerated the webrev in place.
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
>>>
>>> -- daniel
>>>> Otherwise the javadoc looks good to me.
>>>>
>>>> -Alan.
>>>
> 		 	   		  

From philip.race at oracle.com  Fri Sep 12 19:21:24 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 12 Sep 2014 12:21:24 -0700
Subject: RFR: 8058230: Improve java.sql toString formatting
In-Reply-To: <3AD72EA0-7768-48E0-B209-C8188B22FDD6@oracle.com>
References: <5411B535.7040903@oracle.com>
	<3AD72EA0-7768-48E0-B209-C8188B22FDD6@oracle.com>
Message-ID: <541347B4.8060408@oracle.com>

Hi,

http://hg.openjdk.java.net/jdk9/dev/jdk/rev/267950e85a3b
The above changeset for this fix apparently broke the images build.


ERROR: Failed module access verification
CheckModules.gmk:38: recipe for target 'checkdeps' failed
make[3]: Leaving directory '/opt/jprt/T/P1/173827.xxx/s/make'
Main.gmk:301: recipe for target 'verify-modules' failed
fcntl(): Bad file descriptor
inaccessible reference: java.sql.Date (java.sql) -> 
sun.misc.JavaLangAccess (java.base)
inaccessible reference: java.sql.Date (java.sql) -> 
sun.misc.SharedSecrets (java.base)
inaccessible reference: java.sql.Time (java.sql) -> 
sun.misc.JavaLangAccess (java.base)
inaccessible reference: java.sql.Time (java.sql) -> 
sun.misc.SharedSecrets (java.base)
inaccessible reference: java.sql.Timestamp (java.sql) -> 
sun.misc.JavaLangAccess (java.base)
inaccessible reference: java.sql.Timestamp (java.sql) -> 
sun.misc.SharedSecrets (java.base)

-phil.


On 9/11/2014 8:32 AM, Lance Andersen wrote:
> Hi Claes,
>
> I think this is OK,  however, would like to see if others feel if  formatDecimalInt should be located elsewhere so that we just make this change once.
>
> Best,
> Lance
> On Sep 11, 2014, at 10:44 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
>
>> Hi,
>>
>> requesting reviews for this patch which optimizes java.sql.Date/Time/Timestamp::toString
>> by avoiding some unnecessary object allocations. java.sql.Date had similar optimizations
>> applied which this patch improves upon.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8058230
>> webrev: http://cr.openjdk.java.net/~redestad/8058230/webrev.00/
>>
>> Testing: jtreg jdk/test/java/sql with and without 8057826 tests
>>
>> Before/after performance running a minimal JMH micro[1]:
>>
>> Benchmark                         Mode  Samples      Score Score error   Units
>> t.DateBench.dateToString         thrpt       20 30225.628      623.887  ops/ms
>> t.DateBench.dateToString         thrpt       20 38350.173     1349.432  ops/ms  # 1.3x
>>
>> t.DateBench.timeToString         thrpt       20 11793.338      232.121  ops/ms
>> t.DateBench.timeToString         thrpt       20 47048.344     1969.939  ops/ms  # 4.0x
>>
>> t.DateBench.timestampToString    thrpt       20 2529.601       45.990  ops/ms
>> t.DateBench.timestampToString    thrpt       20 14143.612      407.351  ops/ms  # 5.6x
>>
>> /Claes
>>
>> [1]
>>
>> package test;
>>
>> import org.openjdk.jmh.annotations.*;
>>
>> @State(Scope.Thread)
>> public class DateBench {
>>
>>     public java.sql.Time time = java.sql.Time.valueOf("15:15:25");
>>
>>     @Benchmark
>>     public String timeToString() {
>>         return time.toString();
>>     }
>>
>>     public java.sql.Date date = java.sql.Date.valueOf("2013-01-01");
>>
>>     @Benchmark
>>     public String dateToString() {
>>         return date.toString();
>>     }
>>
>>     public Timestamp timestamp = Timestamp.valueOf("1999-12-13 15:15:25.645634");
>>
>>     @Benchmark
>>     public String timestampToString() {
>>         return timestamp.toString();
>>     }
>>
>> }
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>



From mandy.chung at oracle.com  Fri Sep 12 20:03:28 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 Sep 2014 13:03:28 -0700
Subject: RFR: 8058230: Improve java.sql toString formatting
In-Reply-To: <541347B4.8060408@oracle.com>
References: <5411B535.7040903@oracle.com>
	<3AD72EA0-7768-48E0-B209-C8188B22FDD6@oracle.com>
	<541347B4.8060408@oracle.com>
Message-ID: <54135190.1010400@oracle.com>

On 9/12/14 12:21 PM, Phil Race wrote:
> Hi,
>
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/267950e85a3b
> The above changeset for this fix apparently broke the images build.
>
>
> ERROR: Failed module access verification
> CheckModules.gmk:38: recipe for target 'checkdeps' failed
> make[3]: Leaving directory '/opt/jprt/T/P1/173827.xxx/s/make'
> Main.gmk:301: recipe for target 'verify-modules' failed
> fcntl(): Bad file descriptor
> inaccessible reference: java.sql.Date (java.sql) -> 
> sun.misc.JavaLangAccess (java.base)
> inaccessible reference: java.sql.Date (java.sql) -> 
> sun.misc.SharedSecrets (java.base)
> inaccessible reference: java.sql.Time (java.sql) -> 
> sun.misc.JavaLangAccess (java.base)
> inaccessible reference: java.sql.Time (java.sql) -> 
> sun.misc.SharedSecrets (java.base)
> inaccessible reference: java.sql.Timestamp (java.sql) -> 
> sun.misc.JavaLangAccess (java.base)
> inaccessible reference: java.sql.Timestamp (java.sql) -> 
> sun.misc.SharedSecrets (java.base)

This changeset adds a new dependence from java.sql.* to sun.misc
that fails the build.  The module boundaries are enforced at build
time [1] to catch regressions before the module system is further
long.

The fix to this build failure is to add a qualified export
sun.misc to java.sql.

I'm looking into why the CI system doesn't catch this build failure
(seems like some make targets are not invoking the checkdeps target)

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

>
> -phil.
>
>
> On 9/11/2014 8:32 AM, Lance Andersen wrote:
>> Hi Claes,
>>
>> I think this is OK,  however, would like to see if others feel if  
>> formatDecimalInt should be located elsewhere so that we just make 
>> this change once.
>>
>> Best,
>> Lance
>> On Sep 11, 2014, at 10:44 AM, Claes Redestad 
>> <claes.redestad at oracle.com> wrote:
>>
>>> Hi,
>>>
>>> requesting reviews for this patch which optimizes 
>>> java.sql.Date/Time/Timestamp::toString
>>> by avoiding some unnecessary object allocations. java.sql.Date had 
>>> similar optimizations
>>> applied which this patch improves upon.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058230
>>> webrev: http://cr.openjdk.java.net/~redestad/8058230/webrev.00/
>>>
>>> Testing: jtreg jdk/test/java/sql with and without 8057826 tests
>>>
>>> Before/after performance running a minimal JMH micro[1]:
>>>
>>> Benchmark                         Mode  Samples      Score Score 
>>> error   Units
>>> t.DateBench.dateToString         thrpt       20 30225.628 623.887  
>>> ops/ms
>>> t.DateBench.dateToString         thrpt       20 38350.173 1349.432  
>>> ops/ms  # 1.3x
>>>
>>> t.DateBench.timeToString         thrpt       20 11793.338 232.121  
>>> ops/ms
>>> t.DateBench.timeToString         thrpt       20 47048.344 1969.939  
>>> ops/ms  # 4.0x
>>>
>>> t.DateBench.timestampToString    thrpt       20 2529.601 45.990  ops/ms
>>> t.DateBench.timestampToString    thrpt       20 14143.612 407.351  
>>> ops/ms  # 5.6x
>>>
>>> /Claes
>>>
>>> [1]
>>>
>>> package test;
>>>
>>> import org.openjdk.jmh.annotations.*;
>>>
>>> @State(Scope.Thread)
>>> public class DateBench {
>>>
>>>     public java.sql.Time time = java.sql.Time.valueOf("15:15:25");
>>>
>>>     @Benchmark
>>>     public String timeToString() {
>>>         return time.toString();
>>>     }
>>>
>>>     public java.sql.Date date = java.sql.Date.valueOf("2013-01-01");
>>>
>>>     @Benchmark
>>>     public String dateToString() {
>>>         return date.toString();
>>>     }
>>>
>>>     public Timestamp timestamp = Timestamp.valueOf("1999-12-13 
>>> 15:15:25.645634");
>>>
>>>     @Benchmark
>>>     public String timestampToString() {
>>>         return timestamp.toString();
>>>     }
>>>
>>> }
>>
>>
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>>
>>
>>
>



From brian.burkhalter at oracle.com  Fri Sep 12 23:54:05 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 12 Sep 2014 16:54:05 -0700
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <54124DFE.7000706@oracle.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
	<54124DFE.7000706@oracle.com>
Message-ID: <81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>

Hello,

I created a formal webrev:

Issue:	https://bugs.openjdk.java.net/browse/JDK-8057793
Webrev:	http://cr.openjdk.java.net/~bpb/8057793/webrev.00/

Based on manual inspection of the revised code the patch looks good to me. The test submitted with the issue now succeeds as do all regression tests in jdk/test/java/math to which I also added the code from the test case in the issue report.

Note that this webrev is with respect to JDK 9.

Thanks,

Brian

On Sep 11, 2014, at 6:35 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello,
> 
> Hmmm. I haven't dived into the details of the code, but setScale calls out to divide functionality so it is plausible a bug in divide could cause a problem in setScale.
> 
> Thanks for the bug report,
> 
> -Joe
> 
> On 9/9/2014 1:30 AM, Robert Gibson wrote:
>> 
>> 
>> Hi there,
>> 
>> I came across a case in BigDecimal division where the dividend ends up getting mutated, which is rather strange for a seemingly immutable class! (It's a subset of the cases where the Burnikel-Ziegler algorithm is used, I haven't done the analysis to find out under which exact conditions it's triggered.)
>> 
>> The attached patch - against the JDK8 version - should fix the problem, at the cost of an extra array copy.  Could somebody review and/or comment please?
>> 
>> Thanks,
>> Robert
>> 
>> --- MutableBigInteger.java      2014-09-04 09:42:23.426815000 +0200
>> +++ MutableBigInteger.java.patched      2014-09-04 09:46:21.344132000 +0200
>> @@ -1261,19 +1261,20 @@
>>              int sigma = (int) Math.max(0, n32 - b.bitLength());   // step 3: sigma = max{T | (2^T)*B < beta^n}
>>              MutableBigInteger bShifted = new MutableBigInteger(b);
>>              bShifted.safeLeftShift(sigma);   // step 4a: shift b so its length is a multiple of n
>> -            safeLeftShift(sigma);     // step 4b: shift this by the same amount
>> +            MutableBigInteger aShifted = new MutableBigInteger (this);
>> +            aShifted.safeLeftShift(sigma);     // step 4b: shift a by the same amount
>> -            // step 5: t is the number of blocks needed to accommodate this plus one additional bit
>> -            int t = (int) ((bitLength()+n32) / n32);
>> +            // step 5: t is the number of blocks needed to accommodate a plus one additional bit
>> +            int t = (int) ((aShifted.bitLength()+n32) / n32);
>>              if (t < 2) {
>>                  t = 2;
>>              }
>> -            // step 6: conceptually split this into blocks a[t-1], ..., a[0]
>> -            MutableBigInteger a1 = getBlock(t-1, t, n);   // the most significant block of this
>> +            // step 6: conceptually split a into blocks a[t-1], ..., a[0]
>> +            MutableBigInteger a1 = aShifted.getBlock(t-1, t, n);   // the most significant block of a
>>              // step 7: z[t-2] = [a[t-1], a[t-2]]
>> -            MutableBigInteger z = getBlock(t-2, t, n);    // the second to most significant block
>> +            MutableBigInteger z = aShifted.getBlock(t-2, t, n);    // the second to most significant block
>>              z.addDisjoint(a1, n);   // z[t-2]
>>              // do schoolbook division on blocks, dividing 2-block numbers by 1-block numbers
>> @@ -1284,7 +1285,7 @@
>>                  ri = z.divide2n1n(bShifted, qi);
>>                  // step 8b: z = [ri, a[i-1]]
>> -                z = getBlock(i-1, t, n);   // a[i-1]
>> +                z = aShifted.getBlock(i-1, t, n);   // a[i-1]
>>                  z.addDisjoint(ri, n);
>>                  quotient.addShifted(qi, i*n);   // update q (part of step 9)
>>              }
>> @@ -1292,7 +1293,7 @@
>>              ri = z.divide2n1n(bShifted, qi);
>>              quotient.add(qi);
>> -           ri.rightShift(sigma);   // step 9: this and b were shifted, so shift back
>> +           ri.rightShift(sigma);   // step 9: a and b were shifted, so shift back
>>              return ri;
>>          }
>>      }
> 



From brian.burkhalter at oracle.com  Sat Sep 13 14:56:49 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Sat, 13 Sep 2014 07:56:49 -0700
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
	<54124DFE.7000706@oracle.com>
	<81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>
Message-ID: <D65197CD-A641-4666-B01A-B90B81D010BE@oracle.com>

I forgot to add setScaleDoesNotMutateTest() to main() in ZeroScalingTests. D?oh! Here?s the corrected webrev:

http://cr.openjdk.java.net/~bpb/8057793/webrev.01/

Thanks,

Brian

On Sep 12, 2014, at 4:54 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Hello,
> 
> I created a formal webrev:
> 
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8057793
> Webrev:	http://cr.openjdk.java.net/~bpb/8057793/webrev.00/
> 
> Based on manual inspection of the revised code the patch looks good to me. The test submitted with the issue now succeeds as do all regression tests in jdk/test/java/math to which I also added the code from the test case in the issue report.
> 
> Note that this webrev is with respect to JDK 9.
> 
> Thanks,
> 
> Brian
> 
> On Sep 11, 2014, at 6:35 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> 
>> Hello,
>> 
>> Hmmm. I haven't dived into the details of the code, but setScale calls out to divide functionality so it is plausible a bug in divide could cause a problem in setScale.
>> 
>> Thanks for the bug report,
>> 
>> -Joe
>> 
>> On 9/9/2014 1:30 AM, Robert Gibson wrote:
>>> 
>>> 
>>> Hi there,
>>> 
>>> I came across a case in BigDecimal division where the dividend ends up getting mutated, which is rather strange for a seemingly immutable class! (It's a subset of the cases where the Burnikel-Ziegler algorithm is used, I haven't done the analysis to find out under which exact conditions it's triggered.)
>>> 
>>> The attached patch - against the JDK8 version - should fix the problem, at the cost of an extra array copy.  Could somebody review and/or comment please?
>>> 
>>> Thanks,
>>> Robert
>>> 
>>> --- MutableBigInteger.java      2014-09-04 09:42:23.426815000 +0200
>>> +++ MutableBigInteger.java.patched      2014-09-04 09:46:21.344132000 +0200
>>> @@ -1261,19 +1261,20 @@
>>>             int sigma = (int) Math.max(0, n32 - b.bitLength());   // step 3: sigma = max{T | (2^T)*B < beta^n}
>>>             MutableBigInteger bShifted = new MutableBigInteger(b);
>>>             bShifted.safeLeftShift(sigma);   // step 4a: shift b so its length is a multiple of n
>>> -            safeLeftShift(sigma);     // step 4b: shift this by the same amount
>>> +            MutableBigInteger aShifted = new MutableBigInteger (this);
>>> +            aShifted.safeLeftShift(sigma);     // step 4b: shift a by the same amount
>>> -            // step 5: t is the number of blocks needed to accommodate this plus one additional bit
>>> -            int t = (int) ((bitLength()+n32) / n32);
>>> +            // step 5: t is the number of blocks needed to accommodate a plus one additional bit
>>> +            int t = (int) ((aShifted.bitLength()+n32) / n32);
>>>             if (t < 2) {
>>>                 t = 2;
>>>             }
>>> -            // step 6: conceptually split this into blocks a[t-1], ..., a[0]
>>> -            MutableBigInteger a1 = getBlock(t-1, t, n);   // the most significant block of this
>>> +            // step 6: conceptually split a into blocks a[t-1], ..., a[0]
>>> +            MutableBigInteger a1 = aShifted.getBlock(t-1, t, n);   // the most significant block of a
>>>             // step 7: z[t-2] = [a[t-1], a[t-2]]
>>> -            MutableBigInteger z = getBlock(t-2, t, n);    // the second to most significant block
>>> +            MutableBigInteger z = aShifted.getBlock(t-2, t, n);    // the second to most significant block
>>>             z.addDisjoint(a1, n);   // z[t-2]
>>>             // do schoolbook division on blocks, dividing 2-block numbers by 1-block numbers
>>> @@ -1284,7 +1285,7 @@
>>>                 ri = z.divide2n1n(bShifted, qi);
>>>                 // step 8b: z = [ri, a[i-1]]
>>> -                z = getBlock(i-1, t, n);   // a[i-1]
>>> +                z = aShifted.getBlock(i-1, t, n);   // a[i-1]
>>>                 z.addDisjoint(ri, n);
>>>                 quotient.addShifted(qi, i*n);   // update q (part of step 9)
>>>             }
>>> @@ -1292,7 +1293,7 @@
>>>             ri = z.divide2n1n(bShifted, qi);
>>>             quotient.add(qi);
>>> -           ri.rightShift(sigma);   // step 9: this and b were shifted, so shift back
>>> +           ri.rightShift(sigma);   // step 9: a and b were shifted, so shift back
>>>             return ri;
>>>         }
>>>     }
>> 
> 



From joe.darcy at oracle.com  Sat Sep 13 17:10:08 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sat, 13 Sep 2014 10:10:08 -0700
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <D65197CD-A641-4666-B01A-B90B81D010BE@oracle.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
	<54124DFE.7000706@oracle.com>
	<81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>
	<D65197CD-A641-4666-B01A-B90B81D010BE@oracle.com>
Message-ID: <54147A70.30008@oracle.com>

Hi Brian,

Other than removing the

     // bug 8057793

comment on the new test method, this looks good to be pushed.

Thanks,

-Joe

On 9/13/2014 7:56 AM, Brian Burkhalter wrote:
> I forgot to add setScaleDoesNotMutateTest() to main() in ZeroScalingTests. D?oh! Here?s the corrected webrev:
>
> http://cr.openjdk.java.net/~bpb/8057793/webrev.01/
>
> Thanks,
>
> Brian
>
> On Sep 12, 2014, at 4:54 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
>
>> Hello,
>>
>> I created a formal webrev:
>>
>> Issue:	https://bugs.openjdk.java.net/browse/JDK-8057793
>> Webrev:	http://cr.openjdk.java.net/~bpb/8057793/webrev.00/
>>
>> Based on manual inspection of the revised code the patch looks good to me. The test submitted with the issue now succeeds as do all regression tests in jdk/test/java/math to which I also added the code from the test case in the issue report.
>>
>> Note that this webrev is with respect to JDK 9.
>>
>> Thanks,
>>
>> Brian
>>
>> On Sep 11, 2014, at 6:35 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
>>
>>> Hello,
>>>
>>> Hmmm. I haven't dived into the details of the code, but setScale calls out to divide functionality so it is plausible a bug in divide could cause a problem in setScale.
>>>
>>> Thanks for the bug report,
>>>
>>> -Joe
>>>
>>> On 9/9/2014 1:30 AM, Robert Gibson wrote:
>>>>
>>>> Hi there,
>>>>
>>>> I came across a case in BigDecimal division where the dividend ends up getting mutated, which is rather strange for a seemingly immutable class! (It's a subset of the cases where the Burnikel-Ziegler algorithm is used, I haven't done the analysis to find out under which exact conditions it's triggered.)
>>>>
>>>> The attached patch - against the JDK8 version - should fix the problem, at the cost of an extra array copy.  Could somebody review and/or comment please?
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>> --- MutableBigInteger.java      2014-09-04 09:42:23.426815000 +0200
>>>> +++ MutableBigInteger.java.patched      2014-09-04 09:46:21.344132000 +0200
>>>> @@ -1261,19 +1261,20 @@
>>>>              int sigma = (int) Math.max(0, n32 - b.bitLength());   // step 3: sigma = max{T | (2^T)*B < beta^n}
>>>>              MutableBigInteger bShifted = new MutableBigInteger(b);
>>>>              bShifted.safeLeftShift(sigma);   // step 4a: shift b so its length is a multiple of n
>>>> -            safeLeftShift(sigma);     // step 4b: shift this by the same amount
>>>> +            MutableBigInteger aShifted = new MutableBigInteger (this);
>>>> +            aShifted.safeLeftShift(sigma);     // step 4b: shift a by the same amount
>>>> -            // step 5: t is the number of blocks needed to accommodate this plus one additional bit
>>>> -            int t = (int) ((bitLength()+n32) / n32);
>>>> +            // step 5: t is the number of blocks needed to accommodate a plus one additional bit
>>>> +            int t = (int) ((aShifted.bitLength()+n32) / n32);
>>>>              if (t < 2) {
>>>>                  t = 2;
>>>>              }
>>>> -            // step 6: conceptually split this into blocks a[t-1], ..., a[0]
>>>> -            MutableBigInteger a1 = getBlock(t-1, t, n);   // the most significant block of this
>>>> +            // step 6: conceptually split a into blocks a[t-1], ..., a[0]
>>>> +            MutableBigInteger a1 = aShifted.getBlock(t-1, t, n);   // the most significant block of a
>>>>              // step 7: z[t-2] = [a[t-1], a[t-2]]
>>>> -            MutableBigInteger z = getBlock(t-2, t, n);    // the second to most significant block
>>>> +            MutableBigInteger z = aShifted.getBlock(t-2, t, n);    // the second to most significant block
>>>>              z.addDisjoint(a1, n);   // z[t-2]
>>>>              // do schoolbook division on blocks, dividing 2-block numbers by 1-block numbers
>>>> @@ -1284,7 +1285,7 @@
>>>>                  ri = z.divide2n1n(bShifted, qi);
>>>>                  // step 8b: z = [ri, a[i-1]]
>>>> -                z = getBlock(i-1, t, n);   // a[i-1]
>>>> +                z = aShifted.getBlock(i-1, t, n);   // a[i-1]
>>>>                  z.addDisjoint(ri, n);
>>>>                  quotient.addShifted(qi, i*n);   // update q (part of step 9)
>>>>              }
>>>> @@ -1292,7 +1293,7 @@
>>>>              ri = z.divide2n1n(bShifted, qi);
>>>>              quotient.add(qi);
>>>> -           ri.rightShift(sigma);   // step 9: this and b were shifted, so shift back
>>>> +           ri.rightShift(sigma);   // step 9: a and b were shifted, so shift back
>>>>              return ri;
>>>>          }
>>>>      }



From Alan.Bateman at oracle.com  Mon Sep 15 07:33:30 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 15 Sep 2014 08:33:30 +0100
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <54132534.407@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>,
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>,
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>,
	<5412F768.7050904@oracle.com> <5412FB09.6060804@oracle.com>,
	<54130047.1030805@oracle.com> <54130662.9000803@oracle.com>,
	<54130A37.8070503@oracle.com>	<BLU175-W12259009585054C5ACE4E083CD0@phx.gbl>
	<54132534.407@oracle.com>
Message-ID: <5416964A.2080600@oracle.com>

On 12/09/2014 17:54, Daniel Fuchs wrote:
> :
>
> For this patch - I think that our options are limited to the alternative:
>   1. propagate the exception
>   2. catch and silentlty drop the exception
>
> What is the 'better' behavior (and I agree neither of the two are ideal)
> probably depends on what is the typical use case for these listeners.
> My assumption is that in most cases - there will be a single listener, in
> which case 1. is probably better. I haven't seen any bug complaining
> about how exceptions were handled in the previous implementation,
> though I have seen some complaining about swallowed exceptions...
>
> That said - if there is consensus that 2. is better - I have no real
> objection except those stated above.
As you point out, the choice isn't great. #1 has been the long standing 
behavior (since JDK 1.4) and I'm not not aware of any comments or 
complaints. At the same time usage was extremely rare so the opportunity 
to even notice this was rare. I expect this will be the same with any 
replacement methods.

If you go with #1 and only fail after all listeners have been notified 
then it might not be too bad. It would of course require special-casing 
ThreadDeath, maybe others, as would option #2.

-Alan.


From robbiexgibson at yahoo.com  Mon Sep 15 09:09:19 2014
From: robbiexgibson at yahoo.com (Robert Gibson)
Date: Mon, 15 Sep 2014 02:09:19 -0700
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
	<54124DFE.7000706@oracle.com>
	<81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>
Message-ID: <1410772159.90189.YahooMailNeo@web121302.mail.ne1.yahoo.com>

Hi Brian, 
How are the performance characteristics after the patch? I see that a lot of effort went in to tuning last December under 8029501.
By the way, as part of my investigations into this bug I noticed that BigIntegerTest::divideLarge no longer tests the Burnikel-Ziegler part of the division code, since the heuristic to decide Knuth or BZ diverged from the algorithm to generate the test cases (as part of 8029501). 
Best,
Robert
  
On Saturday, 13 September 2014, 2:09, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
Hello,

I created a formal webrev:

Issue:    https://bugs.openjdk.java.net/browse/JDK-8057793
Webrev:    http://cr.openjdk.java.net/~bpb/8057793/webrev.00/

Based on manual inspection of the revised code the patch looks good to me. The test submitted with the issue now succeeds as do all regression tests in jdk/test/java/math to which I also added the code from the test case in the issue report.

Note that this webrev is with respect to JDK 9.

Thanks,

Brian




On Sep 11, 2014, at 6:35 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello,
> 
> Hmmm. I haven't dived into the details of the code, but setScale calls out to divide functionality so it is plausible a bug in divide could cause a problem in setScale.
> 
> Thanks for the bug report,
> 
> -Joe
> 
> On 9/9/2014 1:30 AM, Robert Gibson wrote:
>> 
>> 
>> Hi there,
>> 
>> I came across a case in BigDecimal division where the dividend ends up getting mutated, which is rather strange for a seemingly immutable class! (It's a subset of the cases where the Burnikel-Ziegler algorithm is used, I haven't done the analysis to find out under which exact conditions it's triggered.)
>> 
>> The attached patch - against the JDK8 version - should fix the problem, at the cost of an extra array copy.  Could somebody review and/or comment please?
>> 
>> Thanks,
>> Robert
>> 
>> --- MutableBigInteger.java      2014-09-04 09:42:23.426815000 +0200
>> +++ MutableBigInteger.java.patched      2014-09-04 09:46:21.344132000 +0200
>> @@ -1261,19 +1261,20 @@
>>              int sigma = (int) Math.max(0, n32 - b.bitLength());   // step 3: sigma = max{T | (2^T)*B < beta^n}
>>              MutableBigInteger bShifted = new MutableBigInteger(b);
>>              bShifted.safeLeftShift(sigma);   // step 4a: shift b so its length is a multiple of n
>> -            safeLeftShift(sigma);     // step 4b: shift this by the same amount
>> +            MutableBigInteger aShifted = new MutableBigInteger (this);
>> +            aShifted.safeLeftShift(sigma);     // step 4b: shift a by the same amount
>> -            // step 5: t is the number of blocks needed to accommodate this plus one additional bit
>> -            int t = (int) ((bitLength()+n32) / n32);
>> +            // step 5: t is the number of blocks needed to accommodate a plus one additional bit
>> +            int t = (int) ((aShifted.bitLength()+n32) / n32);
>>              if (t < 2) {
>>                  t = 2;
>>              }
>> -            // step 6: conceptually split this into blocks a[t-1], ..., a[0]
>> -            MutableBigInteger a1 = getBlock(t-1, t, n);   // the most significant block of this
>> +            // step 6: conceptually split a into blocks a[t-1], ..., a[0]
>> +            MutableBigInteger a1 = aShifted.getBlock(t-1, t, n);   // the most significant block of a
>>              // step 7: z[t-2] = [a[t-1], a[t-2]]
>> -            MutableBigInteger z = getBlock(t-2, t, n);    // the second to most significant block
>> +            MutableBigInteger z = aShifted.getBlock(t-2, t, n);    // the second to most significant block
>>              z.addDisjoint(a1, n);   // z[t-2]
>>              // do schoolbook division on blocks, dividing 2-block numbers by 1-block numbers
>> @@ -1284,7 +1285,7 @@
>>                  ri = z.divide2n1n(bShifted, qi);
>>                  // step 8b: z = [ri, a[i-1]]
>> -                z = getBlock(i-1, t, n);   // a[i-1]
>> +                z = aShifted.getBlock(i-1, t, n);   // a[i-1]
>>                  z.addDisjoint(ri, n);
>>                  quotient.addShifted(qi, i*n);   // update q (part of step 9)
>>              }
>> @@ -1292,7 +1293,7 @@
>>              ri = z.divide2n1n(bShifted, qi);
>>              quotient.add(qi);
>> -           ri.rightShift(sigma);   // step 9: this and b were shifted, so shift back
>> +           ri.rightShift(sigma);   // step 9: a and b were shifted, so shift back
>>              return ri;
>>          }
>>      }
> 


From robbiexgibson at yahoo.com  Mon Sep 15 14:17:39 2014
From: robbiexgibson at yahoo.com (Robert Gibson)
Date: Mon, 15 Sep 2014 07:17:39 -0700
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <1410772159.90189.YahooMailNeo@web121302.mail.ne1.yahoo.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
	<54124DFE.7000706@oracle.com>
	<81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>
	<1410772159.90189.YahooMailNeo@web121302.mail.ne1.yahoo.com>
Message-ID: <1410790659.15255.YahooMailNeo@web121302.mail.ne1.yahoo.com>

Here is a patch to fix the test bug mentioned previously.  The Burnikel-Ziegler division code is now exercised, and you'll be glad to know that the tests still pass!
Robert

--- BigIntegerTest.java 2014-09-15 15:55:47.632012000 +0200
+++ BigIntegerTestPatched.java  2014-09-15 16:07:53.363563000 +0200
@@ -71,6 +71,7 @@
     static final int BITS_TOOM_COOK_SQUARE = 6912;
     static final int BITS_SCHOENHAGE_BASE = 640;
     static final int BITS_BURNIKEL_ZIEGLER = 2560;
+    static final int BITS_BURNIKEL_ZIEGLER_OFFSET = 1280;
     static final int ORDER_SMALL = 60;
     static final int ORDER_MEDIUM = 100;
@@ -288,19 +289,19 @@
      * where {@code abs(u) > abs(v)} and {@code a > b && b > 0}, then if
      * {@code w/z = q1*z + r1} and {@code u/v = q2*v + r2}, then
      * {@code q1 = q2*pow(2,a-b)} and {@code r1 = r2*pow(2,b)}.  The test
-     * ensures that {@code v} is just under the B-Z threshold and that {@code w}
-     * and {@code z} are both over the threshold.  This implies that {@code u/v}
-     * uses the standard division algorithm and {@code w/z} uses the B-Z
-     * algorithm.  The results of the two algorithms are then compared using the
-     * observation described in the foregoing and if they are not equal a
-     * failure is logged.
+     * ensures that {@code v} is just under the B-Z threshold, that {@code z} is
+     * over the threshold and {@code w} is much larger than {@code z}. This
+     * implies that {@code u/v} uses the standard division algorithm and
+     * {@code w/z} uses the B-Z algorithm.  The results of the two algorithms
+     * are then compared using the observation described in the foregoing and
+     * if they are not equal a failure is logged.
      */
     public static void divideLarge() {
         int failCount = 0;
-        BigInteger base = BigInteger.ONE.shiftLeft(BITS_BURNIKEL_ZIEGLER - 33);
+        BigInteger base = BigInteger.ONE.shiftLeft(BITS_BURNIKEL_ZIEGLER + BITS_BURNIKEL_ZIEGLER_OFFSET - 33);
         for (int i=0; i<SIZE; i++) {
-            BigInteger addend = new BigInteger(BITS_BURNIKEL_ZIEGLER - 34, rnd);
+            BigInteger addend = new BigInteger(BITS_BURNIKEL_ZIEGLER + BITS_BURNIKEL_ZIEGLER_OFFSET - 34, rnd);
             BigInteger v = base.add(addend);
             BigInteger u = v.multiply(BigInteger.valueOf(2 + rnd.nextInt(Short.MAX_VALUE - 1)));
@@ -312,14 +313,14 @@
                 v = v.negate();
             }
-            int a = 17 + rnd.nextInt(16);
+            int a = BITS_BURNIKEL_ZIEGLER_OFFSET + rnd.nextInt(16);
             int b = 1 + rnd.nextInt(16);
-            BigInteger w = u.multiply(BigInteger.valueOf(1L << a));
-            BigInteger z = v.multiply(BigInteger.valueOf(1L << b));
+            BigInteger w = u.multiply(BigInteger.ONE.shiftLeft(a));
+            BigInteger z = v.multiply(BigInteger.ONE.shiftLeft(b));
             BigInteger[] divideResult = u.divideAndRemainder(v);
-            divideResult[0] = divideResult[0].multiply(BigInteger.valueOf(1L << (a - b)));
-            divideResult[1] = divideResult[1].multiply(BigInteger.valueOf(1L << b));
+            divideResult[0] = divideResult[0].multiply(BigInteger.ONE.shiftLeft(a - b));
+            divideResult[1] = divideResult[1].multiply(BigInteger.ONE.shiftLeft(b));
             BigInteger[] bzResult = w.divideAndRemainder(z);
             if (divideResult[0].compareTo(bzResult[0]) != 0 ||





On Monday, 15 September 2014, 11:09, Robert Gibson <robbiexgibson at yahoo.com> wrote:



Hi Brian, 
How are the performance characteristics after the patch? I see that a lot of effort went in to tuning last December under 8029501.
By the way, as part of my investigations into this bug I noticed that BigIntegerTest::divideLarge no longer tests the Burnikel-Ziegler part of the division code, since the heuristic to decide Knuth or BZ diverged from the algorithm to generate the test cases (as part of 8029501). 
Best,
Robert


On Saturday, 13 September 2014, 2:09, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
Hello,

I created a formal webrev:

Issue:    https://bugs.openjdk.java.net/browse/JDK-8057793
Webrev:    http://cr.openjdk.java.net/~bpb/8057793/webrev.00/

Based on manual inspection of the revised code the patch looks good to me. The test submitted with the issue now succeeds as do all regression tests in jdk/test/java/math to which I also added the code from the test case in the issue report.

Note that this webrev is with respect to JDK 9.

Thanks,

Brian




On Sep 11, 2014, at 6:35 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> Hello,
> 
> Hmmm. I haven't dived into the details of the code, but setScale calls out to divide functionality so it is plausible a bug in divide could cause a problem in setScale.
> 
> Thanks for the bug report,
> 
> -Joe
> 
> On 9/9/2014 1:30 AM, Robert Gibson wrote:
>> 
>> 
>> Hi there,
>> 
>> I came across a case in BigDecimal division where the dividend ends up getting mutated, which is rather strange for a seemingly immutable class! (It's a subset of the cases where the Burnikel-Ziegler algorithm is used, I haven't done the analysis to find out under which exact conditions it's triggered.)
>> 
>> The attached patch - against the JDK8 version - should fix the problem, at the cost of an extra array copy.  Could somebody review and/or comment please?
>> 
>> Thanks,
>> Robert
>> 
>> --- MutableBigInteger.java      2014-09-04 09:42:23.426815000 +0200
>> +++ MutableBigInteger.java.patched      2014-09-04 09:46:21.344132000 +0200
>> @@ -1261,19 +1261,20 @@
>>              int sigma = (int) Math.max(0, n32 - b.bitLength());   // step 3: sigma = max{T | (2^T)*B < beta^n}
>>              MutableBigInteger bShifted = new MutableBigInteger(b);
>>              bShifted.safeLeftShift(sigma);   // step 4a: shift b so its length is a multiple of n
>> -            safeLeftShift(sigma);     // step 4b: shift this by the same amount
>> +            MutableBigInteger aShifted = new MutableBigInteger (this);
>> +            aShifted.safeLeftShift(sigma);     // step 4b: shift a by the same amount
>> -            // step 5: t is the number of blocks needed to accommodate this plus one additional bit
>> -            int t = (int) ((bitLength()+n32) / n32);
>> +            // step 5: t is the number of blocks needed to accommodate a plus one additional bit
>> +            int t = (int) ((aShifted.bitLength()+n32) / n32);
>>              if (t < 2) {
>>                  t = 2;
>>              }
>> -            // step 6: conceptually split this into blocks a[t-1], ..., a[0]
>> -            MutableBigInteger a1 = getBlock(t-1, t, n);   // the most significant block of this
>> +            // step 6: conceptually split a into blocks a[t-1], ..., a[0]
>> +            MutableBigInteger a1 = aShifted.getBlock(t-1, t, n);   // the most significant block of a
>>              // step 7: z[t-2] = [a[t-1], a[t-2]]
>> -            MutableBigInteger z = getBlock(t-2, t, n);    // the second to most significant block
>> +            MutableBigInteger z = aShifted.getBlock(t-2, t, n);    // the second to most significant block
>>              z.addDisjoint(a1, n);   // z[t-2]
>>              // do schoolbook division on blocks, dividing 2-block numbers by 1-block numbers
>> @@ -1284,7 +1285,7 @@
>>                  ri = z.divide2n1n(bShifted, qi);
>>                  // step 8b: z = [ri, a[i-1]]
>> -                z = getBlock(i-1, t, n);   // a[i-1]
>> +                z = aShifted.getBlock(i-1, t, n);   // a[i-1]
>>                  z.addDisjoint(ri, n);
>>                  quotient.addShifted(qi, i*n);   // update q (part of step 9)
>>              }
>> @@ -1292,7 +1293,7 @@
>>              ri = z.divide2n1n(bShifted, qi);
>>              quotient.add(qi);
>> -           ri.rightShift(sigma);   // step 9: this and b were shifted, so shift back
>> +           ri.rightShift(sigma);   // step 9: a and b were shifted, so shift back
>>              return ri;
>>          }
>>      }
>      


From daniel.fuchs at oracle.com  Mon Sep 15 16:03:19 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 15 Sep 2014 18:03:19 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <BLU175-W471CC4F5FA1389062DC2DC83CD0@phx.gbl>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>,
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>,
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>,
	<5412F768.7050904@oracle.com> <5412FB09.6060804@oracle.com>,
	<54130047.1030805@oracle.com> <54130662.9000803@oracle.com>,
	<54130A37.8070503@oracle.com>
	<BLU175-W12259009585054C5ACE4E083CD0@phx.gbl>,
	<54132534.407@oracle.com> <BLU175-W471CC4F5FA1389062DC2DC83CD0@phx.gbl>
Message-ID: <54170DC7.7090603@oracle.com>

Hi Jason,

Logging on System.err is usually frowned upon - especially if there
are alternatives.

May I suggest the following?

1. do option #1, and only fail after all listeners have been notified
    as Alan indicated 'it might not be too bad'.
    As Paul suggested to me privately we could use
    Throwable.addSuppressed to link the suppressed exceptions, if there
    are any.

2. Log an RFE for LogManager to use ErrorManager (or
    some similar object).

    IMHO the proposal #1 above should not cripple how LogManager will
    evolve in the future too much - especially if it is a rarely
    used functionality.

Here is a new webrev - with updated test case:

http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.05/

best regards

-- daniel

On 9/12/14 7:21 PM, Jason Mehrens wrote:
> Daniel,
>
>
> Agreed.  My preference would be to:
>
> 1. Catch and report them to 'System.err'.  That type of code happens in the LogManager and exceptions in this case are not the normal condition.
>
> 2. Don't specify how uncaught exceptions are handled in the javadocs.
>
> 3. Outside of this issue, make an RFE to allow the LogManager to contain a j.u.l.ErrorManager and use it to replace all calls to System.err to use this new root/default error manager.  Once these exception are captured in a error manager you can alter the behavior (rethrow, write to console, ignore, report to O/S event log, etc.)
>
>
> I worry that over specification of the exception handling might cripple how the LogManager can evolve with regard to future RFEs.
>
>
> Jason
>
> ----------------------------------------
>> Date: Fri, 12 Sep 2014 18:54:12 +0200
>> From: daniel.fuchs at oracle.com
>> To: jason_mehrens at hotmail.com
>> CC: core-libs-dev at openjdk.java.net
>> Subject: Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
>>
>> On 9/12/14 5:39 PM, Jason Mehrens wrote:
>>> Daniel,
>>>
>>>
>>> I suppose that the propagating uncaught exceptions to the caller was the previous behavior of the old property change methods but it seems out of place for the LogManager. The LogManager is a global resource so broken listener code in web app A could suppress notifications in web app B and C. That doesn't seem very nice. A lot of the LogManager code handles exception via catch, report or ignore, and continue when dealing with handlers etc. I would think that same strategy applies here too.
>>
>> Hi Jason,
>>
>> Yes - that was also the behavior of the old property change methods.
>> When the global LogManager calls itself readConfiguration it will
>> silently ignore exceptions that might be raised.
>>
>> I'm not too keen in specifying that exceptions raised by listeners will
>> be silently dropped. We're in the process of reinitializing the
>> configuration,
>> so trying to log the exceptions through a Logger would have its own
>> risks too.
>> Reporting exceptions raised during initialization and configuration is
>> an area where java.util.logging is clearly lacking.
>>
>> For this patch - I think that our options are limited to the alternative:
>> 1. propagate the exception
>> 2. catch and silentlty drop the exception
>>
>> What is the 'better' behavior (and I agree neither of the two are ideal)
>> probably depends on what is the typical use case for these listeners.
>> My assumption is that in most cases - there will be a single listener, in
>> which case 1. is probably better. I haven't seen any bug complaining
>> about how exceptions were handled in the previous implementation,
>> though I have seen some complaining about swallowed exceptions...
>>
>> That said - if there is consensus that 2. is better - I have no real
>> objection except those stated above.
>>
>> best regards,
>>
>> -- daniel
>>
>>
>>
>>>
>>>
>>>
>>> Jason
>>>
>>>
>>> ----------------------------------------
>>>> Date: Fri, 12 Sep 2014 16:59:03 +0200
>>>> From: daniel.fuchs at oracle.com
>>>> To: Alan.Bateman at oracle.com
>>>> Subject: Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
>>>> CC: core-libs-dev at openjdk.java.net
>>>>
>>>> On 9/12/14 4:42 PM, Alan Bateman wrote:
>>>>> On 12/09/2014 15:16, Daniel Fuchs wrote:
>>>>>> Thanks Alan!
>>>>>>
>>>>>> I have updated the webrev with your suggestions:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
>>>>>>
>>>>>> -- daniel
>>>>>>
>>>>> A minor suggestion for readConfiguration is that "Any register
>>>>> configuration listeners .." might be a bit better than "The
>>>>> configuration listeners ...".
>>>>>
>>>>> In addConfigurationListener there is a <br> between the two sentences
>>>>> that talk about exceptions, I don't know if you intended that.
>>>> Done. I regenerated the webrev in place.
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
>>>>
>>>> -- daniel
>>>>> Otherwise the javadoc looks good to me.
>>>>>
>>>>> -Alan.
>>>>
>> 		 	   		



From vladimir.x.ivanov at oracle.com  Mon Sep 15 16:03:41 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 15 Sep 2014 20:03:41 +0400
Subject: [9] RFR (S): 8058291: Missing some checks during parameter validation
Message-ID: <54170DDD.1010102@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8058291/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8058291

8057656 & 8050166 changes accidentally removed some checks during 
argument validation in MHs.dropArguments() and 
MHs.explicitCastArguments(). The fix is to restore them.

Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke, 
jdk/java/util/streams w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}

Thanks!

Best regards,
Vladimir Ivanov


From vladimir.x.ivanov at oracle.com  Mon Sep 15 16:48:08 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 15 Sep 2014 20:48:08 +0400
Subject: [9] RFR (S): 8058293: Bit set computation in
	MHs.findFirstDupOrDrop/findFirstDrop is broken
Message-ID: <54171848.4060200@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8058293
http://cr.openjdk.java.net/~vlivanov/8058293/webrev.00

Bit set computation in MHs.findFirstDupOrDrop/findFirstDrop is incorrect 
due to widening primitive conversions (int -> long) taking place. The 
fix is to explicitly use long where needed.

Also, fixed a case when reorder represents a permutation (zeroPos == 
newArity).

Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke, 
jdk/java/util/streams w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}

Thanks!

Best regards,
Vladimir Ivanov


From Ulf.Zibis at CoSoCo.de  Mon Sep 15 17:47:08 2014
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Mon, 15 Sep 2014 19:47:08 +0200
Subject: Missing clarity in TimerTask doc
Message-ID: <5417261C.8090103@CoSoCo.de>

Hi all,

I'm missing clarity, if a j.u.TimerTask object can be scheduled more than once.
Especially, can it be scheduled again with Timer.schedule(...) after it has been cancelled, or has a 
new TimerTask object to be instantiated?
What happens if a TimerTask is scheduled again before the first schedule had happened; would it then 
happen twice or would the same run be re-scheduled?

Thanks,

-Ulf



From tbuktu at hotmail.com  Mon Sep 15 18:53:28 2014
From: tbuktu at hotmail.com (Tim Buktu)
Date: Mon, 15 Sep 2014 20:53:28 +0200
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
Message-ID: <BLU436-SMTP1341428E9EAFEB5F57A6CCFC6C80@phx.gbl>

That was my screw-up. Thanks for fixing it.

Tim


On 09.09.2014 10:30, Robert Gibson wrote:
>
>
> Hi there,
>
> I came across a case in BigDecimal division where the dividend ends up getting mutated, which is rather strange for a seemingly immutable class! (It's a subset of the cases where the Burnikel-Ziegler algorithm is used, I haven't done the analysis to find out under which exact conditions it's triggered.)
>
> The attached patch - against the JDK8 version - should fix the problem, at the cost of an extra array copy.  Could somebody review and/or comment please?
>
> Thanks,
> Robert
>
> --- MutableBigInteger.java      2014-09-04 09:42:23.426815000 +0200
> +++ MutableBigInteger.java.patched      2014-09-04 09:46:21.344132000 +0200
> @@ -1261,19 +1261,20 @@
>              int sigma = (int) Math.max(0, n32 - b.bitLength());   // step 3: sigma = max{T | (2^T)*B < beta^n}
>              MutableBigInteger bShifted = new MutableBigInteger(b);
>              bShifted.safeLeftShift(sigma);   // step 4a: shift b so its length is a multiple of n
> -            safeLeftShift(sigma);     // step 4b: shift this by the same amount
> +            MutableBigInteger aShifted = new MutableBigInteger (this);
> +            aShifted.safeLeftShift(sigma);     // step 4b: shift a by the same amount
> -            // step 5: t is the number of blocks needed to accommodate this plus one additional bit
> -            int t = (int) ((bitLength()+n32) / n32);
> +            // step 5: t is the number of blocks needed to accommodate a plus one additional bit
> +            int t = (int) ((aShifted.bitLength()+n32) / n32);
>              if (t < 2) {
>                  t = 2;
>              }
> -            // step 6: conceptually split this into blocks a[t-1], ..., a[0]
> -            MutableBigInteger a1 = getBlock(t-1, t, n);   // the most significant block of this
> +            // step 6: conceptually split a into blocks a[t-1], ..., a[0]
> +            MutableBigInteger a1 = aShifted.getBlock(t-1, t, n);   // the most significant block of a
>              // step 7: z[t-2] = [a[t-1], a[t-2]]
> -            MutableBigInteger z = getBlock(t-2, t, n);    // the second to most significant block
> +            MutableBigInteger z = aShifted.getBlock(t-2, t, n);    // the second to most significant block
>              z.addDisjoint(a1, n);   // z[t-2]
>              // do schoolbook division on blocks, dividing 2-block numbers by 1-block numbers
> @@ -1284,7 +1285,7 @@
>                  ri = z.divide2n1n(bShifted, qi);
>                  // step 8b: z = [ri, a[i-1]]
> -                z = getBlock(i-1, t, n);   // a[i-1]
> +                z = aShifted.getBlock(i-1, t, n);   // a[i-1]
>                  z.addDisjoint(ri, n);
>                  quotient.addShifted(qi, i*n);   // update q (part of step 9)
>              }
> @@ -1292,7 +1293,7 @@
>              ri = z.divide2n1n(bShifted, qi);
>              quotient.add(qi);
> -           ri.rightShift(sigma);   // step 9: this and b were shifted, so shift back
> +           ri.rightShift(sigma);   // step 9: a and b were shifted, so shift back
>              return ri;
>          }
>      }
>
>



From brian.burkhalter at oracle.com  Mon Sep 15 19:04:47 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 15 Sep 2014 12:04:47 -0700
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <BLU436-SMTP1341428E9EAFEB5F57A6CCFC6C80@phx.gbl>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
	<BLU436-SMTP1341428E9EAFEB5F57A6CCFC6C80@phx.gbl>
Message-ID: <52145487-5C13-4E09-B925-4FBDBE123F12@oracle.com>

And none of us who reviewed it nor any of the tests caught it either.

Thanks to both (Tim & Robert) for the original and current patches.

Brian

On Sep 15, 2014, at 11:53 AM, Tim Buktu <tbuktu at hotmail.com> wrote:

> That was my screw-up. Thanks for fixing it.


From john.r.rose at oracle.com  Mon Sep 15 19:44:27 2014
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 15 Sep 2014 12:44:27 -0700
Subject: [9] RFR (S): 8058293: Bit set computation in
	MHs.findFirstDupOrDrop/findFirstDrop is broken
In-Reply-To: <54171848.4060200@oracle.com>
References: <54171848.4060200@oracle.com>
Message-ID: <C5F2AC42-440A-4699-9709-FDC3DF371A34@oracle.com>

On Sep 15, 2014, at 9:48 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8058293
> http://cr.openjdk.java.net/~vlivanov/8058293/webrev.00
> 
> Bit set computation in MHs.findFirstDupOrDrop/findFirstDrop is incorrect due to widening primitive conversions (int -> long) taking place. The fix is to explicitly use long where needed.
> 
> Also, fixed a case when reorder represents a permutation (zeroPos == newArity).
> 
> Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}

Wow, that's foul.  Thanks for patching it up.  Next time I'll start with "BIT_LIMIT = 31".

Reviewed.

FTR, it's worth exercising the code with BIT_LIMIT = 0, just to stress the slow path.

? John

From claes.redestad at oracle.com  Mon Sep 15 19:51:27 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 15 Sep 2014 21:51:27 +0200
Subject: RFR: 8058429: JCK test api/java_sql/Timestamp/descriptions.html start
	failing after 8058230
Message-ID: <5417433F.70209@oracle.com>

Hi,

please review this simple fix which addresses a JCK test failure

webrev: http://cr.openjdk.java.net/~redestad/8058429/webrev.03
bug: https://bugs.openjdk.java.net/browse/JDK-8058429

/Claes


From Lance.Andersen at oracle.com  Mon Sep 15 19:55:46 2014
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Mon, 15 Sep 2014 15:55:46 -0400
Subject: RFR: 8058429: JCK test api/java_sql/Timestamp/descriptions.html
	start failing after 8058230
In-Reply-To: <5417433F.70209@oracle.com>
References: <5417433F.70209@oracle.com>
Message-ID: <2886845C-5B98-4C14-B595-4B3673267184@oracle.com>

Hi Claes,

The fix is fine for now.  As we discussed and I discussed with the JCK team, the test that is failing is suspect and goes beyond the JDBC spec requirements.

However until it is fixed, we will include this change.

I will push this later for you.


Best,
lance
On Sep 15, 2014, at 3:51 PM, Claes Redestad <claes.redestad at oracle.com> wrote:

> Hi,
> 
> please review this simple fix which addresses a JCK test failure
> 
> webrev: http://cr.openjdk.java.net/~redestad/8058429/webrev.03
> bug: https://bugs.openjdk.java.net/browse/JDK-8058429
> 
> /Claes




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com






From john.r.rose at oracle.com  Mon Sep 15 20:01:30 2014
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 15 Sep 2014 13:01:30 -0700
Subject: [9] RFR (S): 8058291: Missing some checks during parameter
	validation
In-Reply-To: <54170DDD.1010102@oracle.com>
References: <54170DDD.1010102@oracle.com>
Message-ID: <835AAD6C-DE35-4EB2-B174-B977C16E9BBE@oracle.com>

Reviewed.

Nice tuning of the asserts.

? John

On Sep 15, 2014, at 9:03 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8058291/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8058291
> 
> 8057656 & 8050166 changes accidentally removed some checks during argument validation in MHs.dropArguments() and MHs.explicitCastArguments(). The fix is to restore them.
> 
> Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov



From brian.burkhalter at oracle.com  Mon Sep 15 20:14:30 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 15 Sep 2014 13:14:30 -0700
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <54147A70.30008@oracle.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
	<54124DFE.7000706@oracle.com>
	<81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>
	<D65197CD-A641-4666-B01A-B90B81D010BE@oracle.com>
	<54147A70.30008@oracle.com>
Message-ID: <46261010-BD40-4102-8F23-4D5F9B703C1D@oracle.com>

Hi Joe,

This has been pushed http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b20d87c5905 with the indicated comment excised.

Thanks,

Brian

On Sep 13, 2014, at 10:10 AM, Joe Darcy <joe.darcy at oracle.com> wrote:

> Other than removing the
> 
>    // bug 8057793
> 
> comment on the new test method, this looks good to be pushed.



From brian.burkhalter at oracle.com  Mon Sep 15 20:18:42 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 15 Sep 2014 13:18:42 -0700
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <1410772159.90189.YahooMailNeo@web121302.mail.ne1.yahoo.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
	<54124DFE.7000706@oracle.com>
	<81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>
	<1410772159.90189.YahooMailNeo@web121302.mail.ne1.yahoo.com>
Message-ID: <47428F39-5EB9-4EDE-A593-DF12EDDEF8BE@oracle.com>

Hi Robert,

On Sep 15, 2014, at 2:09 AM, Robert Gibson <robbiexgibson at yahoo.com> wrote:

> How are the performance characteristics after the patch?

I have not tested that aspect as yet but clearly it should be evaluated. Given that JDK-8057793 causes a violation of the specification of BigDecimal I thought it was important to check in the fix as-is without further delay.

> I see that a lot of effort went in to tuning last December under 8029501.

Yes, that was a fair bit of work.

> By the way, as part of my investigations into this bug I noticed that BigIntegerTest::divideLarge no longer tests the Burnikel-Ziegler part of the division code, since the heuristic to decide Knuth or BZ diverged from the algorithm to generate the test cases (as part of 8029501). 

I created https://bugs.openjdk.java.net/browse/JDK-8058505 for this problem.

Thanks,

Brian

From brian.burkhalter at oracle.com  Mon Sep 15 20:30:37 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 15 Sep 2014 13:30:37 -0700
Subject: JDK 9 RFR of 8058505: BigIntegerTest does not exercise
	Burnikel-Ziegler division
In-Reply-To: <1410790659.15255.YahooMailNeo@web121302.mail.ne1.yahoo.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
	<54124DFE.7000706@oracle.com>
	<81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>
	<1410772159.90189.YahooMailNeo@web121302.mail.ne1.yahoo.com>
	<1410790659.15255.YahooMailNeo@web121302.mail.ne1.yahoo.com>
Message-ID: <5DA38313-5D49-468F-9B7E-6A91BA7F85FF@oracle.com>

Hello,

This is a test-only change.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8058505
Webrev:	http://cr.openjdk.java.net/~bpb/8058505/webrev.00/

I verified that the updated version passes (as mentioned below) and in fact exercises the B-Z division branch of the library code.

Thanks,

Brian

On Sep 15, 2014, at 7:17 AM, Robert Gibson <robbiexgibson at yahoo.com> wrote:

> Here is a patch to fix the test bug mentioned previously.  The Burnikel-Ziegler division code is now exercised, and you'll be glad to know that the tests still pass!
> Robert
> 
> --- BigIntegerTest.java 2014-09-15 15:55:47.632012000 +0200
> +++ BigIntegerTestPatched.java  2014-09-15 16:07:53.363563000 +0200
> @@ -71,6 +71,7 @@
>     static final int BITS_TOOM_COOK_SQUARE = 6912;
>     static final int BITS_SCHOENHAGE_BASE = 640;
>     static final int BITS_BURNIKEL_ZIEGLER = 2560;
> +    static final int BITS_BURNIKEL_ZIEGLER_OFFSET = 1280;
>     static final int ORDER_SMALL = 60;
>     static final int ORDER_MEDIUM = 100;
> @@ -288,19 +289,19 @@
>      * where {@code abs(u) > abs(v)} and {@code a > b && b > 0}, then if
>      * {@code w/z = q1*z + r1} and {@code u/v = q2*v + r2}, then
>      * {@code q1 = q2*pow(2,a-b)} and {@code r1 = r2*pow(2,b)}.  The test
> -     * ensures that {@code v} is just under the B-Z threshold and that {@code w}
> -     * and {@code z} are both over the threshold.  This implies that {@code u/v}
> -     * uses the standard division algorithm and {@code w/z} uses the B-Z
> -     * algorithm.  The results of the two algorithms are then compared using the
> -     * observation described in the foregoing and if they are not equal a
> -     * failure is logged.
> +     * ensures that {@code v} is just under the B-Z threshold, that {@code z} is
> +     * over the threshold and {@code w} is much larger than {@code z}. This
> +     * implies that {@code u/v} uses the standard division algorithm and
> +     * {@code w/z} uses the B-Z algorithm.  The results of the two algorithms
> +     * are then compared using the observation described in the foregoing and
> +     * if they are not equal a failure is logged.
>      */
>     public static void divideLarge() {
>         int failCount = 0;
> -        BigInteger base = BigInteger.ONE.shiftLeft(BITS_BURNIKEL_ZIEGLER - 33);
> +        BigInteger base = BigInteger.ONE.shiftLeft(BITS_BURNIKEL_ZIEGLER + BITS_BURNIKEL_ZIEGLER_OFFSET - 33);
>         for (int i=0; i<SIZE; i++) {
> -            BigInteger addend = new BigInteger(BITS_BURNIKEL_ZIEGLER - 34, rnd);
> +            BigInteger addend = new BigInteger(BITS_BURNIKEL_ZIEGLER + BITS_BURNIKEL_ZIEGLER_OFFSET - 34, rnd);
>             BigInteger v = base.add(addend);
>             BigInteger u = v.multiply(BigInteger.valueOf(2 + rnd.nextInt(Short.MAX_VALUE - 1)));
> @@ -312,14 +313,14 @@
>                 v = v.negate();
>             }
> -            int a = 17 + rnd.nextInt(16);
> +            int a = BITS_BURNIKEL_ZIEGLER_OFFSET + rnd.nextInt(16);
>             int b = 1 + rnd.nextInt(16);
> -            BigInteger w = u.multiply(BigInteger.valueOf(1L << a));
> -            BigInteger z = v.multiply(BigInteger.valueOf(1L << b));
> +            BigInteger w = u.multiply(BigInteger.ONE.shiftLeft(a));
> +            BigInteger z = v.multiply(BigInteger.ONE.shiftLeft(b));
>             BigInteger[] divideResult = u.divideAndRemainder(v);
> -            divideResult[0] = divideResult[0].multiply(BigInteger.valueOf(1L << (a - b)));
> -            divideResult[1] = divideResult[1].multiply(BigInteger.valueOf(1L << b));
> +            divideResult[0] = divideResult[0].multiply(BigInteger.ONE.shiftLeft(a - b));
> +            divideResult[1] = divideResult[1].multiply(BigInteger.ONE.shiftLeft(b));
>             BigInteger[] bzResult = w.divideAndRemainder(z);
>             if (divideResult[0].compareTo(bzResult[0]) != 0 ||



From martinrb at google.com  Mon Sep 15 20:39:07 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 15 Sep 2014 13:39:07 -0700
Subject: Missing clarity in TimerTask doc
In-Reply-To: <5417261C.8090103@CoSoCo.de>
References: <5417261C.8090103@CoSoCo.de>
Message-ID: <CA+kOe0-rguidb2QEC4uhhSvsC7Yx+kpmVifdnQWenaABjqyORg@mail.gmail.com>

http://docs.oracle.com/javase/8/docs/api/java/util/Timer.html#schedule-java.util.TimerTask-long-

IllegalStateException - if task was already scheduled or cancelled, timer
was cancelled, or timer thread terminated.


On Mon, Sep 15, 2014 at 10:47 AM, Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:

> Hi all,
>
> I'm missing clarity, if a j.u.TimerTask object can be scheduled more than
> once.
> Especially, can it be scheduled again with Timer.schedule(...) after it
> has been cancelled, or has a new TimerTask object to be instantiated?
> What happens if a TimerTask is scheduled again before the first schedule
> had happened; would it then happen twice or would the same run be
> re-scheduled?
>
> Thanks,
>
> -Ulf
>
>


From jason_mehrens at hotmail.com  Mon Sep 15 21:02:13 2014
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Mon, 15 Sep 2014 16:02:13 -0500
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <54170DC7.7090603@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>
	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>
	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>
	<5412B1B3.4090708@oracle.com>,
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>,
	<5412CEBE.3000607@oracle.com>
	<5412E903.5090703@oracle.com>,<5412F768.7050904@oracle.com>
	<5412FB09.6060804@oracle.com>,<54130047.1030805@oracle.com>
	<54130662.9000803@oracle.com>,<54130A37.8070503@oracle.com>
	<BLU175-W12259009585054C5ACE4E083CD0@phx.gbl>, <54132534.407@oracle.com>
	<BLU175-W471CC4F5FA1389062DC2DC83CD0@phx.gbl>,
	<54170DC7.7090603@oracle.com>
Message-ID: <BLU175-W51D5147E68DD63EFCE04A783C80@phx.gbl>

Hi Daniel,


You covered my main concern regarding the notification so I'm on board with this patch.


For any other package I agree with you on the frowning of System.err.   However, the LogManager/Handler.reportError(ex2) seem to use it like it is the debug/failsafe option for the logging framework.  For 8043306, I think designing a failsafe mode for these types of exceptions is out of scope.  That is why I suggested using System.err.


I still think that in this case the specification could be a little user hostile given how hard it is to get the LogManager initialization just right.  I would have gone for a spec with a tone of "Don't throw uncaught exceptions.  If you do you are on your own."


regards,


Jason


----------------------------------------
> Date: Mon, 15 Sep 2014 18:03:19 +0200
> From: daniel.fuchs at oracle.com
> To: jason_mehrens at hotmail.com
> CC: core-libs-dev at openjdk.java.net
> Subject: Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
>
> Hi Jason,
>
> Logging on System.err is usually frowned upon - especially if there
> are alternatives.
>
> May I suggest the following?
>
> 1. do option #1, and only fail after all listeners have been notified
> as Alan indicated 'it might not be too bad'.
> As Paul suggested to me privately we could use
> Throwable.addSuppressed to link the suppressed exceptions, if there
> are any.
>
> 2. Log an RFE for LogManager to use ErrorManager (or
> some similar object).
>
> IMHO the proposal #1 above should not cripple how LogManager will
> evolve in the future too much - especially if it is a rarely
> used functionality.
>
> Here is a new webrev - with updated test case:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.05/
>
> best regards
>
> -- daniel
>
> On 9/12/14 7:21 PM, Jason Mehrens wrote:
>> Daniel,
>>
>>
>> Agreed. My preference would be to:
>>
>> 1. Catch and report them to 'System.err'. That type of code happens in the LogManager and exceptions in this case are not the normal condition.
>>
>> 2. Don't specify how uncaught exceptions are handled in the javadocs.
>>
>> 3. Outside of this issue, make an RFE to allow the LogManager to contain a j.u.l.ErrorManager and use it to replace all calls to System.err to use this new root/default error manager. Once these exception are captured in a error manager you can alter the behavior (rethrow, write to console, ignore, report to O/S event log, etc.)
>>
>>
>> I worry that over specification of the exception handling might cripple how the LogManager can evolve with regard to future RFEs.
>>
>>
>> Jason
>>
>> ----------------------------------------
>>> Date: Fri, 12 Sep 2014 18:54:12 +0200
>>> From: daniel.fuchs at oracle.com
>>> To: jason_mehrens at hotmail.com
>>> CC: core-libs-dev at openjdk.java.net
>>> Subject: Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
>>>
>>> On 9/12/14 5:39 PM, Jason Mehrens wrote:
>>>> Daniel,
>>>>
>>>>
>>>> I suppose that the propagating uncaught exceptions to the caller was the previous behavior of the old property change methods but it seems out of place for the LogManager. The LogManager is a global resource so broken listener code in web app A could suppress notifications in web app B and C. That doesn't seem very nice. A lot of the LogManager code handles exception via catch, report or ignore, and continue when dealing with handlers etc. I would think that same strategy applies here too.
>>>
>>> Hi Jason,
>>>
>>> Yes - that was also the behavior of the old property change methods.
>>> When the global LogManager calls itself readConfiguration it will
>>> silently ignore exceptions that might be raised.
>>>
>>> I'm not too keen in specifying that exceptions raised by listeners will
>>> be silently dropped. We're in the process of reinitializing the
>>> configuration,
>>> so trying to log the exceptions through a Logger would have its own
>>> risks too.
>>> Reporting exceptions raised during initialization and configuration is
>>> an area where java.util.logging is clearly lacking.
>>>
>>> For this patch - I think that our options are limited to the alternative:
>>> 1. propagate the exception
>>> 2. catch and silentlty drop the exception
>>>
>>> What is the 'better' behavior (and I agree neither of the two are ideal)
>>> probably depends on what is the typical use case for these listeners.
>>> My assumption is that in most cases - there will be a single listener, in
>>> which case 1. is probably better. I haven't seen any bug complaining
>>> about how exceptions were handled in the previous implementation,
>>> though I have seen some complaining about swallowed exceptions...
>>>
>>> That said - if there is consensus that 2. is better - I have no real
>>> objection except those stated above.
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>> Jason
>>>>
>>>>
>>>> ----------------------------------------
>>>>> Date: Fri, 12 Sep 2014 16:59:03 +0200
>>>>> From: daniel.fuchs at oracle.com
>>>>> To: Alan.Bateman at oracle.com
>>>>> Subject: Re: RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes
>>>>> CC: core-libs-dev at openjdk.java.net
>>>>>
>>>>> On 9/12/14 4:42 PM, Alan Bateman wrote:
>>>>>> On 12/09/2014 15:16, Daniel Fuchs wrote:
>>>>>>> Thanks Alan!
>>>>>>>
>>>>>>> I have updated the webrev with your suggestions:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
>>>>>>>
>>>>>>> -- daniel
>>>>>>>
>>>>>> A minor suggestion for readConfiguration is that "Any register
>>>>>> configuration listeners .." might be a bit better than "The
>>>>>> configuration listeners ...".
>>>>>>
>>>>>> In addConfigurationListener there is a <br> between the two sentences
>>>>>> that talk about exceptions, I don't know if you intended that.
>>>>> Done. I regenerated the webrev in place.
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.04/
>>>>>
>>>>> -- daniel
>>>>>> Otherwise the javadoc looks good to me.
>>>>>>
>>>>>> -Alan.
>>>>>
>>>
> 		 	   		  

From Ulf.Zibis at CoSoCo.de  Mon Sep 15 22:11:16 2014
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 16 Sep 2014 00:11:16 +0200
Subject: Missing clarity in TimerTask doc
In-Reply-To: <CA+kOe0-rguidb2QEC4uhhSvsC7Yx+kpmVifdnQWenaABjqyORg@mail.gmail.com>
References: <5417261C.8090103@CoSoCo.de>
	<CA+kOe0-rguidb2QEC4uhhSvsC7Yx+kpmVifdnQWenaABjqyORg@mail.gmail.com>
Message-ID: <54176404.3020302@CoSoCo.de>


Am 15.09.2014 um 22:39 schrieb Martin Buchholz:
> http://docs.oracle.com/javase/8/docs/api/java/util/Timer.html#schedule-java.util.TimerTask-long-
>
> IllegalStateException - if task was already scheduled or cancelled, timer was cancelled, or timer 
> thread terminated.

Oops, overseen, thanks!

Maybe it could be extentend to:
IllegalStateException - if task was already scheduled, cancelled or already done, timer was 
cancelled, or timer thread terminated.
... as I assume a TimerTask instance is never reusable.

Is there a reason why a TimerTask is not reset for reuse when cancelled or already done?

-Ulf


>
>
> On Mon, Sep 15, 2014 at 10:47 AM, Ulf Zibis <Ulf.Zibis at cosoco.de <mailto:Ulf.Zibis at cosoco.de>> wrote:
>
>     Hi all,
>
>     I'm missing clarity, if a j.u.TimerTask object can be scheduled more than once.
>     Especially, can it be scheduled again with Timer.schedule(...) after it has been cancelled, or
>     has a new TimerTask object to be instantiated?
>     What happens if a TimerTask is scheduled again before the first schedule had happened; would
>     it then happen twice or would the same run be re-scheduled?
>
>     Thanks,
>
>     -Ulf
>
>



From claes.redestad at oracle.com  Mon Sep 15 22:41:05 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 16 Sep 2014 00:41:05 +0200
Subject: RFR: 8058514: TEST_BUG: New tests introduced in 8058429 are TimeZone
	dependent
Message-ID: <54176B01.4090602@oracle.com>

Hi,

please review this simple fix which ensures 
java.sql.test.sql.TimestampsTests can be run successfully across the 
globe. Also use a custom timezone ("GMT+01") to make sure the test does 
not observe DST, which will keep the test running happily all year round.

webrev: http://cr.openjdk.java.net/~redestad/8058514/webrev.01/
bug: https://bugs.openjdk.java.net/browse/JDK-8058514

Thanks!

/Claes


From martinrb at google.com  Mon Sep 15 22:47:28 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 15 Sep 2014 15:47:28 -0700
Subject: Missing clarity in TimerTask doc
In-Reply-To: <54176404.3020302@CoSoCo.de>
References: <5417261C.8090103@CoSoCo.de>
	<CA+kOe0-rguidb2QEC4uhhSvsC7Yx+kpmVifdnQWenaABjqyORg@mail.gmail.com>
	<54176404.3020302@CoSoCo.de>
Message-ID: <CA+kOe0-HdYBAvCQX=iYRU2wr+jTprxEf_KTLAR=Y-9GXqTzb3g@mail.gmail.com>

On Mon, Sep 15, 2014 at 3:11 PM, Ulf Zibis <Ulf.Zibis at cosoco.de> wrote:

>
> Am 15.09.2014 um 22:39 schrieb Martin Buchholz:
>
>> http://docs.oracle.com/javase/8/docs/api/java/util/Timer.
>> html#schedule-java.util.TimerTask-long-
>>
>> IllegalStateException - if task was already scheduled or cancelled, timer
>> was cancelled, or timer thread terminated.
>>
>
> Oops, overseen, thanks!
>
> Maybe it could be extentend to:
> IllegalStateException - if task was already scheduled, cancelled or
> already done, timer was cancelled, or timer thread terminated.
> ... as I assume a TimerTask instance is never reusable.
>

It's already "technically correct" - if it was already done, then it was
already scheduled!


>
> Is there a reason why a TimerTask is not reset for reuse when cancelled or
> already done?


It's a reasonable question.  Like Futures, it's a lot easier to reason
about tasks when they atomically transition to a done state at most once.
 But e.g. FutureTask has runAndReset.


From lance.andersen at oracle.com  Mon Sep 15 23:00:52 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 15 Sep 2014 19:00:52 -0400
Subject: RFR: 8058514: TEST_BUG: New tests introduced in 8058429 are
	TimeZone dependent
In-Reply-To: <54176B01.4090602@oracle.com>
References: <54176B01.4090602@oracle.com>
Message-ID: <972462E1-FEDF-48D6-8EE2-C96B8BFD0D73@oracle.com>

Hi Claes,

I ran the revised test which passes on my box with Eastern TZ.

I know you also ran the jck tests for java.sql and they passed as well.

Thank you for doing this extra clean up.  I will push the change

Best,
lance
On Sep 15, 2014, at 6:41 PM, Claes Redestad <claes.redestad at oracle.com> wrote:

> Hi,
> 
> please review this simple fix which ensures java.sql.test.sql.TimestampsTests can be run successfully across the globe. Also use a custom timezone ("GMT+01") to make sure the test does not observe DST, which will keep the test running happily all year round.
> 
> webrev: http://cr.openjdk.java.net/~redestad/8058514/webrev.01/
> bug: https://bugs.openjdk.java.net/browse/JDK-8058514
> 
> Thanks!
> 
> /Claes



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From brent.christian at oracle.com  Mon Sep 15 23:52:31 2014
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 15 Sep 2014 16:52:31 -0700
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <53C45C88.3090000@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>
	<53C45C88.3090000@oracle.com>
Message-ID: <54177BBF.4080000@oracle.com>

Hi, Claes

I've looked over the latest changes, and they look good to me.  I can 
sponsor this.  Note that we need approval from a Reviewer.

One small nitpick from me:
2914:
If the text is left-justified, then aren't we padding on the right?  I 
would call this "padRight".

Thanks,
-Brent

On 7/14/14 3:41 PM, Claes Redestad wrote:
> Sorry about that; maybe I should've renamed the field c to conv instead,
> but I think I need to be conservative now and will revert the name changes.
>
> New webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.3
>
> Changing usage of given locale or any semantic change is really
> out-of-scope here. There seems to be a few ancient bugs hanging around
> which maybe someone should take a look at, e.g.,
> https://bugs.openjdk.java.net/browse/JDK-5063466
>
> /Claes
>
> On 2014-07-14 20:05, Jason Mehrens wrote:
>> Claes,
>>
>>
>> Maybe change (or not):
>>
>>
>> -throw new UnknownFormatConversionException(String.valueOf(c));
>>
>> +throw new UnknownFormatConversionException(String.valueOf(conv));
>>
>>
>>
>> I haven't examined it too deeply but it seems odd that some of those
>> print methods don't use the given locale when converting case.  That
>> is probably not a change for this issue.
>>
>>
>> Jason
>>
>>
>>
>>
>> ----------------------------------------
>>> Date: Mon, 14 Jul 2014 17:40:41 +0200
>>> From: claes.redestad at oracle.com
>>> To: core-libs-dev at openjdk.java.net
>>> Subject: Re: RFR [9]: 8050142: Optimize java.util.Formatter
>>>
>>> Hi,
>>>
>>> final(?) webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.2
>>>
>>> Thanks in advance for reviews. I also need a volunteer to sponsor
>>> this. :-)
>>>
>>> /Claes
>>>
>>> On 07/14/2014 04:21 PM, Claes Redestad wrote:
>>>> Yes, might be worth addressing just for correctness/readability.
>>>>
>>>> /Claes
>>>>
>>>> On 07/14/2014 03:02 PM, Ivan Gerasimov wrote:
>>>>> A very minor one:
>>>>> 2704 if (Character.isUpperCase(conv))
>>>>> 2705 f.add(Flags.UPPERCASE);
>>>>> 2706 c = Character.toLowerCase(conv);
>>>>>
>>>>> maybe
>>>>>
>>>>> 2704 if (Character.isUpperCase(conv)) {
>>>>> 2705 f.add(Flags.UPPERCASE);
>>>>> 2706 c = Character.toLowerCase(conv);
>>>>> }
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>>
>>>>> On 14.07.2014 16:23, Claes Redestad wrote:
>>>>>> Hi again,
>>>>>>
>>>>>> updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1
>>>>>>
>>>>>> changes:
>>>>>> - specify capacity on line 2931 as suggested by Andrej Golovnin
>>>>>> - exp.append("0") -> exp.append('0') on line 3781
>>>>>> - merged append+justify into appendJustified as suggested by Peter
>>>>>> Levart
>>>>>> - replaced the reoccuring pattern of appending a number of zeros
>>>>>> into a call to trailingZeros
>>>>>>
>>>>>> performance difference seemingly at noise levels in micros, but
>>>>>> bonus to readability and Formatter*.class-files are now a total of
>>>>>> 246 bytes smaller
>>>>>>
>>>>>> /Claes
>>>>>>
>>>>>> On 2014-07-14 13:29, Claes Redestad wrote:
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> On 2014-07-14 13:25, Peter Levart wrote:
>>>>>>>> On 07/14/2014 12:07 PM, Claes Redestad wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> please review this patch which optimizes away some allocations
>>>>>>>>> from java.util.Formatter and achieve 1.1-1.3x speedups of micros
>>>>>>>>> targetting String.format. See bug for more details.
>>>>>>>>>
>>>>>>>>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142
>>>>>>>>>
>>>>>>>>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter),
>>>>>>>>> SPECjbb2013 and microbenchmarks
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> /Claes
>>>>>>>> Hi Claes,
>>>>>>>>
>>>>>>>> Since justify() result is always appended to the resulting
>>>>>>>> Appendable, you could merge the functionality and eliminate
>>>>>>>> constructing intermediary StringBuilder altogether:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/
>>>>>>>>
>>>>>>> Looks good, especially eliminating the need for two different
>>>>>>> append methods. I'll update based on this and other suggestions.
>>>>>>>
>>>>>>> /Claes
>>>>>>>> Regards, Peter
>>>>>>
>>>>>>
>>>
>


From joe.darcy at oracle.com  Tue Sep 16 00:04:01 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 15 Sep 2014 17:04:01 -0700
Subject: JDK 9 RFR of 8058505: BigIntegerTest does not exercise
	Burnikel-Ziegler division
In-Reply-To: <5DA38313-5D49-468F-9B7E-6A91BA7F85FF@oracle.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
	<54124DFE.7000706@oracle.com>
	<81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>
	<1410772159.90189.YahooMailNeo@web121302.mail.ne1.yahoo.com>
	<1410790659.15255.YahooMailNeo@web121302.mail.ne1.yahoo.com>
	<5DA38313-5D49-468F-9B7E-6A91BA7F85FF@oracle.com>
Message-ID: <54177E71.2040405@oracle.com>

Hi Brian,

The test change looks fine; thanks,

-Joe

On 9/15/2014 1:30 PM, Brian Burkhalter wrote:
> Hello,
>
> This is a test-only change.
>
> Issue:https://bugs.openjdk.java.net/browse/JDK-8058505
> Webrev:http://cr.openjdk.java.net/~bpb/8058505/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ebpb/8058505/webrev.00/>
>
> I verified that the updated version passes (as mentioned below) and in 
> fact exercises the B-Z division branch of the library code.
>
> Thanks,
>
> Brian
>
> On Sep 15, 2014, at 7:17 AM, Robert Gibson <robbiexgibson at yahoo.com 
> <mailto:robbiexgibson at yahoo.com>> wrote:
>
>> Here is a patch to fix the test bug mentioned previously.  The 
>> Burnikel-Ziegler division code is now exercised, and you'll be glad 
>> to know that the tests still pass!
>> Robert
>>
>> --- BigIntegerTest.java 2014-09-15 15:55:47.632012000 +0200
>> +++ BigIntegerTestPatched.java  2014-09-15 16:07:53.363563000 +0200
>> @@ -71,6 +71,7 @@
>>     static final int BITS_TOOM_COOK_SQUARE = 6912;
>>     static final int BITS_SCHOENHAGE_BASE = 640;
>>     static final int BITS_BURNIKEL_ZIEGLER = 2560;
>> +    static final int BITS_BURNIKEL_ZIEGLER_OFFSET = 1280;
>>     static final int ORDER_SMALL = 60;
>>     static final int ORDER_MEDIUM = 100;
>> @@ -288,19 +289,19 @@
>>      * where {@code abs(u) > abs(v)} and {@code a > b && b > 0}, then if
>>      * {@code w/z = q1*z + r1} and {@code u/v = q2*v + r2}, then
>>      * {@code q1 = q2*pow(2,a-b)} and {@code r1 = r2*pow(2,b)}.  The test
>> -     * ensures that {@code v} is just under the B-Z threshold and 
>> that {@code w}
>> -     * and {@code z} are both over the threshold.  This implies that 
>> {@code u/v}
>> -     * uses the standard division algorithm and {@code w/z} uses the B-Z
>> -     * algorithm.  The results of the two algorithms are then 
>> compared using the
>> -     * observation described in the foregoing and if they are not 
>> equal a
>> -     * failure is logged.
>> +     * ensures that {@code v} is just under the B-Z threshold, that 
>> {@code z} is
>> +     * over the threshold and {@code w} is much larger than {@code 
>> z}. This
>> +     * implies that {@code u/v} uses the standard division algorithm and
>> +     * {@code w/z} uses the B-Z algorithm.  The results of the two 
>> algorithms
>> +     * are then compared using the observation described in the 
>> foregoing and
>> +     * if they are not equal a failure is logged.
>>      */
>>     public static void divideLarge() {
>>         int failCount = 0;
>> -        BigInteger base = 
>> BigInteger.ONE.shiftLeft(BITS_BURNIKEL_ZIEGLER - 33);
>> +        BigInteger base = 
>> BigInteger.ONE.shiftLeft(BITS_BURNIKEL_ZIEGLER + 
>> BITS_BURNIKEL_ZIEGLER_OFFSET - 33);
>>         for (int i=0; i<SIZE; i++) {
>> -            BigInteger addend = new BigInteger(BITS_BURNIKEL_ZIEGLER 
>> - 34, rnd);
>> +            BigInteger addend = new BigInteger(BITS_BURNIKEL_ZIEGLER 
>> + BITS_BURNIKEL_ZIEGLER_OFFSET - 34, rnd);
>>             BigInteger v = base.add(addend);
>>             BigInteger u = v.multiply(BigInteger.valueOf(2 + 
>> rnd.nextInt(Short.MAX_VALUE - 1)));
>> @@ -312,14 +313,14 @@
>>                 v = v.negate();
>>             }
>> -            int a = 17 + rnd.nextInt(16);
>> +            int a = BITS_BURNIKEL_ZIEGLER_OFFSET + rnd.nextInt(16);
>>             int b = 1 + rnd.nextInt(16);
>> -            BigInteger w = u.multiply(BigInteger.valueOf(1L << a));
>> -            BigInteger z = v.multiply(BigInteger.valueOf(1L << b));
>> +            BigInteger w = u.multiply(BigInteger.ONE.shiftLeft(a));
>> +            BigInteger z = v.multiply(BigInteger.ONE.shiftLeft(b));
>>             BigInteger[] divideResult = u.divideAndRemainder(v);
>> -            divideResult[0] = 
>> divideResult[0].multiply(BigInteger.valueOf(1L << (a - b)));
>> -            divideResult[1] = 
>> divideResult[1].multiply(BigInteger.valueOf(1L << b));
>> +            divideResult[0] = 
>> divideResult[0].multiply(BigInteger.ONE.shiftLeft(a - b));
>> +            divideResult[1] = 
>> divideResult[1].multiply(BigInteger.ONE.shiftLeft(b));
>>             BigInteger[] bzResult = w.divideAndRemainder(z);
>>             if (divideResult[0].compareTo(bzResult[0]) != 0 ||
>



From martinrb at google.com  Tue Sep 16 01:40:28 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 15 Sep 2014 18:40:28 -0700
Subject: RFR: 8058520: jar xf does not work on zip files with leading garbage.
Message-ID: <CA+kOe0_2_Tpcs7z9NoTVa13HCzP76T0Q_Qkz9hysdbXxzNPYiw@mail.gmail.com>

Hi Alan, Xueming,

I'd like you to do a code review.

https://bugs.openjdk.java.net/browse/JDK-8058520
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jar-leadingGarbage/


From marcus.lagergren at oracle.com  Tue Sep 16 09:34:17 2014
From: marcus.lagergren at oracle.com (Marcus Lagergren)
Date: Tue, 16 Sep 2014 11:34:17 +0200
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <54177BBF.4080000@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>
	<53C45C88.3090000@oracle.com> <54177BBF.4080000@oracle.com>
Message-ID: <A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>

I am reviewer and they look good to me too. ~30% better performance for random indata- Do you pass the JCK? If so you have my blessing.

/M

On 16 Sep 2014, at 01:52, Brent Christian <brent.christian at oracle.com> wrote:

> Hi, Claes
> 
> I've looked over the latest changes, and they look good to me.  I can sponsor this.  Note that we need approval from a Reviewer.
> 
> One small nitpick from me:
> 2914:
> If the text is left-justified, then aren't we padding on the right?  I would call this "padRight".
> 
> Thanks,
> -Brent
> 
> On 7/14/14 3:41 PM, Claes Redestad wrote:
>> Sorry about that; maybe I should've renamed the field c to conv instead,
>> but I think I need to be conservative now and will revert the name changes.
>> 
>> New webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.3
>> 
>> Changing usage of given locale or any semantic change is really
>> out-of-scope here. There seems to be a few ancient bugs hanging around
>> which maybe someone should take a look at, e.g.,
>> https://bugs.openjdk.java.net/browse/JDK-5063466
>> 
>> /Claes
>> 
>> On 2014-07-14 20:05, Jason Mehrens wrote:
>>> Claes,
>>> 
>>> 
>>> Maybe change (or not):
>>> 
>>> 
>>> -throw new UnknownFormatConversionException(String.valueOf(c));
>>> 
>>> +throw new UnknownFormatConversionException(String.valueOf(conv));
>>> 
>>> 
>>> 
>>> I haven't examined it too deeply but it seems odd that some of those
>>> print methods don't use the given locale when converting case.  That
>>> is probably not a change for this issue.
>>> 
>>> 
>>> Jason
>>> 
>>> 
>>> 
>>> 
>>> ----------------------------------------
>>>> Date: Mon, 14 Jul 2014 17:40:41 +0200
>>>> From: claes.redestad at oracle.com
>>>> To: core-libs-dev at openjdk.java.net
>>>> Subject: Re: RFR [9]: 8050142: Optimize java.util.Formatter
>>>> 
>>>> Hi,
>>>> 
>>>> final(?) webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.2
>>>> 
>>>> Thanks in advance for reviews. I also need a volunteer to sponsor
>>>> this. :-)
>>>> 
>>>> /Claes
>>>> 
>>>> On 07/14/2014 04:21 PM, Claes Redestad wrote:
>>>>> Yes, might be worth addressing just for correctness/readability.
>>>>> 
>>>>> /Claes
>>>>> 
>>>>> On 07/14/2014 03:02 PM, Ivan Gerasimov wrote:
>>>>>> A very minor one:
>>>>>> 2704 if (Character.isUpperCase(conv))
>>>>>> 2705 f.add(Flags.UPPERCASE);
>>>>>> 2706 c = Character.toLowerCase(conv);
>>>>>> 
>>>>>> maybe
>>>>>> 
>>>>>> 2704 if (Character.isUpperCase(conv)) {
>>>>>> 2705 f.add(Flags.UPPERCASE);
>>>>>> 2706 c = Character.toLowerCase(conv);
>>>>>> }
>>>>>> 
>>>>>> Sincerely yours,
>>>>>> Ivan
>>>>>> 
>>>>>> 
>>>>>> On 14.07.2014 16:23, Claes Redestad wrote:
>>>>>>> Hi again,
>>>>>>> 
>>>>>>> updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1
>>>>>>> 
>>>>>>> changes:
>>>>>>> - specify capacity on line 2931 as suggested by Andrej Golovnin
>>>>>>> - exp.append("0") -> exp.append('0') on line 3781
>>>>>>> - merged append+justify into appendJustified as suggested by Peter
>>>>>>> Levart
>>>>>>> - replaced the reoccuring pattern of appending a number of zeros
>>>>>>> into a call to trailingZeros
>>>>>>> 
>>>>>>> performance difference seemingly at noise levels in micros, but
>>>>>>> bonus to readability and Formatter*.class-files are now a total of
>>>>>>> 246 bytes smaller
>>>>>>> 
>>>>>>> /Claes
>>>>>>> 
>>>>>>> On 2014-07-14 13:29, Claes Redestad wrote:
>>>>>>>> Hi Peter,
>>>>>>>> 
>>>>>>>> On 2014-07-14 13:25, Peter Levart wrote:
>>>>>>>>> On 07/14/2014 12:07 PM, Claes Redestad wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> please review this patch which optimizes away some allocations
>>>>>>>>>> from java.util.Formatter and achieve 1.1-1.3x speedups of micros
>>>>>>>>>> targetting String.format. See bug for more details.
>>>>>>>>>> 
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142
>>>>>>>>>> 
>>>>>>>>>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter),
>>>>>>>>>> SPECjbb2013 and microbenchmarks
>>>>>>>>>> 
>>>>>>>>>> Thanks!
>>>>>>>>>> 
>>>>>>>>>> /Claes
>>>>>>>>> Hi Claes,
>>>>>>>>> 
>>>>>>>>> Since justify() result is always appended to the resulting
>>>>>>>>> Appendable, you could merge the functionality and eliminate
>>>>>>>>> constructing intermediary StringBuilder altogether:
>>>>>>>>> 
>>>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/
>>>>>>>>> 
>>>>>>>> Looks good, especially eliminating the need for two different
>>>>>>>> append methods. I'll update based on this and other suggestions.
>>>>>>>> 
>>>>>>>> /Claes
>>>>>>>>> Regards, Peter
>>>>>>> 
>>>>>>> 
>>>> 
>> 



From pavel.rappo at oracle.com  Tue Sep 16 11:12:14 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 16 Sep 2014 12:12:14 +0100
Subject: RFR JDK-8044627: Update JNDI to work with modules
Message-ID: <FA8A05BE-42D8-4F46-BD4B-270CDCEA7BE2@oracle.com>

Hi everyone,

Could you please review my change for JDK-8044627?

http://cr.openjdk.java.net/~prappo/8044627/webrev.00/

-Pavel


From Ulf.Zibis at CoSoCo.de  Tue Sep 16 12:05:46 2014
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 16 Sep 2014 14:05:46 +0200
Subject: Missing clarity in TimerTask doc
In-Reply-To: <CA+kOe0-HdYBAvCQX=iYRU2wr+jTprxEf_KTLAR=Y-9GXqTzb3g@mail.gmail.com>
References: <5417261C.8090103@CoSoCo.de>	<CA+kOe0-rguidb2QEC4uhhSvsC7Yx+kpmVifdnQWenaABjqyORg@mail.gmail.com>	<54176404.3020302@CoSoCo.de>
	<CA+kOe0-HdYBAvCQX=iYRU2wr+jTprxEf_KTLAR=Y-9GXqTzb3g@mail.gmail.com>
Message-ID: <5418279A.5070800@CoSoCo.de>

Am 16.09.2014 um 00:47 schrieb Martin Buchholz:
>
>     Maybe it could be extentend to:
>     IllegalStateException - if task was already scheduled, cancelled or already done, timer was
>     cancelled, or timer thread terminated.
>     ... as I assume a TimerTask instance is never reusable.
>
>
> It's already "technically correct" - if it was already done, then it was already scheduled!

Correct!
Note: https://bugs.openjdk.java.net/browse/JDK-8058550

>     Is there a reason why a TimerTask is not reset for reuse when cancelled or already done?
>
>
> It's a reasonable question.  Like Futures, it's a lot easier to reason about tasks when they 
> atomically transition to a done state at most once.  But e.g. FutureTask has runAndReset.

Interesting.

-Ulf




From daniel.fuchs at oracle.com  Tue Sep 16 13:11:18 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 16 Sep 2014 15:11:18 +0200
Subject: RFR JDK-8044627: Update JNDI to work with modules
In-Reply-To: <FA8A05BE-42D8-4F46-BD4B-270CDCEA7BE2@oracle.com>
References: <FA8A05BE-42D8-4F46-BD4B-270CDCEA7BE2@oracle.com>
Message-ID: <541836F6.6090504@oracle.com>

On 9/16/14 1:12 PM, Pavel Rappo wrote:
> Hi everyone,
>
> Could you please review my change for JDK-8044627?
>
> http://cr.openjdk.java.net/~prappo/8044627/webrev.00/
>
> -Pavel
>

Hi Pavel,

Given that helper.loadClass uses the context class loader,
Should you also simply use
   ServiceLoader<InitialContextFactory> loader =
                      ServiceLoader.load(InitialContextFactory.class);
at lines 680-681 ?


Also it might be good to log an RFE against the ServiceLoader, so
that you could look for a service implementation of a specific
concrete class without having to instantiate all the other
service implementations encountered along the way.
Streams should provide a nice infrastructure for such an API.

It would certainly be more robust than looping over
ServiceLoader.iterator().next() - which is unfortunately the only
option available to you at the moment.
This seems a bit fragile to me - unless it's guaranteed that
the various InitialContextFactory have no static initializer
that might throw exceptions (such as SecurityException) - and
that their default constructor does nothing (so that instantiating
e.g. com.sun.jndi.cosnaming.CNCtxFactory when you're actually
looking for com.sun.jndi.ldap.LdapCtxFactory has no side effect
- which fortunately seems to be the case).

Also - it would be good to clarify the specification of
   public static Context getInitialContext(Hashtable<?,?> env)

It was not clear to me that you would loop over all the
services found by the ServiceLoader until you'd find one
whose concrete class matched the name pointed to by
Context.INITIAL_CONTEXT_FACTORY.

best regards,

-- daniel






From claes.redestad at oracle.com  Tue Sep 16 13:15:50 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 16 Sep 2014 15:15:50 +0200
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>
	<53C45C88.3090000@oracle.com> <54177BBF.4080000@oracle.com>
	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>
Message-ID: <54183806.8050401@oracle.com>

Brent, Marcus,

thank you for reviewing!

JCK 9 tests for api/java_util api/java_lang either pass or fail with or 
without this patch on my machine.

Also reran relevant jtreg tests (jdk/test/java/util/Formatter 
jdk/test/java/util/Formattable jdk/test/java/lang/String 
jdk/test/java/lang/System)

Ok to fix nits offline without posting new webrev?

/Claes

On 09/16/2014 11:34 AM, Marcus Lagergren wrote:
> I am reviewer and they look good to me too. ~30% better performance for random indata- Do you pass the JCK? If so you have my blessing.
>
> /M
>
> On 16 Sep 2014, at 01:52, Brent Christian <brent.christian at oracle.com> wrote:
>
>> Hi, Claes
>>
>> I've looked over the latest changes, and they look good to me.  I can sponsor this.  Note that we need approval from a Reviewer.
>>
>> One small nitpick from me:
>> 2914:
>> If the text is left-justified, then aren't we padding on the right?  I would call this "padRight".
>>
>> Thanks,
>> -Brent
>>
>> On 7/14/14 3:41 PM, Claes Redestad wrote:
>>> Sorry about that; maybe I should've renamed the field c to conv instead,
>>> but I think I need to be conservative now and will revert the name changes.
>>>
>>> New webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.3
>>>
>>> Changing usage of given locale or any semantic change is really
>>> out-of-scope here. There seems to be a few ancient bugs hanging around
>>> which maybe someone should take a look at, e.g.,
>>> https://bugs.openjdk.java.net/browse/JDK-5063466
>>>
>>> /Claes
>>>
>>> On 2014-07-14 20:05, Jason Mehrens wrote:
>>>> Claes,
>>>>
>>>>
>>>> Maybe change (or not):
>>>>
>>>>
>>>> -throw new UnknownFormatConversionException(String.valueOf(c));
>>>>
>>>> +throw new UnknownFormatConversionException(String.valueOf(conv));
>>>>
>>>>
>>>>
>>>> I haven't examined it too deeply but it seems odd that some of those
>>>> print methods don't use the given locale when converting case.  That
>>>> is probably not a change for this issue.
>>>>
>>>>
>>>> Jason
>>>>
>>>>
>>>>
>>>>
>>>> ----------------------------------------
>>>>> Date: Mon, 14 Jul 2014 17:40:41 +0200
>>>>> From: claes.redestad at oracle.com
>>>>> To: core-libs-dev at openjdk.java.net
>>>>> Subject: Re: RFR [9]: 8050142: Optimize java.util.Formatter
>>>>>
>>>>> Hi,
>>>>>
>>>>> final(?) webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.2
>>>>>
>>>>> Thanks in advance for reviews. I also need a volunteer to sponsor
>>>>> this. :-)
>>>>>
>>>>> /Claes
>>>>>
>>>>> On 07/14/2014 04:21 PM, Claes Redestad wrote:
>>>>>> Yes, might be worth addressing just for correctness/readability.
>>>>>>
>>>>>> /Claes
>>>>>>
>>>>>> On 07/14/2014 03:02 PM, Ivan Gerasimov wrote:
>>>>>>> A very minor one:
>>>>>>> 2704 if (Character.isUpperCase(conv))
>>>>>>> 2705 f.add(Flags.UPPERCASE);
>>>>>>> 2706 c = Character.toLowerCase(conv);
>>>>>>>
>>>>>>> maybe
>>>>>>>
>>>>>>> 2704 if (Character.isUpperCase(conv)) {
>>>>>>> 2705 f.add(Flags.UPPERCASE);
>>>>>>> 2706 c = Character.toLowerCase(conv);
>>>>>>> }
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>>
>>>>>>>
>>>>>>> On 14.07.2014 16:23, Claes Redestad wrote:
>>>>>>>> Hi again,
>>>>>>>>
>>>>>>>> updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1
>>>>>>>>
>>>>>>>> changes:
>>>>>>>> - specify capacity on line 2931 as suggested by Andrej Golovnin
>>>>>>>> - exp.append("0") -> exp.append('0') on line 3781
>>>>>>>> - merged append+justify into appendJustified as suggested by Peter
>>>>>>>> Levart
>>>>>>>> - replaced the reoccuring pattern of appending a number of zeros
>>>>>>>> into a call to trailingZeros
>>>>>>>>
>>>>>>>> performance difference seemingly at noise levels in micros, but
>>>>>>>> bonus to readability and Formatter*.class-files are now a total of
>>>>>>>> 246 bytes smaller
>>>>>>>>
>>>>>>>> /Claes
>>>>>>>>
>>>>>>>> On 2014-07-14 13:29, Claes Redestad wrote:
>>>>>>>>> Hi Peter,
>>>>>>>>>
>>>>>>>>> On 2014-07-14 13:25, Peter Levart wrote:
>>>>>>>>>> On 07/14/2014 12:07 PM, Claes Redestad wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> please review this patch which optimizes away some allocations
>>>>>>>>>>> from java.util.Formatter and achieve 1.1-1.3x speedups of micros
>>>>>>>>>>> targetting String.format. See bug for more details.
>>>>>>>>>>>
>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0
>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142
>>>>>>>>>>>
>>>>>>>>>>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter),
>>>>>>>>>>> SPECjbb2013 and microbenchmarks
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> /Claes
>>>>>>>>>> Hi Claes,
>>>>>>>>>>
>>>>>>>>>> Since justify() result is always appended to the resulting
>>>>>>>>>> Appendable, you could merge the functionality and eliminate
>>>>>>>>>> constructing intermediary StringBuilder altogether:
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/
>>>>>>>>>>
>>>>>>>>> Looks good, especially eliminating the need for two different
>>>>>>>>> append methods. I'll update based on this and other suggestions.
>>>>>>>>>
>>>>>>>>> /Claes
>>>>>>>>>> Regards, Peter
>>>>>>>>



From Alan.Bateman at oracle.com  Tue Sep 16 13:56:06 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Sep 2014 14:56:06 +0100
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <54170DC7.7090603@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>,
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>,
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>,
	<5412F768.7050904@oracle.com> <5412FB09.6060804@oracle.com>,
	<54130047.1030805@oracle.com> <54130662.9000803@oracle.com>,
	<54130A37.8070503@oracle.com>	<BLU175-W12259009585054C5ACE4E083CD0@phx.gbl>,
	<54132534.407@oracle.com> <BLU175-W471CC4F5FA1389062DC2DC83CD0@phx.gbl>
	<54170DC7.7090603@oracle.com>
Message-ID: <54184176.701@oracle.com>

On 15/09/2014 17:03, Daniel Fuchs wrote:
> :
>
>
> Here is a new webrev - with updated test case:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.05/
>
I think this quite good now.

Just on this wording:

"If a listener terminates with an uncaught error or exception thenthe 
first exception that was raised will be propagated to the caller of 
readConfiguration after all listeners have been invoked."

I think you can shorten this a bit by dropping "that was raised" from 
the sentence.

Future maintainers might wonder why invokeConfigurationListeners takes a 
snapshot of the listeners so I think that deserves a comment in the code.

-Alan


From vladimir.x.ivanov at oracle.com  Tue Sep 16 14:01:56 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 16 Sep 2014 18:01:56 +0400
Subject: [9] RFR (S): 8058291: Missing some checks during parameter
	validation
In-Reply-To: <835AAD6C-DE35-4EB2-B174-B977C16E9BBE@oracle.com>
References: <54170DDD.1010102@oracle.com>
	<835AAD6C-DE35-4EB2-B174-B977C16E9BBE@oracle.com>
Message-ID: <541842D4.9030701@oracle.com>

Thank you, John.

Best regards,
Vladimir Ivanov

On 9/16/14, 12:01 AM, John Rose wrote:
> Reviewed.
>
> Nice tuning of the asserts.
>
> ? John
>
> On Sep 15, 2014, at 9:03 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> http://cr.openjdk.java.net/~vlivanov/8058291/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8058291
>>
>> 8057656 & 8050166 changes accidentally removed some checks during argument validation in MHs.dropArguments() and MHs.explicitCastArguments(). The fix is to restore them.
>>
>> Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>


From vladimir.x.ivanov at oracle.com  Tue Sep 16 14:03:35 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 16 Sep 2014 18:03:35 +0400
Subject: [9] RFR (S): 8058293: Bit set computation in
	MHs.findFirstDupOrDrop/findFirstDrop is broken
In-Reply-To: <C5F2AC42-440A-4699-9709-FDC3DF371A34@oracle.com>
References: <54171848.4060200@oracle.com>
	<C5F2AC42-440A-4699-9709-FDC3DF371A34@oracle.com>
Message-ID: <54184337.3070704@oracle.com>

Thank you, John.

I did an adhoc test run with BIT_LIMIT=0 set, but I don't think it worth 
a separate parameter in the code.

Best regards,
Vladimir Ivanov

On 9/15/14, 11:44 PM, John Rose wrote:
> On Sep 15, 2014, at 9:48 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> https://bugs.openjdk.java.net/browse/JDK-8058293
>> http://cr.openjdk.java.net/~vlivanov/8058293/webrev.00
>>
>> Bit set computation in MHs.findFirstDupOrDrop/findFirstDrop is incorrect due to widening primitive conversions (int -> long) taking place. The fix is to explicitly use long where needed.
>>
>> Also, fixed a case when reorder represents a permutation (zeroPos == newArity).
>>
>> Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams w/ "-ea -esa" and COMPILE_THRESHOLD={0,30}
>
> Wow, that's foul.  Thanks for patching it up.  Next time I'll start with "BIT_LIMIT = 31".
>
> Reviewed.
>
> FTR, it's worth exercising the code with BIT_LIMIT = 0, just to stress the slow path.
>
> ? John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


From pavel.rappo at oracle.com  Tue Sep 16 14:14:49 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 16 Sep 2014 15:14:49 +0100
Subject: RFR JDK-8044627: Update JNDI to work with modules
In-Reply-To: <541836F6.6090504@oracle.com>
References: <FA8A05BE-42D8-4F46-BD4B-270CDCEA7BE2@oracle.com>
	<541836F6.6090504@oracle.com>
Message-ID: <A061F1F8-6954-40E1-A622-00DBC7168C0A@oracle.com>

Daniel,

> Given that helper.loadClass uses the context class loader,
> Should you also simply use
>  ServiceLoader<InitialContextFactory> loader =
>                     ServiceLoader.load(InitialContextFactory.class);
> at lines 680-681 ?

It needs to be the system class loader to allow for JNDI providers that might be on the class path or module path. 

> Also it might be good to log an RFE against the ServiceLoader, so
> that you could look for a service implementation of a specific
> concrete class without having to instantiate all the other
> service implementations encountered along the way.
> Streams should provide a nice infrastructure for such an API.
> It would certainly be more robust than looping over
> ServiceLoader.iterator().next() - which is unfortunately the only
> option available to you at the moment.

IMO, it's not just an inconvenience, but rather a part of ServiceLoader's design. I mean, it's definitely designed to provide, so to say, a "one-to-many" mapping for the classes (providers) that implements some interface (a service) to a client. It merely delivers you implementations. You should than iterate though them and decide which one satisfies your needs. I'm not sure it's a good idea to get services based on their implementation classnames. It's more likely to be a little bit a flaw in design from the JNDI part -- when you have to specify the implementation class's FQN. But given the history of the JNDI (it's started as a project outside the JDK) -- it's totally understandable.
(Just as a side-note, have a look at these examples of usage of ServiceLoader:

	java.net.InetAddress:862
	java.time.chrono.AbstractChronology:274
	java.time.chrono.AbstractChronology:307
	javax.xml.validation.SchemaFactoryFinder:405
	javax.xml.xpath.XPathFactoryFinder:403
	java.time.zone.ZoneRulesProvider:177)

> Also - it would be good to clarify the specification of
>  public static Context getInitialContext(Hashtable<?,?> env)
> It was not clear to me that you would loop over all the
> services found by the ServiceLoader until you'd find one
> whose concrete class matched the name pointed to by
> Context.INITIAL_CONTEXT_FACTORY.

Don't you think it becomes than 'overspecified'? Why should we want to tie ourselves?

> This seems a bit fragile to me - unless it's guaranteed that
> the various InitialContextFactory have no static initializer
> that might throw exceptions (such as SecurityException) - and
> that their default constructor does nothing (so that instantiating
> e.g. com.sun.jndi.cosnaming.CNCtxFactory when you're actually
> looking for com.sun.jndi.ldap.LdapCtxFactory has no side effect
> - which fortunately seems to be the case).

Well, no one can guarantee us this. Even a constructor could do all the things you've mentioned :) It's just the nature of a factory. It should better be stateless and without any side effects.

-Pavel



From Alan.Bateman at oracle.com  Tue Sep 16 14:56:50 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Sep 2014 15:56:50 +0100
Subject: RFR JDK-8044627: Update JNDI to work with modules
In-Reply-To: <A061F1F8-6954-40E1-A622-00DBC7168C0A@oracle.com>
References: <FA8A05BE-42D8-4F46-BD4B-270CDCEA7BE2@oracle.com>	<541836F6.6090504@oracle.com>
	<A061F1F8-6954-40E1-A622-00DBC7168C0A@oracle.com>
Message-ID: <54184FB2.1000108@oracle.com>

On 16/09/2014 15:14, Pavel Rappo wrote:
> Daniel,
>
>> Given that helper.loadClass uses the context class loader,
>> Should you also simply use
>>   ServiceLoader<InitialContextFactory> loader =
>>                      ServiceLoader.load(InitialContextFactory.class);
>> at lines 680-681 ?
> It needs to be the system class loader to allow for JNDI providers that might be on the class path or module path.
The TCCL would be more appropriate here as that would allow for JNDI 
providers that are bundled with the application (the TCCL should 
eventually delegate to the system class loader so it should find the 
JNDI provider on the class path or linked into the runtime image too).

> :
>
> IMO, it's not just an inconvenience, but rather a part of ServiceLoader's design. I mean, it's definitely designed to provide, so to say, a "one-to-many" mapping for the classes (providers) that implements some interface (a service) to a client. It merely delivers you implementations. You should than iterate though them and decide which one satisfies your needs. I'm not sure it's a good idea to get services based on their implementation classnames.
Right, it's the user of ServiceLoader that does the selection. The real 
issue here of course is the JNDI API where the user specifies the class 
name of the implementation factory when creating the initial context. 
I've no doubt that it would be done differently if re-designed now.

-Alan


From daniel.fuchs at oracle.com  Tue Sep 16 15:31:54 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 16 Sep 2014 17:31:54 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <54184176.701@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>,
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>,
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>,
	<5412F768.7050904@oracle.com> <5412FB09.6060804@oracle.com>,
	<54130047.1030805@oracle.com> <54130662.9000803@oracle.com>,
	<54130A37.8070503@oracle.com>	<BLU175-W12259009585054C5ACE4E083CD0@phx.gbl>,
	<54132534.407@oracle.com> <BLU175-W471CC4F5FA1389062DC2DC83CD0@phx.gbl>
	<54170DC7.7090603@oracle.com> <54184176.701@oracle.com>
Message-ID: <541857EA.3070300@oracle.com>

Done.

http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.06

On 9/16/14 3:56 PM, Alan Bateman wrote:
> On 15/09/2014 17:03, Daniel Fuchs wrote:
>> :
>>
>>
>> Here is a new webrev - with updated test case:
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.05/
>>
> I think this quite good now.
>
> Just on this wording:
>
> "If a listener terminates with an uncaught error or exception thenthe
> first exception that was raised will be propagated to the caller of
> readConfiguration after all listeners have been invoked."
>
> I think you can shorten this a bit by dropping "that was raised" from
> the sentence.
>
> Future maintainers might wonder why invokeConfigurationListeners takes a
> snapshot of the listeners so I think that deserves a comment in the code.
>
> -Alan



From daniel.fuchs at oracle.com  Tue Sep 16 15:37:44 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 16 Sep 2014 17:37:44 +0200
Subject: RFR JDK-8044627: Update JNDI to work with modules
In-Reply-To: <A061F1F8-6954-40E1-A622-00DBC7168C0A@oracle.com>
References: <FA8A05BE-42D8-4F46-BD4B-270CDCEA7BE2@oracle.com>
	<541836F6.6090504@oracle.com>
	<A061F1F8-6954-40E1-A622-00DBC7168C0A@oracle.com>
Message-ID: <54185948.2000400@oracle.com>

On 9/16/14 4:14 PM, Pavel Rappo wrote:
> Daniel,
>
>> Given that helper.loadClass uses the context class loader,
>> Should you also simply use
>>   ServiceLoader<InitialContextFactory> loader =
>>                      ServiceLoader.load(InitialContextFactory.class);
>> at lines 680-681 ?
>
> It needs to be the system class loader to allow for JNDI providers that might be on the class path or module path.

So is it expected that modules (e.g. java.corba) will register
their own service provider for the InitialContextFactory
(I mean - using META-INF/services/)?

>> Also it might be good to log an RFE against the ServiceLoader, so
>> that you could look for a service implementation of a specific
>> concrete class without having to instantiate all the other
>> service implementations encountered along the way.
>> Streams should provide a nice infrastructure for such an API.
>> It would certainly be more robust than looping over
>> ServiceLoader.iterator().next() - which is unfortunately the only
>> option available to you at the moment.
>
> IMO, it's not just an inconvenience, but rather a part of ServiceLoader's design. I mean, it's definitely designed to provide, so to say, a "one-to-many" mapping for the classes (providers) that implements some interface (a service) to a client. It merely delivers you implementations. You should than iterate though them and decide which one satisfies your needs. I'm not sure it's a good idea to get services based on their implementation classnames. It's more likely to be a little bit a flaw in design from the JNDI part -- when you have to specify the implementation class's FQN. But given the history of the JNDI (it's started as a project outside the JDK) -- it's totally understandable.

Right. It's not usual to use the service loader to look for a specific
concrete implementation class name. So on the one side what you're doing
may be better than modifying ServiceLoader to support an unusual usage.
I can buy this.

> (Just as a side-note, have a look at these examples of usage of ServiceLoader:
>
         [snip]
> 	javax.xml.validation.SchemaFactoryFinder:405
> 	javax.xml.xpath.XPathFactoryFinder:403
         [snip]

I know these two ;-) I updated JAXP to use ServiceLoader :-)

The difference however is that in  this two case we're looking for
a service implementing a specific feature, we're not looking for a
service whose concrete class matches a specific class name.

In the case of InitialContextFactory - as a client of the API, I
would be a bit surprised if - asking for a LDAP InitialContext,
I received a CORBA exception. This would look strange to me.
But maybe there's nothing you can do given how JNDI is
currently working.

A possibilty might be to use InitialContextFactoryBuilder as the
service interface instead, and loop over the implementations until
you find one that does not throw NamingException - but then it
would be difficult to make the distinction between
'This builder does not support the Context.INITIAL_CONTEXT_FACTORY
  that you ask for' and 'The InitialContextFactory could not be
  instantiated for various reasons'...

So I'm not sure it would be better.

> 	java.time.zone.ZoneRulesProvider:177)
>
>> Also - it would be good to clarify the specification of
>>   public static Context getInitialContext(Hashtable<?,?> env)
>> It was not clear to me that you would loop over all the
>> services found by the ServiceLoader until you'd find one
>> whose concrete class matched the name pointed to by
>> Context.INITIAL_CONTEXT_FACTORY.
>
> Don't you think it becomes than 'overspecified'? Why should we want to tie ourselves?

Maybe it's because I haven't used JNDI very often, but when
I read the spec I didn't realize that the value of 
Context.INITIAL_CONTEXT_FACTORY would have any effect if
ServiceLoader was used - because it's not usual to use
ServiceLoader in this way (even though the usage of
ServiceLoader is nested below 'the class specified in
the Context.INITIAL_CONTEXT_FACTORY</tt> environment property
is used').
I'm not sure it would be overspecifying to say that the ServiceLoader
is used to locate and load an implementation of the service whose
concrete class matches the named class - since that's what it's
doing anyway - but I understand your concern.


>> This seems a bit fragile to me - unless it's guaranteed that
>> the various InitialContextFactory have no static initializer
>> that might throw exceptions (such as SecurityException) - and
>> that their default constructor does nothing (so that instantiating
>> e.g. com.sun.jndi.cosnaming.CNCtxFactory when you're actually
>> looking for com.sun.jndi.ldap.LdapCtxFactory has no side effect
>> - which fortunately seems to be the case).
>
> Well, no one can guarantee us this. Even a constructor could do all the things you've mentioned :) It's just the nature of a factory. It should better be stateless and without any side effects.

So a broken InitialContextFactory for technology XXX can
prevent getting the InitialContext for technology YYY even if both
have nothing in common, and even if XXX is never actually
used in the application.
On the other hand I don't see that you have any other choice
but propagate the exception if one is emitted - as you can't know
whether it has been emitted by the class you're trying to load :-(

-- daniel

>
> -Pavel
>



From amy.lu at oracle.com  Tue Sep 16 15:49:27 2014
From: amy.lu at oracle.com (Amy Lu)
Date: Tue, 16 Sep 2014 23:49:27 +0800
Subject: RFR 8058569: Update java/lang/invoke/lambda tests to eliminate
	dependency on sun.tools.jar.Main
Message-ID: <54185C07.2040605@oracle.com>

Some java/lang/invoke/lambda tests have dependency on sun.tools.jar.Main
This fix is to remove above internal JDK API dependency from the tests.

bug: https://bugs.openjdk.java.net/browse/JDK-8058569
webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.01/

Thanks,
Amy



From xueming.shen at oracle.com  Tue Sep 16 16:03:48 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 16 Sep 2014 09:03:48 -0700
Subject: RFR: 8058520: jar xf does not work on zip files with leading
	garbage.
In-Reply-To: <CA+kOe0_2_Tpcs7z9NoTVa13HCzP76T0Q_Qkz9hysdbXxzNPYiw@mail.gmail.com>
References: <CA+kOe0_2_Tpcs7z9NoTVa13HCzP76T0Q_Qkz9hysdbXxzNPYiw@mail.gmail.com>
Message-ID: <54185F64.8030105@oracle.com>

On 9/15/14 6:40 PM, Martin Buchholz wrote:
> Hi Alan, Xueming,
>
> I'd like you to do a code review.
>
> https://bugs.openjdk.java.net/browse/JDK-8058520
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jar-leadingGarbage/ <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/jar-leadingGarbage/>


It was the performance concern back then that led us to keep using the 
input stream
for extracting, if it's to extract the whole zip/jar.

There is also some "regressions" reported later with the ZipFile path 
when dealing with
some "wrong"/non-ZIP64-spec-compliant huge zip file, in which it's fine 
to access those
entries from the beginning of the stream, but can't jump back to the 
individual entries
from the cen table.

It appears you will have to flip a coin to see which case is more 
"important"?

-Sherman


From vladimir.x.ivanov at oracle.com  Tue Sep 16 16:34:05 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 16 Sep 2014 20:34:05 +0400
Subject: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a
	base LF
In-Reply-To: <54106E7D.30201@gmail.com>
References: <5405CCDB.6040706@oracle.com> <5405CD4E.4070409@oracle.com>
	<5406FEE9.6030000@gmail.com> <540717B4.5010705@oracle.com>
	<54106E7D.30201@gmail.com>
Message-ID: <5418667D.8030902@oracle.com>

Peter, thank you very much for experimenting with that!

It looks really promising. I do believe we need to purge LambdaForm 
cache, until there's no upper limit on a possible number of LambdaForm 
instance.

I'll gather some data how efficient a cache with weak keys is and get 
back to you.

Best regards,
Vladimir Ivanov

On 9/10/14, 7:30 PM, Peter Levart wrote:
> On 09/03/2014 03:29 PM, Vladimir Ivanov wrote:
>> Peter,
>>
>> Yes, it's a known problem [1].
>> There are other caches (in MethodTypeForm, for example), which
>> shouldn't retain their elements.
>
> Hi Vladimir,
>
> I was tempted to see what it would take to use weakly referenced
> LambdaForms from cache entries (LambdaFormEditor.Transform objects).
>
> This is what I came up with:
>
> http://cr.openjdk.java.net/~plevart/misc/LambdaFormEditor.WeakCache/webrev.01/
>
>
> In this modification on top of your patch, a reference to LambdaForm
> from Transform is not a final field any more (WeakReference has a normal
> field), so I had to change LambdaForm.transformCacheto be volatile field
> to enable safe publication of Transform objects and transiently
> LambdaForm objects. I also used ordered writes with volatile reads for
> Transform[] array elements where necessary. CHM already does what's
> necessary. If LambdaForm objects are unsafe-publication-tolerable, this
> can be simplified.
>
> I have made a little effort to re-use slots occupied by cleared
> Transform objects, but nothing fancy like using ReferenceQueue(s) or
> such, since there would have to be a queue per LambdaForm and this would
> bring some overhead with it. Transform objects are very compact (even
> when they extend a WeakReference) and majority of heap is released by
> free-ing weakly reachable LambdaForm objects which can be quite big and
> deep sometimes.
>
> A cache forms a tree of LambdaForm objects. Child LFs are derived from
> base (parent) LFs. parent -> child references are weak, but I added
> child -> parent references which are strong. If there is a strong
> reference to some cached LF from the application, the whole path leading
> from the root LF to the cached LF is kept alive this way, so that any
> code that wishes to follow that path can get to the cached LF.
>
> So do you think that cached LambdaForm(s) are so general that they are
> better cached for the life of JVM even in long-running application
> servers that re-deploy apps on the fly and using WeakReference(s) is not
> necessary?
>
> Regards, Peter
>
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8057020
>>
>> On 9/3/14, 3:43 PM, Peter Levart wrote:
>>> Hi Vladimir,
>>>
>>> I'm sure you and John have thought about it through, but I'll ask
>>> anyway. Are cached LambdaForms going to stay around forever? What about
>>> using a WeakReference<LambdaForm> (LambdaFormEditor.Transform could
>>> extend WeakReference). This way unused LambdaForms would get GCed.
>>>
>>> Regards, Peter
>>>
>>> On 09/02/2014 03:59 PM, Vladimir Ivanov wrote:
>>>> Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> On 9/2/14, 5:57 PM, Vladimir Ivanov wrote:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8057042
>>>>>
>>>>> LambdaFormEditor provides an API to transform LambdaForms. Deriving
>>>>> new
>>>>> LambdaForms from a base one allows to cache and reuse results of
>>>>> repeated transformations.
>>>>>
>>>>> BMH binding is rewritten to use LambdaFormEditor.
>>>>>
>>>>> Testing: jdk/java/lang/invoke, jdk/java/util/streams, nashorn,
>>>>> octane w/
>>>>> "-ea -esa" and COMPILE_THRESHOLD={0,30}.
>>>>>
>>>>> Reviewed-by: vlivanov, ?
>>>>> Contributed-by: john.r.rose at oracle.com
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>> _______________________________________________
>>>>> mlvm-dev mailing list
>>>>> mlvm-dev at openjdk.java.net
>>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>


From pavel.rappo at oracle.com  Tue Sep 16 17:07:50 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 16 Sep 2014 18:07:50 +0100
Subject: RFR JDK-8044627: Update JNDI to work with modules
In-Reply-To: <54185948.2000400@oracle.com>
References: <FA8A05BE-42D8-4F46-BD4B-270CDCEA7BE2@oracle.com>
	<541836F6.6090504@oracle.com>
	<A061F1F8-6954-40E1-A622-00DBC7168C0A@oracle.com>
	<54185948.2000400@oracle.com>
Message-ID: <DD57AD46-42F4-43F2-87B5-051D4C91D2B0@oracle.com>

Daniel,

> So is it expected that modules (e.g. java.corba) will register
> their own service provider for the InitialContextFactory
> (I mean - using META-INF/services/)?

Alan's already answered this point. TCCL is the way to go. You are right.

> The difference however is that in  this two case we're looking for
> a service implementing a specific feature, we're not looking for a
> service whose concrete class matches a specific class name.

Agreed.

> In the case of InitialContextFactory - as a client of the API, I
> would be a bit surprised if - asking for a LDAP InitialContext,
> I received a CORBA exception. This would look strange to me.

Once again, agreed.

> A possibilty might be to use InitialContextFactoryBuilder as the
> service interface instead, and loop over the implementations until
> you find one that does not throw NamingException - but then it
> would be difficult to make the distinction between
> 'This builder does not support the Context.INITIAL_CONTEXT_FACTORY
> that you ask for' and 'The InitialContextFactory could not be
> instantiated for various reasons'...

The closest thing to what you described here would be java.sql.DriverManager:664, I think. I don't think this is an acceptable for JNDI though. This would require to modify all the providers out there to provide a new entry point -- their own implementation of InitialContextFactoryBuilder.

> Maybe it's because I haven't used JNDI very often, but when
> I read the spec I didn't realize that the value of Context.INITIAL_CONTEXT_FACTORY would have any effect if
> ServiceLoader was used - because it's not usual to use
> ServiceLoader in this way (even though the usage of
> ServiceLoader is nested below 'the class specified in
> the Context.INITIAL_CONTEXT_FACTORY</tt> environment property
> is used').
> I'm not sure it would be overspecifying to say that the ServiceLoader
> is used to locate and load an implementation of the service whose
> concrete class matches the named class - since that's what it's
> doing anyway - but I understand your concern.

It's definitely worth thinking about. Thanks.

> So a broken InitialContextFactory for technology XXX can
> prevent getting the InitialContext for technology YYY even if both
> have nothing in common, and even if XXX is never actually
> used in the application.

+1 It indeed seems very strange at first sight. But I believe this thing is a subjective tradeoff between the effects caused by unexpected "CORBA exception" and the effects caused by some strange behaviour after an "unrelated" exception was silently swallowed by the runtime.
It's more like a fail-fast behaviour, when even "unrelated" things are reported about:

	I dropped by your house to deliver the letter. Btw, it seems you've left you kettle on...

Some time ago I asked myself the same question. And looked through the codebase to see how the ServiceLoader is used. I found some "fault-tolerant" implementations:

	com.sun.media.sound.JSSecurityManager:189
	java.sql.DriverManager:605
	sun.tools.jconsole.JConsole:1004
	com.sun.tools.attach.spi.AttachProvider:261
	com.sun.tools.jdi.VirtualMachineManagerImpl:95
	com.sun.tools.jdi.VirtualMachineManagerImpl:124
	javax.script.ScriptEngineManager:124

As you can see there's no right answer here. It certainly depends on the behaviour you want to achieve. Suppose your service provider are plugins (as it is the case for JConsole example above) then it doesn't make any sense to shutdown if any single plugin failed. Leave this decision to a client. Report the warning. On the language level there's no such thing is warning. Only exceptions and return values. We could emulate warning with logging but... I'm sure there are many reasons why that might not fly.
 
-Pavel



From vladimir.x.ivanov at oracle.com  Tue Sep 16 18:43:18 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 16 Sep 2014 22:43:18 +0400
Subject: [9] RFR (XS): 8058584: Ignore
	java/lang/invoke/LFCaching/LFGarbageCollectedTest
	until 8057020 is fixed
Message-ID: <541884C6.9010109@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8058584/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8058584

Exclude java/lang/invoke/LFCaching/LFGarbageCollectedTest from test runs 
until 8057020 is fixed.

Thanks!

Best regards,
Vladimir Ivanov


From joe.darcy at oracle.com  Tue Sep 16 18:49:21 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 16 Sep 2014 11:49:21 -0700
Subject: [9] RFR (XS): 8058584: Ignore
	java/lang/invoke/LFCaching/LFGarbageCollectedTest
	until 8057020 is fixed
In-Reply-To: <541884C6.9010109@oracle.com>
References: <541884C6.9010109@oracle.com>
Message-ID: <54188631.8070505@oracle.com>

Looks good; approved to go back,

Thanks Vladimir,

-Joe

On 9/16/2014 11:43 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8058584/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8058584
>
> Exclude java/lang/invoke/LFCaching/LFGarbageCollectedTest from test 
> runs until 8057020 is fixed.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov



From Alan.Bateman at oracle.com  Tue Sep 16 18:55:16 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Sep 2014 19:55:16 +0100
Subject: [9] RFR (XS): 8058584: Ignore
	java/lang/invoke/LFCaching/LFGarbageCollectedTest
	until 8057020 is fixed
In-Reply-To: <541884C6.9010109@oracle.com>
References: <541884C6.9010109@oracle.com>
Message-ID: <54188794.3040907@oracle.com>

On 16/09/2014 19:43, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8058584/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8058584
>
> Exclude java/lang/invoke/LFCaching/LFGarbageCollectedTest from test 
> runs until 8057020 is fixed.
>
We usually use jdk/test/ProblemList.txt to exclude tests these days, 
mostly because it allows us to exclude tests on a per platform basis (so 
more flexible than @ignore). Using @ignore is okay too, just not used as 
much now.

-Alan.


From vladimir.x.ivanov at oracle.com  Tue Sep 16 19:09:43 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 16 Sep 2014 23:09:43 +0400
Subject: [9] RFR (XS): 8058584: Ignore
	java/lang/invoke/LFCaching/LFGarbageCollectedTest
	until 8057020 is fixed
In-Reply-To: <54188794.3040907@oracle.com>
References: <541884C6.9010109@oracle.com> <54188794.3040907@oracle.com>
Message-ID: <54188AF7.5070305@oracle.com>

Joe, Alan, thanks for review.

Best regards,
Vladimir Ivanov

On 9/16/14, 10:55 PM, Alan Bateman wrote:
> On 16/09/2014 19:43, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8058584/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8058584
>>
>> Exclude java/lang/invoke/LFCaching/LFGarbageCollectedTest from test
>> runs until 8057020 is fixed.
>>
> We usually use jdk/test/ProblemList.txt to exclude tests these days,
> mostly because it allows us to exclude tests on a per platform basis (so
> more flexible than @ignore). Using @ignore is okay too, just not used as
> much now.
>
> -Alan.


From mandy.chung at oracle.com  Tue Sep 16 21:26:10 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 16 Sep 2014 14:26:10 -0700
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <541857EA.3070300@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>,
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>,
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>,
	<5412F768.7050904@oracle.com> <5412FB09.6060804@oracle.com>,
	<54130047.1030805@oracle.com> <54130662.9000803@oracle.com>,
	<54130A37.8070503@oracle.com>	<BLU175-W12259009585054C5ACE4E083CD0@phx.gbl>,
	<54132534.407@oracle.com>
	<BLU175-W471CC4F5FA1389062DC2DC83CD0@phx.gbl>	<54170DC7.7090603@oracle.com>
	<54184176.701@oracle.com> <541857EA.3070300@oracle.com>
Message-ID: <5418AAF2.5000702@oracle.com>

On 9/16/14 8:31 AM, Daniel Fuchs wrote:
> Done.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.06
>

Looks good.

Mandy

> On 9/16/14 3:56 PM, Alan Bateman wrote:
>> On 15/09/2014 17:03, Daniel Fuchs wrote:
>>> :
>>>
>>>
>>> Here is a new webrev - with updated test case:
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.05/
>>>
>> I think this quite good now.
>>
>> Just on this wording:
>>
>> "If a listener terminates with an uncaught error or exception thenthe
>> first exception that was raised will be propagated to the caller of
>> readConfiguration after all listeners have been invoked."
>>
>> I think you can shorten this a bit by dropping "that was raised" from
>> the sentence.
>>
>> Future maintainers might wonder why invokeConfigurationListeners takes a
>> snapshot of the listeners so I think that deserves a comment in the 
>> code.
>>
>> -Alan
>



From paul.sandoz at oracle.com  Tue Sep 16 21:45:53 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 16 Sep 2014 23:45:53 +0200
Subject: RFR JDK-8058204 stream tests timeout,
	intermittently but more likely to happen after JDK-8056248
Message-ID: <8F989FE2-E8A9-49A5-B038-18B47E4981B5@oracle.com>

Hi,

Please see below for a patch to disable concurrent execution of the stream tests by jtreg.

Due to recent f/j changes some stream tests are now timing out. This is because the tests are running concurrently and parallel stream execution in one process is competing for resources with parallel stream execution in another process. This was actually always the case, but the recent f/j changes appear to be more sensitive to OS scheduling effects on some platforms and there is not much we can do about that at the moment.

This is unlikely to increase the overall execution time of the JDK tests by much.

Paul. 

diff -r aabb503ab6de test/TEST.ROOT
--- a/test/TEST.ROOT	Tue Sep 16 23:16:01 2014 +0200
+++ b/test/TEST.ROOT	Tue Sep 16 23:26:11 2014 +0200
@@ -8,7 +8,7 @@
 othervm.dirs=java/awt java/beans javax/accessibility javax/imageio javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d sun/pisces
 
 # Tests that cannot run concurrently
-exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi
+exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream
 
 # Group definitions
 groups=TEST.groups [closed/TEST.groups]



From david.holmes at oracle.com  Wed Sep 17 00:31:51 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Sep 2014 10:31:51 +1000
Subject: RFR 8058569: Update java/lang/invoke/lambda tests to eliminate
	dependency on sun.tools.jar.Main
In-Reply-To: <54185C07.2040605@oracle.com>
References: <54185C07.2040605@oracle.com>
Message-ID: <5418D677.6000808@oracle.com>

Hi Amy,

On 17/09/2014 1:49 AM, Amy Lu wrote:
> Some java/lang/invoke/lambda tests have dependency on sun.tools.jar.Main
> This fix is to remove above internal JDK API dependency from the tests.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8058569
> webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.01/

I'm a little confused as to the issue here. Running the jar tool 
programmatically as a Java program doesn't seem like a big deal, but if 
it is then just run the the jar tool directly (this test is a JDK-only 
test either way); or remove the static dependency with reflection based 
code. Plus the same code still has this dependency:

      static final com.sun.tools.javac.Main javac =
               new com.sun.tools.javac.Main();

so I don't see that anything is being gained at the moment.

Is there a bigger picture that this is part of?

Thanks,
David

> Thanks,
> Amy
>


From david.holmes at oracle.com  Wed Sep 17 00:35:52 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Sep 2014 10:35:52 +1000
Subject: RFR JDK-8058204 stream tests timeout, intermittently but more
	likely to happen after JDK-8056248
In-Reply-To: <8F989FE2-E8A9-49A5-B038-18B47E4981B5@oracle.com>
References: <8F989FE2-E8A9-49A5-B038-18B47E4981B5@oracle.com>
Message-ID: <5418D768.6000808@oracle.com>

On 17/09/2014 7:45 AM, Paul Sandoz wrote:
> Hi,
>
> Please see below for a patch to disable concurrent execution of the stream tests by jtreg.

A number of our smaller systems may not be able to handle running these 
tests concurrently regardless, so I think removing the concurrency is a 
good thing regardless of F/J changes.

So looks good to me.

Thanks,
David

> Due to recent f/j changes some stream tests are now timing out. This is because the tests are running concurrently and parallel stream execution in one process is competing for resources with parallel stream execution in another process. This was actually always the case, but the recent f/j changes appear to be more sensitive to OS scheduling effects on some platforms and there is not much we can do about that at the moment.
>
> This is unlikely to increase the overall execution time of the JDK tests by much.
>
> Paul.
>
> diff -r aabb503ab6de test/TEST.ROOT
> --- a/test/TEST.ROOT	Tue Sep 16 23:16:01 2014 +0200
> +++ b/test/TEST.ROOT	Tue Sep 16 23:26:11 2014 +0200
> @@ -8,7 +8,7 @@
>   othervm.dirs=java/awt java/beans javax/accessibility javax/imageio javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d sun/pisces
>
>   # Tests that cannot run concurrently
> -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi
> +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi java/util/stream
>
>   # Group definitions
>   groups=TEST.groups [closed/TEST.groups]
>


From Alan.Bateman at oracle.com  Wed Sep 17 06:22:21 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Sep 2014 07:22:21 +0100
Subject: RFR JDK-8058204 stream tests timeout, intermittently but more
	likely to happen after JDK-8056248
In-Reply-To: <8F989FE2-E8A9-49A5-B038-18B47E4981B5@oracle.com>
References: <8F989FE2-E8A9-49A5-B038-18B47E4981B5@oracle.com>
Message-ID: <5419289D.4000104@oracle.com>

On 16/09/2014 22:45, Paul Sandoz wrote:
> Hi,
>
> Please see below for a patch to disable concurrent execution of the stream tests by jtreg.
>
>
Looks good to me too, we should know soon enough if it helps with the 
timeout issues (just in case there is something else going on).

-Alan


From ivan.gerasimov at oracle.com  Wed Sep 17 08:08:37 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 17 Sep 2014 12:08:37 +0400
Subject: RFR [8058099] (ch) Cleanup in FileChannel/FileDispatcher native
	implementation [win]
In-Reply-To: <541029BA.5030103@oracle.com>
References: <541029BA.5030103@oracle.com>
Message-ID: <54194185.5000107@oracle.com>

Hello!

Is there any interest in this change?
It's mostly cleanup, so it is of low priority, but it would be good, if 
someone could review this.

Besides increased readability, this fix makes the code 24 lines shorter 
and eliminates a compiler warning! :-)

Sincerely yours,
Ivan

On 10.09.2014 14:36, Ivan Gerasimov wrote:
> Hello!
>
> This is a proposal to slightly rework FileChannel/FileDispatcher 
> native implementation on Windows.
> If the newer API is used (which is already available on XP and 2003), 
> this will make code a bit clear and let us save a few redundant calls.
>
> Would you please help review the change?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058099
> WEBREV: http://cr.openjdk.java.net/~igerasim/8058099/0/webrev/
>
> Sincerely yours,
> Ivan
>
>



From robbiexgibson at yahoo.com  Wed Sep 17 09:35:38 2014
From: robbiexgibson at yahoo.com (Robbie Gibson)
Date: Wed, 17 Sep 2014 11:35:38 +0200
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <46261010-BD40-4102-8F23-4D5F9B703C1D@oracle.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
	<54124DFE.7000706@oracle.com>
	<81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>
	<D65197CD-A641-4666-B01A-B90B81D010BE@oracle.com>
	<54147A70.30008@oracle.com>
	<46261010-BD40-4102-8F23-4D5F9B703C1D@oracle.com>
Message-ID: <FDAE3267-75B3-4F63-BD1A-02E59894799C@yahoo.com>

Hi Brian,
I hope there will be a backport to JDK8?
Regards,
Robert

> On 15 Sep 2014, at 22:14, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Hi Joe,
> 
> This has been pushed http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b20d87c5905 with the indicated comment excised.
> 
> Thanks,
> 
> Brian
> 
>> On Sep 13, 2014, at 10:10 AM, Joe Darcy <joe.darcy at oracle.com> wrote:
>> 
>> Other than removing the
>> 
>>    // bug 8057793
>> 
>> comment on the new test method, this looks good to be pushed.
> 


From Alan.Bateman at oracle.com  Wed Sep 17 09:41:18 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Sep 2014 10:41:18 +0100
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <541857EA.3070300@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>,
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>,
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>,
	<5412F768.7050904@oracle.com> <5412FB09.6060804@oracle.com>,
	<54130047.1030805@oracle.com> <54130662.9000803@oracle.com>,
	<54130A37.8070503@oracle.com>	<BLU175-W12259009585054C5ACE4E083CD0@phx.gbl>,
	<54132534.407@oracle.com> <BLU175-W471CC4F5FA1389062DC2DC83CD0@phx.gbl>
	<54170DC7.7090603@oracle.com> <54184176.701@oracle.com>
	<541857EA.3070300@oracle.com>
Message-ID: <5419573E.2030402@oracle.com>

On 16/09/2014 16:31, Daniel Fuchs wrote:
> Done.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.06
>
Thanks for the updates, I think this looks good now.

-Alan


From vladimir.x.ivanov at oracle.com  Wed Sep 17 11:09:01 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 17 Sep 2014 15:09:01 +0400
Subject: [8u40] RFR (S): Missing part of 8057656 in 8u40 compared to 9
Message-ID: <54196BCD.7020609@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8058626/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8058626

I've noticed a difference between 8057656 fixes in 8u-dev [1] and 9 [2].
It seems I integrated [3] into 8u and [4] into 9.
This change syncs 8u to 9.

Thanks!

Best regards,
Vladimir Ivanov

[1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/4b2bc06d521c
[2] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5ae5da7305a8
[3] http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/
[4] http://cr.openjdk.java.net/~vlivanov/8057656/webrev.01/


From miroslav.kos at oracle.com  Wed Sep 17 13:00:36 2014
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Wed, 17 Sep 2014 15:00:36 +0200
Subject: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for Web
	services
Message-ID: <541985F4.6010202@oracle.com>

Hi everybody,

please review patch fixing following issue:

JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
webrev:
http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
http://cr.openjdk.java.net/~mkos/8038966/jdk.01/

It is second part of fix ensuring that content of type 
xsd:any/content=mixed stays unchanged when processed with JAX-B RI. 
Regression test within webrev.

Sean, could you sponsor it for me?

Thanks
Miran





From paul.sandoz at oracle.com  Wed Sep 17 13:38:59 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 17 Sep 2014 15:38:59 +0200
Subject: [8u40] RFR (S): Missing part of 8057656 in 8u40 compared to 9
In-Reply-To: <54196BCD.7020609@oracle.com>
References: <54196BCD.7020609@oracle.com>
Message-ID: <16C6EF46-A11B-490F-A4F4-0E1B64430ED2@oracle.com>


On Sep 17, 2014, at 1:09 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8058626/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8058626
> 
> I've noticed a difference between 8057656 fixes in 8u-dev [1] and 9 [2].
> It seems I integrated [3] into 8u and [4] into 9.
> This change syncs 8u to 9.
> 

+1

Paul.


From vladimir.x.ivanov at oracle.com  Wed Sep 17 14:02:16 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 17 Sep 2014 18:02:16 +0400
Subject: [8u40] RFR (S): Missing part of 8057656 in 8u40 compared to 9
In-Reply-To: <16C6EF46-A11B-490F-A4F4-0E1B64430ED2@oracle.com>
References: <54196BCD.7020609@oracle.com>
	<16C6EF46-A11B-490F-A4F4-0E1B64430ED2@oracle.com>
Message-ID: <54199468.3060202@oracle.com>

Thanks, Paul!

Best regards,
Vladimir Ivanov

On 9/17/14, 5:38 PM, Paul Sandoz wrote:
>
> On Sep 17, 2014, at 1:09 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> http://cr.openjdk.java.net/~vlivanov/8058626/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8058626
>>
>> I've noticed a difference between 8057656 fixes in 8u-dev [1] and 9 [2].
>> It seems I integrated [3] into 8u and [4] into 9.
>> This change syncs 8u to 9.
>>
>
> +1
>
> Paul.
>


From sean.coffey at oracle.com  Wed Sep 17 14:16:49 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Wed, 17 Sep 2014 15:16:49 +0100
Subject: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for
	Web services
In-Reply-To: <541985F4.6010202@oracle.com>
References: <541985F4.6010202@oracle.com>
Message-ID: <541997D1.8040602@oracle.com>

Miran,

the src change looks ok but I think there's a problem with the testcase.

You've defined generated classes for wsimport to be output to the TESTSRC
directory. This is often read only and won't work.

TESTCLASSES is the variable you're probably looking for. In any case, I 
think
it's possible for you to avoid use of scripting. Can you invoke wsimport via
the ProcessBuilder API like that done for other wsimport tests ?

regards,
Sean.

On 17/09/14 14:00, Miroslav Kos wrote:
> Hi everybody,
>
> please review patch fixing following issue:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
> webrev:
> http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
> http://cr.openjdk.java.net/~mkos/8038966/jdk.01/
>
> It is second part of fix ensuring that content of type 
> xsd:any/content=mixed stays unchanged when processed with JAX-B RI. 
> Regression test within webrev.
>
> Sean, could you sponsor it for me?
>
> Thanks
> Miran
>
>
>



From aleksey.shipilev at oracle.com  Wed Sep 17 14:28:57 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 17 Sep 2014 18:28:57 +0400
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
Message-ID: <54199AA9.2090804@oracle.com>

Hi,

Can I have a review and a sponsorship for this tiny readability cleanup
in String.hashCode()?
 http://cr.openjdk.java.net/~shade/8058643/webrev.01/
 https://bugs.openjdk.java.net/browse/JDK-8058643

Thanks,
-Aleksey.



From vladimir.x.ivanov at oracle.com  Wed Sep 17 15:02:40 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 17 Sep 2014 19:02:40 +0400
Subject: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization
	checks scale devastatingly poorly
Message-ID: <5419A290.30409@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8058309/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8058309

j.l.i.LambdaForm class has ~50-100 dependent nmethods on average. For 
every compiled LF, Unsafe.defineAnonymousClass() should validate all 
dependencies on parent class. Since thousands of LFs are compiled, VM 
wastes considerable amount of time re-validating dependencies. Most of 
the dependencies on j.l.i.LambdaForm are of type unique_concrete_method 
and can't be invalidated with the code generated for LFs.

The fix is to decouple compiled LambdaForms and j.l.i.LambdaForm class 
and use j.l.Object as a parent class instead. Since LambdaForm is 
already used as a host class, all access checks pass.

Reviewed-by: vlivanov, jrose, ?
Contributed-by: aleksey.shipilev at oracle.com

Testing: jck (api/java_lang/invoke), jdk/java/lang/invoke, 
jdk/java/util/streams w/ "-ea -esa" and COMPILE_THRESHOLD={0,30},

Aleksey refers to performance analysis in the bug [1].

Thanks!

Best regards,
Vladimir Ivanov

[1] http://cr.openjdk.java.net/~shade/8058309/usdacdependency.txt


From aleksey.shipilev at oracle.com  Wed Sep 17 15:14:39 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 17 Sep 2014 19:14:39 +0400
Subject: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization
	checks scale devastatingly poorly
In-Reply-To: <5419A290.30409@oracle.com>
References: <5419A290.30409@oracle.com>
Message-ID: <5419A55F.3070806@oracle.com>

On 09/17/2014 07:02 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8058309/webrev.00/

Looks good, thanks!

Sorry for not being clear earlier, but I am a bit concerned with the bug
synopsis: we have sure worked around the issue with LambdaForms, but are
we sure this fixed the general problem? John asked me to follow up on
that with more concrete benchmark, and I will do that later. In other
words, I would like to see the separate issue submitted for this
workaround, and record the fix under that issue.

Thanks,
-Aleksey.


From martinrb at google.com  Wed Sep 17 15:19:49 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 17 Sep 2014 08:19:49 -0700
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <54199AA9.2090804@oracle.com>
References: <54199AA9.2090804@oracle.com>
Message-ID: <CA+kOe0_+5R4uqfsJPkm0irX00NUgtbABZkHAiAqnCoXF7S-WRw@mail.gmail.com>

Looks good, but I would use this title:

(str) Improve String.hashCode implementation

On Wed, Sep 17, 2014 at 7:28 AM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> Hi,
>
> Can I have a review and a sponsorship for this tiny readability cleanup
> in String.hashCode()?
>  http://cr.openjdk.java.net/~shade/8058643/webrev.01/
>  https://bugs.openjdk.java.net/browse/JDK-8058643
>
> Thanks,
> -Aleksey.
>
>


From aleksey.shipilev at oracle.com  Wed Sep 17 15:25:04 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 17 Sep 2014 19:25:04 +0400
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <CA+kOe0_+5R4uqfsJPkm0irX00NUgtbABZkHAiAqnCoXF7S-WRw@mail.gmail.com>
References: <54199AA9.2090804@oracle.com>
	<CA+kOe0_+5R4uqfsJPkm0irX00NUgtbABZkHAiAqnCoXF7S-WRw@mail.gmail.com>
Message-ID: <5419A7D0.3010207@oracle.com>

Thanks Martin!

It used to be "Clean-up String.hashCode()", and Alan had improved it
since then. :) To Alan's defense, the bug report was shallow at that
point to understand what is being proposed. I changed the title to
"Improve...".

Cheers,
-Aleksey.

On 09/17/2014 07:19 PM, Martin Buchholz wrote:
> Looks good, but I would use this title:
> 
> (str) Improve String.hashCode implementation
> 
> On Wed, Sep 17, 2014 at 7:28 AM, Aleksey Shipilev
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
> 
>     Hi,
> 
>     Can I have a review and a sponsorship for this tiny readability cleanup
>     in String.hashCode()?
>      http://cr.openjdk.java.net/~shade/8058643/webrev.01/
>     <http://cr.openjdk.java.net/%7Eshade/8058643/webrev.01/>
>      https://bugs.openjdk.java.net/browse/JDK-8058643
> 
>     Thanks,
>     -Aleksey.
> 
> 




From brian.burkhalter at oracle.com  Wed Sep 17 15:25:34 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 17 Sep 2014 08:25:34 -0700
Subject: RFR 8057793 BigDecimal is no longer effectively immutable
In-Reply-To: <FDAE3267-75B3-4F63-BD1A-02E59894799C@yahoo.com>
References: <1409817421.41637.YahooMailNeo@web121304.mail.ne1.yahoo.com>
	<1410251456.11151.YahooMailNeo@web121306.mail.ne1.yahoo.com>
	<54124DFE.7000706@oracle.com>
	<81A51744-D158-4BE2-A13F-07C6DB1317A4@oracle.com>
	<D65197CD-A641-4666-B01A-B90B81D010BE@oracle.com>
	<54147A70.30008@oracle.com>
	<46261010-BD40-4102-8F23-4D5F9B703C1D@oracle.com>
	<FDAE3267-75B3-4F63-BD1A-02E59894799C@yahoo.com>
Message-ID: <5D75A8E9-1E13-4893-91FA-DABAC6199B1B@oracle.com>

Hi Robert,

That?s the plan.

Regards,

Brian

On Sep 17, 2014, at 2:35 AM, Robbie Gibson <robbiexgibson at yahoo.com> wrote:

> I hope there will be a backport to JDK8?



From Alan.Bateman at oracle.com  Wed Sep 17 15:27:07 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Sep 2014 16:27:07 +0100
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <54199AA9.2090804@oracle.com>
References: <54199AA9.2090804@oracle.com>
Message-ID: <5419A84B.7040103@oracle.com>

On 17/09/2014 15:28, Aleksey Shipilev wrote:
> Hi,
>
> Can I have a review and a sponsorship for this tiny readability cleanup
> in String.hashCode()?
>   http://cr.openjdk.java.net/~shade/8058643/webrev.01/
>   https://bugs.openjdk.java.net/browse/JDK-8058643
>
Looks good to me.

-Alan


From amy.lu at oracle.com  Wed Sep 17 15:29:41 2014
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 17 Sep 2014 23:29:41 +0800
Subject: RFR 8058569: Update java/lang/invoke/lambda tests to eliminate
	dependency on sun.tools.jar.Main
In-Reply-To: <5418D677.6000808@oracle.com>
References: <54185C07.2040605@oracle.com> <5418D677.6000808@oracle.com>
Message-ID: <5419A8E5.3000102@oracle.com>

Hi, David

Thank you for your review!

Here's the updated version, run jar tool directly:
webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.02/

com.sun.tools.javac.Main is not reported as internal API so far (see 
below jdeps result before the fix), if this changed in the future, it 
will be fixed in a separate bug.

Before the fix:
$ $TEST_JAVA/bin/jdeps -jdkinternals $CLASSES_DIR
lambda -> jdk.dev
    LUtils (lambda)
       -> sun.tools.jar.Main JDK internal API (jdk.dev)
    LambdaAccessControlDoPrivilegedTest (lambda)
       -> sun.tools.jar.Main JDK internal API (jdk.dev)

Warning: JDK internal APIs are unsupported and private to JDK 
implementation that are
subject to be removed or changed incompatibly and could break your 
application.
Please modify your code to eliminate dependency on any JDK internal APIs.
For the most recent update on JDK internal API replacements, please check:
https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool

JDK Internal API                         Suggested Replacement
----------------                         ---------------------
sun.tools.jar.Main                       Use java.util.jar or jar tool 
@since 1.2


Thanks,
Amy

On 9/17/14, 8:31 AM, David Holmes wrote:
> Hi Amy,
>
> On 17/09/2014 1:49 AM, Amy Lu wrote:
>> Some java/lang/invoke/lambda tests have dependency on sun.tools.jar.Main
>> This fix is to remove above internal JDK API dependency from the tests.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8058569
>> webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.01/
>
> I'm a little confused as to the issue here. Running the jar tool 
> programmatically as a Java program doesn't seem like a big deal, but 
> if it is then just run the the jar tool directly (this test is a 
> JDK-only test either way); or remove the static dependency with 
> reflection based code. Plus the same code still has this dependency:
>
>      static final com.sun.tools.javac.Main javac =
>               new com.sun.tools.javac.Main();
>
> so I don't see that anything is being gained at the moment.
>
> Is there a bigger picture that this is part of?
>
> Thanks,
> David
>
>> Thanks,
>> Amy
>>



From Alan.Bateman at oracle.com  Wed Sep 17 15:37:42 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Sep 2014 16:37:42 +0100
Subject: RFR 8058569: Update java/lang/invoke/lambda tests to eliminate
	dependency on sun.tools.jar.Main
In-Reply-To: <5419A8E5.3000102@oracle.com>
References: <54185C07.2040605@oracle.com> <5418D677.6000808@oracle.com>
	<5419A8E5.3000102@oracle.com>
Message-ID: <5419AAC6.3000503@oracle.com>

On 17/09/2014 16:29, Amy Lu wrote:
> Hi, David
>
> Thank you for your review!
>
> Here's the updated version, run jar tool directly:
> webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.02/
>
> com.sun.tools.javac.Main is not reported as internal API so far (see 
> below jdeps result before the fix), if this changed in the future, it 
> will be fixed in a separate bug.
>
com.sun.tools.javac.Main is a supported API so it will need to be 
exported when we move to module. The standard API is of course 
javax.tools but I don't think there is a need to change these tests to 
use that.

The jar tool never had a supported API so if tests don't strictly need 
to use sun.tools.jar directly then it would be good to eliminate that 
dependency.

-Alan.



From xueming.shen at oracle.com  Wed Sep 17 16:13:28 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 17 Sep 2014 09:13:28 -0700
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <5419A7D0.3010207@oracle.com>
References: <54199AA9.2090804@oracle.com>	<CA+kOe0_+5R4uqfsJPkm0irX00NUgtbABZkHAiAqnCoXF7S-WRw@mail.gmail.com>
	<5419A7D0.3010207@oracle.com>
Message-ID: <5419B328.4040007@oracle.com>


It definitely helps the "readability". String.hashCode() has intrinsics, 
so I don't think
we are seeing the real performance "difference" of the implementations. 
My guess
is the original one probably is faster.

On 9/17/14 8:25 AM, Aleksey Shipilev wrote:
> Thanks Martin!
>
> It used to be "Clean-up String.hashCode()", and Alan had improved it
> since then. :) To Alan's defense, the bug report was shallow at that
> point to understand what is being proposed. I changed the title to
> "Improve...".
>
> Cheers,
> -Aleksey.
>
> On 09/17/2014 07:19 PM, Martin Buchholz wrote:
>> Looks good, but I would use this title:
>>
>> (str) Improve String.hashCode implementation
>>
>> On Wed, Sep 17, 2014 at 7:28 AM, Aleksey Shipilev
>> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
>>
>>      Hi,
>>
>>      Can I have a review and a sponsorship for this tiny readability cleanup
>>      in String.hashCode()?
>>       http://cr.openjdk.java.net/~shade/8058643/webrev.01/
>>      <http://cr.openjdk.java.net/%7Eshade/8058643/webrev.01/>
>>       https://bugs.openjdk.java.net/browse/JDK-8058643
>>
>>      Thanks,
>>      -Aleksey.
>>
>>
>



From vitalyd at gmail.com  Wed Sep 17 16:20:46 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 17 Sep 2014 12:20:46 -0400
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <5419B328.4040007@oracle.com>
References: <54199AA9.2090804@oracle.com>
	<CA+kOe0_+5R4uqfsJPkm0irX00NUgtbABZkHAiAqnCoXF7S-WRw@mail.gmail.com>
	<5419A7D0.3010207@oracle.com> <5419B328.4040007@oracle.com>
Message-ID: <CAHjP37Hm2S6KDC0U_zycibEmTZge+VwmZ73C=j4rVE3rbZ3hjg@mail.gmail.com>

There's no such intrinsic; there's intrinsic support for calling native
object hashcode, but string isn't special cased.

Sent from my phone
On Sep 17, 2014 12:14 PM, "Xueming Shen" <xueming.shen at oracle.com> wrote:

>
> It definitely helps the "readability". String.hashCode() has intrinsics,
> so I don't think
> we are seeing the real performance "difference" of the implementations. My
> guess
> is the original one probably is faster.
>
> On 9/17/14 8:25 AM, Aleksey Shipilev wrote:
>
>> Thanks Martin!
>>
>> It used to be "Clean-up String.hashCode()", and Alan had improved it
>> since then. :) To Alan's defense, the bug report was shallow at that
>> point to understand what is being proposed. I changed the title to
>> "Improve...".
>>
>> Cheers,
>> -Aleksey.
>>
>> On 09/17/2014 07:19 PM, Martin Buchholz wrote:
>>
>>> Looks good, but I would use this title:
>>>
>>> (str) Improve String.hashCode implementation
>>>
>>> On Wed, Sep 17, 2014 at 7:28 AM, Aleksey Shipilev
>>> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>>
>>> wrote:
>>>
>>>      Hi,
>>>
>>>      Can I have a review and a sponsorship for this tiny readability
>>> cleanup
>>>      in String.hashCode()?
>>>       http://cr.openjdk.java.net/~shade/8058643/webrev.01/
>>>      <http://cr.openjdk.java.net/%7Eshade/8058643/webrev.01/>
>>>       https://bugs.openjdk.java.net/browse/JDK-8058643
>>>
>>>      Thanks,
>>>      -Aleksey.
>>>
>>>
>>>
>>
>


From xueming.shen at oracle.com  Wed Sep 17 16:36:33 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 17 Sep 2014 09:36:33 -0700
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <CAHjP37Hm2S6KDC0U_zycibEmTZge+VwmZ73C=j4rVE3rbZ3hjg@mail.gmail.com>
References: <54199AA9.2090804@oracle.com>	<CA+kOe0_+5R4uqfsJPkm0irX00NUgtbABZkHAiAqnCoXF7S-WRw@mail.gmail.com>	<5419A7D0.3010207@oracle.com>	<5419B328.4040007@oracle.com>
	<CAHjP37Hm2S6KDC0U_zycibEmTZge+VwmZ73C=j4rVE3rbZ3hjg@mail.gmail.com>
Message-ID: <5419B891.4040707@oracle.com>

You's right. The native implementation in vm is only for those 
"constants", and that's not "intrinsic".

On 9/17/14 9:20 AM, Vitaly Davidovich wrote:
>
> There's no such intrinsic; there's intrinsic support for calling 
> native object hashcode, but string isn't special cased.
>
> Sent from my phone
>
> On Sep 17, 2014 12:14 PM, "Xueming Shen" <xueming.shen at oracle.com 
> <mailto:xueming.shen at oracle.com>> wrote:
>
>
>     It definitely helps the "readability". String.hashCode() has
>     intrinsics, so I don't think
>     we are seeing the real performance "difference" of the
>     implementations. My guess
>     is the original one probably is faster.
>
>     On 9/17/14 8:25 AM, Aleksey Shipilev wrote:
>
>         Thanks Martin!
>
>         It used to be "Clean-up String.hashCode()", and Alan had
>         improved it
>         since then. :) To Alan's defense, the bug report was shallow
>         at that
>         point to understand what is being proposed. I changed the title to
>         "Improve...".
>
>         Cheers,
>         -Aleksey.
>
>         On 09/17/2014 07:19 PM, Martin Buchholz wrote:
>
>             Looks good, but I would use this title:
>
>             (str) Improve String.hashCode implementation
>
>             On Wed, Sep 17, 2014 at 7:28 AM, Aleksey Shipilev
>             <aleksey.shipilev at oracle.com
>             <mailto:aleksey.shipilev at oracle.com>
>             <mailto:aleksey.shipilev at oracle.com
>             <mailto:aleksey.shipilev at oracle.com>>> wrote:
>
>                  Hi,
>
>                  Can I have a review and a sponsorship for this tiny
>             readability cleanup
>                  in String.hashCode()?
>             http://cr.openjdk.java.net/~shade/8058643/webrev.01/
>             <http://cr.openjdk.java.net/%7Eshade/8058643/webrev.01/>
>                  <http://cr.openjdk.java.net/%7Eshade/8058643/webrev.01/>
>             https://bugs.openjdk.java.net/browse/JDK-8058643
>
>                  Thanks,
>                  -Aleksey.
>
>
>
>



From vladimir.x.ivanov at oracle.com  Wed Sep 17 16:43:24 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 17 Sep 2014 20:43:24 +0400
Subject: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization
	checks scale devastatingly poorly
In-Reply-To: <5419A55F.3070806@oracle.com>
References: <5419A290.30409@oracle.com> <5419A55F.3070806@oracle.com>
Message-ID: <5419BA2C.2060007@oracle.com>

Aleksey,

> Sorry for not being clear earlier, but I am a bit concerned with the bug
> synopsis: we have sure worked around the issue with LambdaForms, but are
> we sure this fixed the general problem? John asked me to follow up on
> that with more concrete benchmark, and I will do that later. In other
> words, I would like to see the separate issue submitted for this
> workaround, and record the fix under that issue.
It depends on what do you mean by general problem here.

I don't see anything obviously wrong either with U.dAC() or with 
dependency tracking in VM. What we stumbled upon is an inherent 
limitation of current dependency tracking implementation.

It's not specific to U.dAC(). Regular class loaders can hit similar 
problem as well.

With compiled LFs we ended up in relatively polluted context. 
Considering how many classes we spin for LFs, validating this context 
over and over again takes considerable amount of time.

The question is how common polluted contexts are and how frequently do 
we need to validate them.

We could think of improving dependency tracking in VM by increasing 
granularity and narrowing contexts, thus making polluted contexts less 
likely.

If you want to use 8058309 for dependency tracking improvments in VM, 
let me know. So far, I got an impression it is about LFs & JSR292 mostly.

Best regards,
Vladimir Ivanov


From aleksey.shipilev at oracle.com  Wed Sep 17 16:43:58 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 17 Sep 2014 20:43:58 +0400
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <5419B328.4040007@oracle.com>
References: <54199AA9.2090804@oracle.com>	<CA+kOe0_+5R4uqfsJPkm0irX00NUgtbABZkHAiAqnCoXF7S-WRw@mail.gmail.com>	<5419A7D0.3010207@oracle.com>
	<5419B328.4040007@oracle.com>
Message-ID: <5419BA4E.8070200@oracle.com>

Hi Xueming,

On 09/17/2014 08:13 PM, Xueming Shen wrote:
> String.hashCode() has intrinsics,

No, we have no intrinsics for String.hashCode. We do have a native
implementation for VM internal purposes though, but it's irrelevant here.

> so I don't think  we are seeing the real performance "difference" of
> the implementations.

No, we are seeing the difference, but it is about consistently and
slightly different code generation, see the disassemblies linked in the
bug report. Really, the performance run was to look out for regressions,
and there is no indication there is one.

> My guess is the original one probably is faster.

No, it is not. Btw, that guess is inconsistent with a hypothesis we have
intrinsics for String.hashCode() ;)

Thanks,
-Aleksey.



From aleksey.shipilev at oracle.com  Wed Sep 17 16:47:33 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 17 Sep 2014 20:47:33 +0400
Subject: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization
	checks scale devastatingly poorly
In-Reply-To: <5419BA2C.2060007@oracle.com>
References: <5419A290.30409@oracle.com> <5419A55F.3070806@oracle.com>
	<5419BA2C.2060007@oracle.com>
Message-ID: <5419BB25.6080105@oracle.com>

On 09/17/2014 08:43 PM, Vladimir Ivanov wrote:
> I don't see anything obviously wrong either with U.dAC() or with
> dependency tracking in VM. What we stumbled upon is an inherent
> limitation of current dependency tracking implementation.

Yes, and so the question from John, which I need to follow up on, if we
need to fix that implementation generically, instead of avoiding the
problem with point fixes :)

> It's not specific to U.dAC(). Regular class loaders can hit similar
> problem as well.

Even better, this is even more generic.

> If you want to use 8058309 for dependency tracking improvments in VM,
> let me know. So far, I got an impression it is about LFs & JSR292 mostly.

Yes, please commit the LF fix under the different bug ID, if that is not
a hassle?

-Aleksey.




From xueming.shen at oracle.com  Wed Sep 17 16:52:12 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 17 Sep 2014 09:52:12 -0700
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <5419BA4E.8070200@oracle.com>
References: <54199AA9.2090804@oracle.com>	<CA+kOe0_+5R4uqfsJPkm0irX00NUgtbABZkHAiAqnCoXF7S-WRw@mail.gmail.com>	<5419A7D0.3010207@oracle.com>
	<5419B328.4040007@oracle.com> <5419BA4E.8070200@oracle.com>
Message-ID: <5419BC3C.9050407@oracle.com>

You're correct. I was confused by the hash_code() in javaClass that I'm 
recently working on:-)
that is for those constants only.

-Sherman

On 9/17/14 9:43 AM, Aleksey Shipilev wrote:
> Hi Xueming,
>
> On 09/17/2014 08:13 PM, Xueming Shen wrote:
>> String.hashCode() has intrinsics,
> No, we have no intrinsics for String.hashCode. We do have a native
> implementation for VM internal purposes though, but it's irrelevant here.
>
>> so I don't think  we are seeing the real performance "difference" of
>> the implementations.
> No, we are seeing the difference, but it is about consistently and
> slightly different code generation, see the disassemblies linked in the
> bug report. Really, the performance run was to look out for regressions,
> and there is no indication there is one.
>
>> My guess is the original one probably is faster.
> No, it is not. Btw, that guess is inconsistent with a hypothesis we have
> intrinsics for String.hashCode() ;)
>
> Thanks,
> -Aleksey.
>



From martinrb at google.com  Wed Sep 17 16:54:01 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 17 Sep 2014 09:54:01 -0700
Subject: RFR: 8058520: jar xf does not work on zip files with leading
	garbage.
In-Reply-To: <54185F64.8030105@oracle.com>
References: <CA+kOe0_2_Tpcs7z9NoTVa13HCzP76T0Q_Qkz9hysdbXxzNPYiw@mail.gmail.com>
	<54185F64.8030105@oracle.com>
Message-ID: <CA+kOe0-G-iOV3DRJKciRXZS+jE10kJBP98cXApKTVptGPH+K9Q@mail.gmail.com>

[image: Read zip files from the beginning? Read zip files from the end?
(both)]

On Tue, Sep 16, 2014 at 9:03 AM, Xueming Shen <xueming.shen at oracle.com>
wrote:

> On 9/15/14 6:40 PM, Martin Buchholz wrote:
>
>> Hi Alan, Xueming,
>>
>> I'd like you to do a code review.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8058520
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jar-leadingGarbage/ <
>> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/jar-leadingGarbage/
>> >
>>
>
>
> It was the performance concern back then that led us to keep using the
> input stream
> for extracting, if it's to extract the whole zip/jar.
>
> There is also some "regressions" reported later with the ZipFile path when
> dealing with
> some "wrong"/non-ZIP64-spec-compliant huge zip file, in which it's fine
> to access those
> entries from the beginning of the stream, but can't jump back to the
> individual entries
> from the cen table.
>
> It appears you will have to flip a coin to see which case is more
> "important"?
>
> -Sherman
>


From vladimir.x.ivanov at oracle.com  Wed Sep 17 16:55:35 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 17 Sep 2014 20:55:35 +0400
Subject: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization
	checks scale devastatingly poorly
In-Reply-To: <5419BB25.6080105@oracle.com>
References: <5419A290.30409@oracle.com> <5419A55F.3070806@oracle.com>
	<5419BA2C.2060007@oracle.com> <5419BB25.6080105@oracle.com>
Message-ID: <5419BD07.3070004@oracle.com>

 >> It's not specific to U.dAC(). Regular class loaders can hit similar
>> problem as well.
>
> Even better, this is even more generic.
Please, update bug synopsis then.

>> If you want to use 8058309 for dependency tracking improvments in VM,
>> let me know. So far, I got an impression it is about LFs & JSR292 mostly.
>
> Yes, please commit the LF fix under the different bug ID, if that is not
> a hassle?
Done:
     8058661: Compiled LambdaForms should inherit from Object to improve 
class loading performance
     https://bugs.openjdk.java.net/browse/JDK-8058661

Best regards,
Vladimir Ivanov


From aleksey.shipilev at oracle.com  Wed Sep 17 17:03:44 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 17 Sep 2014 21:03:44 +0400
Subject: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization
	checks scale devastatingly poorly
In-Reply-To: <5419BD07.3070004@oracle.com>
References: <5419A290.30409@oracle.com> <5419A55F.3070806@oracle.com>
	<5419BA2C.2060007@oracle.com> <5419BB25.6080105@oracle.com>
	<5419BD07.3070004@oracle.com>
Message-ID: <5419BEF0.4050303@oracle.com>

On 09/17/2014 08:55 PM, Vladimir Ivanov wrote:
>>> It's not specific to U.dAC(). Regular class loaders can hit similar
>>> problem as well.
>>
>> Even better, this is even more generic.
> Please, update bug synopsis then.

Thanks, did so. Also reassigned the bug, and lowered the priority.

> Done:
>     8058661: Compiled LambdaForms should inherit from Object to improve
> class loading performance
>     https://bugs.openjdk.java.net/browse/JDK-8058661

Awesome. I have no further comments, the patch is plain and simple.

-Aleksey.




From brian.burkhalter at oracle.com  Wed Sep 17 17:43:42 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 17 Sep 2014 10:43:42 -0700
Subject: JDK 9 RFR of 8058664: Bad fonts in BigIntegerTest 
Message-ID: <D1396A34-D382-404D-817A-D2732645AC0C@oracle.com>

Hello,

Issue:	https://bugs.openjdk.java.net/browse/JDK-8058664
Webrev:	http://cr.openjdk.java.net/~bpb/8058664/webrev.00/

Somehow some bad fonts got in to the line prefixes of some comments and none of the tools caught it.

Thanks,

Brian

From Alan.Bateman at oracle.com  Wed Sep 17 17:46:10 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Sep 2014 18:46:10 +0100
Subject: JDK 9 RFR of 8058664: Bad fonts in BigIntegerTest
In-Reply-To: <D1396A34-D382-404D-817A-D2732645AC0C@oracle.com>
References: <D1396A34-D382-404D-817A-D2732645AC0C@oracle.com>
Message-ID: <5419C8E2.10706@oracle.com>

On 17/09/2014 18:43, Brian Burkhalter wrote:
> Hello,
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8058664
> Webrev:	http://cr.openjdk.java.net/~bpb/8058664/webrev.00/
>
> Somehow some bad fonts got in to the line prefixes of some comments and none of the tools caught it.
>
? ? ? ? Looks good :-)



From mandy.chung at oracle.com  Wed Sep 17 18:02:39 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 17 Sep 2014 11:02:39 -0700
Subject: RFR 8058569: Update java/lang/invoke/lambda tests to eliminate
	dependency on sun.tools.jar.Main
In-Reply-To: <5419AAC6.3000503@oracle.com>
References: <54185C07.2040605@oracle.com>
	<5418D677.6000808@oracle.com>	<5419A8E5.3000102@oracle.com>
	<5419AAC6.3000503@oracle.com>
Message-ID: <5419CCBF.5090602@oracle.com>


On 9/17/2014 8:37 AM, Alan Bateman wrote:
> On 17/09/2014 16:29, Amy Lu wrote:
>> Hi, David
>>
>> Thank you for your review!
>>
>> Here's the updated version, run jar tool directly:
>> webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.02/
>>
>> com.sun.tools.javac.Main is not reported as internal API so far (see 
>> below jdeps result before the fix), if this changed in the future, it 
>> will be fixed in a separate bug.
>>
> com.sun.tools.javac.Main is a supported API so it will need to be 
> exported when we move to module.

A good way to determine if an API is exported or not (before the module 
system is further along):
check out http://hg.openjdk.java.net/jdk9/dev/file/d1d2ca914d49/modules.xml:

  <module>
     <name>jdk.compiler</name>
     ...
     <export>
       <name>com.sun.tools.javac</name>
     </export>
     ...
  </module>

Mandy


From tim.bell at oracle.com  Wed Sep 17 18:05:00 2014
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 17 Sep 2014 11:05:00 -0700
Subject: JDK 9 RFR of 8058664: Bad fonts in BigIntegerTest
In-Reply-To: <5419C8E2.10706@oracle.com>
References: <D1396A34-D382-404D-817A-D2732645AC0C@oracle.com>
	<5419C8E2.10706@oracle.com>
Message-ID: <5419CD4C.5010002@oracle.com>

On 09/17/14 10:46, Alan Bateman wrote:
> On 17/09/2014 18:43, Brian Burkhalter wrote:
>> Hello,
>>
>> Issue:    https://bugs.openjdk.java.net/browse/JDK-8058664
>> Webrev:    http://cr.openjdk.java.net/~bpb/8058664/webrev.00/
>>
>> Somehow some bad fonts got in to the line prefixes of some comments 
>> and none of the tools caught it.

Too bad - this is a weakness in the tools we use...

>>
> ? ? ? ? Looks good :-)
>

Looks good to me as well - sorry for the DUP bug report JDK-8058669

Tim



From martinrb at google.com  Wed Sep 17 18:42:26 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 17 Sep 2014 11:42:26 -0700
Subject: RFR: 8058520: jar xf does not work on zip files with leading
	garbage.
In-Reply-To: <54185F64.8030105@oracle.com>
References: <CA+kOe0_2_Tpcs7z9NoTVa13HCzP76T0Q_Qkz9hysdbXxzNPYiw@mail.gmail.com>
	<54185F64.8030105@oracle.com>
Message-ID: <CA+kOe08tN0asPAGY-FVvWfLXopLYK9UAA42J_sinCp1XTmuvmw@mail.gmail.com>

On Tue, Sep 16, 2014 at 9:03 AM, Xueming Shen <xueming.shen at oracle.com>
wrote:

>
> There is also some "regressions" reported later with the ZipFile path when
> dealing with
> some "wrong"/non-ZIP64-spec-compliant huge zip file, in which it's fine
> to access those
> entries from the beginning of the stream, but can't jump back to the
> individual entries
> from the cen table.
>
>
I think I have a couple of brain cells with dim memories of that.


> It appears you will have to flip a coin to see which case is more
> "important"?
>

"Why not both?"

Implemented in my latest webrev.  Hopefully maximal efficiency and maximal
support for leading garbage.


From forax at univ-mlv.fr  Wed Sep 17 18:53:58 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 17 Sep 2014 20:53:58 +0200
Subject: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization
	checks scale devastatingly poorly
In-Reply-To: <5419BD07.3070004@oracle.com>
References: <5419A290.30409@oracle.com>
	<5419A55F.3070806@oracle.com>	<5419BA2C.2060007@oracle.com>
	<5419BB25.6080105@oracle.com> <5419BD07.3070004@oracle.com>
Message-ID: <5419D8C6.1030608@univ-mlv.fr>


On 09/17/2014 06:55 PM, Vladimir Ivanov wrote:
> >> It's not specific to U.dAC(). Regular class loaders can hit similar
>>> problem as well.
>>
>> Even better, this is even more generic.
> Please, update bug synopsis then.
>
>>> If you want to use 8058309 for dependency tracking improvments in VM,
>>> let me know. So far, I got an impression it is about LFs & JSR292 
>>> mostly.
>>
>> Yes, please commit the LF fix under the different bug ID, if that is not
>> a hassle?
> Done:
>     8058661: Compiled LambdaForms should inherit from Object to 
> improve class loading performance
>     https://bugs.openjdk.java.net/browse/JDK-8058661

I wonder if the Proxy generation code (j.l.r.Proxy) and the method 
accessor generation code (j.l.r.Method) doesn't have the very same issue.

> Best regards,
> Vladimir Ivanov

R?mi



From aleksey.shipilev at oracle.com  Wed Sep 17 18:58:47 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 17 Sep 2014 22:58:47 +0400
Subject: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization
	checks scale devastatingly poorly
In-Reply-To: <5419D8C6.1030608@univ-mlv.fr>
References: <5419A290.30409@oracle.com>
	<5419A55F.3070806@oracle.com>	<5419BA2C.2060007@oracle.com>
	<5419BB25.6080105@oracle.com> <5419BD07.3070004@oracle.com>
	<5419D8C6.1030608@univ-mlv.fr>
Message-ID: <5419D9E7.5000406@oracle.com>

On 09/17/2014 10:53 PM, Remi Forax wrote:
> 
> On 09/17/2014 06:55 PM, Vladimir Ivanov wrote:
>> >> It's not specific to U.dAC(). Regular class loaders can hit similar
>>>> problem as well.
>>>
>>> Even better, this is even more generic.
>> Please, update bug synopsis then.
>>
>>>> If you want to use 8058309 for dependency tracking improvments in VM,
>>>> let me know. So far, I got an impression it is about LFs & JSR292
>>>> mostly.
>>>
>>> Yes, please commit the LF fix under the different bug ID, if that is not
>>> a hassle?
>> Done:
>>     8058661: Compiled LambdaForms should inherit from Object to
>> improve class loading performance
>>     https://bugs.openjdk.java.net/browse/JDK-8058661
> 
> I wonder if the Proxy generation code (j.l.r.Proxy) and the method
> accessor generation code (j.l.r.Method) doesn't have the very same issue.

We'll see, Remi, in the course of the original issue:
  https://bugs.openjdk.java.net/browse/JDK-8058309

Thanks for pointing two new opportunities too look for!

-Aleksey



From brian.burkhalter at oracle.com  Wed Sep 17 20:48:34 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 17 Sep 2014 13:48:34 -0700
Subject: JDK 9 RFR of 8058679: More bad characters in BigIntegerTest
Message-ID: <2E3DE0B5-65D2-4CFE-94FF-291356F8EC41@oracle.com>

Hello bad characters,

Issue:	https://bugs.openjdk.java.net/browse/JDK-8058679
Webrev:	http://cr.openjdk.java.net/~bpb/8058679/webrev.00/

Tested with "-encoding US-ASCII? passed to javac.

Thanks,

Brian

From Alan.Bateman at oracle.com  Wed Sep 17 20:52:28 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Sep 2014 21:52:28 +0100
Subject: JDK 9 RFR of 8058679: More bad characters in BigIntegerTest
In-Reply-To: <2E3DE0B5-65D2-4CFE-94FF-291356F8EC41@oracle.com>
References: <2E3DE0B5-65D2-4CFE-94FF-291356F8EC41@oracle.com>
Message-ID: <5419F48C.8080601@oracle.com>

On 17/09/2014 21:48, Brian Burkhalter wrote:
> Hello bad characters,
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8058679
> Webrev:	http://cr.openjdk.java.net/~bpb/8058679/webrev.00/
>
> Tested with "-encoding US-ASCII? passed to javac.
>
\ufffd\ufffd Looks okay and if it compiles with -encoding US-ASCII then 
it gives confidence that they have all been fixed now.

-Alan


From brian.burkhalter at oracle.com  Wed Sep 17 20:54:08 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 17 Sep 2014 13:54:08 -0700
Subject: JDK 9 RFR of 8058679: More bad characters in BigIntegerTest
In-Reply-To: <5419F48C.8080601@oracle.com>
References: <2E3DE0B5-65D2-4CFE-94FF-291356F8EC41@oracle.com>
	<5419F48C.8080601@oracle.com>
Message-ID: <DA86D344-A604-4C7C-AB0C-6636D02F957D@oracle.com>


On Sep 17, 2014, at 1:52 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 17/09/2014 21:48, Brian Burkhalter wrote:
>> Hello bad characters,
>> 
>> Issue:	https://bugs.openjdk.java.net/browse/JDK-8058679
>> Webrev:	http://cr.openjdk.java.net/~bpb/8058679/webrev.00/
>> 
>> Tested with "-encoding US-ASCII? passed to javac.
>> 
> \ufffd\ufffd Looks okay and if it compiles with -encoding US-ASCII then it gives confidence that they have all been fixed now.

To be specific:

javac -cp ../build/linux-x86-normal-server-fastdebug/jdk/classes -encoding US-ASCII test/java/math/BigInteger/BigIntegerTest.java

did not complain.

Thanks,

Brian

From david.holmes at oracle.com  Thu Sep 18 02:51:10 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Sep 2014 12:51:10 +1000
Subject: RFR 8058569: Update java/lang/invoke/lambda tests to eliminate
	dependency on sun.tools.jar.Main
In-Reply-To: <5419A8E5.3000102@oracle.com>
References: <54185C07.2040605@oracle.com> <5418D677.6000808@oracle.com>
	<5419A8E5.3000102@oracle.com>
Message-ID: <541A489E.703@oracle.com>

On 18/09/2014 1:29 AM, Amy Lu wrote:
> Hi, David
>
> Thank you for your review!
>
> Here's the updated version, run jar tool directly:
> webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.02/

Looks fine to me.

Thanks,
David

> com.sun.tools.javac.Main is not reported as internal API so far (see
> below jdeps result before the fix), if this changed in the future, it
> will be fixed in a separate bug.
>
> Before the fix:
> $ $TEST_JAVA/bin/jdeps -jdkinternals $CLASSES_DIR
> lambda -> jdk.dev
>     LUtils (lambda)
>        -> sun.tools.jar.Main JDK internal API (jdk.dev)
>     LambdaAccessControlDoPrivilegedTest (lambda)
>        -> sun.tools.jar.Main JDK internal API (jdk.dev)
>
> Warning: JDK internal APIs are unsupported and private to JDK
> implementation that are
> subject to be removed or changed incompatibly and could break your
> application.
> Please modify your code to eliminate dependency on any JDK internal APIs.
> For the most recent update on JDK internal API replacements, please check:
> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
>
> JDK Internal API                         Suggested Replacement
> ----------------                         ---------------------
> sun.tools.jar.Main                       Use java.util.jar or jar tool
> @since 1.2
>
>
> Thanks,
> Amy
>
> On 9/17/14, 8:31 AM, David Holmes wrote:
>> Hi Amy,
>>
>> On 17/09/2014 1:49 AM, Amy Lu wrote:
>>> Some java/lang/invoke/lambda tests have dependency on sun.tools.jar.Main
>>> This fix is to remove above internal JDK API dependency from the tests.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058569
>>> webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.01/
>>
>> I'm a little confused as to the issue here. Running the jar tool
>> programmatically as a Java program doesn't seem like a big deal, but
>> if it is then just run the the jar tool directly (this test is a
>> JDK-only test either way); or remove the static dependency with
>> reflection based code. Plus the same code still has this dependency:
>>
>>      static final com.sun.tools.javac.Main javac =
>>               new com.sun.tools.javac.Main();
>>
>> so I don't see that anything is being gained at the moment.
>>
>> Is there a bigger picture that this is part of?
>>
>> Thanks,
>> David
>>
>>> Thanks,
>>> Amy
>>>
>


From amy.lu at oracle.com  Thu Sep 18 02:59:20 2014
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 18 Sep 2014 10:59:20 +0800
Subject: RFR 8058569: Update java/lang/invoke/lambda tests to eliminate
	dependency on sun.tools.jar.Main
In-Reply-To: <541A489E.703@oracle.com>
References: <54185C07.2040605@oracle.com> <5418D677.6000808@oracle.com>
	<5419A8E5.3000102@oracle.com> <541A489E.703@oracle.com>
Message-ID: <541A4A88.3090206@oracle.com>

On 9/18/14, 10:51 AM, David Holmes wrote:
> On 18/09/2014 1:29 AM, Amy Lu wrote:
>> Hi, David
>>
>> Thank you for your review!
>>
>> Here's the updated version, run jar tool directly:
>> webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.02/
>
> Looks fine to me.

Thank you David!

May I have your help to push this change?

Thanks,
Amy

>
> Thanks,
> David
>
>> com.sun.tools.javac.Main is not reported as internal API so far (see
>> below jdeps result before the fix), if this changed in the future, it
>> will be fixed in a separate bug.
>>
>> Before the fix:
>> $ $TEST_JAVA/bin/jdeps -jdkinternals $CLASSES_DIR
>> lambda -> jdk.dev
>>     LUtils (lambda)
>>        -> sun.tools.jar.Main JDK internal API (jdk.dev)
>>     LambdaAccessControlDoPrivilegedTest (lambda)
>>        -> sun.tools.jar.Main JDK internal API (jdk.dev)
>>
>> Warning: JDK internal APIs are unsupported and private to JDK
>> implementation that are
>> subject to be removed or changed incompatibly and could break your
>> application.
>> Please modify your code to eliminate dependency on any JDK internal 
>> APIs.
>> For the most recent update on JDK internal API replacements, please 
>> check:
>> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
>>
>> JDK Internal API                         Suggested Replacement
>> ----------------                         ---------------------
>> sun.tools.jar.Main                       Use java.util.jar or jar tool
>> @since 1.2
>>
>>
>> Thanks,
>> Amy
>>
>> On 9/17/14, 8:31 AM, David Holmes wrote:
>>> Hi Amy,
>>>
>>> On 17/09/2014 1:49 AM, Amy Lu wrote:
>>>> Some java/lang/invoke/lambda tests have dependency on 
>>>> sun.tools.jar.Main
>>>> This fix is to remove above internal JDK API dependency from the 
>>>> tests.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058569
>>>> webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.01/
>>>
>>> I'm a little confused as to the issue here. Running the jar tool
>>> programmatically as a Java program doesn't seem like a big deal, but
>>> if it is then just run the the jar tool directly (this test is a
>>> JDK-only test either way); or remove the static dependency with
>>> reflection based code. Plus the same code still has this dependency:
>>>
>>>      static final com.sun.tools.javac.Main javac =
>>>               new com.sun.tools.javac.Main();
>>>
>>> so I don't see that anything is being gained at the moment.
>>>
>>> Is there a bigger picture that this is part of?
>>>
>>> Thanks,
>>> David
>>>
>>>> Thanks,
>>>> Amy
>>>>
>>



From david.holmes at oracle.com  Thu Sep 18 03:21:13 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 Sep 2014 13:21:13 +1000
Subject: RFR 8058569: Update java/lang/invoke/lambda tests to eliminate
	dependency on sun.tools.jar.Main
In-Reply-To: <541A4A88.3090206@oracle.com>
References: <54185C07.2040605@oracle.com> <5418D677.6000808@oracle.com>
	<5419A8E5.3000102@oracle.com> <541A489E.703@oracle.com>
	<541A4A88.3090206@oracle.com>
Message-ID: <541A4FA9.10900@oracle.com>

On 18/09/2014 12:59 PM, Amy Lu wrote:
> On 9/18/14, 10:51 AM, David Holmes wrote:
>> On 18/09/2014 1:29 AM, Amy Lu wrote:
>>> Hi, David
>>>
>>> Thank you for your review!
>>>
>>> Here's the updated version, run jar tool directly:
>>> webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.02/
>>
>> Looks fine to me.
>
> Thank you David!
>
> May I have your help to push this change?

Sure. Will put myself and Alan as reviewers. Not sure if Mandy actually 
reviewed.

David


> Thanks,
> Amy
>
>>
>> Thanks,
>> David
>>
>>> com.sun.tools.javac.Main is not reported as internal API so far (see
>>> below jdeps result before the fix), if this changed in the future, it
>>> will be fixed in a separate bug.
>>>
>>> Before the fix:
>>> $ $TEST_JAVA/bin/jdeps -jdkinternals $CLASSES_DIR
>>> lambda -> jdk.dev
>>>     LUtils (lambda)
>>>        -> sun.tools.jar.Main JDK internal API (jdk.dev)
>>>     LambdaAccessControlDoPrivilegedTest (lambda)
>>>        -> sun.tools.jar.Main JDK internal API (jdk.dev)
>>>
>>> Warning: JDK internal APIs are unsupported and private to JDK
>>> implementation that are
>>> subject to be removed or changed incompatibly and could break your
>>> application.
>>> Please modify your code to eliminate dependency on any JDK internal
>>> APIs.
>>> For the most recent update on JDK internal API replacements, please
>>> check:
>>> https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
>>>
>>> JDK Internal API                         Suggested Replacement
>>> ----------------                         ---------------------
>>> sun.tools.jar.Main                       Use java.util.jar or jar tool
>>> @since 1.2
>>>
>>>
>>> Thanks,
>>> Amy
>>>
>>> On 9/17/14, 8:31 AM, David Holmes wrote:
>>>> Hi Amy,
>>>>
>>>> On 17/09/2014 1:49 AM, Amy Lu wrote:
>>>>> Some java/lang/invoke/lambda tests have dependency on
>>>>> sun.tools.jar.Main
>>>>> This fix is to remove above internal JDK API dependency from the
>>>>> tests.
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058569
>>>>> webrev: http://cr.openjdk.java.net/~tyan/amylu/8058569/webrev.01/
>>>>
>>>> I'm a little confused as to the issue here. Running the jar tool
>>>> programmatically as a Java program doesn't seem like a big deal, but
>>>> if it is then just run the the jar tool directly (this test is a
>>>> JDK-only test either way); or remove the static dependency with
>>>> reflection based code. Plus the same code still has this dependency:
>>>>
>>>>      static final com.sun.tools.javac.Main javac =
>>>>               new com.sun.tools.javac.Main();
>>>>
>>>> so I don't see that anything is being gained at the moment.
>>>>
>>>> Is there a bigger picture that this is part of?
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Thanks,
>>>>> Amy
>>>>>
>>>
>


From robbiexgibson at yahoo.com  Thu Sep 18 08:52:24 2014
From: robbiexgibson at yahoo.com (Robert Gibson)
Date: Thu, 18 Sep 2014 01:52:24 -0700
Subject: JDK 9 RFR of 8058679: More bad characters in BigIntegerTest
In-Reply-To: <5419F48C.8080601@oracle.com>
References: <2E3DE0B5-65D2-4CFE-94FF-291356F8EC41@oracle.com>
	<5419F48C.8080601@oracle.com>
Message-ID: <1411030344.42589.YahooMailNeo@web121302.mail.ne1.yahoo.com>

Sorry about that, let's blame my crappy webmail ;) 
(Strange that the patch appears fine in the mail archives and the webrev?)
Robert 

On Thursday, 18 September 2014, 3:18, Alan Bateman <Alan.Bateman at oracle.com> wrote:
On 17/09/2014 21:48, Brian Burkhalter wrote:
> Hello bad characters,
>
> Issue:    https://bugs.openjdk.java.net/browse/JDK-8058679
> Webrev:    http://cr.openjdk.java.net/~bpb/8058679/webrev.00/
>
> Tested with "-encoding US-ASCII? passed to javac.
>
\ufffd\ufffd Looks okay and if it compiles with -encoding US-ASCII then 
it gives confidence that they have all been fixed now.

-Alan  


From joel.franck at oracle.com  Thu Sep 18 09:00:39 2014
From: joel.franck at oracle.com (=?windows-1252?Q?Joel_Borggr=E9n-Franck?=)
Date: Thu, 18 Sep 2014 11:00:39 +0200
Subject: [8u40] RFR: JDK-8058632: Revert JDK-8054984 from 8u40
Message-ID: <C143BD92-3B55-41E1-A1C2-F3FB33D405C1@oracle.com>

Hi,

Can I get a review for this anti-patch for JDK-8054984  (which is a backport  of JDK-8044629 "(reflect) Constructor.getAnnotatedReceiverType() returns wrong value? to 8u).

The fix shouldn?t have been back ported, so this change reverts it in 8u only.

Webrev: http://cr.openjdk.java.net/~jfranck/8058632/webrev.00/
Side-by-side-diff: http://cr.openjdk.java.net/~jfranck/8058632/side-by-side.diff

Original jdk8u webrev for reference: http://cr.openjdk.java.net/~jfranck/8044629/jdk8u/

cheers
/Joel

From miroslav.kos at oracle.com  Thu Sep 18 09:12:34 2014
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Thu, 18 Sep 2014 11:12:34 +0200
Subject: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for
	Web services
In-Reply-To: <541997D1.8040602@oracle.com>
References: <541985F4.6010202@oracle.com> <541997D1.8040602@oracle.com>
Message-ID: <541AA202.10203@oracle.com>

Thanks, Sean, good catch ...

I changed the destination for generated files:
http://cr.openjdk.java.net/~mkos/8038966/jdk.02/

Regarding usage ProcessBuilder instead of shell script - the problem is, 
that to compile test classes, wsdl must be compiled first - shell script 
is setup required before javac. The test would have to be run in two 
phases - first compiling+running java classes that compile wsdl 
(ProcessBuilder) and after that compiling other java classes using 
result of previous run.

I was solving this with jtreg some time ago already, but I haven't found 
other way than using shell script. If you know better solution, it would 
be great ...

Thanks
Miran



On 17/09/14 16:16, Se?n Coffey wrote:
> Miran,
>
> the src change looks ok but I think there's a problem with the testcase.
>
> You've defined generated classes for wsimport to be output to the TESTSRC
> directory. This is often read only and won't work.
>
> TESTCLASSES is the variable you're probably looking for. In any case, 
> I think
> it's possible for you to avoid use of scripting. Can you invoke 
> wsimport via
> the ProcessBuilder API like that done for other wsimport tests ?
>
> regards,
> Sean.
>
> On 17/09/14 14:00, Miroslav Kos wrote:
>> Hi everybody,
>>
>> please review patch fixing following issue:
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
>> webrev:
>> http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
>> http://cr.openjdk.java.net/~mkos/8038966/jdk.01/
>>
>> It is second part of fix ensuring that content of type 
>> xsd:any/content=mixed stays unchanged when processed with JAX-B RI. 
>> Regression test within webrev.
>>
>> Sean, could you sponsor it for me?
>>
>> Thanks
>> Miran
>>
>>
>>
>



From vladimir.x.ivanov at oracle.com  Thu Sep 18 09:26:44 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 18 Sep 2014 13:26:44 +0400
Subject: [9] RFR (XXS): 8058309: Unsafe.defineAnonymousClass deoptimization
	checks scale devastatingly poorly
In-Reply-To: <5419D8C6.1030608@univ-mlv.fr>
References: <5419A290.30409@oracle.com>	<5419A55F.3070806@oracle.com>	<5419BA2C.2060007@oracle.com>	<5419BB25.6080105@oracle.com>
	<5419BD07.3070004@oracle.com> <5419D8C6.1030608@univ-mlv.fr>
Message-ID: <541AA554.90807@oracle.com>

Remi,

Good question!

I looked into the code and my understanding is that they don't have the 
same problem as compiled LambdaForms.

Proxy doesn't have instance methods (only public/private static), so no 
unique_concrete_method dependencies in Proxy context.

Similar situation with Method: SerializationConstructorAccessorImpl, 
ConstructorAccessorImpl, MethodAccessorImpl, their supertypes, and 
interfaces they implement declare megamorphic abstract instance methods. 
So, I don't expect any unique_concrete_method dependencies in these 
contexts as well.

But it's mostly an educated guess, it'd be great to see some data 
confirming my observations.

Best regards,
Vladimir Ivanov

On 9/17/14, 10:53 PM, Remi Forax wrote:
>
> On 09/17/2014 06:55 PM, Vladimir Ivanov wrote:
>> >> It's not specific to U.dAC(). Regular class loaders can hit similar
>>>> problem as well.
>>>
>>> Even better, this is even more generic.
>> Please, update bug synopsis then.
>>
>>>> If you want to use 8058309 for dependency tracking improvments in VM,
>>>> let me know. So far, I got an impression it is about LFs & JSR292
>>>> mostly.
>>>
>>> Yes, please commit the LF fix under the different bug ID, if that is not
>>> a hassle?
>> Done:
>>     8058661: Compiled LambdaForms should inherit from Object to
>> improve class loading performance
>>     https://bugs.openjdk.java.net/browse/JDK-8058661
>
> I wonder if the Proxy generation code (j.l.r.Proxy) and the method
> accessor generation code (j.l.r.Method) doesn't have the very same issue.
>
>> Best regards,
>> Vladimir Ivanov
>
> R?mi
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From staffan.larsen at oracle.com  Thu Sep 18 09:27:39 2014
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 18 Sep 2014 11:27:39 +0200
Subject: [8u40] RFR: JDK-8058632: Revert JDK-8054984 from 8u40
In-Reply-To: <C143BD92-3B55-41E1-A1C2-F3FB33D405C1@oracle.com>
References: <C143BD92-3B55-41E1-A1C2-F3FB33D405C1@oracle.com>
Message-ID: <9E28B8A0-98DF-4588-9F93-31633E441B8B@oracle.com>

Looks good!

Thanks,
/Staffan

On 18 sep 2014, at 11:00, Joel Borggr?n-Franck <joel.franck at oracle.com> wrote:

> Hi,
> 
> Can I get a review for this anti-patch for JDK-8054984  (which is a backport  of JDK-8044629 "(reflect) Constructor.getAnnotatedReceiverType() returns wrong value? to 8u).
> 
> The fix shouldn?t have been back ported, so this change reverts it in 8u only.
> 
> Webrev: http://cr.openjdk.java.net/~jfranck/8058632/webrev.00/
> Side-by-side-diff: http://cr.openjdk.java.net/~jfranck/8058632/side-by-side.diff
> 
> Original jdk8u webrev for reference: http://cr.openjdk.java.net/~jfranck/8044629/jdk8u/
> 
> cheers
> /Joel



From sean.coffey at oracle.com  Thu Sep 18 09:49:59 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Thu, 18 Sep 2014 10:49:59 +0100
Subject: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for
	Web services
In-Reply-To: <541AA202.10203@oracle.com>
References: <541985F4.6010202@oracle.com> <541997D1.8040602@oracle.com>
	<541AA202.10203@oracle.com>
Message-ID: <541AAAC7.8030806@oracle.com>


On 18/09/2014 10:12, Miroslav Kos wrote:
> Thanks, Sean, good catch ...
>
> I changed the destination for generated files:
> http://cr.openjdk.java.net/~mkos/8038966/jdk.02/
>
> Regarding usage ProcessBuilder instead of shell script - the problem 
> is, that to compile test classes, wsdl must be compiled first - shell 
> script is setup required before javac. The test would have to be run 
> in two phases - first compiling+running java classes that compile wsdl 
> (ProcessBuilder) and after that compiling other java classes using 
> result of previous run.
>
> I was solving this with jtreg some time ago already, but I haven't 
> found other way than using shell script. If you know better solution, 
> it would be great ...
Ah - I see the dependency now. Thanks for the information.

Just spotted one other issue. The deleteGeneratedFiles() method scans 
for files in the
test src path (for deletion) - No files should be created there now. You 
can change that
to scan the test classes path now. You could just use the current 
working directory I guess
since that's where jtreg will generate the new files.

Paths.get("org");

once that's fixed up, I can run this through JPRT and it should be good 
to push then.

regards,
Sean.

>
> Thanks
> Miran
>
>
>
> On 17/09/14 16:16, Se?n Coffey wrote:
>> Miran,
>>
>> the src change looks ok but I think there's a problem with the testcase.
>>
>> You've defined generated classes for wsimport to be output to the 
>> TESTSRC
>> directory. This is often read only and won't work.
>>
>> TESTCLASSES is the variable you're probably looking for. In any case, 
>> I think
>> it's possible for you to avoid use of scripting. Can you invoke 
>> wsimport via
>> the ProcessBuilder API like that done for other wsimport tests ?
>>
>> regards,
>> Sean.
>>
>> On 17/09/14 14:00, Miroslav Kos wrote:
>>> Hi everybody,
>>>
>>> please review patch fixing following issue:
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
>>> webrev:
>>> http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.01/
>>>
>>> It is second part of fix ensuring that content of type 
>>> xsd:any/content=mixed stays unchanged when processed with JAX-B RI. 
>>> Regression test within webrev.
>>>
>>> Sean, could you sponsor it for me?
>>>
>>> Thanks
>>> Miran
>>>
>>>
>>>
>>
>



From joel.franck at oracle.com  Thu Sep 18 10:31:00 2014
From: joel.franck at oracle.com (Joel =?utf-8?Q?Borggr=C3=A9n-Franck?=)
Date: Thu, 18 Sep 2014 12:31:00 +0200
Subject: [8u40] RFR: JDK-8058632: Revert JDK-8054984 from 8u40
In-Reply-To: <9E28B8A0-98DF-4588-9F93-31633E441B8B@oracle.com>
References: <C143BD92-3B55-41E1-A1C2-F3FB33D405C1@oracle.com>
	<9E28B8A0-98DF-4588-9F93-31633E441B8B@oracle.com>
Message-ID: <20140918103100.GH19198@oracle.com>

Thanks for the review Staffan!

cheers
/Joel

On 2014-09-18, Staffan Larsen wrote:
> Looks good!
> 
> Thanks,
> /Staffan
> 
> On 18 sep 2014, at 11:00, Joel Borggr?n-Franck <joel.franck at oracle.com> wrote:
> 
> > Hi,
> > 
> > Can I get a review for this anti-patch for JDK-8054984  (which is a backport  of JDK-8044629 "(reflect) Constructor.getAnnotatedReceiverType() returns wrong value? to 8u).
> > 
> > The fix shouldn?t have been back ported, so this change reverts it in 8u only.
> > 
> > Webrev: http://cr.openjdk.java.net/~jfranck/8058632/webrev.00/
> > Side-by-side-diff: http://cr.openjdk.java.net/~jfranck/8058632/side-by-side.diff
> > 
> > Original jdk8u webrev for reference: http://cr.openjdk.java.net/~jfranck/8044629/jdk8u/
> > 
> > cheers
> > /Joel
> 


From miroslav.kos at oracle.com  Thu Sep 18 11:29:39 2014
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Thu, 18 Sep 2014 13:29:39 +0200
Subject: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for
	Web services
In-Reply-To: <541AAAC7.8030806@oracle.com>
References: <541985F4.6010202@oracle.com> <541997D1.8040602@oracle.com>
	<541AA202.10203@oracle.com> <541AAAC7.8030806@oracle.com>
Message-ID: <541AC223.6080003@oracle.com>

Oops, I missed that, thanks. One question yet - does it make sense any 
more to clean generated files now, when the location was changed? I 
think clean up should be done automatically by jtreg now, shouldn't it? 
If you agree, I would delete the method instead.

Thanks
Miran

On 18/09/14 11:49, Se?n Coffey wrote:
>
> On 18/09/2014 10:12, Miroslav Kos wrote:
>> Thanks, Sean, good catch ...
>>
>> I changed the destination for generated files:
>> http://cr.openjdk.java.net/~mkos/8038966/jdk.02/
>>
>> Regarding usage ProcessBuilder instead of shell script - the problem 
>> is, that to compile test classes, wsdl must be compiled first - shell 
>> script is setup required before javac. The test would have to be run 
>> in two phases - first compiling+running java classes that compile 
>> wsdl (ProcessBuilder) and after that compiling other java classes 
>> using result of previous run.
>>
>> I was solving this with jtreg some time ago already, but I haven't 
>> found other way than using shell script. If you know better solution, 
>> it would be great ...
> Ah - I see the dependency now. Thanks for the information.
>
> Just spotted one other issue. The deleteGeneratedFiles() method scans 
> for files in the
> test src path (for deletion) - No files should be created there now. 
> You can change that
> to scan the test classes path now. You could just use the current 
> working directory I guess
> since that's where jtreg will generate the new files.
>
> Paths.get("org");
>
> once that's fixed up, I can run this through JPRT and it should be 
> good to push then.
>
> regards,
> Sean.
>
>>
>> Thanks
>> Miran
>>
>>
>>
>> On 17/09/14 16:16, Se?n Coffey wrote:
>>> Miran,
>>>
>>> the src change looks ok but I think there's a problem with the 
>>> testcase.
>>>
>>> You've defined generated classes for wsimport to be output to the 
>>> TESTSRC
>>> directory. This is often read only and won't work.
>>>
>>> TESTCLASSES is the variable you're probably looking for. In any 
>>> case, I think
>>> it's possible for you to avoid use of scripting. Can you invoke 
>>> wsimport via
>>> the ProcessBuilder API like that done for other wsimport tests ?
>>>
>>> regards,
>>> Sean.
>>>
>>> On 17/09/14 14:00, Miroslav Kos wrote:
>>>> Hi everybody,
>>>>
>>>> please review patch fixing following issue:
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
>>>> webrev:
>>>> http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
>>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.01/
>>>>
>>>> It is second part of fix ensuring that content of type 
>>>> xsd:any/content=mixed stays unchanged when processed with JAX-B RI. 
>>>> Regression test within webrev.
>>>>
>>>> Sean, could you sponsor it for me?
>>>>
>>>> Thanks
>>>> Miran
>>>>
>>>>
>>>>
>>>
>>
>



From sean.coffey at oracle.com  Thu Sep 18 12:01:36 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Thu, 18 Sep 2014 13:01:36 +0100
Subject: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for
	Web services
In-Reply-To: <541AC223.6080003@oracle.com>
References: <541985F4.6010202@oracle.com> <541997D1.8040602@oracle.com>
	<541AA202.10203@oracle.com> <541AAAC7.8030806@oracle.com>
	<541AC223.6080003@oracle.com>
Message-ID: <541AC9A0.1090900@oracle.com>

jtreg should remove the work/scratch directory upon test completion but 
it's best practice to attempt to clean up generated files. No harm there 
I think. Also needed in cases where test might be run manually. I'd 
suggest keeping the clean up code in the testcase.

regards,
Sean.

On 18/09/2014 12:29, Miroslav Kos wrote:
> Oops, I missed that, thanks. One question yet - does it make sense any 
> more to clean generated files now, when the location was changed? I 
> think clean up should be done automatically by jtreg now, shouldn't 
> it? If you agree, I would delete the method instead.
>
> Thanks
> Miran
>
> On 18/09/14 11:49, Se?n Coffey wrote:
>>
>> On 18/09/2014 10:12, Miroslav Kos wrote:
>>> Thanks, Sean, good catch ...
>>>
>>> I changed the destination for generated files:
>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.02/
>>>
>>> Regarding usage ProcessBuilder instead of shell script - the problem 
>>> is, that to compile test classes, wsdl must be compiled first - 
>>> shell script is setup required before javac. The test would have to 
>>> be run in two phases - first compiling+running java classes that 
>>> compile wsdl (ProcessBuilder) and after that compiling other java 
>>> classes using result of previous run.
>>>
>>> I was solving this with jtreg some time ago already, but I haven't 
>>> found other way than using shell script. If you know better 
>>> solution, it would be great ...
>> Ah - I see the dependency now. Thanks for the information.
>>
>> Just spotted one other issue. The deleteGeneratedFiles() method scans 
>> for files in the
>> test src path (for deletion) - No files should be created there now. 
>> You can change that
>> to scan the test classes path now. You could just use the current 
>> working directory I guess
>> since that's where jtreg will generate the new files.
>>
>> Paths.get("org");
>>
>> once that's fixed up, I can run this through JPRT and it should be 
>> good to push then.
>>
>> regards,
>> Sean.
>>
>>>
>>> Thanks
>>> Miran
>>>
>>>
>>>
>>> On 17/09/14 16:16, Se?n Coffey wrote:
>>>> Miran,
>>>>
>>>> the src change looks ok but I think there's a problem with the 
>>>> testcase.
>>>>
>>>> You've defined generated classes for wsimport to be output to the 
>>>> TESTSRC
>>>> directory. This is often read only and won't work.
>>>>
>>>> TESTCLASSES is the variable you're probably looking for. In any 
>>>> case, I think
>>>> it's possible for you to avoid use of scripting. Can you invoke 
>>>> wsimport via
>>>> the ProcessBuilder API like that done for other wsimport tests ?
>>>>
>>>> regards,
>>>> Sean.
>>>>
>>>> On 17/09/14 14:00, Miroslav Kos wrote:
>>>>> Hi everybody,
>>>>>
>>>>> please review patch fixing following issue:
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
>>>>> webrev:
>>>>> http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
>>>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.01/
>>>>>
>>>>> It is second part of fix ensuring that content of type 
>>>>> xsd:any/content=mixed stays unchanged when processed with JAX-B 
>>>>> RI. Regression test within webrev.
>>>>>
>>>>> Sean, could you sponsor it for me?
>>>>>
>>>>> Thanks
>>>>> Miran
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>



From miroslav.kos at oracle.com  Thu Sep 18 15:22:00 2014
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Thu, 18 Sep 2014 17:22:00 +0200
Subject: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for
	Web services
In-Reply-To: <541AC9A0.1090900@oracle.com>
References: <541985F4.6010202@oracle.com> <541997D1.8040602@oracle.com>
	<541AA202.10203@oracle.com> <541AAAC7.8030806@oracle.com>
	<541AC223.6080003@oracle.com> <541AC9A0.1090900@oracle.com>
Message-ID: <541AF898.6060400@oracle.com>

Ok then, the webrev updated:
http://cr.openjdk.java.net/~mkos/8038966/jdk.03/
http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/

btw. I had to tweak the path - using simply Paths.get("org") we get
     JTwork/scratch/org
but needed path is
     JTwork/classes/javax/xml/ws/xsanymixed/org
(classes instead of scratch + test path as prefix), so I changed the 
code to
         Path p = Paths.get("..", "classes", "javax", "xml", "ws", 
"xsanymixed", "org");

Thanks
Miran


On 18/09/14 14:01, Se?n Coffey wrote:
> jtreg should remove the work/scratch directory upon test completion 
> but it's best practice to attempt to clean up generated files. No harm 
> there I think. Also needed in cases where test might be run manually. 
> I'd suggest keeping the clean up code in the testcase.
>
> regards,
> Sean.
>
> On 18/09/2014 12:29, Miroslav Kos wrote:
>> Oops, I missed that, thanks. One question yet - does it make sense 
>> any more to clean generated files now, when the location was changed? 
>> I think clean up should be done automatically by jtreg now, shouldn't 
>> it? If you agree, I would delete the method instead.
>>
>> Thanks
>> Miran
>>
>> On 18/09/14 11:49, Se?n Coffey wrote:
>>>
>>> On 18/09/2014 10:12, Miroslav Kos wrote:
>>>> Thanks, Sean, good catch ...
>>>>
>>>> I changed the destination for generated files:
>>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.02/
>>>>
>>>> Regarding usage ProcessBuilder instead of shell script - the 
>>>> problem is, that to compile test classes, wsdl must be compiled 
>>>> first - shell script is setup required before javac. The test would 
>>>> have to be run in two phases - first compiling+running java classes 
>>>> that compile wsdl (ProcessBuilder) and after that compiling other 
>>>> java classes using result of previous run.
>>>>
>>>> I was solving this with jtreg some time ago already, but I haven't 
>>>> found other way than using shell script. If you know better 
>>>> solution, it would be great ...
>>> Ah - I see the dependency now. Thanks for the information.
>>>
>>> Just spotted one other issue. The deleteGeneratedFiles() method 
>>> scans for files in the
>>> test src path (for deletion) - No files should be created there now. 
>>> You can change that
>>> to scan the test classes path now. You could just use the current 
>>> working directory I guess
>>> since that's where jtreg will generate the new files.
>>>
>>> Paths.get("org");
>>>
>>> once that's fixed up, I can run this through JPRT and it should be 
>>> good to push then.
>>>
>>> regards,
>>> Sean.
>>>
>>>>
>>>> Thanks
>>>> Miran
>>>>
>>>>
>>>>
>>>> On 17/09/14 16:16, Se?n Coffey wrote:
>>>>> Miran,
>>>>>
>>>>> the src change looks ok but I think there's a problem with the 
>>>>> testcase.
>>>>>
>>>>> You've defined generated classes for wsimport to be output to the 
>>>>> TESTSRC
>>>>> directory. This is often read only and won't work.
>>>>>
>>>>> TESTCLASSES is the variable you're probably looking for. In any 
>>>>> case, I think
>>>>> it's possible for you to avoid use of scripting. Can you invoke 
>>>>> wsimport via
>>>>> the ProcessBuilder API like that done for other wsimport tests ?
>>>>>
>>>>> regards,
>>>>> Sean.
>>>>>
>>>>> On 17/09/14 14:00, Miroslav Kos wrote:
>>>>>> Hi everybody,
>>>>>>
>>>>>> please review patch fixing following issue:
>>>>>>
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
>>>>>> webrev:
>>>>>> http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
>>>>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.01/
>>>>>>
>>>>>> It is second part of fix ensuring that content of type 
>>>>>> xsd:any/content=mixed stays unchanged when processed with JAX-B 
>>>>>> RI. Regression test within webrev.
>>>>>>
>>>>>> Sean, could you sponsor it for me?
>>>>>>
>>>>>> Thanks
>>>>>> Miran
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From xueming.shen at oracle.com  Thu Sep 18 17:38:15 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 18 Sep 2014 10:38:15 -0700
Subject: RFR: 8058520: jar xf does not work on zip files with leading
	garbage.
In-Reply-To: <CA+kOe08tN0asPAGY-FVvWfLXopLYK9UAA42J_sinCp1XTmuvmw@mail.gmail.com>
References: <CA+kOe0_2_Tpcs7z9NoTVa13HCzP76T0Q_Qkz9hysdbXxzNPYiw@mail.gmail.com>	<54185F64.8030105@oracle.com>
	<CA+kOe08tN0asPAGY-FVvWfLXopLYK9UAA42J_sinCp1XTmuvmw@mail.gmail.com>
Message-ID: <541B1887.3040602@oracle.com>

On 09/17/2014 11:42 AM, Martin Buchholz wrote:
>
>
> On Tue, Sep 16, 2014 at 9:03 AM, Xueming Shen <xueming.shen at oracle.com <mailto:xueming.shen at oracle.com>> wrote:
>
>
>     There is also some "regressions" reported later with the ZipFile path when dealing with
>     some "wrong"/non-ZIP64-spec-compliant huge zip file, in which it's fine to access those
>     entries from the beginning of the stream, but can't jump back to the individual entries
>     from the cen table.
>
>
> I think I have a couple of brain cells with dim memories of that.
>
>     It appears you will have to flip a coin to see which case is more "important"?
>
>
> "Why not both?"
>
> Implemented in my latest webrev.  Hopefully maximal efficiency and maximal support for leading garbage.

looks good.


From martinrb at google.com  Thu Sep 18 17:52:17 2014
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 18 Sep 2014 10:52:17 -0700
Subject: RFR: 8058550: Clarify that TimerTasks are not reusable
Message-ID: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>

Hi Chris,

I'd like you to do a code review.

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TimerTask-clarification/
https://bugs.openjdk.java.net/browse/JDK-8058550


From roger.riggs at oracle.com  Thu Sep 18 17:57:21 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 18 Sep 2014 13:57:21 -0400
Subject: RFR: 8058550: Clarify that TimerTasks are not reusable
In-Reply-To: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>
References: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>
Message-ID: <541B1D01.4090401@oracle.com>

Hi Martin,

I'm not sure why the @see Timer is deleted.  The added link is useful 
but not a substitute.
Much of the behavior is defined in Timer.

Roger

On 9/18/2014 1:52 PM, Martin Buchholz wrote:
> Hi Chris,
>
> I'd like you to do a code review.
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TimerTask-clarification/
> https://bugs.openjdk.java.net/browse/JDK-8058550



From martinrb at google.com  Thu Sep 18 18:01:02 2014
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 18 Sep 2014 11:01:02 -0700
Subject: RFR: 8058550: Clarify that TimerTasks are not reusable
In-Reply-To: <541B1D01.4090401@oracle.com>
References: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>
	<541B1D01.4090401@oracle.com>
Message-ID: <CA+kOe08yJxSLdMZoj0MzmA+9qoscfu7+z6Xb8MqsZ16OBHgcgA@mail.gmail.com>

@see's are often vestiges of an ancient time before the existence of @link.

On Thu, Sep 18, 2014 at 10:57 AM, roger riggs <roger.riggs at oracle.com>
wrote:

> Hi Martin,
>
> I'm not sure why the @see Timer is deleted.  The added link is useful but
> not a substitute.
> Much of the behavior is defined in Timer.
>
> Roger
>
>
> On 9/18/2014 1:52 PM, Martin Buchholz wrote:
>
>> Hi Chris,
>>
>> I'd like you to do a code review.
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/
>> TimerTask-clarification/
>> https://bugs.openjdk.java.net/browse/JDK-8058550
>>
>
>


From martinrb at google.com  Thu Sep 18 18:03:36 2014
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 18 Sep 2014 11:03:36 -0700
Subject: RFR: 8058550: Clarify that TimerTasks are not reusable
In-Reply-To: <541B1D01.4090401@oracle.com>
References: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>
	<541B1D01.4090401@oracle.com>
Message-ID: <CA+kOe0_y53fbKcdZ0v+s2vY=aY9kUw5r3BLNVSfi1=SHseZcWw@mail.gmail.com>

On Thu, Sep 18, 2014 at 10:57 AM, roger riggs <roger.riggs at oracle.com>
wrote:

> Much of the behavior is defined in Timer.


Agreed.  This change is technically redundant - it's just a clarification.


From Alan.Bateman at oracle.com  Thu Sep 18 18:54:44 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Sep 2014 19:54:44 +0100
Subject: RFR: 8058550: Clarify that TimerTasks are not reusable
In-Reply-To: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>
References: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>
Message-ID: <541B2A74.9030700@oracle.com>

On 18/09/2014 18:52, Martin Buchholz wrote:
> Hi Chris,
>
> I'd like you to do a code review.
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TimerTask-clarification/
> https://bugs.openjdk.java.net/browse/JDK-8058550
This looks okay. If I were wording this then I think I might word in the 
singular, as in "Once a timer task has been scheduled ...  then 
subsequent attempts to schedule it ...".

-Alan.


From Ulf.Zibis at CoSoCo.de  Thu Sep 18 19:29:23 2014
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Thu, 18 Sep 2014 21:29:23 +0200
Subject: RFR: 8058550: Clarify that TimerTasks are not reusable
In-Reply-To: <541B2A74.9030700@oracle.com>
References: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>
	<541B2A74.9030700@oracle.com>
Message-ID: <541B3293.7040709@CoSoCo.de>


Am 18.09.2014 um 20:54 schrieb Alan Bateman:
> On 18/09/2014 18:52, Martin Buchholz wrote:
>> Hi Chris,
>>
>> I'd like you to do a code review.
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TimerTask-clarification/
>> https://bugs.openjdk.java.net/browse/JDK-8058550
> This looks okay. If I were wording this then I think I might word in the singular, as in "Once a 
> timer task has been scheduled ... then subsequent attempts to schedule it ...".

Sounds reasonable. On the other hand, plural indirectly underlines the usual need of multiple timer 
task instances. I let it up to you.     in other respects the wording looks okay to me.

I still like to see the extended explanation for the IllegalStateExeption at Timer.schedule(...), 
even if technically redundant, as one might miss the note at TimerTask.

-Ulf




From chris.hegarty at oracle.com  Thu Sep 18 19:51:18 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 18 Sep 2014 20:51:18 +0100
Subject: RFR: 8058550: Clarify that TimerTasks are not reusable
In-Reply-To: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>
References: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>
Message-ID: <159DE4DC-011B-4D37-B027-8A60EBAC36C4@oracle.com>

This looks fine to me.

-Chris.

On 18 Sep 2014, at 18:52, Martin Buchholz <martinrb at google.com> wrote:

> Hi Chris,
> 
> I'd like you to do a code review.
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/TimerTask-clarification/
> https://bugs.openjdk.java.net/browse/JDK-8058550



From martinrb at google.com  Thu Sep 18 23:22:55 2014
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 18 Sep 2014 16:22:55 -0700
Subject: RFR: 8058550: Clarify that TimerTasks are not reusable
In-Reply-To: <541B2A74.9030700@oracle.com>
References: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>
	<541B2A74.9030700@oracle.com>
Message-ID: <CA+kOe09XxSgeN+3h=46aQjxeq3Gug7GQdJcd8LqACAFNd_htiw@mail.gmail.com>

Alan's suggestion of using the singular is a small improvement.  I'm
committing

 * <p>A timer task is <em>not</em> reusable.  Once a task has been scheduled
 * for execution on a {@code Timer} or cancelled, subsequent attempts to
 * schedule it for execution will throw {@code IllegalStateException}.


On Thu, Sep 18, 2014 at 11:54 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 18/09/2014 18:52, Martin Buchholz wrote:
>
>> Hi Chris,
>>
>> I'd like you to do a code review.
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/
>> TimerTask-clarification/
>> https://bugs.openjdk.java.net/browse/JDK-8058550
>>
> This looks okay. If I were wording this then I think I might word in the
> singular, as in "Once a timer task has been scheduled ...  then subsequent
> attempts to schedule it ...".
>
> -Alan.
>


From peter.levart at gmail.com  Fri Sep 19 06:43:13 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 19 Sep 2014 08:43:13 +0200
Subject: RFR: 8055232 (ref) Exceptions while processing Reference pending list
Message-ID: <541BD081.8050202@gmail.com>

Hi,

This story has a long tail. It started with:

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

Some stress tests triggered OOME in ReferenceHandler thread which would 
die. The first attempt at fixing this was the following discussion:

https://www.mail-archive.com/core-libs-dev%40openjdk.java.net/msg16250.html

Which resulted in patch:

     http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/0b8dab7fec54

This assumed that ReferenceHandler thread doing Object.wait() could be 
interrupted (by stress test - normal application don't do that) and 
failed to allocate InterruptedException object. A jtreg test was 
designed which triggered that situation and a fix would catch OOME and 
ignore it.

But the stress tests (the same or some other, I don't know) apparently 
were not entirely happy with this fix. The following discussion 
describes this:

https://www.mail-archive.com/core-libs-dev%40openjdk.java.net/msg23596.html

The other "unprotected" point at which OOME could be thrown and was 
later confirmed by debugging is (r instanceof Cleaner) test. The 
assumption was that it could trigger Cleaner class loading at 1st 
execution which would cause OOME to be thrown. The fix that finally 
silenced stress tests was the following:

     http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d04102f69d46

This part of code (the j.l.r.Reference class and its members) has 
undergone further changes afterwards for fixing another bug:

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

With following patch:

     http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9934d34ed3c0

But this did not change the code paths - just factored-out the content 
of the loop into a separate method that could be used from outside.

All well until kim.barrett at oracle.com noticed that the 2nd fix 
introduced a potentially illegal situation. There is a 
j.l.r.Reference.Lock inner class and a singleton object assigned to 
static field in j.l.Reference class with the following notice:

     /* Object used to synchronize with the garbage collector.  The 
collector
      * must acquire this lock at the beginning of each collection 
cycle.  It is
      * therefore critical that any code holding this lock complete as 
quickly
      * as possible, allocate no new objects, and avoid calling user code.
      */
     static private class Lock { }
     private static Lock lock = new Lock();

The conflicting part is "allocate no new objects". Catching OOME inside 
a synchronized block holding this lock implies that new objects could be 
allocated. I have a feeling that the 2nd fix prevented that by 
pre-loading the Cleaner class at Reference class initialization time. 
But because it was hard to reproduce the situation where OOME was thrown 
from (r instanceof Cleaner) check, we nevertheless handled this 
hypothetical situation. Perhaps it would be better that we didn't and 
just see if OOME returned after just adding the pre-loading of Cleaner 
class...

So here we are, at an attempt to clean this up:

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

We can move (r instanceof Cleaner) check outside of synchronized block 
to where it was before the 2nd fix and wait what stress tests will show. 
Another possibility is to move the instanceof check outside of 
synchronized block, but handle the hypothetical OOME by re-linking the 
unlinked reference back into the pending chain:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ReferenceHandlerExceptions/webrev.01/

What would you suggest?

Regards, Peter



From david.holmes at oracle.com  Fri Sep 19 07:06:28 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Sep 2014 17:06:28 +1000
Subject: RFR: 8055232 (ref) Exceptions while processing Reference pending
	list
In-Reply-To: <541BD081.8050202@gmail.com>
References: <541BD081.8050202@gmail.com>
Message-ID: <541BD5F4.90606@oracle.com>

Hi Peter,

Two comments:

1. Doing the Object.wait() violates the thou-shalt-not-allocate rule, 
due to the potential for creating the InterruptedException. But there is 
no way to avoid that.

2. I don't see how the instanceof can still result in OOME if we have 
pre-loaded and initialized the relevant classes.

So I'm not sure what it is that needs fixing now ?? Note that if the 
OOME is thrown while holding the lock it means we haven't deadlocked 
with the GC.

David

On 19/09/2014 4:43 PM, Peter Levart wrote:
> Hi,
>
> This story has a long tail. It started with:
>
>      https://bugs.openjdk.java.net/browse/JDK-7038914
>
> Some stress tests triggered OOME in ReferenceHandler thread which would
> die. The first attempt at fixing this was the following discussion:
>
> https://www.mail-archive.com/core-libs-dev%40openjdk.java.net/msg16250.html
>
> Which resulted in patch:
>
>      http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/0b8dab7fec54
>
> This assumed that ReferenceHandler thread doing Object.wait() could be
> interrupted (by stress test - normal application don't do that) and
> failed to allocate InterruptedException object. A jtreg test was
> designed which triggered that situation and a fix would catch OOME and
> ignore it.
>
> But the stress tests (the same or some other, I don't know) apparently
> were not entirely happy with this fix. The following discussion
> describes this:
>
> https://www.mail-archive.com/core-libs-dev%40openjdk.java.net/msg23596.html
>
> The other "unprotected" point at which OOME could be thrown and was
> later confirmed by debugging is (r instanceof Cleaner) test. The
> assumption was that it could trigger Cleaner class loading at 1st
> execution which would cause OOME to be thrown. The fix that finally
> silenced stress tests was the following:
>
>      http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d04102f69d46
>
> This part of code (the j.l.r.Reference class and its members) has
> undergone further changes afterwards for fixing another bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-6857566
>
> With following patch:
>
>      http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9934d34ed3c0
>
> But this did not change the code paths - just factored-out the content
> of the loop into a separate method that could be used from outside.
>
> All well until kim.barrett at oracle.com noticed that the 2nd fix
> introduced a potentially illegal situation. There is a
> j.l.r.Reference.Lock inner class and a singleton object assigned to
> static field in j.l.Reference class with the following notice:
>
>      /* Object used to synchronize with the garbage collector.  The
> collector
>       * must acquire this lock at the beginning of each collection
> cycle.  It is
>       * therefore critical that any code holding this lock complete as
> quickly
>       * as possible, allocate no new objects, and avoid calling user code.
>       */
>      static private class Lock { }
>      private static Lock lock = new Lock();
>
> The conflicting part is "allocate no new objects". Catching OOME inside
> a synchronized block holding this lock implies that new objects could be
> allocated. I have a feeling that the 2nd fix prevented that by
> pre-loading the Cleaner class at Reference class initialization time.
> But because it was hard to reproduce the situation where OOME was thrown
> from (r instanceof Cleaner) check, we nevertheless handled this
> hypothetical situation. Perhaps it would be better that we didn't and
> just see if OOME returned after just adding the pre-loading of Cleaner
> class...
>
> So here we are, at an attempt to clean this up:
>
>      https://bugs.openjdk.java.net/browse/JDK-8055232
>
> We can move (r instanceof Cleaner) check outside of synchronized block
> to where it was before the 2nd fix and wait what stress tests will show.
> Another possibility is to move the instanceof check outside of
> synchronized block, but handle the hypothetical OOME by re-linking the
> unlinked reference back into the pending chain:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ReferenceHandlerExceptions/webrev.01/
>
>
> What would you suggest?
>
> Regards, Peter
>


From peter.levart at gmail.com  Fri Sep 19 07:35:00 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 19 Sep 2014 09:35:00 +0200
Subject: RFR: 8055232 (ref) Exceptions while processing Reference pending
	list
In-Reply-To: <541BD5F4.90606@oracle.com>
References: <541BD081.8050202@gmail.com> <541BD5F4.90606@oracle.com>
Message-ID: <541BDCA4.6090700@gmail.com>

On 09/19/2014 09:06 AM, David Holmes wrote:
> Hi Peter,
>
> Two comments:
>
> 1. Doing the Object.wait() violates the thou-shalt-not-allocate rule, 
> due to the potential for creating the InterruptedException. But there 
> is no way to avoid that.

It depends on when the InterruptedException is allocated. While 
Object.wait()-ing, the lock is not held. If, while waiting, the 
interruption is detected, it could be that InterruptedException is 
allocated before the lock is attempted to be re-gained. This can easily 
be verified - stay tuned...

>
> 2. I don't see how the instanceof can still result in OOME if we have 
> pre-loaded and initialized the relevant classes.

I don't see either. So you're more for a variant that we move instanceof 
check outside the synchronized block to where it was before and wait for 
stress tests to show if we're right? This might be a cleaner way to 
final solution...

>
> So I'm not sure what it is that needs fixing now ?? Note that if the 
> OOME is thrown while holding the lock it means we haven't deadlocked 
> with the GC.

This might be an indication that there's not any allocation taking place 
in instanceof check any more (wait is different, since it's releasing 
lock temporarily). If it was taking place, the stress tests that 
detected OOME before, would detect deadlock now, right?

I understand that this is more of a clean-up attempt than fixing any 
real issue.

Regards, Peter

>
> David
>
> On 19/09/2014 4:43 PM, Peter Levart wrote:
>> Hi,
>>
>> This story has a long tail. It started with:
>>
>>      https://bugs.openjdk.java.net/browse/JDK-7038914
>>
>> Some stress tests triggered OOME in ReferenceHandler thread which would
>> die. The first attempt at fixing this was the following discussion:
>>
>> https://www.mail-archive.com/core-libs-dev%40openjdk.java.net/msg16250.html 
>>
>>
>> Which resulted in patch:
>>
>>      http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/0b8dab7fec54
>>
>> This assumed that ReferenceHandler thread doing Object.wait() could be
>> interrupted (by stress test - normal application don't do that) and
>> failed to allocate InterruptedException object. A jtreg test was
>> designed which triggered that situation and a fix would catch OOME and
>> ignore it.
>>
>> But the stress tests (the same or some other, I don't know) apparently
>> were not entirely happy with this fix. The following discussion
>> describes this:
>>
>> https://www.mail-archive.com/core-libs-dev%40openjdk.java.net/msg23596.html 
>>
>>
>> The other "unprotected" point at which OOME could be thrown and was
>> later confirmed by debugging is (r instanceof Cleaner) test. The
>> assumption was that it could trigger Cleaner class loading at 1st
>> execution which would cause OOME to be thrown. The fix that finally
>> silenced stress tests was the following:
>>
>>      http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d04102f69d46
>>
>> This part of code (the j.l.r.Reference class and its members) has
>> undergone further changes afterwards for fixing another bug:
>>
>>      https://bugs.openjdk.java.net/browse/JDK-6857566
>>
>> With following patch:
>>
>>      http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9934d34ed3c0
>>
>> But this did not change the code paths - just factored-out the content
>> of the loop into a separate method that could be used from outside.
>>
>> All well until kim.barrett at oracle.com noticed that the 2nd fix
>> introduced a potentially illegal situation. There is a
>> j.l.r.Reference.Lock inner class and a singleton object assigned to
>> static field in j.l.Reference class with the following notice:
>>
>>      /* Object used to synchronize with the garbage collector. The
>> collector
>>       * must acquire this lock at the beginning of each collection
>> cycle.  It is
>>       * therefore critical that any code holding this lock complete as
>> quickly
>>       * as possible, allocate no new objects, and avoid calling user 
>> code.
>>       */
>>      static private class Lock { }
>>      private static Lock lock = new Lock();
>>
>> The conflicting part is "allocate no new objects". Catching OOME inside
>> a synchronized block holding this lock implies that new objects could be
>> allocated. I have a feeling that the 2nd fix prevented that by
>> pre-loading the Cleaner class at Reference class initialization time.
>> But because it was hard to reproduce the situation where OOME was thrown
>> from (r instanceof Cleaner) check, we nevertheless handled this
>> hypothetical situation. Perhaps it would be better that we didn't and
>> just see if OOME returned after just adding the pre-loading of Cleaner
>> class...
>>
>> So here we are, at an attempt to clean this up:
>>
>>      https://bugs.openjdk.java.net/browse/JDK-8055232
>>
>> We can move (r instanceof Cleaner) check outside of synchronized block
>> to where it was before the 2nd fix and wait what stress tests will show.
>> Another possibility is to move the instanceof check outside of
>> synchronized block, but handle the hypothetical OOME by re-linking the
>> unlinked reference back into the pending chain:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ReferenceHandlerExceptions/webrev.01/ 
>>
>>
>>
>> What would you suggest?
>>
>> Regards, Peter
>>



From david.holmes at oracle.com  Fri Sep 19 07:45:22 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 19 Sep 2014 17:45:22 +1000
Subject: RFR: 8055232 (ref) Exceptions while processing Reference pending
	list
In-Reply-To: <541BDCA4.6090700@gmail.com>
References: <541BD081.8050202@gmail.com> <541BD5F4.90606@oracle.com>
	<541BDCA4.6090700@gmail.com>
Message-ID: <541BDF12.20002@oracle.com>

On 19/09/2014 5:35 PM, Peter Levart wrote:
> On 09/19/2014 09:06 AM, David Holmes wrote:
>> Hi Peter,
>>
>> Two comments:
>>
>> 1. Doing the Object.wait() violates the thou-shalt-not-allocate rule,
>> due to the potential for creating the InterruptedException. But there
>> is no way to avoid that.
>
> It depends on when the InterruptedException is allocated. While
> Object.wait()-ing, the lock is not held. If, while waiting, the
> interruption is detected, it could be that InterruptedException is
> allocated before the lock is attempted to be re-gained. This can easily
> be verified - stay tuned...

Allocation happens after the monitor is re-acquired.

>>
>> 2. I don't see how the instanceof can still result in OOME if we have
>> pre-loaded and initialized the relevant classes.
>
> I don't see either. So you're more for a variant that we move instanceof
> check outside the synchronized block to where it was before and wait for
> stress tests to show if we're right? This might be a cleaner way to
> final solution...

I think I see what you are saying now ...

>>
>> So I'm not sure what it is that needs fixing now ?? Note that if the
>> OOME is thrown while holding the lock it means we haven't deadlocked
>> with the GC.
>
> This might be an indication that there's not any allocation taking place
> in instanceof check any more (wait is different, since it's releasing
> lock temporarily). If it was taking place, the stress tests that
> detected OOME before, would detect deadlock now, right?

There's only a potential for deadlock, it isn't inevitable. You'd need 
to see when the GC needs to acquire this lock.

> I understand that this is more of a clean-up attempt than fixing any
> real issue.

I'm inclined to take the "if it ain't broke ..." position on this. But I 
do see your point.

Cheers,
David

> Regards, Peter
>
>>
>> David
>>
>> On 19/09/2014 4:43 PM, Peter Levart wrote:
>>> Hi,
>>>
>>> This story has a long tail. It started with:
>>>
>>>      https://bugs.openjdk.java.net/browse/JDK-7038914
>>>
>>> Some stress tests triggered OOME in ReferenceHandler thread which would
>>> die. The first attempt at fixing this was the following discussion:
>>>
>>> https://www.mail-archive.com/core-libs-dev%40openjdk.java.net/msg16250.html
>>>
>>>
>>> Which resulted in patch:
>>>
>>>      http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/0b8dab7fec54
>>>
>>> This assumed that ReferenceHandler thread doing Object.wait() could be
>>> interrupted (by stress test - normal application don't do that) and
>>> failed to allocate InterruptedException object. A jtreg test was
>>> designed which triggered that situation and a fix would catch OOME and
>>> ignore it.
>>>
>>> But the stress tests (the same or some other, I don't know) apparently
>>> were not entirely happy with this fix. The following discussion
>>> describes this:
>>>
>>> https://www.mail-archive.com/core-libs-dev%40openjdk.java.net/msg23596.html
>>>
>>>
>>> The other "unprotected" point at which OOME could be thrown and was
>>> later confirmed by debugging is (r instanceof Cleaner) test. The
>>> assumption was that it could trigger Cleaner class loading at 1st
>>> execution which would cause OOME to be thrown. The fix that finally
>>> silenced stress tests was the following:
>>>
>>>      http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d04102f69d46
>>>
>>> This part of code (the j.l.r.Reference class and its members) has
>>> undergone further changes afterwards for fixing another bug:
>>>
>>>      https://bugs.openjdk.java.net/browse/JDK-6857566
>>>
>>> With following patch:
>>>
>>>      http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9934d34ed3c0
>>>
>>> But this did not change the code paths - just factored-out the content
>>> of the loop into a separate method that could be used from outside.
>>>
>>> All well until kim.barrett at oracle.com noticed that the 2nd fix
>>> introduced a potentially illegal situation. There is a
>>> j.l.r.Reference.Lock inner class and a singleton object assigned to
>>> static field in j.l.Reference class with the following notice:
>>>
>>>      /* Object used to synchronize with the garbage collector. The
>>> collector
>>>       * must acquire this lock at the beginning of each collection
>>> cycle.  It is
>>>       * therefore critical that any code holding this lock complete as
>>> quickly
>>>       * as possible, allocate no new objects, and avoid calling user
>>> code.
>>>       */
>>>      static private class Lock { }
>>>      private static Lock lock = new Lock();
>>>
>>> The conflicting part is "allocate no new objects". Catching OOME inside
>>> a synchronized block holding this lock implies that new objects could be
>>> allocated. I have a feeling that the 2nd fix prevented that by
>>> pre-loading the Cleaner class at Reference class initialization time.
>>> But because it was hard to reproduce the situation where OOME was thrown
>>> from (r instanceof Cleaner) check, we nevertheless handled this
>>> hypothetical situation. Perhaps it would be better that we didn't and
>>> just see if OOME returned after just adding the pre-loading of Cleaner
>>> class...
>>>
>>> So here we are, at an attempt to clean this up:
>>>
>>>      https://bugs.openjdk.java.net/browse/JDK-8055232
>>>
>>> We can move (r instanceof Cleaner) check outside of synchronized block
>>> to where it was before the 2nd fix and wait what stress tests will show.
>>> Another possibility is to move the instanceof check outside of
>>> synchronized block, but handle the hypothetical OOME by re-linking the
>>> unlinked reference back into the pending chain:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ReferenceHandlerExceptions/webrev.01/
>>>
>>>
>>>
>>> What would you suggest?
>>>
>>> Regards, Peter
>>>
>


From peter.levart at gmail.com  Fri Sep 19 08:28:51 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 19 Sep 2014 10:28:51 +0200
Subject: RFR: 8055232 (ref) Exceptions while processing Reference pending
	list
In-Reply-To: <541BDF12.20002@oracle.com>
References: <541BD081.8050202@gmail.com> <541BD5F4.90606@oracle.com>
	<541BDCA4.6090700@gmail.com> <541BDF12.20002@oracle.com>
Message-ID: <541BE943.2050909@gmail.com>

On 09/19/2014 09:45 AM, David Holmes wrote:
> On 19/09/2014 5:35 PM, Peter Levart wrote:
>> On 09/19/2014 09:06 AM, David Holmes wrote:
>>> Hi Peter,
>>>
>>> Two comments:
>>>
>>> 1. Doing the Object.wait() violates the thou-shalt-not-allocate rule,
>>> due to the potential for creating the InterruptedException. But there
>>> is no way to avoid that.
>>
>> It depends on when the InterruptedException is allocated. While
>> Object.wait()-ing, the lock is not held. If, while waiting, the
>> interruption is detected, it could be that InterruptedException is
>> allocated before the lock is attempted to be re-gained. This can easily
>> be verified - stay tuned...
>
> Allocation happens after the monitor is re-acquired.

You're right. I have verified this with a simple test (a modified 
InterruptedException class). But this means that interrupting 
ReferenceHandler thread is already a violation of 
thou-shalt-not-allocate rule.

Do you think that a re-design of VM <-> Java interface is warranted?

Now that we have Unsafe, we could handle a queue of 'pending' references 
using CAS. There is a single blocking consumer of that queue - a 
ReferenceHandler thread. Other consumers (calling tryHandlePending() 
from nio.Bits) are non-blocking, just polling the queue. So there could 
be a single static:

private static ReferenceHandler waiter;

field in Reference class, holding the reference to ReferenceHandler 
thread while it is Unsafe.park()-ed - no allocation necessary. The VM 
could just unpark the waiter after CAS-ing new references on the pending 
list...

But that's another issue. We're now asking ourselves if "instanceof" 
call is in need of a clean-up, not wait().

Regards, Peter


>
>>>
>>> 2. I don't see how the instanceof can still result in OOME if we have
>>> pre-loaded and initialized the relevant classes.
>>
>> I don't see either. So you're more for a variant that we move instanceof
>> check outside the synchronized block to where it was before and wait for
>> stress tests to show if we're right? This might be a cleaner way to
>> final solution...
>
> I think I see what you are saying now ...
>
>>>
>>> So I'm not sure what it is that needs fixing now ?? Note that if the
>>> OOME is thrown while holding the lock it means we haven't deadlocked
>>> with the GC.
>>
>> This might be an indication that there's not any allocation taking place
>> in instanceof check any more (wait is different, since it's releasing
>> lock temporarily). If it was taking place, the stress tests that
>> detected OOME before, would detect deadlock now, right?
>
> There's only a potential for deadlock, it isn't inevitable. You'd need 
> to see when the GC needs to acquire this lock.
>
>> I understand that this is more of a clean-up attempt than fixing any
>> real issue.
>
> I'm inclined to take the "if it ain't broke ..." position on this. But 
> I do see your point.
>
> Cheers,
> David
>
>> Regards, Peter
>>
>>>
>>> David
>>>
>>> On 19/09/2014 4:43 PM, Peter Levart wrote:
>>>> Hi,
>>>>
>>>> This story has a long tail. It started with:
>>>>
>>>>      https://bugs.openjdk.java.net/browse/JDK-7038914
>>>>
>>>> Some stress tests triggered OOME in ReferenceHandler thread which 
>>>> would
>>>> die. The first attempt at fixing this was the following discussion:
>>>>
>>>> https://www.mail-archive.com/core-libs-dev%40openjdk.java.net/msg16250.html 
>>>>
>>>>
>>>>
>>>> Which resulted in patch:
>>>>
>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/0b8dab7fec54
>>>>
>>>> This assumed that ReferenceHandler thread doing Object.wait() could be
>>>> interrupted (by stress test - normal application don't do that) and
>>>> failed to allocate InterruptedException object. A jtreg test was
>>>> designed which triggered that situation and a fix would catch OOME and
>>>> ignore it.
>>>>
>>>> But the stress tests (the same or some other, I don't know) apparently
>>>> were not entirely happy with this fix. The following discussion
>>>> describes this:
>>>>
>>>> https://www.mail-archive.com/core-libs-dev%40openjdk.java.net/msg23596.html 
>>>>
>>>>
>>>>
>>>> The other "unprotected" point at which OOME could be thrown and was
>>>> later confirmed by debugging is (r instanceof Cleaner) test. The
>>>> assumption was that it could trigger Cleaner class loading at 1st
>>>> execution which would cause OOME to be thrown. The fix that finally
>>>> silenced stress tests was the following:
>>>>
>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d04102f69d46
>>>>
>>>> This part of code (the j.l.r.Reference class and its members) has
>>>> undergone further changes afterwards for fixing another bug:
>>>>
>>>>      https://bugs.openjdk.java.net/browse/JDK-6857566
>>>>
>>>> With following patch:
>>>>
>>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9934d34ed3c0
>>>>
>>>> But this did not change the code paths - just factored-out the content
>>>> of the loop into a separate method that could be used from outside.
>>>>
>>>> All well until kim.barrett at oracle.com noticed that the 2nd fix
>>>> introduced a potentially illegal situation. There is a
>>>> j.l.r.Reference.Lock inner class and a singleton object assigned to
>>>> static field in j.l.Reference class with the following notice:
>>>>
>>>>      /* Object used to synchronize with the garbage collector. The
>>>> collector
>>>>       * must acquire this lock at the beginning of each collection
>>>> cycle.  It is
>>>>       * therefore critical that any code holding this lock complete as
>>>> quickly
>>>>       * as possible, allocate no new objects, and avoid calling user
>>>> code.
>>>>       */
>>>>      static private class Lock { }
>>>>      private static Lock lock = new Lock();
>>>>
>>>> The conflicting part is "allocate no new objects". Catching OOME 
>>>> inside
>>>> a synchronized block holding this lock implies that new objects 
>>>> could be
>>>> allocated. I have a feeling that the 2nd fix prevented that by
>>>> pre-loading the Cleaner class at Reference class initialization time.
>>>> But because it was hard to reproduce the situation where OOME was 
>>>> thrown
>>>> from (r instanceof Cleaner) check, we nevertheless handled this
>>>> hypothetical situation. Perhaps it would be better that we didn't and
>>>> just see if OOME returned after just adding the pre-loading of Cleaner
>>>> class...
>>>>
>>>> So here we are, at an attempt to clean this up:
>>>>
>>>>      https://bugs.openjdk.java.net/browse/JDK-8055232
>>>>
>>>> We can move (r instanceof Cleaner) check outside of synchronized block
>>>> to where it was before the 2nd fix and wait what stress tests will 
>>>> show.
>>>> Another possibility is to move the instanceof check outside of
>>>> synchronized block, but handle the hypothetical OOME by re-linking the
>>>> unlinked reference back into the pending chain:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ReferenceHandlerExceptions/webrev.01/ 
>>>>
>>>>
>>>>
>>>>
>>>> What would you suggest?
>>>>
>>>> Regards, Peter
>>>>
>>



From chris.hegarty at oracle.com  Fri Sep 19 09:14:23 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 19 Sep 2014 10:14:23 +0100
Subject: RFR: 8058550: Clarify that TimerTasks are not reusable
In-Reply-To: <CA+kOe09XxSgeN+3h=46aQjxeq3Gug7GQdJcd8LqACAFNd_htiw@mail.gmail.com>
References: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>	<541B2A74.9030700@oracle.com>
	<CA+kOe09XxSgeN+3h=46aQjxeq3Gug7GQdJcd8LqACAFNd_htiw@mail.gmail.com>
Message-ID: <541BF3EF.4000503@oracle.com>

Thank you Martin and Alan. This does indeed look better.

Since this is a small specification clarification, of existing behavior, 
then a CCC should be filed so it is included in the next Java SE 
maintenance review, gets JCK attention, etc. I will do this.

-Chris.

On 19/09/14 00:22, Martin Buchholz wrote:
> Alan's suggestion of using the singular is a small improvement.  I'm
> committing
>
>   * <p>A timer task is <em>not</em> reusable.  Once a task has been scheduled
>   * for execution on a {@code Timer} or cancelled, subsequent attempts to
>   * schedule it for execution will throw {@code IllegalStateException}.
>
>
> On Thu, Sep 18, 2014 at 11:54 AM, Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 18/09/2014 18:52, Martin Buchholz wrote:
>>
>>> Hi Chris,
>>>
>>> I'd like you to do a code review.
>>>
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/
>>> TimerTask-clarification/
>>> https://bugs.openjdk.java.net/browse/JDK-8058550
>>>
>> This looks okay. If I were wording this then I think I might word in the
>> singular, as in "Once a timer task has been scheduled ...  then subsequent
>> attempts to schedule it ...".
>>
>> -Alan.
>>


From Alan.Bateman at oracle.com  Fri Sep 19 09:21:18 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Sep 2014 10:21:18 +0100
Subject: RFR: 8058550: Clarify that TimerTasks are not reusable
In-Reply-To: <541BF3EF.4000503@oracle.com>
References: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>	<541B2A74.9030700@oracle.com>
	<CA+kOe09XxSgeN+3h=46aQjxeq3Gug7GQdJcd8LqACAFNd_htiw@mail.gmail.com>
	<541BF3EF.4000503@oracle.com>
Message-ID: <541BF58E.80806@oracle.com>

On 19/09/2014 10:14, Chris Hegarty wrote:
> Thank you Martin and Alan. This does indeed look better.
>
> Since this is a small specification clarification, of existing 
> behavior, then a CCC should be filed so it is included in the next 
> Java SE maintenance review, gets JCK attention, etc. I will do this.
It's just repeating the assertions that are already in the javadoc of 
schedule methods. The only new wording is just the statement that timer 
tasks aren't resuable but that is implied anyway.

-Alan.


From chris.hegarty at oracle.com  Fri Sep 19 09:34:38 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 19 Sep 2014 10:34:38 +0100
Subject: RFR: 8058550: Clarify that TimerTasks are not reusable
In-Reply-To: <541BF58E.80806@oracle.com>
References: <CA+kOe080V2Eks7PcmJATBYcZO-LrFh-2bsLJuY4uD7dERRxCYg@mail.gmail.com>	<541B2A74.9030700@oracle.com>
	<CA+kOe09XxSgeN+3h=46aQjxeq3Gug7GQdJcd8LqACAFNd_htiw@mail.gmail.com>
	<541BF3EF.4000503@oracle.com> <541BF58E.80806@oracle.com>
Message-ID: <541BF8AE.7010603@oracle.com>

On 19/09/14 10:21, Alan Bateman wrote:
> On 19/09/2014 10:14, Chris Hegarty wrote:
>> Thank you Martin and Alan. This does indeed look better.
>>
>> Since this is a small specification clarification, of existing
>> behavior, then a CCC should be filed so it is included in the next
>> Java SE maintenance review, gets JCK attention, etc. I will do this.
> It's just repeating the assertions that are already in the javadoc of
> schedule methods. The only new wording is just the statement that timer
> tasks aren't resuable but that is implied anyway.

OK, got it. No CCC is required since this is already implied.

 From Timer.schedule(...)

    "IllegalStateException - if task was already scheduled or cancelled,
     timer was cancelled, or timer thread terminated."

-Chris.


From konstantin.shefov at oracle.com  Fri Sep 19 09:50:24 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 19 Sep 2014 13:50:24 +0400
Subject: [9] Review request : JDK-8058728: TEST_BUG: Make
	java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
	skip arrayElementSetter and arrayElementGetter methods
Message-ID: <541BFC60.4050503@oracle.com>

Hello,

Please review the test bug fix 
https://bugs.openjdk.java.net/browse/JDK-8058728
Webrev is http://cr.openjdk.java.net/~kshefov/8058728/webrev.00

Thanks

-Konstantin


From vladimir.x.ivanov at oracle.com  Fri Sep 19 09:54:01 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Fri, 19 Sep 2014 13:54:01 +0400
Subject: [9] Review request : JDK-8058728: TEST_BUG: Make
	java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
	skip arrayElementSetter and arrayElementGetter methods
In-Reply-To: <541BFC60.4050503@oracle.com>
References: <541BFC60.4050503@oracle.com>
Message-ID: <541BFD39.6050805@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 9/19/14, 1:50 PM, Konstantin Shefov wrote:
> Hello,
>
> Please review the test bug fix
> https://bugs.openjdk.java.net/browse/JDK-8058728
> Webrev is http://cr.openjdk.java.net/~kshefov/8058728/webrev.00
>
> Thanks
>
> -Konstantin


From paul.sandoz at oracle.com  Fri Sep 19 10:08:26 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 19 Sep 2014 12:08:26 +0200
Subject: [9] Review request : JDK-8058728: TEST_BUG: Make
	java/lang/invoke/LFCaching/LFGarbageCollectedTest.java skip
	arrayElementSetter and arrayElementGetter methods
In-Reply-To: <541BFD39.6050805@oracle.com>
References: <541BFC60.4050503@oracle.com> <541BFD39.6050805@oracle.com>
Message-ID: <6AD56BBC-A73A-4AC5-91A8-0B0276C5C725@oracle.com>

On Sep 19, 2014, at 11:54 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> Looks good.
> 

Small typo in the comment:

  s/filed/field

Otherwise +1,
Paul.

> Best regards,
> Vladimir Ivanov
> 
> On 9/19/14, 1:50 PM, Konstantin Shefov wrote:
>> Hello,
>> 
>> Please review the test bug fix
>> https://bugs.openjdk.java.net/browse/JDK-8058728
>> Webrev is http://cr.openjdk.java.net/~kshefov/8058728/webrev.00
>> 
>> Thanks
>> 
>> -Konstantin
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From olivier.lagneau at oracle.com  Fri Sep 19 10:31:18 2014
From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com)
Date: Fri, 19 Sep 2014 12:31:18 +0200
Subject: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not
	consider required no. of fraction digits properly
In-Reply-To: <5411C8C9.8000400@oracle.com>
References: <540F66B4.1080400@oracle.com> <5411C8C9.8000400@oracle.com>
Message-ID: <541C05F6.80709@oracle.com>

Hi,

This is a code change we would like to integrate in next release of 
JDK8, since impacting some customer apps/deployments.
So it would be good to have it reviewed and backported to 8 soon.

Is there anyone having a bit of free time to review it ?

Best Regards,
Olivier Lagneau


On 11/09/2014 18:07, olivier.lagneau at oracle.com wrote:
> Could someone please review this code change ?
>
> Thanks in advance,
> Olivier Lagneau
>
> On 09/09/2014 22:44, olivier.lagneau at oracle.com wrote:
>> Please review this fix in for wrong rounding-mode mode behavior of 
>> NumberFormat.format(double) in HALF_UP case.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8039915
>>
>> webrev: http://cr.openjdk.java.net/~olagneau/8039915/webrev.00 
>> <http://cr.openjdk.java.net/%7Eolagneau/8039915/webrev.00>
>>
>> Bug came from a mix of a '5' and 'greater than 5' last digit, when 
>> this digit was the last one.
>>
>> Fix consists in properly separating the two cases and cleanly test 
>> all possible cases (see JDK-8039915 comments) for the HALF_UP 
>> rounding-mode.
>>
>> TieRoundingTest test has been extended with a few cases to check such 
>> cases (last digit at the rounding position and != '5')
>>
>> testing: jtreg, jck8, jprt
>>
>> Best regards,
>> Olivier Lagneau
>>
>



From igor.ignatyev at oracle.com  Fri Sep 19 12:01:43 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 19 Sep 2014 16:01:43 +0400
Subject: [9] Review request : JDK-8058728: TEST_BUG: Make
	java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
	skip arrayElementSetter and arrayElementGetter methods
In-Reply-To: <541BFC60.4050503@oracle.com>
References: <541BFC60.4050503@oracle.com>
Message-ID: <541C1B27.1060402@oracle.com>

Hi,

looks good to me.

how have you tested your changes?

Thanks,
Igor

On 09/19/2014 01:50 PM, Konstantin Shefov wrote:
> Hello,
>
> Please review the test bug fix
> https://bugs.openjdk.java.net/browse/JDK-8058728
> Webrev is http://cr.openjdk.java.net/~kshefov/8058728/webrev.00
>
> Thanks
>
> -Konstantin


From konstantin.shefov at oracle.com  Fri Sep 19 12:04:19 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Fri, 19 Sep 2014 16:04:19 +0400
Subject: [9] Review request : JDK-8058728: TEST_BUG: Make
	java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
	skip arrayElementSetter and arrayElementGetter methods
In-Reply-To: <541C1B27.1060402@oracle.com>
References: <541BFC60.4050503@oracle.com> <541C1B27.1060402@oracle.com>
Message-ID: <541C1BC3.8020105@oracle.com>

Yes, the test compiles and runs ok, but fails because of 8057020.
If we remove -Djava.lang.invoke.MethodHandle.USE_LF_EDITOR=true, the 
test passes.

-Konstantin

On 19.09.2014 16:01, Igor Ignatyev wrote:
> Hi,
>
> looks good to me.
>
> how have you tested your changes?
>
> Thanks,
> Igor
>
> On 09/19/2014 01:50 PM, Konstantin Shefov wrote:
>> Hello,
>>
>> Please review the test bug fix
>> https://bugs.openjdk.java.net/browse/JDK-8058728
>> Webrev is http://cr.openjdk.java.net/~kshefov/8058728/webrev.00
>>
>> Thanks
>>
>> -Konstantin



From igor.ignatyev at oracle.com  Fri Sep 19 12:53:56 2014
From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=)
Date: Fri, 19 Sep 2014 16:53:56 +0400
Subject: =?utf-8?B?UmU6IFs5XSBSZXZpZXcgcmVxdWVzdCA6IEpESy04MDU4NzI4OiBURVNUX0JVRzog?=
	=?utf-8?B?TWFrZSBqYXZhL2xhbmcvaW52b2tlL0xGQ2FjaGluZy9MRkdhcmJhZ2VDb2xsZWN0?=
	=?utf-8?B?ZWRUZXN0LmphdmEgc2tpcCBhcnJheUVsZW1lbnRTZXR0ZXIgYW5kIGFycmF5RWxl?=
	=?utf-8?B?bWVudEdldHRlciBtZXRob2Rz?=
Message-ID: <201409191253.s8JCrvuh005864@aserz7021.oracle.com>

thx. Reviewed.

-- II

----- Reply message -----
From: "Konstantin Shefov" <konstantin.shefov at oracle.com>
To: "Igor Ignatyev" <igor.ignatyev at oracle.com>
Cc: "VLADIMIR.X.IVANOV" <vladimir.x.ivanov at oracle.com>, <core-libs-dev at openjdk.java.net>, <mlvm-dev at openjdk.java.net>
Subject: [9] Review request : JDK-8058728: TEST_BUG: Make java/lang/invoke/LFCaching/LFGarbageCollectedTest.java skip arrayElementSetter and arrayElementGetter methods
Date: Fri, Sep 19, 2014 16:04

Yes, the test compiles and runs ok, but fails because of 8057020.
If we remove -Djava.lang.invoke.MethodHandle.USE_LF_EDITOR=true, the 
test passes.

-Konstantin

On 19.09.2014 16:01, Igor Ignatyev wrote:
> Hi,
>
> looks good to me.
>
> how have you tested your changes?
>
> Thanks,
> Igor
>
> On 09/19/2014 01:50 PM, Konstantin Shefov wrote:
>> Hello,
>>
>> Please review the test bug fix
>> https://bugs.openjdk.java.net/browse/JDK-8058728
>> Webrev is http://cr.openjdk.java.net/~kshefov/8058728/webrev.00
>>
>> Thanks
>>
>> -Konstantin

From markt at apache.org  Fri Sep 19 13:12:50 2014
From: markt at apache.org (Mark Thomas)
Date: Fri, 19 Sep 2014 14:12:50 +0100
Subject: Use of internal APIs to protect against memory leaks
Message-ID: <541C2BD2.7060704@apache.org>

All,

As you may know I am one of the Apache Tomcat committers. The Tomcat
project was approached recently[1] to see what, if any, internal APIs
Tomcat was using as part of the JDK 9 preparations.

My response was that the only place Tomcat does this is in the memory
leak prevention class [2]. I also commented that if the memory leaks
could be addressed then we'd have no need to us the internal API. The
response from Oracle was a suggestion to bring up these memory leaks on
this list.

The memory leaks stem from the generally more complex class loader
structure present in a JavaEE container than is typically present in a
standalone Java app.

At this point, I have two questions.

1. Is this community interested in examining these memory leaks further
to see what can be done in the JDK to avoid them?

2. If yes, would you prefer a discussion thread for each leak or one
thread for all leaks? Personally, I think a thread per leak would be
easier to manage but it might make sense just to look at one leak first
as there may well be some common themes that emerge which would save us
discussing them on each thread.

Mark

[1] http://tomcat.markmail.org/thread/n3n6arf3j7f27zhb

[2]
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/JreMemoryLeakPreventionListener.java?view=annotate


From sean.coffey at oracle.com  Fri Sep 19 15:42:49 2014
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Fri, 19 Sep 2014 16:42:49 +0100
Subject: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for
	Web services
In-Reply-To: <541AF898.6060400@oracle.com>
References: <541985F4.6010202@oracle.com> <541997D1.8040602@oracle.com>
	<541AA202.10203@oracle.com> <541AAAC7.8030806@oracle.com>
	<541AC223.6080003@oracle.com> <541AC9A0.1090900@oracle.com>
	<541AF898.6060400@oracle.com>
Message-ID: <541C4EF9.8070806@oracle.com>

Miran,

thanks for the update. Seems like you're working from an old JDK 9 
forest. The webrev is
using the pre-modular path layout. I've converted them. I'm am seeing 
the new test fail
on windows though. Will share the details with you offline.

regards,
Sean.

On 18/09/14 16:22, Miroslav Kos wrote:
> Ok then, the webrev updated:
> http://cr.openjdk.java.net/~mkos/8038966/jdk.03/
> http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
>
> btw. I had to tweak the path - using simply Paths.get("org") we get
>     JTwork/scratch/org
> but needed path is
>     JTwork/classes/javax/xml/ws/xsanymixed/org
> (classes instead of scratch + test path as prefix), so I changed the 
> code to
>         Path p = Paths.get("..", "classes", "javax", "xml", "ws", 
> "xsanymixed", "org");
>
> Thanks
> Miran
>
>
> On 18/09/14 14:01, Se?n Coffey wrote:
>> jtreg should remove the work/scratch directory upon test completion 
>> but it's best practice to attempt to clean up generated files. No 
>> harm there I think. Also needed in cases where test might be run 
>> manually. I'd suggest keeping the clean up code in the testcase.
>>
>> regards,
>> Sean.
>>
>> On 18/09/2014 12:29, Miroslav Kos wrote:
>>> Oops, I missed that, thanks. One question yet - does it make sense 
>>> any more to clean generated files now, when the location was 
>>> changed? I think clean up should be done automatically by jtreg now, 
>>> shouldn't it? If you agree, I would delete the method instead.
>>>
>>> Thanks
>>> Miran
>>>
>>> On 18/09/14 11:49, Se?n Coffey wrote:
>>>>
>>>> On 18/09/2014 10:12, Miroslav Kos wrote:
>>>>> Thanks, Sean, good catch ...
>>>>>
>>>>> I changed the destination for generated files:
>>>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.02/
>>>>>
>>>>> Regarding usage ProcessBuilder instead of shell script - the 
>>>>> problem is, that to compile test classes, wsdl must be compiled 
>>>>> first - shell script is setup required before javac. The test 
>>>>> would have to be run in two phases - first compiling+running java 
>>>>> classes that compile wsdl (ProcessBuilder) and after that 
>>>>> compiling other java classes using result of previous run.
>>>>>
>>>>> I was solving this with jtreg some time ago already, but I haven't 
>>>>> found other way than using shell script. If you know better 
>>>>> solution, it would be great ...
>>>> Ah - I see the dependency now. Thanks for the information.
>>>>
>>>> Just spotted one other issue. The deleteGeneratedFiles() method 
>>>> scans for files in the
>>>> test src path (for deletion) - No files should be created there 
>>>> now. You can change that
>>>> to scan the test classes path now. You could just use the current 
>>>> working directory I guess
>>>> since that's where jtreg will generate the new files.
>>>>
>>>> Paths.get("org");
>>>>
>>>> once that's fixed up, I can run this through JPRT and it should be 
>>>> good to push then.
>>>>
>>>> regards,
>>>> Sean.
>>>>
>>>>>
>>>>> Thanks
>>>>> Miran
>>>>>
>>>>>
>>>>>
>>>>> On 17/09/14 16:16, Se?n Coffey wrote:
>>>>>> Miran,
>>>>>>
>>>>>> the src change looks ok but I think there's a problem with the 
>>>>>> testcase.
>>>>>>
>>>>>> You've defined generated classes for wsimport to be output to the 
>>>>>> TESTSRC
>>>>>> directory. This is often read only and won't work.
>>>>>>
>>>>>> TESTCLASSES is the variable you're probably looking for. In any 
>>>>>> case, I think
>>>>>> it's possible for you to avoid use of scripting. Can you invoke 
>>>>>> wsimport via
>>>>>> the ProcessBuilder API like that done for other wsimport tests ?
>>>>>>
>>>>>> regards,
>>>>>> Sean.
>>>>>>
>>>>>> On 17/09/14 14:00, Miroslav Kos wrote:
>>>>>>> Hi everybody,
>>>>>>>
>>>>>>> please review patch fixing following issue:
>>>>>>>
>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
>>>>>>> webrev:
>>>>>>> http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
>>>>>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.01/
>>>>>>>
>>>>>>> It is second part of fix ensuring that content of type 
>>>>>>> xsd:any/content=mixed stays unchanged when processed with JAX-B 
>>>>>>> RI. Regression test within webrev.
>>>>>>>
>>>>>>> Sean, could you sponsor it for me?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Miran
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From Alan.Bateman at oracle.com  Fri Sep 19 16:19:58 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Sep 2014 17:19:58 +0100
Subject: Use of internal APIs to protect against memory leaks
In-Reply-To: <541C2BD2.7060704@apache.org>
References: <541C2BD2.7060704@apache.org>
Message-ID: <541C57AE.6070600@oracle.com>

On 19/09/2014 14:12, Mark Thomas wrote:
> :
>
> The memory leaks stem from the generally more complex class loader
> structure present in a JavaEE container than is typically present in a
> standalone Java app.
>
> At this point, I have two questions.
>
> 1. Is this community interested in examining these memory leaks further
> to see what can be done in the JDK to avoid them?
>
> 2. If yes, would you prefer a discussion thread for each leak or one
> thread for all leaks? Personally, I think a thread per leak would be
> easier to manage but it might make sense just to look at one leak first
> as there may well be some common themes that emerge which would save us
> discussing them on each thread.
>
>
I agree with with your suggestion that a discussion per so-called leak 
would be better than trying to discuss all of this in one thread. The 
hard bit will be finding the right list to start the discussion. For the 
AWT issues then awt-dev is the place to start. For the 2D disposer issue 
then 2d-dev is the place to start. The security-dev list is the place 
for the security library issues. The net-dev list for the URLConnection  
issue. I think core-libs-dev is probably okay for the rest.

Just to set expectations, it's possible that the outcome of some of 
these will be just a bug in the JIRA. In some cases then I expect you 
might get a bit of push back as there are performance and compatibility 
issues to take account.  As an example, the system-wide/singleton ORB 
returned by ORB.init should never be located via the TCCL. However 
switching this to using the system class loader breaks a number of 3rd 
party ORBs that freely cast between per-application ORBs of whatever ORB 
is bundled with the application and the system-wide ORB that acts as the 
type code factory. However in general then having the JDK cache anything 
that is located via the TCCL is a bug and I think you will get support 
for poking at those issues.

-Alan


From john.r.rose at oracle.com  Fri Sep 19 17:05:55 2014
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 19 Sep 2014 10:05:55 -0700
Subject: [8u40] RFR (S): Missing part of 8057656 in 8u40 compared to 9
In-Reply-To: <54196BCD.7020609@oracle.com>
References: <54196BCD.7020609@oracle.com>
Message-ID: <F30CB76A-4716-4D11-A70F-99248D87D5C9@oracle.com>

Reviewed.

On Sep 17, 2014, at 4:09 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8058626/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8058626
> 
> I've noticed a difference between 8057656 fixes in 8u-dev [1] and 9 [2].
> It seems I integrated [3] into 8u and [4] into 9.
> This change syncs 8u to 9.
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/4b2bc06d521c
> [2] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5ae5da7305a8
> [3] http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/
> [4] http://cr.openjdk.java.net/~vlivanov/8057656/webrev.01/



From wprice at pros.com  Fri Sep 19 17:08:43 2014
From: wprice at pros.com (William Price)
Date: Fri, 19 Sep 2014 17:08:43 +0000
Subject: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not
	consider required no. of fraction digits properly
Message-ID: <248346644B359C488489A7D3D971B3CC81D417DB@PROS-EXMB02.prosrm.com>

Hi Oliver,

I wrote a javaagent-based patch for this bug.  I haven't contributed it formally since my employer's legal department is still hung up on the Oracle Contributor Agreement (though we have released it on GitHub under GPLv2 w/CPE).  I'm not linking to it here under the assumption that your patch was developed independently and I don't want to confuse the issue with legalities.  I copied your patch into my shim locally and ran my test cases and still get a couple failures (see output below).  Your patch and my version differ in the way and order in which we interpret allDecimalDigits and alreadyRounded.

PATCH SELF TEST:
  java.text.DigitList.shouldRoundUp(int,boolean,boolean)
  HALF_UP case

StackOverflow.com question 24426438 test case 1:
         6.2088 HALF_UP --> 6.209               OK
         6.2089 HALF_UP --> 6.209               OK

StackOverflow.com question 24426438 test case 2:
            0.0 HALF_UP --> 0                   OK
           ...
           0.14 HALF_UP --> 0.1                 OK
           0.15 HALF_UP --> 0.1                 expected: 0.2
           0.16 HALF_UP --> 0.2                 OK
           ...
           0.34 HALF_UP --> 0.3                 OK
           0.35 HALF_UP --> 0.3                 expected: 0.4
           0.36 HALF_UP --> 0.4                 OK
           ...
           0.84 HALF_UP --> 0.8                 OK
           0.85 HALF_UP --> 0.8                 expected: 0.9
           0.86 HALF_UP --> 0.9                 OK
           ...
           0.94 HALF_UP --> 0.9                 OK
           0.95 HALF_UP --> 0.9                 expected: 1
           0.96 HALF_UP --> 1                   OK
           ...
           0.99 HALF_UP --> 1                   OK

JDK-8041961 test case:
        99.9989 HALF_UP --> 100                 OK
         99.999 HALF_UP --> 100                 OK

JDK-8039915 test case:
     0.95000055 HALF_UP --> 0.950001            OK
      0.9500006 HALF_UP --> 0.950001            OK

Above tests used Java 1.8.0_20 (Oracle Corporation)
installed at C:\JAVA\latest8\jre

Agent installed: yes
Patch applied  : yes

Overall result : BAD PATCH (!) on Oracle Corporation Java 1.8.0_20

-- 
William Price | Software Architect | PROS, Inc.
Phone:?+1 713-335-5244






From philip.race at oracle.com  Fri Sep 19 19:50:38 2014
From: philip.race at oracle.com (Phil Race)
Date: Fri, 19 Sep 2014 12:50:38 -0700
Subject: Use of internal APIs to protect against memory leaks
In-Reply-To: <541C57AE.6070600@oracle.com>
References: <541C2BD2.7060704@apache.org> <541C57AE.6070600@oracle.com>
Message-ID: <541C890E.8040508@oracle.com>

 > For the 2D disposer issue then 2d-dev is the place to start

The 2d disposer has a call to Thread.setContextClassLoader(null)

It's been there since JDK6u21 ... and is in all later releases.

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

So there is no need I see for accessing this in JDK 9

-phil.

On 9/19/2014 9:19 AM, Alan Bateman wrote:
> On 19/09/2014 14:12, Mark Thomas wrote:
>> :
>>
>> The memory leaks stem from the generally more complex class loader
>> structure present in a JavaEE container than is typically present in a
>> standalone Java app.
>>
>> At this point, I have two questions.
>>
>> 1. Is this community interested in examining these memory leaks further
>> to see what can be done in the JDK to avoid them?
>>
>> 2. If yes, would you prefer a discussion thread for each leak or one
>> thread for all leaks? Personally, I think a thread per leak would be
>> easier to manage but it might make sense just to look at one leak first
>> as there may well be some common themes that emerge which would save us
>> discussing them on each thread.
>>
>>
> I agree with with your suggestion that a discussion per so-called leak 
> would be better than trying to discuss all of this in one thread. The 
> hard bit will be finding the right list to start the discussion. For 
> the AWT issues then awt-dev is the place to start. For the 2D disposer 
> issue then 2d-dev is the place to start. The security-dev list is the 
> place for the security library issues. The net-dev list for the 
> URLConnection  issue. I think core-libs-dev is probably okay for the 
> rest.
>
> Just to set expectations, it's possible that the outcome of some of 
> these will be just a bug in the JIRA. In some cases then I expect you 
> might get a bit of push back as there are performance and 
> compatibility issues to take account.  As an example, the 
> system-wide/singleton ORB returned by ORB.init should never be located 
> via the TCCL. However switching this to using the system class loader 
> breaks a number of 3rd party ORBs that freely cast between 
> per-application ORBs of whatever ORB is bundled with the application 
> and the system-wide ORB that acts as the type code factory. However in 
> general then having the JDK cache anything that is located via the 
> TCCL is a bug and I think you will get support for poking at those 
> issues.
>
> -Alan



From wprice at pros.com  Fri Sep 19 20:02:09 2014
From: wprice at pros.com (William Price)
Date: Fri, 19 Sep 2014 20:02:09 +0000
Subject: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not
	consider required no. of fraction digits properly
Message-ID: <248346644B359C488489A7D3D971B3CC81D41992@PROS-EXMB02.prosrm.com>

> Hi Oliver,

First, sorry about mistyping your name, Olivier!

> I copied your patch into my shim locally and ran my test cases and
> still get a couple failures (see output below).  Your patch and my version
> differ in the way and order in which we interpret allDecimalDigits and
> alreadyRounded.

And I should have been more diligent. On second look these are all "very close to a tie"
as described in JDK-7131459, so I now believe my test suite is incorrect.  It matched the
JDK 6-7 behavior but did not account for the JDK8 intended changes for these edge cases.

JDK-7131459 test case:
           0.15 is actually: 0.1499999999999999944488848768742172978818416595458984375
                HALF_UP  --> 0.1                OK
           0.35 is actually: 0.34999999999999997779553950749686919152736663818359375
                HALF_UP  --> 0.3                OK
           0.85 is actually: 0.84999999999999997779553950749686919152736663818359375
                HALF_UP  --> 0.8                OK
           0.95 is actually: 0.9499999999999999555910790149937383830547332763671875
                HALF_UP  --> 0.9                OK

Above tests used Java 1.8.0_20 (Oracle Corporation)
installed at C:\JAVA\latest8\jre

Agent installed: yes
Patch applied  : yes

Overall result : FIXED
 
-- 
William Price | Software Architect | PROS, Inc.



From brian.burkhalter at oracle.com  Fri Sep 19 20:38:25 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 19 Sep 2014 13:38:25 -0700
Subject: JDK 9 RFR of 8058679: More bad characters in BigIntegerTest
In-Reply-To: <1411030344.42589.YahooMailNeo@web121302.mail.ne1.yahoo.com>
References: <2E3DE0B5-65D2-4CFE-94FF-291356F8EC41@oracle.com>
	<5419F48C.8080601@oracle.com>
	<1411030344.42589.YahooMailNeo@web121302.mail.ne1.yahoo.com>
Message-ID: <E94972B6-8D7C-4ABD-8555-3E09FA0D5777@oracle.com>

Hi Robert,

What happened was that for whatever reason my version of the ?patch? command did not like your patch. I tried various things to get ?patch? to accept it but without success. Note that this had nothing to do with the modular restructuring of the source tree as the path is easily unshuffled. Consequently I reproduced it manually, copy-pasting the revisions from Firefox into Netbeans on Mac OS 10.9. This is apparently font-preserving but not visible in a webrev and the jcheck tool did not catch it either.

In any case, the problems appear to be fixed now.

Thanks,

Brian

On Sep 18, 2014, at 1:52 AM, Robert Gibson <robbiexgibson at yahoo.com> wrote:

> Sorry about that, let's blame my crappy webmail ;) 
> (Strange that the patch appears fine in the mail archives and the webrev?)
> Robert 
> 
> On Thursday, 18 September 2014, 3:18, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 17/09/2014 21:48, Brian Burkhalter wrote:
>> Hello bad characters,
>> 
>> Issue:    https://bugs.openjdk.java.net/browse/JDK-8058679
>> Webrev:    http://cr.openjdk.java.net/~bpb/8058679/webrev.00/
>> 
>> Tested with "-encoding US-ASCII? passed to javac.
>> 
> \ufffd\ufffd Looks okay and if it compiles with -encoding US-ASCII then 
> it gives confidence that they have all been fixed now.
> 
> -Alan



From brian.burkhalter at oracle.com  Fri Sep 19 20:54:25 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 19 Sep 2014 13:54:25 -0700
Subject: JDK 9 RFR of 8043740: Doubles with large exponents overflow to
	Infinity incorrectly 
In-Reply-To: <CAHnpNSYkJzOn-Oc7t0wG7fyLkKXNOTkgiY4OLDr0r0reFjNQ6w@mail.gmail.com>
References: <CAHnpNSYkJzOn-Oc7t0wG7fyLkKXNOTkgiY4OLDr0r0reFjNQ6w@mail.gmail.com>
Message-ID: <DB476A6C-9CDE-48C4-A4D2-995D9B65180B@oracle.com>

Hello Sandipan,

Finally got this off the back burner ?

This review request follows this thread:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027086.html

in which you provided a patch (thank you!) for:

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

I?ve created an updated webrev here:

http://cr.openjdk.java.net/~bpb/8043740/webrev.00/

Aside from minor reformatting there is no update to the proposed FloatingDecimal change. I have not however included the test class Bug8043740 from the contributed patch opting instead to update the existing ParseDouble test by adding a few more strings to the goodStrings array.

The changes to FloatingDecimal appear reasonable to me. I am wondering however if lines 2001-2002 should not be changed to include !expOverflow in the conditional:
2001                     if (!expOverflow && expSign == 1 && decExp < 0
2002                             && (expVal + decExp) < expLimit) {
2003                         // Cannot overflow: adding a positive and negative number.
2004                         decExp += expVal;
I don?t think that it?s possible for both expOverflow and the conditionals at lines 2001-2002 of the webrev to all be true, but the additional test would guarantee branching to the correct block.

Thanks,

Brian

On Jun 2, 2014, at 6:08 AM, Sandipan Razzaque <me at sandipan.net> wrote:
> I've made a quick revision to that last patch. Please find inline the
> latest link + patch.
> 
> http://www.sandipan.net/public/webrevs/8043740/webrev.01/




From brian.burkhalter at oracle.com  Fri Sep 19 22:50:36 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 19 Sep 2014 15:50:36 -0700
Subject: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not
	consider required no. of fraction digits properly
In-Reply-To: <541C05F6.80709@oracle.com>
References: <540F66B4.1080400@oracle.com> <5411C8C9.8000400@oracle.com>
	<541C05F6.80709@oracle.com>
Message-ID: <143C890A-9D8B-4ADA-8E91-E9BA2EFEF1D7@oracle.com>

Hello Olivier,

By inspection I think that the fix and the test update look good. I verified that the test hits all five branches contained in the else-if block of DigitList beginning at line 527. I also verified that the current code base fails four test cases when run against the updated test. The welcome testing performed by William Price is good corroboration as well.

My only suggestions are trivial: 1) enhance the method javadoc of shouldRoundUp(), e.g., there are no @param tags for the boolean parameters, and 2) use braces around all the statements contained in if/else blocks (see below). Comment #2 is nit-picky.

Lastly and this is not really part of your changeset, but I found it curious that the test prints the details of all cases that succeed as opposed to those that fail. I would think that either all results or the failures alone ought to be printed instead of successes only. See for example the partial diff below the DigitList diff.

Thanks,

Brian

--- a/src/java.base/share/classes/java/text/DigitList.java
+++ b/src/java.base/share/classes/java/text/DigitList.java
@@ -526,24 +526,25 @@
                 }
                 else if (digits[maximumDigits] == '5') {
                     // Digit at rounding position is a '5'. Tie cases.
-                    if (maximumDigits != (count - 1))
+                    if (maximumDigits != (count - 1)) {
                         // Remaining digits. Above tie  => must round-up
                         return true;
-                    else {
+                    } else {
                         // Digit at rounding position is the last one !
-                        if (allDecimalDigits)
+                        if (allDecimalDigits) {
                             // Exact binary representation. On the tie.
                             // Strictly follow HALF_UP rule ==> round-up
                             return true;
-                        else {
-                            if (alreadyRounded)
+                        } else {
+                            if (alreadyRounded) {
                                 // Digit sequence rounded-up. Was below tie.
                                 // Don't round-up twice !
                                 return false;
-                            else
+                            } else {
                                 // Digit sequence truncated. Was above tie
                                 // HALF_UP rule ==>  must round-up !
                                 return true;
+                            }
                         }
                     }
                 }

test/java/text/Format/DecimalFormat/TieRoundingTest.java

             errorCounter++;
             allPassed = false;
+            System.out.println("\nFailure for double value : " + doubleToTest + " :");
         } else {
             testCounter++;
             System.out.println("\nSuccess for double value : " + doubleToTest + " :");
-            System.out.println(" Input digits :" + inputDigits +
-                               ", BigDecimal value : " +
-                               new BigDecimal(doubleToTest).toString());
-            System.out.print(" Rounding mode: " + rm);
-            System.out.print(", fract digits : " + mfd);
-            System.out.print(", position : " + tiePosition + " tie");
-            System.out.print(", result : " + result);
-            System.out.println(", expected : " + expectedOutput);
         }
+
+        System.out.println(" Input digits :" + inputDigits
+                + ", BigDecimal value : "
+                + new BigDecimal(doubleToTest).toString());
+        System.out.print(" Rounding mode: " + rm);
+        System.out.print(", fract digits : " + mfd);
+        System.out.print(", position : " + tiePosition + " tie");
+        System.out.print(", result : " + result);
+        System.out.println(", expected : " + expectedOutput);
     }

On Sep 19, 2014, at 3:31 AM, olivier.lagneau at oracle.com wrote:

> This is a code change we would like to integrate in next release of JDK8, since impacting some customer apps/deployments.
> So it would be good to have it reviewed and backported to 8 soon.
> 
> Is there anyone having a bit of free time to review it ?
> 
> Best Regards,
> Olivier Lagneau
> 
> 
> On 11/09/2014 18:07, olivier.lagneau at oracle.com wrote:
>> Could someone please review this code change ?
>> 
>> Thanks in advance,
>> Olivier Lagneau
>> 
>> On 09/09/2014 22:44, olivier.lagneau at oracle.com wrote:
>>> Please review this fix in for wrong rounding-mode mode behavior of NumberFormat.format(double) in HALF_UP case.
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8039915
>>> 
>>> webrev: http://cr.openjdk.java.net/~olagneau/8039915/webrev.00<http://cr.openjdk.java.net/%7Eolagneau/8039915/webrev.00>



From me at sandipan.net  Sat Sep 20 23:06:27 2014
From: me at sandipan.net (Sandipan Razzaque)
Date: Sat, 20 Sep 2014 19:06:27 -0400
Subject: JDK 9 RFR of 8043740: Doubles with large exponents overflow to
	Infinity incorrectly
In-Reply-To: <DB476A6C-9CDE-48C4-A4D2-995D9B65180B@oracle.com>
References: <CAHnpNSYkJzOn-Oc7t0wG7fyLkKXNOTkgiY4OLDr0r0reFjNQ6w@mail.gmail.com>
	<DB476A6C-9CDE-48C4-A4D2-995D9B65180B@oracle.com>
Message-ID: <CAHnpNSYTCKOe7vip5ZUMu8T-nB4Vb2M7rD7xtLGjG7dGpH8Z0Q@mail.gmail.com>

Hi Brian -

Thanks for your review!

I think your point about adding !expOverflow to that conditional makes
perfect sense. We're only looking to account for expVal > expLimit where
decExp would be adjusted downward. Please adjust as appropriate.

Cheers,
SR





Sandipan Razzaque | www.sandipan.net

On Fri, Sep 19, 2014 at 4:54 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> Hello Sandipan,
>
> Finally got this off the back burner ?
>
> This review request follows this thread:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027086.html
>
> in which you provided a patch (thank you!) for:
>
> https://bugs.openjdk.java.net/browse/JDK-8043740
>
> I?ve created an updated webrev here:
>
> http://cr.openjdk.java.net/~bpb/8043740/webrev.00/
>
> Aside from minor reformatting there is no update to the proposed
> FloatingDecimal change. I have not however included the test class
> Bug8043740 from the contributed patch opting instead to update the existing
> ParseDouble test by adding a few more strings to the goodStrings array.
>
> The changes to FloatingDecimal appear reasonable to me. I am wondering
> however if lines 2001-2002 should not be changed to include !expOverflow in
> the conditional:
>
> 2001                     if (!expOverflow && expSign == 1 && decExp < 0
> 2002                             && (expVal + decExp) < expLimit) {
> 2003                         // Cannot overflow: adding a positive and negative number.
> 2004                         decExp += expVal;
>
> I don?t think that it?s possible for both expOverflow and the conditionals
> at lines 2001-2002 of the webrev to all be true, but the additional test
> would guarantee branching to the correct block.
>
> Thanks,
>
> Brian
>
> On Jun 2, 2014, at 6:08 AM, Sandipan Razzaque <me at sandipan.net> wrote:
>
> I've made a quick revision to that last patch. Please find inline the
> latest link + patch.
> http://www.sandipan.net/public/webrevs/8043740/webrev.01/
>
>
>
>


From joe.darcy at oracle.com  Mon Sep 22 04:52:00 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Sun, 21 Sep 2014 21:52:00 -0700
Subject: JDK 9 RFR of 8043740: Doubles with large exponents overflow to
	Infinity incorrectly
In-Reply-To: <CAHnpNSYTCKOe7vip5ZUMu8T-nB4Vb2M7rD7xtLGjG7dGpH8Z0Q@mail.gmail.com>
References: <CAHnpNSYkJzOn-Oc7t0wG7fyLkKXNOTkgiY4OLDr0r0reFjNQ6w@mail.gmail.com>	<DB476A6C-9CDE-48C4-A4D2-995D9B65180B@oracle.com>
	<CAHnpNSYTCKOe7vip5ZUMu8T-nB4Vb2M7rD7xtLGjG7dGpH8Z0Q@mail.gmail.com>
Message-ID: <541FAAF0.8010604@oracle.com>

Hello,

Do the additional cases in the regression tests full cover the proposed 
revision of the code changes?

Thanks,

-Joe

On 9/20/2014 4:06 PM, Sandipan Razzaque wrote:
> Hi Brian -
>
> Thanks for your review!
>
> I think your point about adding !expOverflow to that conditional makes
> perfect sense. We're only looking to account for expVal > expLimit where
> decExp would be adjusted downward. Please adjust as appropriate.
>
> Cheers,
> SR
>
>
>
>
>
> Sandipan Razzaque | www.sandipan.net
>
> On Fri, Sep 19, 2014 at 4:54 PM, Brian Burkhalter <
> brian.burkhalter at oracle.com> wrote:
>
>> Hello Sandipan,
>>
>> Finally got this off the back burner ?
>>
>> This review request follows this thread:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027086.html
>>
>> in which you provided a patch (thank you!) for:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8043740
>>
>> I?ve created an updated webrev here:
>>
>> http://cr.openjdk.java.net/~bpb/8043740/webrev.00/
>>
>> Aside from minor reformatting there is no update to the proposed
>> FloatingDecimal change. I have not however included the test class
>> Bug8043740 from the contributed patch opting instead to update the existing
>> ParseDouble test by adding a few more strings to the goodStrings array.
>>
>> The changes to FloatingDecimal appear reasonable to me. I am wondering
>> however if lines 2001-2002 should not be changed to include !expOverflow in
>> the conditional:
>>
>> 2001                     if (!expOverflow && expSign == 1 && decExp < 0
>> 2002                             && (expVal + decExp) < expLimit) {
>> 2003                         // Cannot overflow: adding a positive and negative number.
>> 2004                         decExp += expVal;
>>
>> I don?t think that it?s possible for both expOverflow and the conditionals
>> at lines 2001-2002 of the webrev to all be true, but the additional test
>> would guarantee branching to the correct block.
>>
>> Thanks,
>>
>> Brian
>>
>> On Jun 2, 2014, at 6:08 AM, Sandipan Razzaque <me at sandipan.net> wrote:
>>
>> I've made a quick revision to that last patch. Please find inline the
>> latest link + patch.
>> http://www.sandipan.net/public/webrevs/8043740/webrev.01/
>>
>>
>>
>>



From Alan.Bateman at oracle.com  Mon Sep 22 08:55:32 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Sep 2014 09:55:32 +0100
Subject: RFR JDK-8044627: Update JNDI to work with modules
In-Reply-To: <FA8A05BE-42D8-4F46-BD4B-270CDCEA7BE2@oracle.com>
References: <FA8A05BE-42D8-4F46-BD4B-270CDCEA7BE2@oracle.com>
Message-ID: <541FE404.8080503@oracle.com>

On 16/09/2014 12:12, Pavel Rappo wrote:
> Hi everyone,
>
> Could you please review my change for JDK-8044627?
>
Pavel - are you planning to send an updated webrev based on the 
discussion so far?

The other thing that I meant to ask is whether this change will add 
service configuration files for the RMI, DNS and CosNaming 
implementations, maybe this is going to be another patch?

-Alan


From Alan.Bateman at oracle.com  Mon Sep 22 09:07:45 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Sep 2014 10:07:45 +0100
Subject: extcheck
In-Reply-To: <DF1BDD7A-AA34-4BC7-AA43-12DAA4BD2935@oracle.com>
References: <DF1BDD7A-AA34-4BC7-AA43-12DAA4BD2935@oracle.com>
Message-ID: <541FE6E1.1070109@oracle.com>

On 11/09/2014 17:23, Pavel Rappo wrote:
> :
>
> We don't think it is widely used. And will become even less useful with upcoming modularization. Are there any good reasons to keep this thing in the JDK?
>
Searching for usages on stackoverflow and other sites doesn't come up 
with much, it would be surprising to find significant usage nowadays. So 
I can't think of any reason to keep it around.

-Alan.


From richard.warburton at gmail.com  Mon Sep 22 11:25:53 2014
From: richard.warburton at gmail.com (Richard Warburton)
Date: Mon, 22 Sep 2014 12:25:53 +0100
Subject: Lower overhead String encoding/decoding
Message-ID: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>

Hi all,

A long-standing issue with Strings in Java is the ease and performance of
creating a String from a ByteBuffer. People who are using nio to bring in
data off the network will be receiving that data in the form of bytebuffers
and converting it to some form of String. For example restful systems
receiving XML or Json messages.

The current workaround is to create a byte[] from the ByteBuffer - a
copying action for any direct bytebuffer - and then pass that to the
String. I'd like to propose that we add an additional constructor to the
String class that takes a ByteBuffer as an argument, and directly create
the char[] value inside the String from the ByteBuffer.

Similarly if you have a String that you want to encode onto the wire then
you need to call String.getBytes(), then write your byte[] into a
ByteBuffer or send it over the network. This ends up allocating a byte[] to
do the copy and also trimming the byte[] back down again, usually
allocating another byte[]. To address this problem I've added a couple of
getBytes() overloads that take byte[] and ByteBuffer arguments and write
directly to those buffers.

I've put together a patch that implements this to demonstrate the overall
direction.

http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-5/

I'm happy to take any feedback on direction or the patch itself or the
overall idea/approach. I think there are a number of similar API situations
in other places as well, for example StringBuffer/StringBuilder instances
which could have similar appends directly from ByteBuffer instances instead
of byte[] instances.

I'll also be at Javaone next week, so if you want to talk about this, just
let me know.

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto <http://twitter.com/richardwarburto>

PS: I appreciate that since I'm adding a method to the public API which
consequently requires standardisation but I think that this could get
incorporated into the Java 9 umbrella JSR.


From Alan.Bateman at oracle.com  Mon Sep 22 11:59:03 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Sep 2014 12:59:03 +0100
Subject: Lower overhead String encoding/decoding
In-Reply-To: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>
References: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>
Message-ID: <54200F07.4070604@oracle.com>

On 22/09/2014 12:25, Richard Warburton wrote:
> :
>
> I've put together a patch that implements this to demonstrate the overall
> direction.
>
> http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-5/
>
> I'm happy to take any feedback on direction or the patch itself or the
> overall idea/approach. I think there are a number of similar API situations
> in other places as well, for example StringBuffer/StringBuilder instances
> which could have similar appends directly from ByteBuffer instances instead
> of byte[] instances.
>
The direction seems reasonable but I wonder about the offset/length (and 
destOffet) parameters as this isn't consistent with how ByteBuffers were 
originally intended to be used. That is, when you read the bytes from 
the wire into a ByteBuffer and flip it then the position and limit will 
delimit the bytes to be decoded.

If the constructor is changed to String(ByteBuffer in, Charset cs) and 
decodes the remaining bytes in the buffer to a String using the 
specified Charset then I think would be more consistent. Also I think 
this would give you a solution to the underflow case.

Similarly if getBytes is replaced with with a getBytes or 
encode(ByteBuffer, Charset cs) then then it would encode as many 
characters as possible into the output buffer and I think would be more 
consistent and also help with overflow case.

-Alan.


From Ulf.Zibis at CoSoCo.de  Mon Sep 22 12:43:02 2014
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Mon, 22 Sep 2014 14:43:02 +0200
Subject: Lower overhead String encoding/decoding
In-Reply-To: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>
References: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>
Message-ID: <54201956.40806@CoSoCo.de>

Compare with https://bugs.openjdk.java.net/browse/JDK-6695386
Maybe that would help a little.

-Ulf


Am 22.09.2014 um 13:25 schrieb Richard Warburton:
> Hi all,
>
> A long-standing issue with Strings in Java is the ease and performance of
> creating a String from a ByteBuffer. People who are using nio to bring in
> data off the network will be receiving that data in the form of bytebuffers
> and converting it to some form of String. For example restful systems
> receiving XML or Json messages.
>
> The current workaround is to create a byte[] from the ByteBuffer - a
> copying action for any direct bytebuffer - and then pass that to the
> String. I'd like to propose that we add an additional constructor to the
> String class that takes a ByteBuffer as an argument, and directly create
> the char[] value inside the String from the ByteBuffer.
>
> Similarly if you have a String that you want to encode onto the wire then
> you need to call String.getBytes(), then write your byte[] into a
> ByteBuffer or send it over the network. This ends up allocating a byte[] to
> do the copy and also trimming the byte[] back down again, usually
> allocating another byte[]. To address this problem I've added a couple of
> getBytes() overloads that take byte[] and ByteBuffer arguments and write
> directly to those buffers.
>
> I've put together a patch that implements this to demonstrate the overall
> direction.
>
> http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-5/
>
> I'm happy to take any feedback on direction or the patch itself or the
> overall idea/approach. I think there are a number of similar API situations
> in other places as well, for example StringBuffer/StringBuilder instances
> which could have similar appends directly from ByteBuffer instances instead
> of byte[] instances.
>
> I'll also be at Javaone next week, so if you want to talk about this, just
> let me know.
>
> regards,
>
>    Richard Warburton
>
>    http://insightfullogic.com
>    @RichardWarburto <http://twitter.com/richardwarburto>
>
> PS: I appreciate that since I'm adding a method to the public API which
> consequently requires standardisation but I think that this could get
> incorporated into the Java 9 umbrella JSR.
>



From olivier.lagneau at oracle.com  Mon Sep 22 13:39:13 2014
From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com)
Date: Mon, 22 Sep 2014 15:39:13 +0200
Subject: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not
	consider required no. of fraction digits properly
In-Reply-To: <248346644B359C488489A7D3D971B3CC81D41992@PROS-EXMB02.prosrm.com>
References: <248346644B359C488489A7D3D971B3CC81D41992@PROS-EXMB02.prosrm.com>
Message-ID: <54202681.6030308@oracle.com>

Hi William,

Thanks a lot for your time and checks !

On 19/09/2014 22:02, William Price wrote:
>> Hi Oliver,
> First, sorry about mistyping your name, Olivier!
>
>> I copied your patch into my shim locally and ran my test cases and
>> still get a couple failures (see output below).  Your patch and my version
>> differ in the way and order in which we interpret allDecimalDigits and
>> alreadyRounded.
> And I should have been more diligent. On second look these are all "very close to a tie"
> as described in JDK-7131459, so I now believe my test suite is incorrect.  It matched the
> JDK 6-7 behavior but did not account for the JDK8 intended changes for these edge cases.
Yes these are voluntarily all tricky cases with dtoa() returning an 
exact tie
due to IEEE-754 precision limit, thus following nearest to even policy and
either rounding up or truncating right at the rounding digit position.

allDecimalDigits indicates whether dtoa() was able to provide all the 
exact digits,
with result still inside IEEE-754 precision. alreadyRounded indicates 
whether the result
was truncated or rounded up.

I think allDecimalDigits must be checked first, followed by 
alreadyRounded, since
if you get an exact binary representation within IEEE precision, dtoa 
won't do
any rounding by principle.
I believe the latest (last Friday) version of your patch on github is ok.

Thanks again William for following this bug,
and for the feedback and checking of the patch for this review  !

Best Regards,
Olivier.

>
> JDK-7131459 test case:
>             0.15 is actually: 0.1499999999999999944488848768742172978818416595458984375
>                  HALF_UP  --> 0.1                OK
>             0.35 is actually: 0.34999999999999997779553950749686919152736663818359375
>                  HALF_UP  --> 0.3                OK
>             0.85 is actually: 0.84999999999999997779553950749686919152736663818359375
>                  HALF_UP  --> 0.8                OK
>             0.95 is actually: 0.9499999999999999555910790149937383830547332763671875
>                  HALF_UP  --> 0.9                OK
>
> Above tests used Java 1.8.0_20 (Oracle Corporation)
> installed at C:\JAVA\latest8\jre
>
> Agent installed: yes
> Patch applied  : yes
>
> Overall result : FIXED
>   



From aleksey.shipilev at oracle.com  Mon Sep 22 14:06:56 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 22 Sep 2014 18:06:56 +0400
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <54199AA9.2090804@oracle.com>
References: <54199AA9.2090804@oracle.com>
Message-ID: <54202D00.3010207@oracle.com>

Hi again,

On 09/17/2014 06:28 PM, Aleksey Shipilev wrote:
> Can I have a review and a sponsorship for this tiny readability cleanup
> in String.hashCode()?
>  http://cr.openjdk.java.net/~shade/8058643/webrev.01/
>  https://bugs.openjdk.java.net/browse/JDK-8058643

I think we have enough reviews? Here is a changeset:
  http://cr.openjdk.java.net/~shade/8058643/8058643.changeset

Please sponsor!

Thanks,
-Aleksey.



From aleksey.shipilev at oracle.com  Mon Sep 22 14:13:21 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 22 Sep 2014 18:13:21 +0400
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <54202D00.3010207@oracle.com>
References: <54199AA9.2090804@oracle.com> <54202D00.3010207@oracle.com>
Message-ID: <54202E81.8070004@oracle.com>

On 09/22/2014 06:06 PM, Aleksey Shipilev wrote:
> Hi again,
> 
> On 09/17/2014 06:28 PM, Aleksey Shipilev wrote:
>> Can I have a review and a sponsorship for this tiny readability cleanup
>> in String.hashCode()?
>>  http://cr.openjdk.java.net/~shade/8058643/webrev.01/
>>  https://bugs.openjdk.java.net/browse/JDK-8058643
> 
> I think we have enough reviews? Here is a changeset:
>   http://cr.openjdk.java.net/~shade/8058643/8058643.changeset
> 
> Please sponsor!

Wait. Claes spotted an inconsistency:

Should be:
 for (char v : value) {

Not:
 for (int v : value) {

Let me also write a unit test for this :)

-Aleksey.






From aleksey.shipilev at oracle.com  Mon Sep 22 14:29:11 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Mon, 22 Sep 2014 18:29:11 +0400
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <54202E81.8070004@oracle.com>
References: <54199AA9.2090804@oracle.com> <54202D00.3010207@oracle.com>
	<54202E81.8070004@oracle.com>
Message-ID: <54203237.5090901@oracle.com>

On 09/22/2014 06:13 PM, Aleksey Shipilev wrote:
> On 09/22/2014 06:06 PM, Aleksey Shipilev wrote:
>> Hi again,
>>
>> On 09/17/2014 06:28 PM, Aleksey Shipilev wrote:
>>> Can I have a review and a sponsorship for this tiny readability cleanup
>>> in String.hashCode()?
>>>  http://cr.openjdk.java.net/~shade/8058643/webrev.01/
>>>  https://bugs.openjdk.java.net/browse/JDK-8058643
>>
>> I think we have enough reviews? Here is a changeset:
>>   http://cr.openjdk.java.net/~shade/8058643/8058643.changeset
>>
>> Please sponsor!
> 
> Wait. Claes spotted an inconsistency:
> 
> Should be:
>  for (char v : value) {
> 
> Not:
>  for (int v : value) {

Fixed:
 http://cr.openjdk.java.net/~shade/8058643/webrev.02/
 http://cr.openjdk.java.net/~shade/8058643/8058643.changeset

Since there is no performance impact for this touchup (char -> int
promotion is happening anyway), and no functionality changes (char ->
int promotion zero-extends), I haven't developed any new tests, or
re-spinned any existing ones.

Thanks,
-Aleksey.



From claes.redestad at oracle.com  Mon Sep 22 14:35:04 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 22 Sep 2014 16:35:04 +0200
Subject: RFR (XXS): 8058887: TEST_BUG: java/util/Formatter/genBasic.sh points
	to old location of Spp.java
Message-ID: <54203398.7030003@oracle.com>

Hi,

can I have a review and sponsor for this trivial fix to make the jtreg 
test generator script jdk/test/java/util/Formatter/genBasic.sh work in 
the new build system?

bug: https://bugs.openjdk.java.net/browse/JDK-8058887
webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.01/

/Claes


From olivier.lagneau at oracle.com  Mon Sep 22 14:56:49 2014
From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com)
Date: Mon, 22 Sep 2014 16:56:49 +0200
Subject: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not
	consider required no. of fraction digits properly
In-Reply-To: <143C890A-9D8B-4ADA-8E91-E9BA2EFEF1D7@oracle.com>
References: <540F66B4.1080400@oracle.com> <5411C8C9.8000400@oracle.com>
	<541C05F6.80709@oracle.com>
	<143C890A-9D8B-4ADA-8E91-E9BA2EFEF1D7@oracle.com>
Message-ID: <542038B1.7090000@oracle.com>

Hi Brian,

Thanks a lot for your thorough review of the fix !

Please see comments inlined.

On 20/09/2014 00:50, Brian Burkhalter wrote:
> Hello Olivier,
>
> By inspection I think that the fix and the test update look good. I 
> verified that the test hits all five branches contained in the else-if 
> block of DigitList beginning at line 527. I also verified that the 
> current code base fails four test cases when run against the updated 
> test. The welcome testing performed by William Price is good 
> corroboration as well.
Thanks for checking all these. with details of
>
> My only suggestions are trivial: 1) enhance the method javadoc of 
> shouldRoundUp(), e.g., there are no @param tags for the boolean 
> parameters,
Did not notice that. Will add those.
> and 2) use braces around all the statements contained in if/else 
> blocks (see below). Comment #2 is nit-picky.
I tried to keep the same flavour of writing as in HALF_DOWN and 
HALF_EVEN cases, i.e. don't use brace for
terminal/leaf return true/false statements. This is not the standard 
however, at least in this file.
Will use braces in all case (i.e. the 3 of HALF_UP,  HALF_DOWN and 
HALF_EVEN).

>
> Lastly and this is not really part of your changeset, but I found it 
> curious that the test prints the details of all cases that succeed as 
> opposed to those that fail. I would think that either all results or 
> the failures alone ought to be printed instead of successes only. See 
> for example the partial diff below the DigitList diff.
Since these are most often corner and tricky test cases I think it 
interesting to have the details of each result,
including infos of both why returned result is correct or wrong.
That can help the reader to understand all these tricky cases.
The bad side of it being that it prints a lot of text, with failure 
cases (hoepfully few) lost in the middle of it,
thus making failures possibly not immediate to detect.

Here is an example of what is printed in case of failure:
"
========================================
***Error formatting double value from string : 0.6868d
NumberFormat pattern is  : #,##0.###
Maximum number of fractional digits : 3
Fractional rounding digit : 4
Position of value relative to tie : above
Rounding Mode : HALF_UP
BigDecimal output : 0.68679999999999996607158436745521612465381622314453125
FloatingDecimal output : 0.6868
Error. Formatted result different from expected.
Expected output is : "0.687"
Formated output is : "0.686"
========================================
"

There is also a reminder of the number of errors at the end of the report:
"
==> 4 tests failed

Test failed with 4 formating error(s).
"

May be providing a reminder (value + rounding-mode + rounding position)
of the failure cases at the end of the would be better ?
Like:
"
Test failed with 4 formating error(s) for following cases :
- 0.3126d, HALF_UP rounding, 3 fractional digits
- 0.6868d, HALF_UP rounding, 3 fractional digits
- 1.798876d, HALF_UP rounding, 5 fractional digits
- 1.796889d, HALF_UP rounding, 5 fractional digits
"

Would doing so be ok ?

Best Regards,
Olivier.

>
> Thanks,
>
> Brian
>
> --- a/src/java.base/share/classes/java/text/DigitList.java
> +++ b/src/java.base/share/classes/java/text/DigitList.java
> @@ -526,24 +526,25 @@
>                  }
>                  else if (digits[maximumDigits] == '5') {
>                      // Digit at rounding position is a '5'. Tie cases.
> -                    if (maximumDigits != (count - 1))
> +                    if (maximumDigits != (count - 1)) {
>                          // Remaining digits. Above tie  => must round-up
>                          return true;
> -                    else {
> +                    } else {
>                          // Digit at rounding position is the last one !
> -                        if (allDecimalDigits)
> +                        if (allDecimalDigits) {
>                              // Exact binary representation. On the tie.
>                              // Strictly follow HALF_UP rule ==> round-up
>                              return true;
> -                        else {
> -                            if (alreadyRounded)
> +                        } else {
> +                            if (alreadyRounded) {
>                                  // Digit sequence rounded-up. Was 
> below tie.
>                                  // Don't round-up twice !
>                                  return false;
> -                            else
> +                            } else {
>                                  // Digit sequence truncated. Was 
> above tie
>                                  // HALF_UP rule ==>  must round-up !
>                                  return true;
> +                            }
>                          }
>                      }
>                  }
>
> test/java/text/Format/DecimalFormat/TieRoundingTest.java
>
>              errorCounter++;
>              allPassed = false;
> +            System.out.println("\nFailure for double value : " + 
> doubleToTest + " :");
>          } else {
>              testCounter++;
>              System.out.println("\nSuccess for double value : " + 
> doubleToTest + " :");
> -            System.out.println(" Input digits :" + inputDigits +
> -                               ", BigDecimal value : " +
> -                               new BigDecimal(doubleToTest).toString());
> -            System.out.print(" Rounding mode: " + rm);
> -            System.out.print(", fract digits : " + mfd);
> -            System.out.print(", position : " + tiePosition + " tie");
> -            System.out.print(", result : " + result);
> -            System.out.println(", expected : " + expectedOutput);
>          }
> +
> +        System.out.println(" Input digits :" + inputDigits
> +                + ", BigDecimal value : "
> +                + new BigDecimal(doubleToTest).toString());
> +        System.out.print(" Rounding mode: " + rm);
> +        System.out.print(", fract digits : " + mfd);
> +        System.out.print(", position : " + tiePosition + " tie");
> +        System.out.print(", result : " + result);
> +        System.out.println(", expected : " + expectedOutput);
>      }
>
> On Sep 19, 2014, at 3:31 AM, olivier.lagneau at oracle.com 
> <mailto:olivier.lagneau at oracle.com> wrote:
>
>> This is a code change we would like to integrate in next release of 
>> JDK8, since impacting some customer apps/deployments.
>> So it would be good to have it reviewed and backported to 8 soon.
>>
>> Is there anyone having a bit of free time to review it ?
>>
>> Best Regards,
>> Olivier Lagneau
>>
>>
>> On 11/09/2014 18:07,olivier.lagneau at oracle.com 
>> <mailto:olivier.lagneau at oracle.com>wrote:
>>> Could someone please review this code change ?
>>>
>>> Thanks in advance,
>>> Olivier Lagneau
>>>
>>> On 09/09/2014 22:44,olivier.lagneau at oracle.com 
>>> <mailto:olivier.lagneau at oracle.com>wrote:
>>>> Please review this fix in for wrong rounding-mode mode behavior of 
>>>> NumberFormat.format(double) in HALF_UP case.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8039915
>>>>
>>>> webrev:http://cr.openjdk.java.net/~olagneau/8039915/webrev.00 
>>>> <http://cr.openjdk.java.net/%7Eolagneau/8039915/webrev.00><http://cr.openjdk.java.net/%7Eolagneau/8039915/webrev.00>
>



From brian.burkhalter at oracle.com  Mon Sep 22 15:50:57 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 Sep 2014 08:50:57 -0700
Subject: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not
	consider required no. of fraction digits properly
In-Reply-To: <542038B1.7090000@oracle.com>
References: <540F66B4.1080400@oracle.com> <5411C8C9.8000400@oracle.com>
	<541C05F6.80709@oracle.com>
	<143C890A-9D8B-4ADA-8E91-E9BA2EFEF1D7@oracle.com>
	<542038B1.7090000@oracle.com>
Message-ID: <016FF767-532C-4658-912D-3E8119532C57@oracle.com>

Hi Olivier,

On Sep 22, 2014, at 7:56 AM, olivier.lagneau at oracle.com wrote:

>> and 2) use braces around all the statements contained in if/else blocks (see below). Comment #2 is nit-picky.
> I tried to keep the same flavour of writing as in HALF_DOWN and HALF_EVEN cases, i.e. don't use brace for
> terminal/leaf return true/false statements. This is not the standard however, at least in this file.
> Will use braces in all case (i.e. the 3 of HALF_UP,  HALF_DOWN and HALF_EVEN).

I did not look at the other case. If your formatting matches the rest of the file then I think it is OK to leave it as-is.

>> Lastly and this is not really part of your changeset, but I found it curious that the test prints the details of all cases that succeed as opposed to those that fail. I would think that either all results or the failures alone ought to be printed instead of successes only. See for example the partial diff below the DigitList diff.
> Since these are most often corner and tricky test cases I think it interesting to have the details of each result,
> including infos of both why returned result is correct or wrong.
> That can help the reader to understand all these tricky cases.
> The bad side of it being that it prints a lot of text, with failure cases (hoepfully few) lost in the middle of it,
> thus making failures possibly not immediate to detect. 
> 
> Here is an example of what is printed in case of failure:
> "
> ========================================
> ***Error formatting double value from string : 0.6868d
> NumberFormat pattern is  : #,##0.###
> Maximum number of fractional digits : 3
> Fractional rounding digit : 4
> Position of value relative to tie : above
> Rounding Mode : HALF_UP
> BigDecimal output : 0.68679999999999996607158436745521612465381622314453125
> FloatingDecimal output : 0.6868
> Error. Formatted result different from expected.
> Expected output is : "0.687"
> Formated output is : "0.686"
> ========================================

I missed that output: I was looking for the word ?failure.?

> There is also a reminder of the number of errors at the end of the report:
> "
> ==> 4 tests failed
> 
> Test failed with 4 formating error(s).
> "
> 
> May be providing a reminder (value + rounding-mode + rounding position)
> of the failure cases at the end of the would be better ?
> Like:
> "
> Test failed with 4 formating error(s) for following cases :
> - 0.3126d, HALF_UP rounding, 3 fractional digits
> - 0.6868d, HALF_UP rounding, 3 fractional digits
> - 1.798876d, HALF_UP rounding, 5 fractional digits
> - 1.796889d, HALF_UP rounding, 5 fractional digits
> "
> 
> Would doing so be ok ?

If the test is already printing out the information you showed above (?Error formatting ??) then I think it is enough but the verbiage should perhaps match the reminder, e.g., ?Failure: Error formatting double ??

Thanks,

Brian

From brian.burkhalter at oracle.com  Mon Sep 22 15:53:03 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 Sep 2014 08:53:03 -0700
Subject: JDK 9 RFR of 8043740: Doubles with large exponents overflow to
	Infinity incorrectly
In-Reply-To: <541FAAF0.8010604@oracle.com>
References: <CAHnpNSYkJzOn-Oc7t0wG7fyLkKXNOTkgiY4OLDr0r0reFjNQ6w@mail.gmail.com>	<DB476A6C-9CDE-48C4-A4D2-995D9B65180B@oracle.com>
	<CAHnpNSYTCKOe7vip5ZUMu8T-nB4Vb2M7rD7xtLGjG7dGpH8Z0Q@mail.gmail.com>
	<541FAAF0.8010604@oracle.com>
Message-ID: <C766E940-CE27-46C7-AFA8-D5E8818FF18B@oracle.com>

Hi Joe,

Yes, and then some. There are two cases which fail before applying the patch and neither fails thereafter. One of these cases matches the test in the original patch. The remaining cases pass both before and after but I added them as edges cases anyway.

Thanks,

Brian

On Sep 21, 2014, at 9:52 PM, Joe Darcy <joe.darcy at oracle.com> wrote:

> Do the additional cases in the regression tests full cover the proposed revision of the code changes?



From joe.darcy at oracle.com  Mon Sep 22 16:05:09 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 22 Sep 2014 09:05:09 -0700
Subject: JDK 9 RFR of 8043740: Doubles with large exponents overflow to
	Infinity incorrectly
In-Reply-To: <C766E940-CE27-46C7-AFA8-D5E8818FF18B@oracle.com>
References: <CAHnpNSYkJzOn-Oc7t0wG7fyLkKXNOTkgiY4OLDr0r0reFjNQ6w@mail.gmail.com>	<DB476A6C-9CDE-48C4-A4D2-995D9B65180B@oracle.com>
	<CAHnpNSYTCKOe7vip5ZUMu8T-nB4Vb2M7rD7xtLGjG7dGpH8Z0Q@mail.gmail.com>
	<541FAAF0.8010604@oracle.com>
	<C766E940-CE27-46C7-AFA8-D5E8818FF18B@oracle.com>
Message-ID: <542048B5.8080004@oracle.com>

Hi Brian,

Okay; looks good to go back.

Thanks,

-Joe

On 9/22/2014 8:53 AM, Brian Burkhalter wrote:
> Hi Joe,
>
> Yes, and then some. There are two cases which fail before applying the 
> patch and neither fails thereafter. One of these cases matches the 
> test in the original patch. The remaining cases pass both before and 
> after but I added them as edges cases anyway.
>
> Thanks,
>
> Brian
>
> On Sep 21, 2014, at 9:52 PM, Joe Darcy <joe.darcy at oracle.com 
> <mailto:joe.darcy at oracle.com>> wrote:
>
>> Do the additional cases in the regression tests full cover the 
>> proposed revision of the code changes?
>



From claes.redestad at oracle.com  Mon Sep 22 19:02:37 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 22 Sep 2014 21:02:37 +0200
Subject: RFR: 8058887: (fmt) Improve java/util/Formatter test coverage of
	group separators and width
In-Reply-To: <54203398.7030003@oracle.com>
References: <54203398.7030003@oracle.com>
Message-ID: <5420724D.1080602@oracle.com>

Hi,

previous attempt was considered too trivial a fix, so how about actually 
improving the test coverage, fixing the link issue in genBasic and 
upgrade Spp.java to not add thousands of empty lines while we're at it? 
Rejoice!

webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.03/

Most relevant files to review are:

http://cr.openjdk.java.net/~redestad/8058887/webrev.03/test/java/util/Formatter/Basic-X.java.template.udiff.html
http://cr.openjdk.java.net/~redestad/8058887/webrev.03/make/src/classes/build/tools/spp/Spp.java.udiff.html
http://cr.openjdk.java.net/~redestad/8058887/webrev.03/test/java/util/Formatter/genBasic.sh.udiff.html

... while the others are generated from the update Spp.java tool using 
the fixed genBasic.sh.

/Claes

On 09/22/2014 04:35 PM, Claes Redestad wrote:
> Hi,
>
> can I have a review and sponsor for this trivial fix to make the jtreg 
> test generator script jdk/test/java/util/Formatter/genBasic.sh work in 
> the new build system?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8058887
> webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.01/
>
> /Claes



From claes.redestad at oracle.com  Mon Sep 22 19:43:58 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 22 Sep 2014 21:43:58 +0200
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <54183806.8050401@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>
	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>
	<54183806.8050401@oracle.com>
Message-ID: <54207BFE.9040907@oracle.com>

Hi,

Sherman pointed out that there was a path that could actually take a 
minor performance hit from this patch,
which would be unacceptable. This version takes the minimal approach to 
addressing this by adding back a
method operating on a char[], simplified for the specific usage case 
(the exponent part of a %g double formatting):

http://cr.openjdk.java.net/~redestad/8050142/webrev.07/

This latest patch passes using the extended test coverage of 
java.util.Formatter I've proposed in 8058887, see
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028849.html

/Claes

On 09/16/2014 03:15 PM, Claes Redestad wrote:
> Brent, Marcus,
>
> thank you for reviewing!
>
> JCK 9 tests for api/java_util api/java_lang either pass or fail with 
> or without this patch on my machine.
>
> Also reran relevant jtreg tests (jdk/test/java/util/Formatter 
> jdk/test/java/util/Formattable jdk/test/java/lang/String 
> jdk/test/java/lang/System)
>
> Ok to fix nits offline without posting new webrev?
>
> /Claes
>
> On 09/16/2014 11:34 AM, Marcus Lagergren wrote:
>> I am reviewer and they look good to me too. ~30% better performance 
>> for random indata- Do you pass the JCK? If so you have my blessing.
>>
>> /M
>>
>> On 16 Sep 2014, at 01:52, Brent Christian 
>> <brent.christian at oracle.com> wrote:
>>
>>> Hi, Claes
>>>
>>> I've looked over the latest changes, and they look good to me.  I 
>>> can sponsor this.  Note that we need approval from a Reviewer.
>>>
>>> One small nitpick from me:
>>> 2914:
>>> If the text is left-justified, then aren't we padding on the right?  
>>> I would call this "padRight".
>>>
>>> Thanks,
>>> -Brent
>>>
>>> On 7/14/14 3:41 PM, Claes Redestad wrote:
>>>> Sorry about that; maybe I should've renamed the field c to conv 
>>>> instead,
>>>> but I think I need to be conservative now and will revert the name 
>>>> changes.
>>>>
>>>> New webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.3
>>>>
>>>> Changing usage of given locale or any semantic change is really
>>>> out-of-scope here. There seems to be a few ancient bugs hanging around
>>>> which maybe someone should take a look at, e.g.,
>>>> https://bugs.openjdk.java.net/browse/JDK-5063466
>>>>
>>>> /Claes
>>>>
>>>> On 2014-07-14 20:05, Jason Mehrens wrote:
>>>>> Claes,
>>>>>
>>>>>
>>>>> Maybe change (or not):
>>>>>
>>>>>
>>>>> -throw new UnknownFormatConversionException(String.valueOf(c));
>>>>>
>>>>> +throw new UnknownFormatConversionException(String.valueOf(conv));
>>>>>
>>>>>
>>>>>
>>>>> I haven't examined it too deeply but it seems odd that some of those
>>>>> print methods don't use the given locale when converting case.  That
>>>>> is probably not a change for this issue.
>>>>>
>>>>>
>>>>> Jason
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> Date: Mon, 14 Jul 2014 17:40:41 +0200
>>>>>> From: claes.redestad at oracle.com
>>>>>> To: core-libs-dev at openjdk.java.net
>>>>>> Subject: Re: RFR [9]: 8050142: Optimize java.util.Formatter
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> final(?) webrev: 
>>>>>> http://cr.openjdk.java.net/~redestad/8050142/webrev.2
>>>>>>
>>>>>> Thanks in advance for reviews. I also need a volunteer to sponsor
>>>>>> this. :-)
>>>>>>
>>>>>> /Claes
>>>>>>
>>>>>> On 07/14/2014 04:21 PM, Claes Redestad wrote:
>>>>>>> Yes, might be worth addressing just for correctness/readability.
>>>>>>>
>>>>>>> /Claes
>>>>>>>
>>>>>>> On 07/14/2014 03:02 PM, Ivan Gerasimov wrote:
>>>>>>>> A very minor one:
>>>>>>>> 2704 if (Character.isUpperCase(conv))
>>>>>>>> 2705 f.add(Flags.UPPERCASE);
>>>>>>>> 2706 c = Character.toLowerCase(conv);
>>>>>>>>
>>>>>>>> maybe
>>>>>>>>
>>>>>>>> 2704 if (Character.isUpperCase(conv)) {
>>>>>>>> 2705 f.add(Flags.UPPERCASE);
>>>>>>>> 2706 c = Character.toLowerCase(conv);
>>>>>>>> }
>>>>>>>>
>>>>>>>> Sincerely yours,
>>>>>>>> Ivan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 14.07.2014 16:23, Claes Redestad wrote:
>>>>>>>>> Hi again,
>>>>>>>>>
>>>>>>>>> updated webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~redestad/8050142/webrev.1
>>>>>>>>>
>>>>>>>>> changes:
>>>>>>>>> - specify capacity on line 2931 as suggested by Andrej Golovnin
>>>>>>>>> - exp.append("0") -> exp.append('0') on line 3781
>>>>>>>>> - merged append+justify into appendJustified as suggested by 
>>>>>>>>> Peter
>>>>>>>>> Levart
>>>>>>>>> - replaced the reoccuring pattern of appending a number of zeros
>>>>>>>>> into a call to trailingZeros
>>>>>>>>>
>>>>>>>>> performance difference seemingly at noise levels in micros, but
>>>>>>>>> bonus to readability and Formatter*.class-files are now a 
>>>>>>>>> total of
>>>>>>>>> 246 bytes smaller
>>>>>>>>>
>>>>>>>>> /Claes
>>>>>>>>>
>>>>>>>>> On 2014-07-14 13:29, Claes Redestad wrote:
>>>>>>>>>> Hi Peter,
>>>>>>>>>>
>>>>>>>>>> On 2014-07-14 13:25, Peter Levart wrote:
>>>>>>>>>>> On 07/14/2014 12:07 PM, Claes Redestad wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> please review this patch which optimizes away some allocations
>>>>>>>>>>>> from java.util.Formatter and achieve 1.1-1.3x speedups of 
>>>>>>>>>>>> micros
>>>>>>>>>>>> targetting String.format. See bug for more details.
>>>>>>>>>>>>
>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0
>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142
>>>>>>>>>>>>
>>>>>>>>>>>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter),
>>>>>>>>>>>> SPECjbb2013 and microbenchmarks
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> /Claes
>>>>>>>>>>> Hi Claes,
>>>>>>>>>>>
>>>>>>>>>>> Since justify() result is always appended to the resulting
>>>>>>>>>>> Appendable, you could merge the functionality and eliminate
>>>>>>>>>>> constructing intermediary StringBuilder altogether:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/ 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Looks good, especially eliminating the need for two different
>>>>>>>>>> append methods. I'll update based on this and other suggestions.
>>>>>>>>>>
>>>>>>>>>> /Claes
>>>>>>>>>>> Regards, Peter
>>>>>>>>>
>



From ivan.gerasimov at oracle.com  Mon Sep 22 20:14:55 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 23 Sep 2014 00:14:55 +0400
Subject: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for
	UTF-8
Message-ID: <5420833F.1040102@oracle.com>

Hello!

The UTF-8 encoding allows characters that are 4 bytes long.
However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which 
is not always enough.

Would you please review the simple fix for this issue?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058875
WEBREV: http://cr.openjdk.java.net/~igerasim/8058875/0/webrev/

Sincerely yours,
Ivan


From xueming.shen at oracle.com  Mon Sep 22 20:35:45 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 22 Sep 2014 13:35:45 -0700
Subject: RFR (XXS): 8058887: TEST_BUG: java/util/Formatter/genBasic.sh
	points to old location of Spp.java
In-Reply-To: <54203398.7030003@oracle.com>
References: <54203398.7030003@oracle.com>
Message-ID: <54208821.4060309@oracle.com>

On 09/22/2014 07:35 AM, Claes Redestad wrote:
> Hi,
>
> can I have a review and sponsor for this trivial fix to make the jtreg test generator script jdk/test/java/util/Formatter/genBasic.sh work in the new build system?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8058887
> webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.01/
>
> /Claes


looks good.


From xueming.shen at oracle.com  Mon Sep 22 21:00:22 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 22 Sep 2014 14:00:22 -0700
Subject: RFR: 8058887: (fmt) Improve java/util/Formatter test coverage
	of group separators and width
In-Reply-To: <5420724D.1080602@oracle.com>
References: <54203398.7030003@oracle.com> <5420724D.1080602@oracle.com>
Message-ID: <54208DE6.5000209@oracle.com>

It was on purpose to keep those blank lines when I wrote the Spp to replace the original
script. it serves the purpose of preserving  the line number the generated source code
(identical to the ln# of the same code line in template file). This is convenient/import
when debugging those generated nio source files with a specific line number, from
exception stack trace, for example.

-sherman

On 09/22/2014 12:02 PM, Claes Redestad wrote:
> Hi,
>
> previous attempt was considered too trivial a fix, so how about actually improving the test coverage, fixing the link issue in genBasic and upgrade Spp.java to not add thousands of empty lines while we're at it? Rejoice!
>
> webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.03/
>
> Most relevant files to review are:
>
> http://cr.openjdk.java.net/~redestad/8058887/webrev.03/test/java/util/Formatter/Basic-X.java.template.udiff.html
> http://cr.openjdk.java.net/~redestad/8058887/webrev.03/make/src/classes/build/tools/spp/Spp.java.udiff.html
> http://cr.openjdk.java.net/~redestad/8058887/webrev.03/test/java/util/Formatter/genBasic.sh.udiff.html
>
> ... while the others are generated from the update Spp.java tool using the fixed genBasic.sh.
>
> /Claes
>
> On 09/22/2014 04:35 PM, Claes Redestad wrote:
>> Hi,
>>
>> can I have a review and sponsor for this trivial fix to make the jtreg test generator script jdk/test/java/util/Formatter/genBasic.sh work in the new build system?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8058887
>> webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.01/
>>
>> /Claes
>



From xueming.shen at oracle.com  Mon Sep 22 21:05:32 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 22 Sep 2014 14:05:32 -0700
Subject: RFR: 8058887: (fmt) Improve java/util/Formatter test coverage
	of group separators and width
In-Reply-To: <54208DE6.5000209@oracle.com>
References: <54203398.7030003@oracle.com> <5420724D.1080602@oracle.com>
	<54208DE6.5000209@oracle.com>
Message-ID: <54208F1C.3010104@oracle.com>

On 09/22/2014 02:00 PM, Xueming Shen wrote:
> It was on purpose to keep those blank lines when I wrote the Spp to replace the original
> script. it serves the purpose of preserving  the line number the generated source code
> (identical to the ln# of the same code line in template file). This is convenient/import

meant to say "convenient/important" :-)


> when debugging those generated nio source files with a specific line number, from
> exception stack trace, for example.
>
> -sherman
>
> On 09/22/2014 12:02 PM, Claes Redestad wrote:
>> Hi,
>>
>> previous attempt was considered too trivial a fix, so how about actually improving the test coverage, fixing the link issue in genBasic and upgrade Spp.java to not add thousands of empty lines while we're at it? Rejoice!
>>
>> webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.03/
>>
>> Most relevant files to review are:
>>
>> http://cr.openjdk.java.net/~redestad/8058887/webrev.03/test/java/util/Formatter/Basic-X.java.template.udiff.html
>> http://cr.openjdk.java.net/~redestad/8058887/webrev.03/make/src/classes/build/tools/spp/Spp.java.udiff.html
>> http://cr.openjdk.java.net/~redestad/8058887/webrev.03/test/java/util/Formatter/genBasic.sh.udiff.html
>>
>> ... while the others are generated from the update Spp.java tool using the fixed genBasic.sh.
>>
>> /Claes
>>
>> On 09/22/2014 04:35 PM, Claes Redestad wrote:
>>> Hi,
>>>
>>> can I have a review and sponsor for this trivial fix to make the jtreg test generator script jdk/test/java/util/Formatter/genBasic.sh work in the new build system?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058887
>>> webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.01/
>>>
>>> /Claes
>>
>



From brian.burkhalter at oracle.com  Mon Sep 22 21:10:30 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 Sep 2014 14:10:30 -0700
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be
	optimized 
Message-ID: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>

Hello,

Another relatively small numerics fix:

Issue:	https://bugs.openjdk.java.net/browse/JDK-4477961
Webrev:	http://cr.openjdk.java.net/~bpb/4477961/webrev.00/

Summary: Change constructs like ?a * B / C? and ?u / V * W? to ?x * (Y / Z)? where lower case denotes a variable and upper case a constant. This forces the constant value (Y / Z) to be evaluated only once per VM instance, and replaces division of the variable with multiplication. The resulting performance improvement is more than 300% as measure by JMH on a MacBookPro11,1 dual core i7 running Mac OS 10.9.5.

Thanks,

Brian

From martinrb at google.com  Mon Sep 22 21:23:11 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 22 Sep 2014 14:23:11 -0700
Subject: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4
	for UTF-8
In-Reply-To: <5420833F.1040102@oracle.com>
References: <5420833F.1040102@oracle.com>
Message-ID: <CA+kOe0-fD0==NOZQo_pOvSziGsZNkTwuUZghOiyqf0zqk7FJiA@mail.gmail.com>

I think you are mistaken. It's maxBytesPerChar, not maxBytesPerCodepoint!


changeset:   3116:b44704ce8a08
user:        sherman
date:        2010-11-19 12:58 -0800
6957230: CharsetEncoder.maxBytesPerChar() reports 4 for UTF-8; should be 3
Summary: changged utf-8's CharsetEncoder.maxBytesPerChar to 3
Reviewed-by: alanb


On Mon, Sep 22, 2014 at 1:14 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
wrote:

> Hello!
>
> The UTF-8 encoding allows characters that are 4 bytes long.
> However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which is
> not always enough.
>
> Would you please review the simple fix for this issue?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058875
> WEBREV: http://cr.openjdk.java.net/~igerasim/8058875/0/webrev/
>
> Sincerely yours,
> Ivan
>


From mike.duigou at oracle.com  Mon Sep 22 21:24:39 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 22 Sep 2014 14:24:39 -0700
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be
	optimized
In-Reply-To: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
Message-ID: <932DF2E3-6CE1-486D-BA26-07FD974404EE@oracle.com>

Looks fine.

I think it is always important note when a change may result in different results for some inputs. I will reiterate for the record what's mentioned in the bug:

> However, one caveat is that this may affect the results of some calculations.
> For example, some range of numbers that used to overflow to infinity by
> performing the multiplication by 180, will now not overflow and will return a
> valid result.

This also applies to very small quantities in toRadians where dividing by 180 may have previously resulted in a zero.

Cheers,

Mike

On Sep 22 2014, at 14:10 , Brian Burkhalter <Brian.Burkhalter at oracle.com> wrote:

> Hello,
> 
> Another relatively small numerics fix:
> 
> Issue:	https://bugs.openjdk.java.net/browse/JDK-4477961
> Webrev:	http://cr.openjdk.java.net/~bpb/4477961/webrev.00/
> 
> Summary: Change constructs like ?a * B / C? and ?u / V * W? to ?x * (Y / Z)? where lower case denotes a variable and upper case a constant. This forces the constant value (Y / Z) to be evaluated only once per VM instance, and replaces division of the variable with multiplication. The resulting performance improvement is more than 300% as measure by JMH on a MacBookPro11,1 dual core i7 running Mac OS 10.9.5.
> 
> Thanks,
> 
> Brian



From xueming.shen at oracle.com  Mon Sep 22 21:46:48 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 22 Sep 2014 14:46:48 -0700
Subject: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return
	4 for UTF-8
In-Reply-To: <5420833F.1040102@oracle.com>
References: <5420833F.1040102@oracle.com>
Message-ID: <542098C8.60803@oracle.com>

On 09/22/2014 01:14 PM, Ivan Gerasimov wrote:
> Hello!
>
> The UTF-8 encoding allows characters that are 4 bytes long.
> However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which is not always enough.
>
> Would you please review the simple fix for this issue?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058875
> WEBREV: http://cr.openjdk.java.net/~igerasim/8058875/0/webrev/
>
> Sincerely yours,
> Ivan

The "character" in the nio Charset and CharDe/Encoder is specified as "sixteen-bit Unicode
code unit", so it is reasonable to interpret the "character" in the "maximum number of bytes
that will be produced for each character of input" to be the Java "char" as well. In case of
UTF8, each 4-byte form supplementary character is always coded into 2 surrogate chars,
it's "2 byte per char". Do we have a real escalation that complains about this?

-Sherman


From markt at apache.org  Mon Sep 22 21:34:53 2014
From: markt at apache.org (Mark Thomas)
Date: Mon, 22 Sep 2014 22:34:53 +0100
Subject: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return
	4 for UTF-8
In-Reply-To: <CA+kOe0-fD0==NOZQo_pOvSziGsZNkTwuUZghOiyqf0zqk7FJiA@mail.gmail.com>
References: <5420833F.1040102@oracle.com>
	<CA+kOe0-fD0==NOZQo_pOvSziGsZNkTwuUZghOiyqf0zqk7FJiA@mail.gmail.com>
Message-ID: <542095FD.50300@apache.org>

On 22/09/2014 22:23, Martin Buchholz wrote:
> I think you are mistaken. It's maxBytesPerChar, not maxBytesPerCodepoint!

You are going to have to explain that some more. The Javadoc for
CharsetEncoder.maxBytesPerChar() is explicit:
<quote>
Returns the maximum number of bytes that will be produced for each
character of input.
</quote>

For UTF-8 that number is 4, not 3. A quick look at the source for the
default UTF-8 encoder confirms that there are cases where it will output
4 bytes for a single input character.

Mark


> 
> 
> changeset:   3116:b44704ce8a08
> user:        sherman
> date:        2010-11-19 12:58 -0800
> 6957230: CharsetEncoder.maxBytesPerChar() reports 4 for UTF-8; should be 3
> Summary: changged utf-8's CharsetEncoder.maxBytesPerChar to 3
> Reviewed-by: alanb
> 
> 
> On Mon, Sep 22, 2014 at 1:14 PM, Ivan Gerasimov <ivan.gerasimov at oracle.com>
> wrote:
> 
>> Hello!
>>
>> The UTF-8 encoding allows characters that are 4 bytes long.
>> However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which is
>> not always enough.
>>
>> Would you please review the simple fix for this issue?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058875
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8058875/0/webrev/
>>
>> Sincerely yours,
>> Ivan
>>



From brian.burkhalter at oracle.com  Mon Sep 22 21:41:18 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 Sep 2014 14:41:18 -0700
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be
	optimized
In-Reply-To: <932DF2E3-6CE1-486D-BA26-07FD974404EE@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
	<932DF2E3-6CE1-486D-BA26-07FD974404EE@oracle.com>
Message-ID: <5B8C9C61-E9FD-4F5A-9735-EE835331CF3A@oracle.com>

Indeed these considerations made me a little nervous about the change. For the edge cases which would have previously overflowed or underflowed this does not seem like a problem, i.e., to obtain a valid result where one would not have done before. For the cases in between however I suppose that there will be some numerical inconsistencies between the two versions.

Brian

On Sep 22, 2014, at 2:24 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> Looks fine.
> 
> I think it is always important note when a change may result in different results for some inputs. I will reiterate for the record what's mentioned in the bug:
> 
>> However, one caveat is that this may affect the results of some calculations.
>> For example, some range of numbers that used to overflow to infinity by
>> performing the multiplication by 180, will now not overflow and will return a
>> valid result.
> 
> This also applies to very small quantities in toRadians where dividing by 180 may have previously resulted in a zero.



From markt at apache.org  Mon Sep 22 21:42:43 2014
From: markt at apache.org (Mark Thomas)
Date: Mon, 22 Sep 2014 22:42:43 +0100
Subject: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return
	4 for UTF-8
In-Reply-To: <542098C8.60803@oracle.com>
References: <5420833F.1040102@oracle.com> <542098C8.60803@oracle.com>
Message-ID: <542097D3.4040103@apache.org>

On 22/09/2014 22:46, Xueming Shen wrote:
> On 09/22/2014 01:14 PM, Ivan Gerasimov wrote:
>> Hello!
>>
>> The UTF-8 encoding allows characters that are 4 bytes long.
>> However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which
>> is not always enough.
>>
>> Would you please review the simple fix for this issue?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058875
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8058875/0/webrev/
>>
>> Sincerely yours,
>> Ivan
> 
> The "character" in the nio Charset and CharDe/Encoder is specified as
> "sixteen-bit Unicode
> code unit", so it is reasonable to interpret the "character" in the
> "maximum number of bytes
> that will be produced for each character of input" to be the Java "char"
> as well. In case of
> UTF8, each 4-byte form supplementary character is always coded into 2
> surrogate chars,
> it's "2 byte per char". Do we have a real escalation that complains
> about this?

Ah. Got it. I see now. There are single chars that will result in 3
bytes of output but to get 4 bytes of output requires 2 chars of input.

In which case the current value of 3.0 makes sense.

Cheers,

Mark


From aleksey.shipilev at oracle.com  Mon Sep 22 21:43:47 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 23 Sep 2014 01:43:47 +0400
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could
	be optimized
In-Reply-To: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
Message-ID: <54209813.5050407@oracle.com>

Hi Brian,

Looks OK.

On 09/23/2014 01:10 AM, Brian Burkhalter wrote:
> Summary: Change constructs like ?a * B / C? and ?u / V * W? to ?x *
> (Y / Z)? where lower case denotes a variable and upper case a
> constant. This forces the constant value (Y / Z) to be evaluated only
> once per VM instance, and replaces division of the variable with
> multiplication. The resulting performance improvement is more than
> 300% as measure by JMH on a MacBookPro11,1 dual core i7 running Mac
> OS 10.9.5.

Hm, and this compiler transformation works in strictfp context? I hope
compilers do the constant folding in strictfp/fdlibm mode...

I would probably just go and declare the private compile-time constants.
This is safer, since: a) you are not at the mercy of optimizing compiler
anymore (have you tried the benchmark with C1?); b) the initializing
expressions are FP-strict, less opportunity for hard to diagnose numeric
problem.

-Aleksey.



From martinrb at google.com  Mon Sep 22 21:44:18 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 22 Sep 2014 14:44:18 -0700
Subject: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4
	for UTF-8
In-Reply-To: <542095FD.50300@apache.org>
References: <5420833F.1040102@oracle.com>
	<CA+kOe0-fD0==NOZQo_pOvSziGsZNkTwuUZghOiyqf0zqk7FJiA@mail.gmail.com>
	<542095FD.50300@apache.org>
Message-ID: <CA+kOe09A2msU4LfYhkYsbLpz1ucONicmFymcjqBjyiMP+N_5JQ@mail.gmail.com>

Much of the documentation (especially the early stuff when supplementary
characters were rarer/nonexistent) doesn't distinguish between "character
(codepoint)" and "char" clearly enough.  Fixing that in all the docs would
be a fine thing to do.

On Mon, Sep 22, 2014 at 2:34 PM, Mark Thomas <markt at apache.org> wrote:

> On 22/09/2014 22:23, Martin Buchholz wrote:
> > I think you are mistaken. It's maxBytesPerChar, not maxBytesPerCodepoint!
>
> You are going to have to explain that some more. The Javadoc for
> CharsetEncoder.maxBytesPerChar() is explicit:
> <quote>
> Returns the maximum number of bytes that will be produced for each
> character of input.
> </quote>
>
> For UTF-8 that number is 4, not 3. A quick look at the source for the
> default UTF-8 encoder confirms that there are cases where it will output
> 4 bytes for a single input character.
>
> Mark
>
>
> >
> >
> > changeset:   3116:b44704ce8a08
> > user:        sherman
> > date:        2010-11-19 12:58 -0800
> > 6957230: CharsetEncoder.maxBytesPerChar() reports 4 for UTF-8; should be
> 3
> > Summary: changged utf-8's CharsetEncoder.maxBytesPerChar to 3
> > Reviewed-by: alanb
> >
> >
> > On Mon, Sep 22, 2014 at 1:14 PM, Ivan Gerasimov <
> ivan.gerasimov at oracle.com>
> > wrote:
> >
> >> Hello!
> >>
> >> The UTF-8 encoding allows characters that are 4 bytes long.
> >> However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which
> is
> >> not always enough.
> >>
> >> Would you please review the simple fix for this issue?
> >>
> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058875
> >> WEBREV: http://cr.openjdk.java.net/~igerasim/8058875/0/webrev/
> >>
> >> Sincerely yours,
> >> Ivan
> >>
>
>


From mike.duigou at oracle.com  Mon Sep 22 21:48:25 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 22 Sep 2014 14:48:25 -0700
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be
	optimized
In-Reply-To: <5B8C9C61-E9FD-4F5A-9735-EE835331CF3A@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
	<932DF2E3-6CE1-486D-BA26-07FD974404EE@oracle.com>
	<5B8C9C61-E9FD-4F5A-9735-EE835331CF3A@oracle.com>
Message-ID: <B1388410-7353-4318-A29B-E8C3444C113A@oracle.com>

Hi Brian;

I thought it was worth mentioning because I had had to deal with the underflow issue in the mapping software for the Audi/Stanford autonomous. For various reasons that system ends up with many very-tiny-but-non-zero quantities in it's mapping and heading component and I initially had trouble matching results against the Matlab implementation. Since I had to also reduce quantities to -? < x <= ? and -180 < x <= 180 I combined the reduce and convert using an approach similar to this revised implementation.

Mike


On Sep 22 2014, at 14:41 , Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Indeed these considerations made me a little nervous about the change. For the edge cases which would have previously overflowed or underflowed this does not seem like a problem, i.e., to obtain a valid result where one would not have done before. For the cases in between however I suppose that there will be some numerical inconsistencies between the two versions.
> 
> Brian
> 
> On Sep 22, 2014, at 2:24 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
> 
>> Looks fine.
>> 
>> I think it is always important note when a change may result in different results for some inputs. I will reiterate for the record what's mentioned in the bug:
>> 
>>> However, one caveat is that this may affect the results of some calculations.
>>> For example, some range of numbers that used to overflow to infinity by
>>> performing the multiplication by 180, will now not overflow and will return a
>>> valid result.
>> 
>> This also applies to very small quantities in toRadians where dividing by 180 may have previously resulted in a zero.
> 



From brian.burkhalter at oracle.com  Mon Sep 22 21:48:56 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 Sep 2014 14:48:56 -0700
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be
	optimized
In-Reply-To: <54209813.5050407@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
	<54209813.5050407@oracle.com>
Message-ID: <E4ADF5F4-86AA-4679-9C6F-FE9791DA3097@oracle.com>

Hi Aleksey,

On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> I would probably just go and declare the private compile-time constants.
> This is safer, since: a) you are not at the mercy of optimizing compiler
> anymore (have you tried the benchmark with C1?); b) the initializing
> expressions are FP-strict, less opportunity for hard to diagnose numeric
> problem.

I actually tested with compile-time constants and the result was the same as for what I posted. Your suggestion is a good one however so I will update and repost.

Thanks,

Brian

From brian.burkhalter at oracle.com  Mon Sep 22 21:55:26 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 Sep 2014 14:55:26 -0700
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be
	optimized
In-Reply-To: <B1388410-7353-4318-A29B-E8C3444C113A@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
	<932DF2E3-6CE1-486D-BA26-07FD974404EE@oracle.com>
	<5B8C9C61-E9FD-4F5A-9735-EE835331CF3A@oracle.com>
	<B1388410-7353-4318-A29B-E8C3444C113A@oracle.com>
Message-ID: <429CAB5A-9E1C-4B2A-A9A3-D3D0FFA2B6D6@oracle.com>

Hi Mike,

It?s definitely worth mentioning and something which should be taken into consideration when considering the change.

Thanks,

Brian

On Sep 22, 2014, at 2:48 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> I thought it was worth mentioning because I had had to deal with the underflow issue in the mapping software for the Audi/Stanford autonomous. For various reasons that system ends up with many very-tiny-but-non-zero quantities in it's mapping and heading component and I initially had trouble matching results against the Matlab implementation. Since I had to also reduce quantities to -? < x <= ? and -180 < x <= 180 I combined the reduce and convert using an approach similar to this revised implementation.


From claes.redestad at oracle.com  Mon Sep 22 21:55:39 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 22 Sep 2014 23:55:39 +0200
Subject: RFR: 8058887: (fmt) Improve java/util/Formatter test coverage
	of group separators and width
In-Reply-To: <54208DE6.5000209@oracle.com>
References: <54203398.7030003@oracle.com> <5420724D.1080602@oracle.com>
	<54208DE6.5000209@oracle.com>
Message-ID: <54209ADB.3080600@oracle.com>

Fair enough! I removed the Spp changes and and regenerated the test 
files using the original script:

http://cr.openjdk.java.net/~redestad/8058887/webrev.04/

Thanks!

/Claes

On 2014-09-22 23:00, Xueming Shen wrote:
> It was on purpose to keep those blank lines when I wrote the Spp to 
> replace the original
> script. it serves the purpose of preserving  the line number the 
> generated source code
> (identical to the ln# of the same code line in template file). This is 
> convenient/import
> when debugging those generated nio source files with a specific line 
> number, from
> exception stack trace, for example.
>
> -sherman
>
> On 09/22/2014 12:02 PM, Claes Redestad wrote:
>> Hi,
>>
>> previous attempt was considered too trivial a fix, so how about 
>> actually improving the test coverage, fixing the link issue in 
>> genBasic and upgrade Spp.java to not add thousands of empty lines 
>> while we're at it? Rejoice!
>>
>> webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.03/
>>
>> Most relevant files to review are:
>>
>> http://cr.openjdk.java.net/~redestad/8058887/webrev.03/test/java/util/Formatter/Basic-X.java.template.udiff.html 
>>
>> http://cr.openjdk.java.net/~redestad/8058887/webrev.03/make/src/classes/build/tools/spp/Spp.java.udiff.html 
>>
>> http://cr.openjdk.java.net/~redestad/8058887/webrev.03/test/java/util/Formatter/genBasic.sh.udiff.html 
>>
>>
>> ... while the others are generated from the update Spp.java tool 
>> using the fixed genBasic.sh.
>>
>> /Claes
>>
>> On 09/22/2014 04:35 PM, Claes Redestad wrote:
>>> Hi,
>>>
>>> can I have a review and sponsor for this trivial fix to make the 
>>> jtreg test generator script jdk/test/java/util/Formatter/genBasic.sh 
>>> work in the new build system?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8058887
>>> webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.01/
>>>
>>> /Claes
>>
>



From brian.burkhalter at oracle.com  Mon Sep 22 22:34:08 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 Sep 2014 15:34:08 -0700
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be
	optimized
In-Reply-To: <54209813.5050407@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
	<54209813.5050407@oracle.com>
Message-ID: <2F45659E-F243-4137-9AAB-FF0841D4DF6A@oracle.com>

Hi Aleksey,

On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> Hm, and this compiler transformation works in strictfp context? I hope
> compilers do the constant folding in strictfp/fdlibm mode?

Yes.

> I would probably just go and declare the private compile-time constants.
> This is safer, since: a) you are not at the mercy of optimizing compiler
> anymore (have you tried the benchmark with C1?); b) the initializing
> expressions are FP-strict, less opportunity for hard to diagnose numeric
> problem.

I created an alternate webrev using compile-time constants per your suggestion:

http://cr.openjdk.java.net/~bpb/4477961/webrev.01/

The performance improvement is similar to that cited for webrev.00.

If this version is preferable it will need approval from a JDK 9 Reviewer, of course.

Thanks,

Brian

From mike.duigou at oracle.com  Mon Sep 22 23:24:30 2014
From: mike.duigou at oracle.com (Mike Duigou)
Date: Mon, 22 Sep 2014 16:24:30 -0700
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be
	optimized
In-Reply-To: <2F45659E-F243-4137-9AAB-FF0841D4DF6A@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
	<54209813.5050407@oracle.com>
	<2F45659E-F243-4137-9AAB-FF0841D4DF6A@oracle.com>
Message-ID: <A4E16E3A-8030-4784-BA9E-9C742A8867C8@oracle.com>

Looks fine to me!

Mike

On Sep 22 2014, at 15:34 , Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> Hi Aleksey,
> 
> On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
>> Hm, and this compiler transformation works in strictfp context? I hope
>> compilers do the constant folding in strictfp/fdlibm mode?
> 
> Yes.
> 
>> I would probably just go and declare the private compile-time constants.
>> This is safer, since: a) you are not at the mercy of optimizing compiler
>> anymore (have you tried the benchmark with C1?); b) the initializing
>> expressions are FP-strict, less opportunity for hard to diagnose numeric
>> problem.
> 
> I created an alternate webrev using compile-time constants per your suggestion:
> 
> http://cr.openjdk.java.net/~bpb/4477961/webrev.01/
> 
> The performance improvement is similar to that cited for webrev.00.
> 
> If this version is preferable it will need approval from a JDK 9 Reviewer, of course.
> 
> Thanks,
> 
> Brian



From brian.burkhalter at oracle.com  Mon Sep 22 23:36:50 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 Sep 2014 16:36:50 -0700
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be
	optimized
In-Reply-To: <A4E16E3A-8030-4784-BA9E-9C742A8867C8@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
	<54209813.5050407@oracle.com>
	<2F45659E-F243-4137-9AAB-FF0841D4DF6A@oracle.com>
	<A4E16E3A-8030-4784-BA9E-9C742A8867C8@oracle.com>
Message-ID: <656D0A79-1278-4DB1-971D-7AA2B79B77A6@oracle.com>

Hi  Mike,

Thanks for the review.

For the sake of completeness I tested converting 89.0 * Double.MIN_VALUE to radians and Double.MAX_VALUE / 89.0 to degrees. The old version gives 0.0 and Double.POSITIVE_INFINITY, respectively, whereas the webrev.01 version gives the respective results 1.0E-323 and 1.1573059492949775E308.

Brian

On Sep 22, 2014, at 4:24 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> Looks fine to me!
> 
> Mike
> 
> On Sep 22 2014, at 15:34 , Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
>> Hi Aleksey,
>> 
>> On Sep 22, 2014, at 2:43 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
>> 
>>> Hm, and this compiler transformation works in strictfp context? I hope
>>> compilers do the constant folding in strictfp/fdlibm mode?
>> 
>> Yes.
>> 
>>> I would probably just go and declare the private compile-time constants.
>>> This is safer, since: a) you are not at the mercy of optimizing compiler
>>> anymore (have you tried the benchmark with C1?); b) the initializing
>>> expressions are FP-strict, less opportunity for hard to diagnose numeric
>>> problem.
>> 
>> I created an alternate webrev using compile-time constants per your suggestion:
>> 
>> http://cr.openjdk.java.net/~bpb/4477961/webrev.01/
>> 
>> The performance improvement is similar to that cited for webrev.00.
>> 
>> If this version is preferable it will need approval from a JDK 9 Reviewer, of course.
>> 
>> Thanks,
>> 
>> Brian
> 



From stevenschlansker at gmail.com  Mon Sep 22 23:52:56 2014
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Mon, 22 Sep 2014 16:52:56 -0700
Subject: java.time.Clock$TickClock wrong javadoc
Message-ID: <B8FB90EF-4C76-44A4-BD20-485402CB5146@gmail.com>

Hi core-libs-dev,

Quick note that it seems that the Javadoc for Clock$TickClock has copypasta from Clock$OffsetClock.
Not a huge deal for a non-public class but probably worth fixing.

http://hg.openjdk.java.net/jdk9/client/jdk/file/5edbebb72540/src/java.base/share/classes/java/time/Clock.java

    /**
     * Implementation of a clock that adds an offset to an underlying clock.
     */
    static final class OffsetClock extends Clock implements Serializable {

    /**
     * Implementation of a clock that adds an offset to an underlying clock.
     */
    static final class TickClock extends Clock implements Serializable {



From joe.darcy at oracle.com  Tue Sep 23 02:51:06 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 22 Sep 2014 19:51:06 -0700
Subject: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not
	consider required no. of fraction digits properly
In-Reply-To: <016FF767-532C-4658-912D-3E8119532C57@oracle.com>
References: <540F66B4.1080400@oracle.com>
	<5411C8C9.8000400@oracle.com>	<541C05F6.80709@oracle.com>	<143C890A-9D8B-4ADA-8E91-E9BA2EFEF1D7@oracle.com>	<542038B1.7090000@oracle.com>
	<016FF767-532C-4658-912D-3E8119532C57@oracle.com>
Message-ID: <5420E01A.30406@oracle.com>

Hello,

I've looked over the proposed changeset as well.

I don't see a problem with the code, but I'm not (yet) convinced it is 
right.

For future work, I think be clearer to combine the CEILING and FLOOR 
cases to share a loop with a condition test based on CEILING/FLOOR lie. 
In the test, again for future work, I think it would be clearer to 
create a custom class to represent the tuple of information needed for a 
test case as opposed to spreading that information about over a set of 
parallel arrays.

For the new work in question, it might be clearer to me if the HALF_UP 
and HALF_DOWN cases were combined into a single block since they share 
much of the logic. The unique logic for each mode would be easier to see 
if the differences were placed together.

Thanks,

-Joe

On 09/22/2014 08:50 AM, Brian Burkhalter wrote:
> Hi Olivier,
>
> On Sep 22, 2014, at 7:56 AM, olivier.lagneau at oracle.com wrote:
>
>>> and 2) use braces around all the statements contained in if/else blocks (see below). Comment #2 is nit-picky.
>> I tried to keep the same flavour of writing as in HALF_DOWN and HALF_EVEN cases, i.e. don't use brace for
>> terminal/leaf return true/false statements. This is not the standard however, at least in this file.
>> Will use braces in all case (i.e. the 3 of HALF_UP,  HALF_DOWN and HALF_EVEN).
> I did not look at the other case. If your formatting matches the rest of the file then I think it is OK to leave it as-is.
>
>>> Lastly and this is not really part of your changeset, but I found it curious that the test prints the details of all cases that succeed as opposed to those that fail. I would think that either all results or the failures alone ought to be printed instead of successes only. See for example the partial diff below the DigitList diff.
>> Since these are most often corner and tricky test cases I think it interesting to have the details of each result,
>> including infos of both why returned result is correct or wrong.
>> That can help the reader to understand all these tricky cases.
>> The bad side of it being that it prints a lot of text, with failure cases (hoepfully few) lost in the middle of it,
>> thus making failures possibly not immediate to detect.
>>
>> Here is an example of what is printed in case of failure:
>> "
>> ========================================
>> ***Error formatting double value from string : 0.6868d
>> NumberFormat pattern is  : #,##0.###
>> Maximum number of fractional digits : 3
>> Fractional rounding digit : 4
>> Position of value relative to tie : above
>> Rounding Mode : HALF_UP
>> BigDecimal output : 0.68679999999999996607158436745521612465381622314453125
>> FloatingDecimal output : 0.6868
>> Error. Formatted result different from expected.
>> Expected output is : "0.687"
>> Formated output is : "0.686"
>> ========================================
> I missed that output: I was looking for the word ?failure.?
>
>> There is also a reminder of the number of errors at the end of the report:
>> "
>> ==> 4 tests failed
>>
>> Test failed with 4 formating error(s).
>> "
>>
>> May be providing a reminder (value + rounding-mode + rounding position)
>> of the failure cases at the end of the would be better ?
>> Like:
>> "
>> Test failed with 4 formating error(s) for following cases :
>> - 0.3126d, HALF_UP rounding, 3 fractional digits
>> - 0.6868d, HALF_UP rounding, 3 fractional digits
>> - 1.798876d, HALF_UP rounding, 5 fractional digits
>> - 1.796889d, HALF_UP rounding, 5 fractional digits
>> "
>>
>> Would doing so be ok ?
> If the test is already printing out the information you showed above (?Error formatting ??) then I think it is enough but the verbiage should perhaps match the reminder, e.g., ?Failure: Error formatting double ??
>
> Thanks,
>
> Brian



From aleksey.shipilev at oracle.com  Tue Sep 23 06:42:23 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 23 Sep 2014 10:42:23 +0400
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could
	be optimized
In-Reply-To: <2F45659E-F243-4137-9AAB-FF0841D4DF6A@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
	<54209813.5050407@oracle.com>
	<2F45659E-F243-4137-9AAB-FF0841D4DF6A@oracle.com>
Message-ID: <5421164F.7070306@oracle.com>

Hi Brian,

On 09/23/2014 02:34 AM, Brian Burkhalter wrote:
> I created an alternate webrev using compile-time constants per your
> suggestion:
> 
> http://cr.openjdk.java.net/~bpb/4477961/webrev.01/
> <http://cr.openjdk.java.net/%7Ebpb/4477961/webrev.01/>

Ah, sorry for confusing language about "compile-time constants", I meant
"compile-time constant expression", as per JLS 15.28. Constant
expressions are FP-strict, so it should be just fine correctness- and
performance-wise, and less cryptic:
 private static final double DEGREES_TO_RADIANS = PI / 180.0;

Thanks,
-Aleksey.



From ivan.gerasimov at oracle.com  Tue Sep 23 07:37:07 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 23 Sep 2014 11:37:07 +0400
Subject: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return
	4 for UTF-8
In-Reply-To: <542098C8.60803@oracle.com>
References: <5420833F.1040102@oracle.com> <542098C8.60803@oracle.com>
Message-ID: <54212323.5080907@oracle.com>

Martin, Sherman thanks for clarification!

Closing the bug as not a bug.

> The "character" in the nio Charset and CharDe/Encoder is specified as 
> "sixteen-bit Unicode
> code unit", so it is reasonable to interpret the "character" in the 
> "maximum number of bytes
> that will be produced for each character of input" to be the Java 
> "char" as well. In case of
> UTF8, each 4-byte form supplementary character is always coded into 2 
> surrogate chars,
> it's "2 byte per char".

> Do we have a real escalation that complains about this?
>
Yes, the link in on the bug page: 
https://bugs.openjdk.java.net/browse/JDK-8058875
I'm going to try to explain what I've just realized about this function :-)

Sincerely yours,
Ivan


From olivier.lagneau at oracle.com  Tue Sep 23 11:54:21 2014
From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com)
Date: Tue, 23 Sep 2014 13:54:21 +0200
Subject: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not
	consider required no. of fraction digits properly
In-Reply-To: <016FF767-532C-4658-912D-3E8119532C57@oracle.com>
References: <540F66B4.1080400@oracle.com> <5411C8C9.8000400@oracle.com>
	<541C05F6.80709@oracle.com>
	<143C890A-9D8B-4ADA-8E91-E9BA2EFEF1D7@oracle.com>
	<542038B1.7090000@oracle.com>
	<016FF767-532C-4658-912D-3E8119532C57@oracle.com>
Message-ID: <54215F6D.1010308@oracle.com>

Thanks Brian,

Will take into account  your  wording remarks.

Olivier.
On 22/09/2014 17:50, Brian Burkhalter wrote:
> Hi Olivier,
>
> On Sep 22, 2014, at 7:56 AM, olivier.lagneau at oracle.com 
> <mailto:olivier.lagneau at oracle.com> wrote:
>
>>> and 2) use braces around all the statements contained in if/else 
>>> blocks (see below). Comment #2 is nit-picky.
>> I tried to keep the same flavour of writing as in HALF_DOWN and 
>> HALF_EVEN cases, i.e. don't use brace for
>> terminal/leaf return true/false statements. This is not the standard 
>> however, at least in this file.
>> Will use braces in all case (i.e. the 3 of HALF_UP,  HALF_DOWN and 
>> HALF_EVEN).
>
> I did not look at the other case. If your formatting matches the rest 
> of the file then I think it is OK to leave it as-is.
>
>>> Lastly and this is not really part of your changeset, but I found it 
>>> curious that the test prints the details of all cases that succeed 
>>> as opposed to those that fail. I would think that either all results 
>>> or the failures alone ought to be printed instead of successes only. 
>>> See for example the partial diff below the DigitList diff.
>> Since these are most often corner and tricky test cases I think it 
>> interesting to have the details of each result,
>> including infos of both why returned result is correct or wrong.
>> That can help the reader to understand all these tricky cases.
>> The bad side of it being that it prints a lot of text, with failure 
>> cases (hoepfully few) lost in the middle of it,
>> thus making failures possibly not immediate to detect.
>>
>> Here is an example of what is printed in case of failure:
>> "
>> ========================================
>> ***Error formatting double value from string : 0.6868d
>> NumberFormat pattern is  : #,##0.###
>> Maximum number of fractional digits : 3
>> Fractional rounding digit : 4
>> Position of value relative to tie : above
>> Rounding Mode : HALF_UP
>> BigDecimal output : 
>> 0.68679999999999996607158436745521612465381622314453125
>> FloatingDecimal output : 0.6868
>> Error. Formatted result different from expected.
>> Expected output is : "0.687"
>> Formated output is : "0.686"
>> ========================================
>
> I missed that output: I was looking for the word ?failure.?
>
>> There is also a reminder of the number of errors at the end of the 
>> report:
>> "
>> ==> 4 tests failed
>>
>> Test failed with 4 formating error(s).
>> "
>>
>> May be providing a reminder (value + rounding-mode + rounding position)
>> of the failure cases at the end of the would be better ?
>> Like:
>> "
>> Test failed with 4 formating error(s) for following cases :
>> - 0.3126d, HALF_UP rounding, 3 fractional digits
>> - 0.6868d, HALF_UP rounding, 3 fractional digits
>> - 1.798876d, HALF_UP rounding, 5 fractional digits
>> - 1.796889d, HALF_UP rounding, 5 fractional digits
>> "
>>
>> Would doing so be ok ?
>
> If the test is already printing out the information you showed above 
> (?Error formatting ??) then I think it is enough but the verbiage 
> should perhaps match the reminder, e.g., ?Failure: Error formatting 
> double ??
>
> Thanks,
>
> Brian



From olivier.lagneau at oracle.com  Tue Sep 23 12:21:50 2014
From: olivier.lagneau at oracle.com (olivier.lagneau at oracle.com)
Date: Tue, 23 Sep 2014 14:21:50 +0200
Subject: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not
	consider required no. of fraction digits properly
In-Reply-To: <5420E01A.30406@oracle.com>
References: <540F66B4.1080400@oracle.com>
	<5411C8C9.8000400@oracle.com>	<541C05F6.80709@oracle.com>	<143C890A-9D8B-4ADA-8E91-E9BA2EFEF1D7@oracle.com>	<542038B1.7090000@oracle.com>
	<016FF767-532C-4658-912D-3E8119532C57@oracle.com>
	<5420E01A.30406@oracle.com>
Message-ID: <542165DE.4000405@oracle.com>

Hi Joe,

Thanks a lot for taking the time to review !

Please see comments inlined.

On 23/09/2014 04:51, Joe Darcy wrote:
> Hello,
>
> I've looked over the proposed changeset as well.
>
> I don't see a problem with the code, but I'm not (yet) convinced it is 
> right.
>
> For future work, I think be clearer to combine the CEILING and FLOOR 
> cases to share a loop with a condition test based on CEILING/FLOOR lie.
Agreed.
> In the test, again for future work, I think it would be clearer to 
> create a custom class to represent the tuple of information needed for 
> a test case as opposed to spreading that information about over a set 
> of parallel arrays.
Sure. With this set of separate independent arrays, the test is 
currently not much readable, and is weak with regards of maintenance
and evolutivity.
>
> For the new work in question, it might be clearer to me if the HALF_UP 
> and HALF_DOWN cases were combined into a single block since they share 
> much of the logic. The unique logic for each mode would be easier to 
> see if the differences were placed together.
I think so too. I even think it might be good to group HALF_EVEN with 
those two, since behaviour of dtoa impacts
these 3 cases in the same manner when very close to tie.

Will change the code to group HALF_UP and HALF_DOWN.

Thanks,
Olivier.

>
> Thanks,
>
> -Joe
>
> On 09/22/2014 08:50 AM, Brian Burkhalter wrote:
>> Hi Olivier,
>>
>> On Sep 22, 2014, at 7:56 AM, olivier.lagneau at oracle.com wrote:
>>
>>>> and 2) use braces around all the statements contained in if/else 
>>>> blocks (see below). Comment #2 is nit-picky.
>>> I tried to keep the same flavour of writing as in HALF_DOWN and 
>>> HALF_EVEN cases, i.e. don't use brace for
>>> terminal/leaf return true/false statements. This is not the standard 
>>> however, at least in this file.
>>> Will use braces in all case (i.e. the 3 of HALF_UP,  HALF_DOWN and 
>>> HALF_EVEN).
>> I did not look at the other case. If your formatting matches the rest 
>> of the file then I think it is OK to leave it as-is.
>>
>>>> Lastly and this is not really part of your changeset, but I found 
>>>> it curious that the test prints the details of all cases that 
>>>> succeed as opposed to those that fail. I would think that either 
>>>> all results or the failures alone ought to be printed instead of 
>>>> successes only. See for example the partial diff below the 
>>>> DigitList diff.
>>> Since these are most often corner and tricky test cases I think it 
>>> interesting to have the details of each result,
>>> including infos of both why returned result is correct or wrong.
>>> That can help the reader to understand all these tricky cases.
>>> The bad side of it being that it prints a lot of text, with failure 
>>> cases (hoepfully few) lost in the middle of it,
>>> thus making failures possibly not immediate to detect.
>>>
>>> Here is an example of what is printed in case of failure:
>>> "
>>> ========================================
>>> ***Error formatting double value from string : 0.6868d
>>> NumberFormat pattern is  : #,##0.###
>>> Maximum number of fractional digits : 3
>>> Fractional rounding digit : 4
>>> Position of value relative to tie : above
>>> Rounding Mode : HALF_UP
>>> BigDecimal output : 
>>> 0.68679999999999996607158436745521612465381622314453125
>>> FloatingDecimal output : 0.6868
>>> Error. Formatted result different from expected.
>>> Expected output is : "0.687"
>>> Formated output is : "0.686"
>>> ========================================
>> I missed that output: I was looking for the word ?failure.?
>>
>>> There is also a reminder of the number of errors at the end of the 
>>> report:
>>> "
>>> ==> 4 tests failed
>>>
>>> Test failed with 4 formating error(s).
>>> "
>>>
>>> May be providing a reminder (value + rounding-mode + rounding position)
>>> of the failure cases at the end of the would be better ?
>>> Like:
>>> "
>>> Test failed with 4 formating error(s) for following cases :
>>> - 0.3126d, HALF_UP rounding, 3 fractional digits
>>> - 0.6868d, HALF_UP rounding, 3 fractional digits
>>> - 1.798876d, HALF_UP rounding, 5 fractional digits
>>> - 1.796889d, HALF_UP rounding, 5 fractional digits
>>> "
>>>
>>> Would doing so be ok ?
>> If the test is already printing out the information you showed above 
>> (?Error formatting ??) then I think it is enough but the verbiage 
>> should perhaps match the reminder, e.g., ?Failure: Error formatting 
>> double ??
>>
>> Thanks,
>>
>> Brian
>



From roger.riggs at oracle.com  Tue Sep 23 13:48:58 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 23 Sep 2014 09:48:58 -0400
Subject: java.time.Clock$TickClock wrong javadoc
In-Reply-To: <B8FB90EF-4C76-44A4-BD20-485402CB5146@gmail.com>
References: <B8FB90EF-4C76-44A4-BD20-485402CB5146@gmail.com>
Message-ID: <54217A4A.1010203@oracle.com>

Hi,

Filed  https://bugs.openjdk.java.net/browse/JDK-8058957

Given the review and testing cycle overhead; its probably not worth 
fixing (at least by itself).

Thanks, Roger

On 9/22/2014 7:52 PM, Steven Schlansker wrote:
> Hi core-libs-dev,
>
> Quick note that it seems that the Javadoc for Clock$TickClock has copypasta from Clock$OffsetClock.
> Not a huge deal for a non-public class but probably worth fixing.
>
> http://hg.openjdk.java.net/jdk9/client/jdk/file/5edbebb72540/src/java.base/share/classes/java/time/Clock.java
>
>      /**
>       * Implementation of a clock that adds an offset to an underlying clock.
>       */
>      static final class OffsetClock extends Clock implements Serializable {
>
>      /**
>       * Implementation of a clock that adds an offset to an underlying clock.
>       */
>      static final class TickClock extends Clock implements Serializable {
>



From Thomas.Salter at unisys.com  Tue Sep 23 14:58:54 2014
From: Thomas.Salter at unisys.com (Salter, Thomas A)
Date: Tue, 23 Sep 2014 09:58:54 -0500
Subject: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4
	for UTF-8
In-Reply-To: <mailman.17569.1411480150.10816.core-libs-dev@openjdk.java.net>
References: <mailman.17569.1411480150.10816.core-libs-dev@openjdk.java.net>
Message-ID: <63D5DCACD1E9E34C89C8203C64F521C301930651F482@USEA-EXCH7.na.uis.unisys.com>

This response confuses me.  Are you saying that the UTF8 encoder is not really producing UTF8?  RFC 2279 and 3629 both clearly state that surrogates must be combined to form a 32-bit value which is then encoded as a 4-byte sequence.  In fact, the RFCs refer to the alternate encoding CESU_8 definition which encodes each half of the surrogate pair as a 3-byte UTF-8 sequence.

I guess returning 3.0 for maxBytesPerChar works for the purpose of allocating a big enough byte buffer, but the explanation in this thread is confusing.

Tom Salter

------------------------------
Date: Tue, 23 Sep 2014 11:37:07 +0400
From: Ivan Gerasimov <ivan.gerasimov at oracle.com>
To: Xueming Shen <xueming.shen at oracle.com>,	Martin Buchholz
	<martinrb at google.com>
Cc: nio-dev at openjdk.java.net, core-libs-dev
	<core-libs-dev at openjdk.java.net>
Subject: Re: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should
	return	4 for UTF-8
Message-ID: <54212323.5080907 at oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

Martin, Sherman thanks for clarification!

Closing the bug as not a bug.

> The "character" in the nio Charset and CharDe/Encoder is specified as 
> "sixteen-bit Unicode
> code unit", so it is reasonable to interpret the "character" in the 
> "maximum number of bytes
> that will be produced for each character of input" to be the Java 
> "char" as well. In case of
> UTF8, each 4-byte form supplementary character is always coded into 2 
> surrogate chars,
> it's "2 byte per char".

> Do we have a real escalation that complains about this?
>
Yes, the link in on the bug page: 
https://bugs.openjdk.java.net/browse/JDK-8058875
I'm going to try to explain what I've just realized about this function :-)

Sincerely yours,
Ivan



From brian.burkhalter at oracle.com  Tue Sep 23 15:12:05 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 Sep 2014 08:12:05 -0700
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could be
	optimized
In-Reply-To: <5421164F.7070306@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
	<54209813.5050407@oracle.com>
	<2F45659E-F243-4137-9AAB-FF0841D4DF6A@oracle.com>
	<5421164F.7070306@oracle.com>
Message-ID: <10761AC5-4E05-4526-91C2-DE92CFD1C99C@oracle.com>

Hi Aleksey,

On Sep 22, 2014, at 11:42 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> On 09/23/2014 02:34 AM, Brian Burkhalter wrote:
>> I created an alternate webrev using compile-time constants per your
>> suggestion:
>> 
>> http://cr.openjdk.java.net/~bpb/4477961/webrev.01/
>> <http://cr.openjdk.java.net/%7Ebpb/4477961/webrev.01/>
> 
> Ah, sorry for confusing language about "compile-time constants", I meant
> "compile-time constant expression", as per JLS 15.28. Constant
> expressions are FP-strict, so it should be just fine correctness- and
> performance-wise, and less cryptic:
> private static final double DEGREES_TO_RADIANS = PI / 180.0;

Thanks for the clarification. As the issue is already resolved, however, I am not inclined to change the code unless there is a serious objection in which case I can file another issue.

Thanks,

Brian

From aleksey.shipilev at oracle.com  Tue Sep 23 15:15:37 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 23 Sep 2014 19:15:37 +0400
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could
	be optimized
In-Reply-To: <10761AC5-4E05-4526-91C2-DE92CFD1C99C@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>
	<54209813.5050407@oracle.com>
	<2F45659E-F243-4137-9AAB-FF0841D4DF6A@oracle.com>
	<5421164F.7070306@oracle.com>
	<10761AC5-4E05-4526-91C2-DE92CFD1C99C@oracle.com>
Message-ID: <54218E99.9070702@oracle.com>

On 09/23/2014 07:12 PM, Brian Burkhalter wrote:
>> Ah, sorry for confusing language about "compile-time constants", I meant
>> "compile-time constant expression", as per JLS 15.28. Constant
>> expressions are FP-strict, so it should be just fine correctness- and
>> performance-wise, and less cryptic:
>> private static final double DEGREES_TO_RADIANS = PI / 180.0;
> 
> Thanks for the clarification. As the issue is already resolved, however,
> I am not inclined to change the code unless there is a serious objection
> in which case I can file another issue.

Ok, that's fine, keep the constant.

-Aleksey.




From martinrb at google.com  Tue Sep 23 15:26:22 2014
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 23 Sep 2014 08:26:22 -0700
Subject: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4
	for UTF-8
In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C301930651F482@USEA-EXCH7.na.uis.unisys.com>
References: <mailman.17569.1411480150.10816.core-libs-dev@openjdk.java.net>
	<63D5DCACD1E9E34C89C8203C64F521C301930651F482@USEA-EXCH7.na.uis.unisys.com>
Message-ID: <CA+kOe09a+r61eoZrjVReYziTL4y3FAczVcLOFN2P7wbDQ2cuRw@mail.gmail.com>

Again, it's maxBytes per java "char", not maxBytes per Unicode character.

Allocating a big enough buffer is pretty much the only reason
for maxBytesPerChar' existence.

On Tue, Sep 23, 2014 at 7:58 AM, Salter, Thomas A <Thomas.Salter at unisys.com>
wrote:

> This response confuses me.  Are you saying that the UTF8 encoder is not
> really producing UTF8?  RFC 2279 and 3629 both clearly state that
> surrogates must be combined to form a 32-bit value which is then encoded as
> a 4-byte sequence.  In fact, the RFCs refer to the alternate encoding
> CESU_8 definition which encodes each half of the surrogate pair as a 3-byte
> UTF-8 sequence.
>
> I guess returning 3.0 for maxBytesPerChar works for the purpose of
> allocating a big enough byte buffer, but the explanation in this thread is
> confusing.
>
> Tom Salter
>
> ------------------------------
> Date: Tue, 23 Sep 2014 11:37:07 +0400
> From: Ivan Gerasimov <ivan.gerasimov at oracle.com>
> To: Xueming Shen <xueming.shen at oracle.com>,     Martin Buchholz
>         <martinrb at google.com>
> Cc: nio-dev at openjdk.java.net, core-libs-dev
>         <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR [8058875]: CharsetEncoder.maxBytesPerChar() should
>         return  4 for UTF-8
> Message-ID: <54212323.5080907 at oracle.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Martin, Sherman thanks for clarification!
>
> Closing the bug as not a bug.
>
> > The "character" in the nio Charset and CharDe/Encoder is specified as
> > "sixteen-bit Unicode
> > code unit", so it is reasonable to interpret the "character" in the
> > "maximum number of bytes
> > that will be produced for each character of input" to be the Java
> > "char" as well. In case of
> > UTF8, each 4-byte form supplementary character is always coded into 2
> > surrogate chars,
> > it's "2 byte per char".
>
> > Do we have a real escalation that complains about this?
> >
> Yes, the link in on the bug page:
> https://bugs.openjdk.java.net/browse/JDK-8058875
> I'm going to try to explain what I've just realized about this function :-)
>
> Sincerely yours,
> Ivan
>
>


From daniel.fuchs at oracle.com  Tue Sep 23 18:17:42 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 23 Sep 2014 20:17:42 +0200
Subject: RFR: 8043306 - Provide a replacement for the API that allowed
	to listen for LogManager configuration changes
In-Reply-To: <541857EA.3070300@oracle.com>
References: <54101EBF.7000003@oracle.com>	<5410353C.3070705@oracle.com>	<5411CB0E.9060504@oracle.com>	<54129D3E.8020200@gmail.com>	<CAEJX8orCMvB4SyM+OVfr5FduCt49QOytADTchmFdHvHYDkSO0Q@mail.gmail.com>	<5412B1B3.4090708@oracle.com>,
	<CAEJX8oqH1x6B0ix0-eiajBxDJO2RY_avjw1KqmH+aXvEVm4=Pw@mail.gmail.com>,
	<5412CEBE.3000607@oracle.com> <5412E903.5090703@oracle.com>,
	<5412F768.7050904@oracle.com> <5412FB09.6060804@oracle.com>,
	<54130047.1030805@oracle.com> <54130662.9000803@oracle.com>,
	<54130A37.8070503@oracle.com>	<BLU175-W12259009585054C5ACE4E083CD0@phx.gbl>,
	<54132534.407@oracle.com>
	<BLU175-W471CC4F5FA1389062DC2DC83CD0@phx.gbl>	<54170DC7.7090603@oracle.com>
	<54184176.701@oracle.com> <541857EA.3070300@oracle.com>
Message-ID: <5421B946.3080502@oracle.com>

Hi,

I updated the webrev at 
http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.07

      * @implNote If more than one listener terminates with an uncaught 
error or
      * exception, an implementation may record the additional errors or
      * exceptions as {@linkplain 
Throwable#addSuppressed(java.lang.Throwable)
      * suppressed exceptions}.

best regards,

-- daniel

On 16/09/14 17:31, Daniel Fuchs wrote:
> Done.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.06
>
> On 9/16/14 3:56 PM, Alan Bateman wrote:
>> On 15/09/2014 17:03, Daniel Fuchs wrote:
>>> :
>>>
>>>
>>> Here is a new webrev - with updated test case:
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8043306/webrev.05/
>>>
>> I think this quite good now.
>>
>> Just on this wording:
>>
>> "If a listener terminates with an uncaught error or exception thenthe
>> first exception that was raised will be propagated to the caller of
>> readConfiguration after all listeners have been invoked."
>>
>> I think you can shorten this a bit by dropping "that was raised" from
>> the sentence.
>>
>> Future maintainers might wonder why invokeConfigurationListeners takes a
>> snapshot of the listeners so I think that deserves a comment in the code.
>>
>> -Alan
>



From xueming.shen at oracle.com  Tue Sep 23 19:14:11 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 23 Sep 2014 12:14:11 -0700
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <54207BFE.9040907@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>
	<54207BFE.9040907@oracle.com>
Message-ID: <5421C683.9010208@oracle.com>

On 09/22/2014 12:43 PM, Claes Redestad wrote:
> Hi,
>
> Sherman pointed out that there was a path that could actually take a minor performance hit from this patch,
> which would be unacceptable. This version takes the minimal approach to addressing this by adding back a
> method operating on a char[], simplified for the specific usage case (the exponent part of a %g double formatting):
>
> http://cr.openjdk.java.net/~redestad/8050142/webrev.07/
>
> This latest patch passes using the extended test coverage of java.util.Formatter I've proposed in 8058887, see
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028849.html
>

Hi Claes,

Shouldn't we also keep the exp as char[] as well in "c == Conversion.SCIENTIFIC" case?
It appears the usage of exp is the same as the one in "GENERAL", in which we are keeping
the simple char[] for exp.

Thanks!
-Sherman

> /Claes
>
> On 09/16/2014 03:15 PM, Claes Redestad wrote:
>> Brent, Marcus,
>>
>> thank you for reviewing!
>>
>> JCK 9 tests for api/java_util api/java_lang either pass or fail with or without this patch on my machine.
>>
>> Also reran relevant jtreg tests (jdk/test/java/util/Formatter jdk/test/java/util/Formattable jdk/test/java/lang/String jdk/test/java/lang/System)
>>
>> Ok to fix nits offline without posting new webrev?
>>
>> /Claes
>>
>> On 09/16/2014 11:34 AM, Marcus Lagergren wrote:
>>> I am reviewer and they look good to me too. ~30% better performance for random indata- Do you pass the JCK? If so you have my blessing.
>>>
>>> /M
>>>
>>> On 16 Sep 2014, at 01:52, Brent Christian <brent.christian at oracle.com> wrote:
>>>
>>>> Hi, Claes
>>>>
>>>> I've looked over the latest changes, and they look good to me.  I can sponsor this.  Note that we need approval from a Reviewer.
>>>>
>>>> One small nitpick from me:
>>>> 2914:
>>>> If the text is left-justified, then aren't we padding on the right?  I would call this "padRight".
>>>>
>>>> Thanks,
>>>> -Brent
>>>>
>>>> On 7/14/14 3:41 PM, Claes Redestad wrote:
>>>>> Sorry about that; maybe I should've renamed the field c to conv instead,
>>>>> but I think I need to be conservative now and will revert the name changes.
>>>>>
>>>>> New webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.3
>>>>>
>>>>> Changing usage of given locale or any semantic change is really
>>>>> out-of-scope here. There seems to be a few ancient bugs hanging around
>>>>> which maybe someone should take a look at, e.g.,
>>>>> https://bugs.openjdk.java.net/browse/JDK-5063466
>>>>>
>>>>> /Claes
>>>>>
>>>>> On 2014-07-14 20:05, Jason Mehrens wrote:
>>>>>> Claes,
>>>>>>
>>>>>>
>>>>>> Maybe change (or not):
>>>>>>
>>>>>>
>>>>>> -throw new UnknownFormatConversionException(String.valueOf(c));
>>>>>>
>>>>>> +throw new UnknownFormatConversionException(String.valueOf(conv));
>>>>>>
>>>>>>
>>>>>>
>>>>>> I haven't examined it too deeply but it seems odd that some of those
>>>>>> print methods don't use the given locale when converting case.  That
>>>>>> is probably not a change for this issue.
>>>>>>
>>>>>>
>>>>>> Jason
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> Date: Mon, 14 Jul 2014 17:40:41 +0200
>>>>>>> From: claes.redestad at oracle.com
>>>>>>> To: core-libs-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR [9]: 8050142: Optimize java.util.Formatter
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> final(?) webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.2
>>>>>>>
>>>>>>> Thanks in advance for reviews. I also need a volunteer to sponsor
>>>>>>> this. :-)
>>>>>>>
>>>>>>> /Claes
>>>>>>>
>>>>>>> On 07/14/2014 04:21 PM, Claes Redestad wrote:
>>>>>>>> Yes, might be worth addressing just for correctness/readability.
>>>>>>>>
>>>>>>>> /Claes
>>>>>>>>
>>>>>>>> On 07/14/2014 03:02 PM, Ivan Gerasimov wrote:
>>>>>>>>> A very minor one:
>>>>>>>>> 2704 if (Character.isUpperCase(conv))
>>>>>>>>> 2705 f.add(Flags.UPPERCASE);
>>>>>>>>> 2706 c = Character.toLowerCase(conv);
>>>>>>>>>
>>>>>>>>> maybe
>>>>>>>>>
>>>>>>>>> 2704 if (Character.isUpperCase(conv)) {
>>>>>>>>> 2705 f.add(Flags.UPPERCASE);
>>>>>>>>> 2706 c = Character.toLowerCase(conv);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Sincerely yours,
>>>>>>>>> Ivan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 14.07.2014 16:23, Claes Redestad wrote:
>>>>>>>>>> Hi again,
>>>>>>>>>>
>>>>>>>>>> updated webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.1
>>>>>>>>>>
>>>>>>>>>> changes:
>>>>>>>>>> - specify capacity on line 2931 as suggested by Andrej Golovnin
>>>>>>>>>> - exp.append("0") -> exp.append('0') on line 3781
>>>>>>>>>> - merged append+justify into appendJustified as suggested by Peter
>>>>>>>>>> Levart
>>>>>>>>>> - replaced the reoccuring pattern of appending a number of zeros
>>>>>>>>>> into a call to trailingZeros
>>>>>>>>>>
>>>>>>>>>> performance difference seemingly at noise levels in micros, but
>>>>>>>>>> bonus to readability and Formatter*.class-files are now a total of
>>>>>>>>>> 246 bytes smaller
>>>>>>>>>>
>>>>>>>>>> /Claes
>>>>>>>>>>
>>>>>>>>>> On 2014-07-14 13:29, Claes Redestad wrote:
>>>>>>>>>>> Hi Peter,
>>>>>>>>>>>
>>>>>>>>>>> On 2014-07-14 13:25, Peter Levart wrote:
>>>>>>>>>>>> On 07/14/2014 12:07 PM, Claes Redestad wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> please review this patch which optimizes away some allocations
>>>>>>>>>>>>> from java.util.Formatter and achieve 1.1-1.3x speedups of micros
>>>>>>>>>>>>> targetting String.format. See bug for more details.
>>>>>>>>>>>>>
>>>>>>>>>>>>> webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0
>>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8050142
>>>>>>>>>>>>>
>>>>>>>>>>>>> Testing: JPRT, jtreg (java/lang/String, java/util/Formatter),
>>>>>>>>>>>>> SPECjbb2013 and microbenchmarks
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Claes
>>>>>>>>>>>> Hi Claes,
>>>>>>>>>>>>
>>>>>>>>>>>> Since justify() result is always appended to the resulting
>>>>>>>>>>>> Appendable, you could merge the functionality and eliminate
>>>>>>>>>>>> constructing intermediary StringBuilder altogether:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Formatter/webrev.01/
>>>>>>>>>>>>
>>>>>>>>>>> Looks good, especially eliminating the need for two different
>>>>>>>>>>> append methods. I'll update based on this and other suggestions.
>>>>>>>>>>>
>>>>>>>>>>> /Claes
>>>>>>>>>>>> Regards, Peter
>>>>>>>>>>
>>
>



From claes.redestad at oracle.com  Tue Sep 23 19:27:47 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 23 Sep 2014 21:27:47 +0200
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <5421C683.9010208@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>	<54207BFE.9040907@oracle.com>
	<5421C683.9010208@oracle.com>
Message-ID: <5421C9B3.6020809@oracle.com>

On 2014-09-23 21:14, Xueming Shen wrote:
> On 09/22/2014 12:43 PM, Claes Redestad wrote:
>> Hi,
>>
>> Sherman pointed out that there was a path that could actually take a 
>> minor performance hit from this patch,
>> which would be unacceptable. This version takes the minimal approach 
>> to addressing this by adding back a
>> method operating on a char[], simplified for the specific usage case 
>> (the exponent part of a %g double formatting):
>>
>> http://cr.openjdk.java.net/~redestad/8050142/webrev.07/
>>
>> This latest patch passes using the extended test coverage of 
>> java.util.Formatter I've proposed in 8058887, see
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028849.html 
>>
>>
>
> Hi Claes,
>
> Shouldn't we also keep the exp as char[] as well in "c == 
> Conversion.SCIENTIFIC" case?
> It appears the usage of exp is the same as the one in "GENERAL", in 
> which we are keeping
> the simple char[] for exp.

You're right, of course. I'll update the webrev.

/Claes


From xueming.shen at oracle.com  Tue Sep 23 19:30:35 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 23 Sep 2014 12:30:35 -0700
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <5421C9B3.6020809@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>	<54207BFE.9040907@oracle.com>
	<5421C683.9010208@oracle.com> <5421C9B3.6020809@oracle.com>
Message-ID: <5421CA5B.4020104@oracle.com>

Also the logic in the loop of localizedMagnitudeExp() does not look correct.
Shouldn't it be

char c= value[j];
if (c == '.') {
    append l10n dot...
} else {
sb.append(c - '0' + zero);
}

it appears the 'else" is missing? or I read it wrong?

-Sherman

On 09/23/2014 12:27 PM, Claes Redestad wrote:
> On 2014-09-23 21:14, Xueming Shen wrote:
>> On 09/22/2014 12:43 PM, Claes Redestad wrote:
>>> Hi,
>>>
>>> Sherman pointed out that there was a path that could actually take a minor performance hit from this patch,
>>> which would be unacceptable. This version takes the minimal approach to addressing this by adding back a
>>> method operating on a char[], simplified for the specific usage case (the exponent part of a %g double formatting):
>>>
>>> http://cr.openjdk.java.net/~redestad/8050142/webrev.07/
>>>
>>> This latest patch passes using the extended test coverage of java.util.Formatter I've proposed in 8058887, see
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028849.html
>>>
>>
>> Hi Claes,
>>
>> Shouldn't we also keep the exp as char[] as well in "c == Conversion.SCIENTIFIC" case?
>> It appears the usage of exp is the same as the one in "GENERAL", in which we are keeping
>> the simple char[] for exp.
>
> You're right, of course. I'll update the webrev.
>
> /Claes



From martin.desruisseaux at geomatys.fr  Tue Sep 23 19:36:35 2014
From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux)
Date: Tue, 23 Sep 2014 21:36:35 +0200
Subject: JDK 9 RFR of 4477961: java.lang.Math.toDegrees(double) could
	be optimized
In-Reply-To: <2F45659E-F243-4137-9AAB-FF0841D4DF6A@oracle.com>
References: <89B3C322-6C31-4459-BA84-D1D9D7191AE0@oracle.com>	<54209813.5050407@oracle.com>
	<2F45659E-F243-4137-9AAB-FF0841D4DF6A@oracle.com>
Message-ID: <5421CBC3.9090102@geomatys.fr>

Hi Brian

Le 23/09/14 00:34, Brian Burkhalter a ?crit :
> I created an alternate webrev using compile-time constants per your suggestion:
>
> http://cr.openjdk.java.net/~bpb/4477961/webrev.01/

On a very minor formatting detail, the change in StrictMath has a
misplaced empty line (before the RADIANS_TO_DEGREES constant, while it
should be after).

Also, would it be worth to remove the "private" modifier in
StrictMath.DEGREES_TO_RADIANS and StrictMath.RADIANS_TO_DEGREES, and
have Math.toDegrees and Math.toRadians to use the StrictMath constants
instead than duplicating them? It would reduce slightly the size of the
Math.class file by avoiding 2 field declarations.

    Martin




From claes.redestad at oracle.com  Tue Sep 23 19:42:53 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 23 Sep 2014 21:42:53 +0200
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <5421CA5B.4020104@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>	<54207BFE.9040907@oracle.com>
	<5421C683.9010208@oracle.com> <5421C9B3.6020809@oracle.com>
	<5421CA5B.4020104@oracle.com>
Message-ID: <5421CD3D.1040502@oracle.com>

Ouch... but wait... the char[] returned from 
sun.misc.FormattedFloatingDecimal.getExponent() can never contain a '.', 
so we'll never find a dot here. Remove the dead code or fix the logic?

/Claes

On 2014-09-23 21:30, Xueming Shen wrote:
> Also the logic in the loop of localizedMagnitudeExp() does not look 
> correct.
> Shouldn't it be
>
> char c= value[j];
> if (c == '.') {
>    append l10n dot...
> } else {
> sb.append(c - '0' + zero);
> }
>
> it appears the 'else" is missing? or I read it wrong?
>
> -Sherman
>
> On 09/23/2014 12:27 PM, Claes Redestad wrote:
>> On 2014-09-23 21:14, Xueming Shen wrote:
>>> On 09/22/2014 12:43 PM, Claes Redestad wrote:
>>>> Hi,
>>>>
>>>> Sherman pointed out that there was a path that could actually take 
>>>> a minor performance hit from this patch,
>>>> which would be unacceptable. This version takes the minimal 
>>>> approach to addressing this by adding back a
>>>> method operating on a char[], simplified for the specific usage 
>>>> case (the exponent part of a %g double formatting):
>>>>
>>>> http://cr.openjdk.java.net/~redestad/8050142/webrev.07/
>>>>
>>>> This latest patch passes using the extended test coverage of 
>>>> java.util.Formatter I've proposed in 8058887, see
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028849.html 
>>>>
>>>>
>>>
>>> Hi Claes,
>>>
>>> Shouldn't we also keep the exp as char[] as well in "c == 
>>> Conversion.SCIENTIFIC" case?
>>> It appears the usage of exp is the same as the one in "GENERAL", in 
>>> which we are keeping
>>> the simple char[] for exp.
>>
>> You're right, of course. I'll update the webrev.
>>
>> /Claes
>



From xueming.shen at oracle.com  Tue Sep 23 20:12:43 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 23 Sep 2014 13:12:43 -0700
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <5421CD3D.1040502@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>	<54207BFE.9040907@oracle.com>
	<5421C683.9010208@oracle.com> <5421C9B3.6020809@oracle.com>
	<5421CA5B.4020104@oracle.com> <5421CD3D.1040502@oracle.com>
Message-ID: <5421D43B.2060806@oracle.com>

I don''t think an exponent should ever have a "dot', it always a signed integer. I think we can
just remove the dead code, maybe put some wording to explain why no group, no dot here.

-Sherman

On 09/23/2014 12:42 PM, Claes Redestad wrote:
> Ouch... but wait... the char[] returned from sun.misc.FormattedFloatingDecimal.getExponent() can never contain a '.', so we'll never find a dot here. Remove the dead code or fix the logic?
>
> /Claes
>
> On 2014-09-23 21:30, Xueming Shen wrote:
>> Also the logic in the loop of localizedMagnitudeExp() does not look correct.
>> Shouldn't it be
>>
>> char c= value[j];
>> if (c == '.') {
>>    append l10n dot...
>> } else {
>> sb.append(c - '0' + zero);
>> }
>>
>> it appears the 'else" is missing? or I read it wrong?
>>
>> -Sherman
>>
>> On 09/23/2014 12:27 PM, Claes Redestad wrote:
>>> On 2014-09-23 21:14, Xueming Shen wrote:
>>>> On 09/22/2014 12:43 PM, Claes Redestad wrote:
>>>>> Hi,
>>>>>
>>>>> Sherman pointed out that there was a path that could actually take a minor performance hit from this patch,
>>>>> which would be unacceptable. This version takes the minimal approach to addressing this by adding back a
>>>>> method operating on a char[], simplified for the specific usage case (the exponent part of a %g double formatting):
>>>>>
>>>>> http://cr.openjdk.java.net/~redestad/8050142/webrev.07/
>>>>>
>>>>> This latest patch passes using the extended test coverage of java.util.Formatter I've proposed in 8058887, see
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028849.html
>>>>>
>>>>
>>>> Hi Claes,
>>>>
>>>> Shouldn't we also keep the exp as char[] as well in "c == Conversion.SCIENTIFIC" case?
>>>> It appears the usage of exp is the same as the one in "GENERAL", in which we are keeping
>>>> the simple char[] for exp.
>>>
>>> You're right, of course. I'll update the webrev.
>>>
>>> /Claes
>>
>



From claes.redestad at oracle.com  Tue Sep 23 21:07:10 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 23 Sep 2014 23:07:10 +0200
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <5421D43B.2060806@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>	<54207BFE.9040907@oracle.com>
	<5421C683.9010208@oracle.com> <5421C9B3.6020809@oracle.com>
	<5421CA5B.4020104@oracle.com> <5421CD3D.1040502@oracle.com>
	<5421D43B.2060806@oracle.com>
Message-ID: <5421E0FE.30602@oracle.com>

How about:

     // Specialized localization of exponents, where the source value can only
     // contain characters '0' through '9', starting at index offset, and no
     // group separators is added for any locale.
     private void localizedMagnitudeExp(StringBuilder sb, char[] value,
             final int offset, Locale l) {
         char zero = getZero(l);

         int len = value.length;
         for (int j = offset; j < len; j++) {
             char c = value[j];
             sb.append((char) ((c - '0') + zero));
         }
     }

Webrev including this and the fixes for Conversion.SCIENTIFIC:
http://cr.openjdk.java.net/~redestad/8050142/webrev.09/

/Claes

On 2014-09-23 22:12, Xueming Shen wrote:
> I don''t think an exponent should ever have a "dot', it always a 
> signed integer. I think we can
> just remove the dead code, maybe put some wording to explain why no 
> group, no dot here.
>
> -Sherman
>
> On 09/23/2014 12:42 PM, Claes Redestad wrote:
>> Ouch... but wait... the char[] returned from 
>> sun.misc.FormattedFloatingDecimal.getExponent() can never contain a 
>> '.', so we'll never find a dot here. Remove the dead code or fix the 
>> logic?
>>
>> /Claes
>>
>> On 2014-09-23 21:30, Xueming Shen wrote:
>>> Also the logic in the loop of localizedMagnitudeExp() does not look 
>>> correct.
>>> Shouldn't it be
>>>
>>> char c= value[j];
>>> if (c == '.') {
>>>    append l10n dot...
>>> } else {
>>> sb.append(c - '0' + zero);
>>> }
>>>
>>> it appears the 'else" is missing? or I read it wrong?
>>>
>>> -Sherman
>>>
>>> On 09/23/2014 12:27 PM, Claes Redestad wrote:
>>>> On 2014-09-23 21:14, Xueming Shen wrote:
>>>>> On 09/22/2014 12:43 PM, Claes Redestad wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Sherman pointed out that there was a path that could actually 
>>>>>> take a minor performance hit from this patch,
>>>>>> which would be unacceptable. This version takes the minimal 
>>>>>> approach to addressing this by adding back a
>>>>>> method operating on a char[], simplified for the specific usage 
>>>>>> case (the exponent part of a %g double formatting):
>>>>>>
>>>>>> http://cr.openjdk.java.net/~redestad/8050142/webrev.07/
>>>>>>
>>>>>> This latest patch passes using the extended test coverage of 
>>>>>> java.util.Formatter I've proposed in 8058887, see
>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028849.html 
>>>>>>
>>>>>>
>>>>>
>>>>> Hi Claes,
>>>>>
>>>>> Shouldn't we also keep the exp as char[] as well in "c == 
>>>>> Conversion.SCIENTIFIC" case?
>>>>> It appears the usage of exp is the same as the one in "GENERAL", 
>>>>> in which we are keeping
>>>>> the simple char[] for exp.
>>>>
>>>> You're right, of course. I'll update the webrev.
>>>>
>>>> /Claes
>>>
>>
>



From aleksey.shipilev at oracle.com  Wed Sep 24 11:09:07 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 24 Sep 2014 15:09:07 +0400
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <54203237.5090901@oracle.com>
References: <54199AA9.2090804@oracle.com>
	<54202D00.3010207@oracle.com>	<54202E81.8070004@oracle.com>
	<54203237.5090901@oracle.com>
Message-ID: <5422A653.2010209@oracle.com>

Hi again,

Friendly reminder: please sponsor this trivial change. :)

-Aleksey.

On 09/22/2014 06:29 PM, Aleksey Shipilev wrote:
> Fixed:
>  http://cr.openjdk.java.net/~shade/8058643/webrev.02/
>  http://cr.openjdk.java.net/~shade/8058643/8058643.changeset
> 
> Since there is no performance impact for this touchup (char -> int
> promotion is happening anyway), and no functionality changes (char ->
> int promotion zero-extends), I haven't developed any new tests, or
> re-spinned any existing ones.
> 
> Thanks,
> -Aleksey.
> 




From miroslav.kos at oracle.com  Wed Sep 24 12:48:12 2014
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Wed, 24 Sep 2014 14:48:12 +0200
Subject: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for
	Web services
In-Reply-To: <541C4EF9.8070806@oracle.com>
References: <541985F4.6010202@oracle.com> <541997D1.8040602@oracle.com>
	<541AA202.10203@oracle.com> <541AAAC7.8030806@oracle.com>
	<541AC223.6080003@oracle.com> <541AC9A0.1090900@oracle.com>
	<541AF898.6060400@oracle.com> <541C4EF9.8070806@oracle.com>
Message-ID: <5422BD8C.5010103@oracle.com>

The problem was in line endings. The updated webrev for test:
http://cr.openjdk.java.net/~mkos/8038966/jdk.04/

Thanks
Miran


On 19/09/14 17:42, Se?n Coffey wrote:
> Miran,
>
> thanks for the update. Seems like you're working from an old JDK 9 
> forest. The webrev is
> using the pre-modular path layout. I've converted them. I'm am seeing 
> the new test fail
> on windows though. Will share the details with you offline.
>
> regards,
> Sean.
>
> On 18/09/14 16:22, Miroslav Kos wrote:
>> Ok then, the webrev updated:
>> http://cr.openjdk.java.net/~mkos/8038966/jdk.03/
>> http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
>>
>> btw. I had to tweak the path - using simply Paths.get("org") we get
>>     JTwork/scratch/org
>> but needed path is
>>     JTwork/classes/javax/xml/ws/xsanymixed/org
>> (classes instead of scratch + test path as prefix), so I changed the 
>> code to
>>         Path p = Paths.get("..", "classes", "javax", "xml", "ws", 
>> "xsanymixed", "org");
>>
>> Thanks
>> Miran
>>
>>
>> On 18/09/14 14:01, Se?n Coffey wrote:
>>> jtreg should remove the work/scratch directory upon test completion 
>>> but it's best practice to attempt to clean up generated files. No 
>>> harm there I think. Also needed in cases where test might be run 
>>> manually. I'd suggest keeping the clean up code in the testcase.
>>>
>>> regards,
>>> Sean.
>>>
>>> On 18/09/2014 12:29, Miroslav Kos wrote:
>>>> Oops, I missed that, thanks. One question yet - does it make sense 
>>>> any more to clean generated files now, when the location was 
>>>> changed? I think clean up should be done automatically by jtreg 
>>>> now, shouldn't it? If you agree, I would delete the method instead.
>>>>
>>>> Thanks
>>>> Miran
>>>>
>>>> On 18/09/14 11:49, Se?n Coffey wrote:
>>>>>
>>>>> On 18/09/2014 10:12, Miroslav Kos wrote:
>>>>>> Thanks, Sean, good catch ...
>>>>>>
>>>>>> I changed the destination for generated files:
>>>>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.02/
>>>>>>
>>>>>> Regarding usage ProcessBuilder instead of shell script - the 
>>>>>> problem is, that to compile test classes, wsdl must be compiled 
>>>>>> first - shell script is setup required before javac. The test 
>>>>>> would have to be run in two phases - first compiling+running java 
>>>>>> classes that compile wsdl (ProcessBuilder) and after that 
>>>>>> compiling other java classes using result of previous run.
>>>>>>
>>>>>> I was solving this with jtreg some time ago already, but I 
>>>>>> haven't found other way than using shell script. If you know 
>>>>>> better solution, it would be great ...
>>>>> Ah - I see the dependency now. Thanks for the information.
>>>>>
>>>>> Just spotted one other issue. The deleteGeneratedFiles() method 
>>>>> scans for files in the
>>>>> test src path (for deletion) - No files should be created there 
>>>>> now. You can change that
>>>>> to scan the test classes path now. You could just use the current 
>>>>> working directory I guess
>>>>> since that's where jtreg will generate the new files.
>>>>>
>>>>> Paths.get("org");
>>>>>
>>>>> once that's fixed up, I can run this through JPRT and it should be 
>>>>> good to push then.
>>>>>
>>>>> regards,
>>>>> Sean.
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Miran
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 17/09/14 16:16, Se?n Coffey wrote:
>>>>>>> Miran,
>>>>>>>
>>>>>>> the src change looks ok but I think there's a problem with the 
>>>>>>> testcase.
>>>>>>>
>>>>>>> You've defined generated classes for wsimport to be output to 
>>>>>>> the TESTSRC
>>>>>>> directory. This is often read only and won't work.
>>>>>>>
>>>>>>> TESTCLASSES is the variable you're probably looking for. In any 
>>>>>>> case, I think
>>>>>>> it's possible for you to avoid use of scripting. Can you invoke 
>>>>>>> wsimport via
>>>>>>> the ProcessBuilder API like that done for other wsimport tests ?
>>>>>>>
>>>>>>> regards,
>>>>>>> Sean.
>>>>>>>
>>>>>>> On 17/09/14 14:00, Miroslav Kos wrote:
>>>>>>>> Hi everybody,
>>>>>>>>
>>>>>>>> please review patch fixing following issue:
>>>>>>>>
>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
>>>>>>>> webrev:
>>>>>>>> http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
>>>>>>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.01/
>>>>>>>>
>>>>>>>> It is second part of fix ensuring that content of type 
>>>>>>>> xsd:any/content=mixed stays unchanged when processed with JAX-B 
>>>>>>>> RI. Regression test within webrev.
>>>>>>>>
>>>>>>>> Sean, could you sponsor it for me?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Miran
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From sean.coffey at oracle.com  Wed Sep 24 13:00:26 2014
From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=)
Date: Wed, 24 Sep 2014 14:00:26 +0100
Subject: [9] RFR: 8038966 JAX-WS handles wrongly xsd:any arguments for
	Web services
In-Reply-To: <5422BD8C.5010103@oracle.com>
References: <541985F4.6010202@oracle.com> <541997D1.8040602@oracle.com>
	<541AA202.10203@oracle.com> <541AAAC7.8030806@oracle.com>
	<541AC223.6080003@oracle.com> <541AC9A0.1090900@oracle.com>
	<541AF898.6060400@oracle.com> <541C4EF9.8070806@oracle.com>
	<5422BD8C.5010103@oracle.com>
Message-ID: <5422C06A.7070805@oracle.com>

Thanks for fixing Miran. Looks good. I ran it through JPRT also. Just 
realised that you're a committer for JDK 9 Project - great!
Don't forget to update your jaxws repo before pushing. Your current 
webrev is showing non-modular path names.

regards,
Sean.

On 24/09/14 13:48, Miroslav Kos wrote:
> The problem was in line endings. The updated webrev for test:
> http://cr.openjdk.java.net/~mkos/8038966/jdk.04/
>
> Thanks
> Miran
>
>
> On 19/09/14 17:42, Se?n Coffey wrote:
>> Miran,
>>
>> thanks for the update. Seems like you're working from an old JDK 9 
>> forest. The webrev is
>> using the pre-modular path layout. I've converted them. I'm am seeing 
>> the new test fail
>> on windows though. Will share the details with you offline.
>>
>> regards,
>> Sean.
>>
>> On 18/09/14 16:22, Miroslav Kos wrote:
>>> Ok then, the webrev updated:
>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.03/
>>> http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
>>>
>>> btw. I had to tweak the path - using simply Paths.get("org") we get
>>>     JTwork/scratch/org
>>> but needed path is
>>>     JTwork/classes/javax/xml/ws/xsanymixed/org
>>> (classes instead of scratch + test path as prefix), so I changed the 
>>> code to
>>>         Path p = Paths.get("..", "classes", "javax", "xml", "ws", 
>>> "xsanymixed", "org");
>>>
>>> Thanks
>>> Miran
>>>
>>>
>>> On 18/09/14 14:01, Se?n Coffey wrote:
>>>> jtreg should remove the work/scratch directory upon test completion 
>>>> but it's best practice to attempt to clean up generated files. No 
>>>> harm there I think. Also needed in cases where test might be run 
>>>> manually. I'd suggest keeping the clean up code in the testcase.
>>>>
>>>> regards,
>>>> Sean.
>>>>
>>>> On 18/09/2014 12:29, Miroslav Kos wrote:
>>>>> Oops, I missed that, thanks. One question yet - does it make sense 
>>>>> any more to clean generated files now, when the location was 
>>>>> changed? I think clean up should be done automatically by jtreg 
>>>>> now, shouldn't it? If you agree, I would delete the method instead.
>>>>>
>>>>> Thanks
>>>>> Miran
>>>>>
>>>>> On 18/09/14 11:49, Se?n Coffey wrote:
>>>>>>
>>>>>> On 18/09/2014 10:12, Miroslav Kos wrote:
>>>>>>> Thanks, Sean, good catch ...
>>>>>>>
>>>>>>> I changed the destination for generated files:
>>>>>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.02/
>>>>>>>
>>>>>>> Regarding usage ProcessBuilder instead of shell script - the 
>>>>>>> problem is, that to compile test classes, wsdl must be compiled 
>>>>>>> first - shell script is setup required before javac. The test 
>>>>>>> would have to be run in two phases - first compiling+running 
>>>>>>> java classes that compile wsdl (ProcessBuilder) and after that 
>>>>>>> compiling other java classes using result of previous run.
>>>>>>>
>>>>>>> I was solving this with jtreg some time ago already, but I 
>>>>>>> haven't found other way than using shell script. If you know 
>>>>>>> better solution, it would be great ...
>>>>>> Ah - I see the dependency now. Thanks for the information.
>>>>>>
>>>>>> Just spotted one other issue. The deleteGeneratedFiles() method 
>>>>>> scans for files in the
>>>>>> test src path (for deletion) - No files should be created there 
>>>>>> now. You can change that
>>>>>> to scan the test classes path now. You could just use the current 
>>>>>> working directory I guess
>>>>>> since that's where jtreg will generate the new files.
>>>>>>
>>>>>> Paths.get("org");
>>>>>>
>>>>>> once that's fixed up, I can run this through JPRT and it should 
>>>>>> be good to push then.
>>>>>>
>>>>>> regards,
>>>>>> Sean.
>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Miran
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 17/09/14 16:16, Se?n Coffey wrote:
>>>>>>>> Miran,
>>>>>>>>
>>>>>>>> the src change looks ok but I think there's a problem with the 
>>>>>>>> testcase.
>>>>>>>>
>>>>>>>> You've defined generated classes for wsimport to be output to 
>>>>>>>> the TESTSRC
>>>>>>>> directory. This is often read only and won't work.
>>>>>>>>
>>>>>>>> TESTCLASSES is the variable you're probably looking for. In any 
>>>>>>>> case, I think
>>>>>>>> it's possible for you to avoid use of scripting. Can you invoke 
>>>>>>>> wsimport via
>>>>>>>> the ProcessBuilder API like that done for other wsimport tests ?
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> Sean.
>>>>>>>>
>>>>>>>> On 17/09/14 14:00, Miroslav Kos wrote:
>>>>>>>>> Hi everybody,
>>>>>>>>>
>>>>>>>>> please review patch fixing following issue:
>>>>>>>>>
>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8038966
>>>>>>>>> webrev:
>>>>>>>>> http://cr.openjdk.java.net/~mkos/8038966/jaxws.00/
>>>>>>>>> http://cr.openjdk.java.net/~mkos/8038966/jdk.01/
>>>>>>>>>
>>>>>>>>> It is second part of fix ensuring that content of type 
>>>>>>>>> xsd:any/content=mixed stays unchanged when processed with 
>>>>>>>>> JAX-B RI. Regression test within webrev.
>>>>>>>>>
>>>>>>>>> Sean, could you sponsor it for me?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Miran
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From konstantin.shefov at oracle.com  Wed Sep 24 15:54:25 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Wed, 24 Sep 2014 19:54:25 +0400
Subject: [9] Review request : JDK-8058695: [TESTBUG] Reinvokers with arity
	>253 can't be cached
Message-ID: <5422E931.2040509@oracle.com>

Hello,

Please review the test bug fix 
https://bugs.openjdk.java.net/browse/JDK-8058695
Webrev is http://cr.openjdk.java.net/~kshefov/8058695/webrev.00/

There is also a fix to https://bugs.openjdk.java.net/browse/JDK-8058733 
in this diff.

Thanks

-Konstantin


From martinrb at google.com  Wed Sep 24 16:56:06 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 24 Sep 2014 09:56:06 -0700
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <5422A653.2010209@oracle.com>
References: <54199AA9.2090804@oracle.com> <54202D00.3010207@oracle.com>
	<54202E81.8070004@oracle.com> <54203237.5090901@oracle.com>
	<5422A653.2010209@oracle.com>
Message-ID: <CA+kOe0921KRFHkveF=6G_QPoH3T67T076ckK9iM-8Voy_Q7B_A@mail.gmail.com>

I pushed Aleksey's change to jdk9-dev.

If it was up to me, I would give Aleksey all the commit/review bits I had...

On Wed, Sep 24, 2014 at 4:09 AM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

> Hi again,
>
> Friendly reminder: please sponsor this trivial change. :)
>
> -Aleksey.
>
> On 09/22/2014 06:29 PM, Aleksey Shipilev wrote:
> > Fixed:
> >  http://cr.openjdk.java.net/~shade/8058643/webrev.02/
> >  http://cr.openjdk.java.net/~shade/8058643/8058643.changeset
> >
> > Since there is no performance impact for this touchup (char -> int
> > promotion is happening anyway), and no functionality changes (char ->
> > int promotion zero-extends), I haven't developed any new tests, or
> > re-spinned any existing ones.
> >
> > Thanks,
> > -Aleksey.
> >
>
>
>


From aleksey.shipilev at oracle.com  Wed Sep 24 17:01:12 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 24 Sep 2014 21:01:12 +0400
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <CA+kOe0921KRFHkveF=6G_QPoH3T67T076ckK9iM-8Voy_Q7B_A@mail.gmail.com>
References: <54199AA9.2090804@oracle.com>	<54202D00.3010207@oracle.com>	<54202E81.8070004@oracle.com>	<54203237.5090901@oracle.com>	<5422A653.2010209@oracle.com>
	<CA+kOe0921KRFHkveF=6G_QPoH3T67T076ckK9iM-8Voy_Q7B_A@mail.gmail.com>
Message-ID: <5422F8D8.5090404@oracle.com>

Thanks Martin!

-Aleksey.

On 09/24/2014 08:56 PM, Martin Buchholz wrote:
> I pushed Aleksey's change to jdk9-dev.
> 
> If it was up to me, I would give Aleksey all the commit/review bits I had...
> 
> On Wed, Sep 24, 2014 at 4:09 AM, Aleksey Shipilev
> <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
> 
>     Hi again,
> 
>     Friendly reminder: please sponsor this trivial change. :)
> 
>     -Aleksey.
> 
>     On 09/22/2014 06:29 PM, Aleksey Shipilev wrote:
>     > Fixed:
>     >  http://cr.openjdk.java.net/~shade/8058643/webrev.02/
>     <http://cr.openjdk.java.net/%7Eshade/8058643/webrev.02/>
>     >  http://cr.openjdk.java.net/~shade/8058643/8058643.changeset
>     <http://cr.openjdk.java.net/%7Eshade/8058643/8058643.changeset>
>     >
>     > Since there is no performance impact for this touchup (char -> int
>     > promotion is happening anyway), and no functionality changes (char ->
>     > int promotion zero-extends), I haven't developed any new tests, or
>     > re-spinned any existing ones.
>     >
>     > Thanks,
>     > -Aleksey.
>     >
> 
> 
> 




From xueming.shen at oracle.com  Wed Sep 24 17:41:24 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 24 Sep 2014 10:41:24 -0700
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <5421E0FE.30602@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>	<54207BFE.9040907@oracle.com>
	<5421C683.9010208@oracle.com> <5421C9B3.6020809@oracle.com>
	<5421CA5B.4020104@oracle.com> <5421CD3D.1040502@oracle.com>
	<5421D43B.2060806@oracle.com> <5421E0FE.30602@oracle.com>
Message-ID: <54230244.3000401@oracle.com>

Looks good.

On 09/23/2014 02:07 PM, Claes Redestad wrote:
> How about:
>
>     // Specialized localization of exponents, where the source value can only
>     // contain characters '0' through '9', starting at index offset, and no
>     // group separators is added for any locale.
>     private void localizedMagnitudeExp(StringBuilder sb, char[] value,
>             final int offset, Locale l) {
>         char zero = getZero(l);
>
>         int len = value.length;
>         for (int j = offset; j < len; j++) {
>             char c = value[j];
>             sb.append((char) ((c - '0') + zero));
>         }
>     }
>
> Webrev including this and the fixes for Conversion.SCIENTIFIC:
> http://cr.openjdk.java.net/~redestad/8050142/webrev.09/
>
> /Claes
>
> On 2014-09-23 22:12, Xueming Shen wrote:
>> I don''t think an exponent should ever have a "dot', it always a signed integer. I think we can
>> just remove the dead code, maybe put some wording to explain why no group, no dot here.
>>
>> -Sherman
>>
>> On 09/23/2014 12:42 PM, Claes Redestad wrote:
>>> Ouch... but wait... the char[] returned from sun.misc.FormattedFloatingDecimal.getExponent() can never contain a '.', so we'll never find a dot here. Remove the dead code or fix the logic?
>>>
>>> /Claes
>>>
>>> On 2014-09-23 21:30, Xueming Shen wrote:
>>>> Also the logic in the loop of localizedMagnitudeExp() does not look correct.
>>>> Shouldn't it be
>>>>
>>>> char c= value[j];
>>>> if (c == '.') {
>>>>    append l10n dot...
>>>> } else {
>>>> sb.append(c - '0' + zero);
>>>> }
>>>>
>>>> it appears the 'else" is missing? or I read it wrong?
>>>>
>>>> -Sherman
>>>>
>>>> On 09/23/2014 12:27 PM, Claes Redestad wrote:
>>>>> On 2014-09-23 21:14, Xueming Shen wrote:
>>>>>> On 09/22/2014 12:43 PM, Claes Redestad wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Sherman pointed out that there was a path that could actually take a minor performance hit from this patch,
>>>>>>> which would be unacceptable. This version takes the minimal approach to addressing this by adding back a
>>>>>>> method operating on a char[], simplified for the specific usage case (the exponent part of a %g double formatting):
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~redestad/8050142/webrev.07/
>>>>>>>
>>>>>>> This latest patch passes using the extended test coverage of java.util.Formatter I've proposed in 8058887, see
>>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028849.html
>>>>>>>
>>>>>>
>>>>>> Hi Claes,
>>>>>>
>>>>>> Shouldn't we also keep the exp as char[] as well in "c == Conversion.SCIENTIFIC" case?
>>>>>> It appears the usage of exp is the same as the one in "GENERAL", in which we are keeping
>>>>>> the simple char[] for exp.
>>>>>
>>>>> You're right, of course. I'll update the webrev.
>>>>>
>>>>> /Claes
>>>>
>>>
>>
>



From xueming.shen at oracle.com  Wed Sep 24 18:14:52 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 24 Sep 2014 11:14:52 -0700
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <54230244.3000401@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>	<54207BFE.9040907@oracle.com>
	<5421C683.9010208@oracle.com> <5421C9B3.6020809@oracle.com>
	<5421CA5B.4020104@oracle.com> <5421CD3D.1040502@oracle.com>
	<5421D43B.2060806@oracle.com> <5421E0FE.30602@oracle.com>
	<54230244.3000401@oracle.com>
Message-ID: <54230A1C.40000@oracle.com>

Shouldn't this one be at the same class (FormatSpecifier?) as the "localizedMagnitudeExp"?
the webrev shows it is one level up.
Btw, when we are here, maybe we can just remove the FormatSpecifier.getZero(), it appears
we have a static version already at Formatter level.

On 09/24/2014 10:41 AM, Xueming Shen wrote:
> Looks good.
>
> On 09/23/2014 02:07 PM, Claes Redestad wrote:
>> How about:
>>
>>     // Specialized localization of exponents, where the source value can only
>>     // contain characters '0' through '9', starting at index offset, and no
>>     // group separators is added for any locale.
>>     private void localizedMagnitudeExp(StringBuilder sb, char[] value,
>>             final int offset, Locale l) {
>>         char zero = getZero(l);
>>
>>         int len = value.length;
>>         for (int j = offset; j < len; j++) {
>>             char c = value[j];
>>             sb.append((char) ((c - '0') + zero));
>>         }
>>     }
>>
>> Webrev including this and the fixes for Conversion.SCIENTIFIC:
>> http://cr.openjdk.java.net/~redestad/8050142/webrev.09/
>>
>> /Claes
>>
>> On 2014-09-23 22:12, Xueming Shen wrote:
>>> I don''t think an exponent should ever have a "dot', it always a signed integer. I think we can
>>> just remove the dead code, maybe put some wording to explain why no group, no dot here.
>>>
>>> -Sherman
>>>
>>> On 09/23/2014 12:42 PM, Claes Redestad wrote:
>>>> Ouch... but wait... the char[] returned from sun.misc.FormattedFloatingDecimal.getExponent() can never contain a '.', so we'll never find a dot here. Remove the dead code or fix the logic?
>>>>
>>>> /Claes
>>>>
>>>> On 2014-09-23 21:30, Xueming Shen wrote:
>>>>> Also the logic in the loop of localizedMagnitudeExp() does not look correct.
>>>>> Shouldn't it be
>>>>>
>>>>> char c= value[j];
>>>>> if (c == '.') {
>>>>>    append l10n dot...
>>>>> } else {
>>>>> sb.append(c - '0' + zero);
>>>>> }
>>>>>
>>>>> it appears the 'else" is missing? or I read it wrong?
>>>>>
>>>>> -Sherman
>>>>>
>>>>> On 09/23/2014 12:27 PM, Claes Redestad wrote:
>>>>>> On 2014-09-23 21:14, Xueming Shen wrote:
>>>>>>> On 09/22/2014 12:43 PM, Claes Redestad wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Sherman pointed out that there was a path that could actually take a minor performance hit from this patch,
>>>>>>>> which would be unacceptable. This version takes the minimal approach to addressing this by adding back a
>>>>>>>> method operating on a char[], simplified for the specific usage case (the exponent part of a %g double formatting):
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~redestad/8050142/webrev.07/
>>>>>>>>
>>>>>>>> This latest patch passes using the extended test coverage of java.util.Formatter I've proposed in 8058887, see
>>>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028849.html
>>>>>>>>
>>>>>>>
>>>>>>> Hi Claes,
>>>>>>>
>>>>>>> Shouldn't we also keep the exp as char[] as well in "c == Conversion.SCIENTIFIC" case?
>>>>>>> It appears the usage of exp is the same as the one in "GENERAL", in which we are keeping
>>>>>>> the simple char[] for exp.
>>>>>>
>>>>>> You're right, of course. I'll update the webrev.
>>>>>>
>>>>>> /Claes
>>>>>
>>>>
>>>
>>
>



From peter.levart at gmail.com  Wed Sep 24 20:25:41 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 24 Sep 2014 22:25:41 +0200
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <54203237.5090901@oracle.com>
References: <54199AA9.2090804@oracle.com>
	<54202D00.3010207@oracle.com>	<54202E81.8070004@oracle.com>
	<54203237.5090901@oracle.com>
Message-ID: <542328C5.70303@gmail.com>


On 09/22/2014 04:29 PM, Aleksey Shipilev wrote:
>
> Fixed:
>   http://cr.openjdk.java.net/~shade/8058643/webrev.02/
>   http://cr.openjdk.java.net/~shade/8058643/8058643.changeset
>
> Since there is no performance impact for this touchup (char -> int
> promotion is happening anyway), and no functionality changes (char ->
> int promotion zero-extends), I haven't developed any new tests, or
> re-spinned any existing ones.
>
> Thanks,
> -Aleksey.
>

Hi,

String.hashCode() caches the result, so repeatable call to same String 
instance is faster for 2nd and further invocations. But the computation 
of hash code itself could be accelerated for a factor of 2 or more on 
todays CPUs. How? By parallelizing it. And I don't mean computing it in 
multiple threads.

Here is a surprising result of a simple benchmark which computes hash 
code of a 128 character string in 6 different ways:

Benchmark                    Mode   Samples        Score  Score error    
Units
j.t.HashBench.hashCode      thrpt         8  8420103.795 162447.069    ops/s
j.t.HashBench.hashCode0     thrpt         8  8439058.660 2842.755    ops/s
j.t.HashBench.hashCode1     thrpt         8 13809510.573 337888.132    ops/s
j.t.HashBench.hashCode2     thrpt         8 15543687.568 716152.160    ops/s
j.t.HashBench.hashCode3     thrpt         8 18173224.431 49410.256    ops/s
j.t.HashBench.hashCode3x    thrpt         8  8543020.232 18158.686    ops/s


Source:

http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench.java


The "hashCode" benchmark is invoking .hashCode() on a new String using a 
'master' string as a constructor argument, so new string is constructed 
with shared char[] array, but with no pre-computed hashCode.

Compare it to "hashCode0" benchmark which replicates String's hasCode() 
implementation and has a comparable score. This is to set the baseline.

"hashCode1" benchmark is already quite faster.
"hashCode2" is faster than "hashCode1"
"hashCode3" is faster than "hashCode2"
... i haven't tried it further. It should stop somewhere, dependent on 
the CPU of course.

To illustrate this has nothing to do with manual vs. automatic loop 
unrolling (as it might appear by 1st glance of the code), "hashCode3x" 
benchmark is equivalent to "hashCode3" regarding loop structure, but 
it's result is comparable to "hashCode" and "hashCode0" benchmarks.

It appears that "hashCode1,2,3" are utilizing CPU's pipeline which can 
perform multiple (2, 3, 4) multiplications in parallel, whereas 
"hashCode0,3x" can't, since each iteration of loop computes the next 
result from the result of previous iteration.


Regards, Peter



From claes.redestad at oracle.com  Wed Sep 24 20:33:42 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 24 Sep 2014 22:33:42 +0200
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <54230A1C.40000@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>	<54207BFE.9040907@oracle.com>
	<5421C683.9010208@oracle.com> <5421C9B3.6020809@oracle.com>
	<5421CA5B.4020104@oracle.com> <5421CD3D.1040502@oracle.com>
	<5421D43B.2060806@oracle.com> <5421E0FE.30602@oracle.com>
	<54230244.3000401@oracle.com> <54230A1C.40000@oracle.com>
Message-ID: <54232AA6.5040702@oracle.com>


On 2014-09-24 20:14, Xueming Shen wrote:
> Shouldn't this one be at the same class (FormatSpecifier?) as the 
> "localizedMagnitudeExp"?
> the webrev shows it is one level up.

Nice catch!

> Btw, when we are here, maybe we can just remove the 
> FormatSpecifier.getZero(), it appears
> we have a static version already at Formatter level.

They are not identical, and in fact, I think some subtle things would 
change if localizedMagnitudeExp
isn't moved up: FormatSpecifier.getZero() check versus the locale the 
Formatter was created
with while the static method compares against Locale.US. This changes 
semantics when calling
format operations with null, which is a legal option:

Formatter f = new Formatter(Locale.X); // where Locale.X is a locale 
where zero != '0'
f.format(null, "%.0e", 1000000000.0); // would print the exponent in 
different ways

However, current behavior might actually be wrong since it's in 
contradiction to the specification,
e.g., Formatter#format(Locale l, String format, Object ... args):

      * @param  l
      *         The {@linkplain java.util.Locale locale} to apply during
      *         formatting.  If {@code l} is {@code null} then no 
localization
      *         is applied.  This does not change this object's locale 
that was
      *         set during construction.

Most code interprets l == null like this, but FormatSpecifier.getZero() 
is an exception. I think this
needs to be investigated and merits a bug of its own.

Updated localizedMagnitudeExp to reside in FormatSpecifier, leaving 
getZero alone:

http://cr.openjdk.java.net/~redestad/8050142/webrev.10/

/Claes
>
> On 09/24/2014 10:41 AM, Xueming Shen wrote:
>> Looks good.
>>
>> On 09/23/2014 02:07 PM, Claes Redestad wrote:
>>> How about:
>>>
>>>     // Specialized localization of exponents, where the source value 
>>> can only
>>>     // contain characters '0' through '9', starting at index offset, 
>>> and no
>>>     // group separators is added for any locale.
>>>     private void localizedMagnitudeExp(StringBuilder sb, char[] value,
>>>             final int offset, Locale l) {
>>>         char zero = getZero(l);
>>>
>>>         int len = value.length;
>>>         for (int j = offset; j < len; j++) {
>>>             char c = value[j];
>>>             sb.append((char) ((c - '0') + zero));
>>>         }
>>>     }
>>>
>>> Webrev including this and the fixes for Conversion.SCIENTIFIC:
>>> http://cr.openjdk.java.net/~redestad/8050142/webrev.09/
>>>
>>> /Claes
>>>
>>> On 2014-09-23 22:12, Xueming Shen wrote:
>>>> I don''t think an exponent should ever have a "dot', it always a 
>>>> signed integer. I think we can
>>>> just remove the dead code, maybe put some wording to explain why no 
>>>> group, no dot here.
>>>>
>>>> -Sherman
>>>>
>>>> On 09/23/2014 12:42 PM, Claes Redestad wrote:
>>>>> Ouch... but wait... the char[] returned from 
>>>>> sun.misc.FormattedFloatingDecimal.getExponent() can never contain 
>>>>> a '.', so we'll never find a dot here. Remove the dead code or fix 
>>>>> the logic?
>>>>>
>>>>> /Claes
>>>>>
>>>>> On 2014-09-23 21:30, Xueming Shen wrote:
>>>>>> Also the logic in the loop of localizedMagnitudeExp() does not 
>>>>>> look correct.
>>>>>> Shouldn't it be
>>>>>>
>>>>>> char c= value[j];
>>>>>> if (c == '.') {
>>>>>>    append l10n dot...
>>>>>> } else {
>>>>>> sb.append(c - '0' + zero);
>>>>>> }
>>>>>>
>>>>>> it appears the 'else" is missing? or I read it wrong?
>>>>>>
>>>>>> -Sherman
>>>>>>
>>>>>> On 09/23/2014 12:27 PM, Claes Redestad wrote:
>>>>>>> On 2014-09-23 21:14, Xueming Shen wrote:
>>>>>>>> On 09/22/2014 12:43 PM, Claes Redestad wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Sherman pointed out that there was a path that could actually 
>>>>>>>>> take a minor performance hit from this patch,
>>>>>>>>> which would be unacceptable. This version takes the minimal 
>>>>>>>>> approach to addressing this by adding back a
>>>>>>>>> method operating on a char[], simplified for the specific 
>>>>>>>>> usage case (the exponent part of a %g double formatting):
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~redestad/8050142/webrev.07/
>>>>>>>>>
>>>>>>>>> This latest patch passes using the extended test coverage of 
>>>>>>>>> java.util.Formatter I've proposed in 8058887, see
>>>>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028849.html 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Claes,
>>>>>>>>
>>>>>>>> Shouldn't we also keep the exp as char[] as well in "c == 
>>>>>>>> Conversion.SCIENTIFIC" case?
>>>>>>>> It appears the usage of exp is the same as the one in 
>>>>>>>> "GENERAL", in which we are keeping
>>>>>>>> the simple char[] for exp.
>>>>>>>
>>>>>>> You're right, of course. I'll update the webrev.
>>>>>>>
>>>>>>> /Claes
>>>>>>
>>>>>
>>>>
>>>
>>
>



From xueming.shen at oracle.com  Wed Sep 24 20:57:29 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 24 Sep 2014 13:57:29 -0700
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <54232AA6.5040702@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>	<54207BFE.9040907@oracle.com>
	<5421C683.9010208@oracle.com> <5421C9B3.6020809@oracle.com>
	<5421CA5B.4020104@oracle.com> <5421CD3D.1040502@oracle.com>
	<5421D43B.2060806@oracle.com> <5421E0FE.30602@oracle.com>
	<54230244.3000401@oracle.com> <54230A1C.40000@oracle.com>
	<54232AA6.5040702@oracle.com>
Message-ID: <54233039.6030002@oracle.com>

On 09/24/2014 01:33 PM, Claes Redestad wrote:
>
>
>
> Updated localizedMagnitudeExp to reside in FormatSpecifier, leaving getZero alone:
>
> http://cr.openjdk.java.net/~redestad/8050142/webrev.10/

I think we are good to go :-)  I was wrong on getZeron.


From brent.christian at oracle.com  Wed Sep 24 21:16:54 2014
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 24 Sep 2014 14:16:54 -0700
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <54233039.6030002@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>	<54207BFE.9040907@oracle.com>	<5421C683.9010208@oracle.com>
	<5421C9B3.6020809@oracle.com>	<5421CA5B.4020104@oracle.com>
	<5421CD3D.1040502@oracle.com>	<5421D43B.2060806@oracle.com>
	<5421E0FE.30602@oracle.com>	<54230244.3000401@oracle.com>
	<54230A1C.40000@oracle.com>	<54232AA6.5040702@oracle.com>
	<54233039.6030002@oracle.com>
Message-ID: <542334C6.7030201@oracle.com>

I can push this change, Claes.

-Brent


From claes.redestad at oracle.com  Wed Sep 24 21:24:01 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 24 Sep 2014 23:24:01 +0200
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <542334C6.7030201@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>	<54207BFE.9040907@oracle.com>	<5421C683.9010208@oracle.com>
	<5421C9B3.6020809@oracle.com>	<5421CA5B.4020104@oracle.com>
	<5421CD3D.1040502@oracle.com>	<5421D43B.2060806@oracle.com>
	<5421E0FE.30602@oracle.com>	<54230244.3000401@oracle.com>
	<54230A1C.40000@oracle.com>	<54232AA6.5040702@oracle.com>
	<54233039.6030002@oracle.com> <542334C6.7030201@oracle.com>
Message-ID: <54233671.5030903@oracle.com>

Sherman, Brent,

thanks for reviewing and sponsoring this!

/Claes

On 2014-09-24 23:16, Brent Christian wrote:
> I can push this change, Claes.
>
> -Brent



From Ulf.Zibis at CoSoCo.de  Wed Sep 24 21:40:45 2014
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Wed, 24 Sep 2014 23:40:45 +0200
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <542328C5.70303@gmail.com>
References: <54199AA9.2090804@oracle.com>	<54202D00.3010207@oracle.com>	<54202E81.8070004@oracle.com>	<54203237.5090901@oracle.com>
	<542328C5.70303@gmail.com>
Message-ID: <54233A5D.2060003@CoSoCo.de>


Am 24.09.2014 um 22:25 schrieb Peter Levart:
> Hi,
>
> String.hashCode() caches the result, so repeatable call to same String instance is faster for 2nd 
> and further invocations. But the computation of hash code itself could be accelerated for a factor 
> of 2 or more on todays CPUs. How? By parallelizing it. And I don't mean computing it in multiple 
> threads.
>
> Here is a surprising result of a simple benchmark which computes hash code of a 128 character 
> string in 6 different ways:
>
> Benchmark                    Mode   Samples        Score  Score error    Units
> j.t.HashBench.hashCode      thrpt         8  8420103.795 162447.069    ops/s
> j.t.HashBench.hashCode0     thrpt         8  8439058.660 2842.755    ops/s
> j.t.HashBench.hashCode1     thrpt         8 13809510.573 337888.132    ops/s
> j.t.HashBench.hashCode2     thrpt         8 15543687.568 716152.160    ops/s
> j.t.HashBench.hashCode3     thrpt         8 18173224.431 49410.256    ops/s
> j.t.HashBench.hashCode3x    thrpt         8  8543020.232 18158.686    ops/s
>
>
> Source:
>
> http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench.java

This is really great!

Couldn't this be a tweak via HotSpot, instead uglifying and bloating the Java and hence the byte code?

-Ulf



From brent.christian at oracle.com  Wed Sep 24 22:10:56 2014
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 24 Sep 2014 15:10:56 -0700
Subject: RFR [9]: 8050142: Optimize java.util.Formatter
In-Reply-To: <542334C6.7030201@oracle.com>
References: <53C3ABEA.9080009@oracle.com>	<53C3BE16.3040300@gmail.com>	<53C3BF33.7020403@oracle.com>	<53C3CBB1.9070305@oracle.com>,
	<53C3D4D7.3040204@oracle.com> <53C3E74F.8010900@oracle.com>,
	<53C3F9F9.3060903@oracle.com>	<BLU175-W49B63ABFC54F633FC436B2830A0@phx.gbl>	<53C45C88.3090000@oracle.com>	<54177BBF.4080000@oracle.com>	<A37A3160-020E-4842-88DA-68DFCA290DFB@oracle.com>	<54183806.8050401@oracle.com>	<54207BFE.9040907@oracle.com>	<5421C683.9010208@oracle.com>
	<5421C9B3.6020809@oracle.com>	<5421CA5B.4020104@oracle.com>
	<5421CD3D.1040502@oracle.com>	<5421D43B.2060806@oracle.com>
	<5421E0FE.30602@oracle.com>	<54230244.3000401@oracle.com>
	<54230A1C.40000@oracle.com>	<54232AA6.5040702@oracle.com>
	<54233039.6030002@oracle.com> <542334C6.7030201@oracle.com>
Message-ID: <54234170.1020203@oracle.com>

I had to make an update to satisfy jcheck, and neglected to specify the 
user when re-committing, so I'm listed as the author.  Sorry!

-Brent

On 9/24/14 2:16 PM, Brent Christian wrote:
> I can push this change, Claes.
>
> -Brent


From peter.levart at gmail.com  Wed Sep 24 22:46:19 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 25 Sep 2014 00:46:19 +0200
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <54233A5D.2060003@CoSoCo.de>
References: <54199AA9.2090804@oracle.com>	<54202D00.3010207@oracle.com>	<54202E81.8070004@oracle.com>	<54203237.5090901@oracle.com>	<542328C5.70303@gmail.com>
	<54233A5D.2060003@CoSoCo.de>
Message-ID: <542349BB.3080109@gmail.com>


On 09/24/2014 11:40 PM, Ulf Zibis wrote:
>
> Am 24.09.2014 um 22:25 schrieb Peter Levart:
>> Hi,
>>
>> String.hashCode() caches the result, so repeatable call to same 
>> String instance is faster for 2nd and further invocations. But the 
>> computation of hash code itself could be accelerated for a factor of 
>> 2 or more on todays CPUs. How? By parallelizing it. And I don't mean 
>> computing it in multiple threads.
>>
>> Here is a surprising result of a simple benchmark which computes hash 
>> code of a 128 character string in 6 different ways:
>>
>> Benchmark                    Mode   Samples        Score  Score 
>> error    Units
>> j.t.HashBench.hashCode      thrpt         8  8420103.795 
>> 162447.069    ops/s
>> j.t.HashBench.hashCode0     thrpt         8  8439058.660 2842.755    
>> ops/s
>> j.t.HashBench.hashCode1     thrpt         8 13809510.573 
>> 337888.132    ops/s
>> j.t.HashBench.hashCode2     thrpt         8 15543687.568 
>> 716152.160    ops/s
>> j.t.HashBench.hashCode3     thrpt         8 18173224.431 49410.256    
>> ops/s
>> j.t.HashBench.hashCode3x    thrpt         8  8543020.232 18158.686    
>> ops/s
>>
>>
>> Source:
>>
>> http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench.java
>
> This is really great!
>
> Couldn't this be a tweak via HotSpot, instead uglifying and bloating 
> the Java and hence the byte code?

This is for HotSpot compiler guys to answer. Theoretically I think it is 
possible. But it would have to be tailored to the very specific use case 
and I don't know if such specific transformation would have wide-enough 
applicability. If it would only speed-up String.hashCode and very 
similar loops, it is less trouble to do that by hand in one or few 
places...

Regards, Peter


>
> -Ulf
>



From weijun.wang at oracle.com  Thu Sep 25 04:51:59 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 25 Sep 2014 12:51:59 +0800
Subject: How to extract matches from (\d+[hms])+ ?
Message-ID: <D4BDF6AF-64E1-43A5-96B2-EAAABA812BB0@oracle.com>

Hi Sherman

I want to match a time duration like "1h20m30s" and "2h". It looks like if I directly use the pattern "((\\d+)([hms]))+", group(2) and group (3) only return the last match (i.e. 30 and s for 1h20m30s). So I tried multiple matching with "(\\d)([hms])" only, but find() does not always match from the beginning, and lookingAt() does not advance after one call.

This is my code now;

int start = 0;
while (true) {
  if (!m.find() || m.start() != start) {
    throw new Exception();
  }
  start = m.end();
  print(m.group(1), m.group(2));
  if (m.hitEnd()) break;
}
print("Done");

Is this the correct way?

Thanks
Max



From guy.steele at oracle.com  Thu Sep 25 05:06:35 2014
From: guy.steele at oracle.com (Guy Steele)
Date: Thu, 25 Sep 2014 01:06:35 -0400
Subject: How to extract matches from (\d+[hms])+ ?
In-Reply-To: <D4BDF6AF-64E1-43A5-96B2-EAAABA812BB0@oracle.com>
References: <D4BDF6AF-64E1-43A5-96B2-EAAABA812BB0@oracle.com>
Message-ID: <B1666866-0432-42D5-A502-B5E3CFB0AD82@oracle.com>

(A lurker sticking his nose in here! :-)  Is it your intent also to match "30s1h" or "20m30m" as a time duration?

If not, you might be better off with a pattern such as "((\\d+)h)?((\\d+)m)?((\\d+)s)?" and then the whole problem caused by the outer "+" iteration disappear (but you may need to check whether the original string was empty).

But maybe that takes all the fun out of it.

--Guy Steele

On Sep 25, 2014, at 12:51 AM, Wang Weijun <weijun.wang at oracle.com> wrote:

> Hi Sherman
> 
> I want to match a time duration like "1h20m30s" and "2h". It looks like if I directly use the pattern "((\\d+)([hms]))+", group(2) and group (3) only return the last match (i.e. 30 and s for 1h20m30s). So I tried multiple matching with "(\\d)([hms])" only, but find() does not always match from the beginning, and lookingAt() does not advance after one call.
> 
> This is my code now;
> 
> int start = 0;
> while (true) {
>  if (!m.find() || m.start() != start) {
>    throw new Exception();
>  }
>  start = m.end();
>  print(m.group(1), m.group(2));
>  if (m.hitEnd()) break;
> }
> print("Done");
> 
> Is this the correct way?
> 
> Thanks
> Max
> 



From weijun.wang at oracle.com  Thu Sep 25 05:08:55 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 25 Sep 2014 13:08:55 +0800
Subject: How to extract matches from (\d+[hms])+ ?
In-Reply-To: <B1666866-0432-42D5-A502-B5E3CFB0AD82@oracle.com>
References: <D4BDF6AF-64E1-43A5-96B2-EAAABA812BB0@oracle.com>
	<B1666866-0432-42D5-A502-B5E3CFB0AD82@oracle.com>
Message-ID: <DAF493E0-C847-48ED-B920-B96B657B807B@oracle.com>


On Sep 25, 2014, at 13:06, Guy Steele <guy.steele at oracle.com> wrote:

> (A lurker sticking his nose in here! :-)  Is it your intent also to match "30s1h" or "20m30m" as a time duration?
> 
> If not, you might be better off with a pattern such as "((\\d+)h)?((\\d+)m)?((\\d+)s)?" and then the whole problem caused by the outer "+" iteration disappear (but you may need to check whether the original string was empty).

Yes, this is much better.

> 
> But maybe that takes all the fun out of it.

Let someone else enjoy it then. :-)

Thanks
Max

> 
> --Guy Steele
> 
> On Sep 25, 2014, at 12:51 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
>> Hi Sherman
>> 
>> I want to match a time duration like "1h20m30s" and "2h". It looks like if I directly use the pattern "((\\d+)([hms]))+", group(2) and group (3) only return the last match (i.e. 30 and s for 1h20m30s). So I tried multiple matching with "(\\d)([hms])" only, but find() does not always match from the beginning, and lookingAt() does not advance after one call.
>> 
>> This is my code now;
>> 
>> int start = 0;
>> while (true) {
>> if (!m.find() || m.start() != start) {
>>   throw new Exception();
>> }
>> start = m.end();
>> print(m.group(1), m.group(2));
>> if (m.hitEnd()) break;
>> }
>> print("Done");
>> 
>> Is this the correct way?
>> 
>> Thanks
>> Max
>> 
> 



From xueming.shen at oracle.com  Wed Sep 24 06:58:49 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 23 Sep 2014 23:58:49 -0700
Subject: How to extract matches from (\d+[hms])+ ?
In-Reply-To: <DAF493E0-C847-48ED-B920-B96B657B807B@oracle.com>
References: <D4BDF6AF-64E1-43A5-96B2-EAAABA812BB0@oracle.com>
	<B1666866-0432-42D5-A502-B5E3CFB0AD82@oracle.com>
	<DAF493E0-C847-48ED-B920-B96B657B807B@oracle.com>
Message-ID: <202772AF-8448-4081-95A0-BE8B23DA21BF@oracle.com>

java/time/Duration.java has the pattern for the duration, which Is similar to Guy's suggestion.


> On Sep 24, 2014, at 10:08 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
> 
>> On Sep 25, 2014, at 13:06, Guy Steele <guy.steele at oracle.com> wrote:
>> 
>> (A lurker sticking his nose in here! :-)  Is it your intent also to match "30s1h" or "20m30m" as a time duration?
>> 
>> If not, you might be better off with a pattern such as "((\\d+)h)?((\\d+)m)?((\\d+)s)?" and then the whole problem caused by the outer "+" iteration disappear (but you may need to check whether the original string was empty).
> 
> Yes, this is much better.
> 
>> 
>> But maybe that takes all the fun out of it.
> 
> Let someone else enjoy it then. :-)
> 
> Thanks
> Max
> 
>> 
>> --Guy Steele
>> 
>>> On Sep 25, 2014, at 12:51 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
>>> 
>>> Hi Sherman
>>> 
>>> I want to match a time duration like "1h20m30s" and "2h". It looks like if I directly use the pattern "((\\d+)([hms]))+", group(2) and group (3) only return the last match (i.e. 30 and s for 1h20m30s). So I tried multiple matching with "(\\d)([hms])" only, but find() does not always match from the beginning, and lookingAt() does not advance after one call.
>>> 
>>> This is my code now;
>>> 
>>> int start = 0;
>>> while (true) {
>>> if (!m.find() || m.start() != start) {
>>>  throw new Exception();
>>> }
>>> start = m.end();
>>> print(m.group(1), m.group(2));
>>> if (m.hitEnd()) break;
>>> }
>>> print("Done");
>>> 
>>> Is this the correct way?
>>> 
>>> Thanks
>>> Max
> 


From aleksey.shipilev at oracle.com  Thu Sep 25 07:40:03 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 25 Sep 2014 11:40:03 +0400
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <542349BB.3080109@gmail.com>
References: <54199AA9.2090804@oracle.com>	<54202D00.3010207@oracle.com>	<54202E81.8070004@oracle.com>	<54203237.5090901@oracle.com>	<542328C5.70303@gmail.com>	<54233A5D.2060003@CoSoCo.de>
	<542349BB.3080109@gmail.com>
Message-ID: <5423C6D3.2070002@oracle.com>

Hi Peter,

On 09/25/2014 02:46 AM, Peter Levart wrote:
>>> http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench.java

Interesting.

I have to say it once again:
 a) It is *an error* to use static finals as the benchmark input. They
are perfectly constant-foldable in way too many cases. Break this habit,
please.
 b) Explicit Blackholes are not needed, and just returning "int" from
@Benchmark method helps readability a lot. Please break this habit as
well. Having readable and maintainable benchmarks is a key.

>> This is really great!
>>
>> Couldn't this be a tweak via HotSpot, instead uglifying and bloating
>> the Java and hence the byte code?

+1

> This is for HotSpot compiler guys to answer. Theoretically I think it is
> possible. But it would have to be tailored to the very specific use case
> and I don't know if such specific transformation would have wide-enough
> applicability. If it would only speed-up String.hashCode and very
> similar loops, it is less trouble to do that by hand in one or few
> places...

I would think this happens in user-specified hashCode() over arrays.
IDEs would routinely inject the loop like that or delegate to
Arrays.hashCode, that does the same loop.

In other words, I would like to see this fixed on compiler side. This
seems to be the strength-reduction playing tricks with loop unrolling,
I'll submit a bug shortly.

-Aleksey.




From aleksey.shipilev at oracle.com  Thu Sep 25 10:18:39 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Thu, 25 Sep 2014 14:18:39 +0400
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <5423C6D3.2070002@oracle.com>
References: <54199AA9.2090804@oracle.com>	<54202D00.3010207@oracle.com>	<54202E81.8070004@oracle.com>	<54203237.5090901@oracle.com>	<542328C5.70303@gmail.com>	<54233A5D.2060003@CoSoCo.de>	<542349BB.3080109@gmail.com>
	<5423C6D3.2070002@oracle.com>
Message-ID: <5423EBFF.4080407@oracle.com>

On 09/25/2014 11:40 AM, Aleksey Shipilev wrote:
>> This is for HotSpot compiler guys to answer. Theoretically I think it is
>> possible. But it would have to be tailored to the very specific use case
>> and I don't know if such specific transformation would have wide-enough
>> applicability. If it would only speed-up String.hashCode and very
>> similar loops, it is less trouble to do that by hand in one or few
>> places...
> 
> I would think this happens in user-specified hashCode() over arrays.
> IDEs would routinely inject the loop like that or delegate to
> Arrays.hashCode, that does the same loop.
> 
> In other words, I would like to see this fixed on compiler side. This
> seems to be the strength-reduction playing tricks with loop unrolling,
> I'll submit a bug shortly.

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

-Aleksey.



From peter.levart at gmail.com  Thu Sep 25 11:09:13 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 25 Sep 2014 13:09:13 +0200
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <5423C6D3.2070002@oracle.com>
References: <54199AA9.2090804@oracle.com>	<54202D00.3010207@oracle.com>	<54202E81.8070004@oracle.com>	<54203237.5090901@oracle.com>	<542328C5.70303@gmail.com>	<54233A5D.2060003@CoSoCo.de>
	<542349BB.3080109@gmail.com> <5423C6D3.2070002@oracle.com>
Message-ID: <5423F7D9.909@gmail.com>

On 09/25/2014 09:40 AM, Aleksey Shipilev wrote:
> Hi Peter,
>
> On 09/25/2014 02:46 AM, Peter Levart wrote:
>>>> http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench.java
> Interesting.
>
> I have to say it once again:
>   a) It is *an error* to use static finals as the benchmark input. They
> are perfectly constant-foldable in way too many cases. Break this habit,
> please.

Hi Aleksey,

The "constant" in this example is only a reference to the char[] array. 
It's content is not. In String, this is a final instance field, which 
behaves similarly inside an instance method (usually it is read only 
once per method invocation).

>   b) Explicit Blackholes are not needed, and just returning "int" from
> @Benchmark method helps readability a lot. Please break this habit as
> well. Having readable and maintainable benchmarks is a key.

Ok, here's a modified benchmark:

http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench2.java

Which behaves similarly.

Here are it's results:

  * Results on JDK9, Linux, i7-2600K CPU, JMH args: -f 1 -wi 5 -i 8 -gc true
  *
  * Benchmark                     Mode  Samples         Score  Score 
error  Units
  * j.t.HashBench2._hashCode     thrpt        8   8308858.217 
353019.084  ops/s
  * j.t.HashBench2.hashCode0     thrpt        8   8207337.729 
217048.634  ops/s
  * j.t.HashBench2.hashCode1     thrpt        8  13359572.359 
345736.675  ops/s
  * j.t.HashBench2.hashCode2     thrpt        8  15310621.202 
238369.017  ops/s
  * j.t.HashBench2.hashCode3     thrpt        8  17637944.829 
232155.847  ops/s
  * j.t.HashBench2.hashCode3i    thrpt        8  17724181.444 
509913.288  ops/s
  * j.t.HashBench2.hashCode3x    thrpt        8   8344128.432 
159508.813  ops/s
  * j.t.HashBench2.hashCode4     thrpt        8  16526850.489 
969549.448  ops/s
  * j.t.HashBench2.hashCode5     thrpt        8  17567765.554 
917934.885  ops/s
  * j.t.HashBench2.hashCode6     thrpt        8  17705074.332 
419405.652  ops/s
  * j.t.HashBench2.hashCode7     thrpt        8  18805633.563 
209181.299  ops/s
  * j.t.HashBench2.hashCode8     thrpt        8  18300123.201 
376681.550  ops/s

It would be interesting to see how it behaves on different CPUs.

>
>>> This is really great!
>>>
>>> Couldn't this be a tweak via HotSpot, instead uglifying and bloating
>>> the Java and hence the byte code?
> +1
>
>> This is for HotSpot compiler guys to answer. Theoretically I think it is
>> possible. But it would have to be tailored to the very specific use case
>> and I don't know if such specific transformation would have wide-enough
>> applicability. If it would only speed-up String.hashCode and very
>> similar loops, it is less trouble to do that by hand in one or few
>> places...
> I would think this happens in user-specified hashCode() over arrays.
> IDEs would routinely inject the loop like that or delegate to
> Arrays.hashCode, that does the same loop.

Arrays.hasCode() can be "improved" this way too.

>
> In other words, I would like to see this fixed on compiler side. This
> seems to be the strength-reduction playing tricks with loop unrolling,
> I'll submit a bug shortly.

As I said, I don't think it has anything to do with loop unrolling. The 
transformation I applied in hashCode1,2,3, ... 8 produces code that 
executes 2, 3, 4, ... 9 independent multiplications in each chunk, which 
allow CPU's pipeline to execute them in parallel. I had to manually 
unroll the loop a bit just to achieve this transformation. But my manual 
unrolling does not bring the speed-up per se. The parallelization of 
multiplication does. This can be seen by observing the score of 
hashCode3x benchmark, which has the same loop structure as hashCode3, 
but performs multiplications in a way where each of them depends on the 
result of a previous one, which prevents the CPU from parallelizing them.

This is not to say that such transformation couldn't be done on the JIT 
side. I just have a feeling that such transformation won't be widely 
used because it is very specific. It can only be used within integer 
arithmetic of the homogeneous width (since it changes the order of 
operations applied, the final result depends on which width is used when 
overflow happens). Floating arithmetic is equally unsiutable for such 
transformations that change order of operations. It can only help when 
the sequence of operations that are dependent on one another are changed 
into a sequence of independent operations and those operations have a 
weight that matters (such as multiplication).

Regards, Peter

>
> -Aleksey.
>
>



From richard.warburton at gmail.com  Thu Sep 25 14:48:24 2014
From: richard.warburton at gmail.com (Richard Warburton)
Date: Thu, 25 Sep 2014 15:48:24 +0100
Subject: Lower overhead String encoding/decoding
In-Reply-To: <54200F07.4070604@oracle.com>
References: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>
	<54200F07.4070604@oracle.com>
Message-ID: <CAMaYbv+Jc_98x7P2gGVEHJLsQq8kiSOx5EmmMjucwMhgKfNV7Q@mail.gmail.com>

Hi Alan,

Thanks for the feedback.

The direction seems reasonable but I wonder about the offset/length (and
> destOffet) parameters as this isn't consistent with how ByteBuffers were
> originally intended to be used. That is, when you read the bytes from the
> wire into a ByteBuffer and flip it then the position and limit will delimit
> the bytes to be decoded.
>
> If the constructor is changed to String(ByteBuffer in, Charset cs) and
> decodes the remaining bytes in the buffer to a String using the specified
> Charset then I think would be more consistent. Also I think this would give
> you a solution to the underflow case.
>

I've updated the webrev to reflect this, removing the offset and length
parameters and using position() and limit() instead.

http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-6/

Similarly if getBytes is replaced with with a getBytes or
> encode(ByteBuffer, Charset cs) then then it would encode as many characters
> as possible into the output buffer and I think would be more consistent and
> also help with overflow case.
>

I've also applied the this to the getBytes() method. I chose the getBytes()
method name for consistency with the existing getBytes() method that
returns a byte[]. To my mind encode() is a more natural name for the
method, which you mention in your email, do people have a preference here?

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto <http://twitter.com/richardwarburto>


From vitalyd at gmail.com  Thu Sep 25 16:00:07 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 25 Sep 2014 12:00:07 -0400
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <5423F7D9.909@gmail.com>
References: <54199AA9.2090804@oracle.com> <54202D00.3010207@oracle.com>
	<54202E81.8070004@oracle.com> <54203237.5090901@oracle.com>
	<542328C5.70303@gmail.com> <54233A5D.2060003@CoSoCo.de>
	<542349BB.3080109@gmail.com> <5423C6D3.2070002@oracle.com>
	<5423F7D9.909@gmail.com>
Message-ID: <CAHjP37EyT5YM1MCxts98gwatzw6N3yoyY--17_2gYZ32zaGS4Q@mail.gmail.com>

Note that compiler does not use multiplication here.  This is strength
reduced into a bit shift followed by a subtraction (i.e. h * 31 = h * 32
(i.e. sal 5) - h).  The point about allowing execution units to run in
parallel (given the break in data dependency) is very valid though.

For kicks and giggles, I looked at what gcc, clang, and icc generate for
similar C code at O2 and O3, and did not observe them making any
transformations to break the data dependency.

While it would be cool if compiler could do this transformation on its own,
as you say Peter, the scope of where this transform is applicable is
somewhat narrow(?).  If speeding up the non-cached String.hashCode() or
Arrays.hashCode() methods is desired, perhaps intrinsics could be
implemented (utility for String.hashCode seems low though).  In that case,
one could then do this transformation manually and also vectorize it for
long inputs.

On Thu, Sep 25, 2014 at 7:09 AM, Peter Levart <peter.levart at gmail.com>
wrote:

> On 09/25/2014 09:40 AM, Aleksey Shipilev wrote:
>
>> Hi Peter,
>>
>> On 09/25/2014 02:46 AM, Peter Levart wrote:
>>
>>> http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench.java
>>>>>
>>>> Interesting.
>>
>> I have to say it once again:
>>   a) It is *an error* to use static finals as the benchmark input. They
>> are perfectly constant-foldable in way too many cases. Break this habit,
>> please.
>>
>
> Hi Aleksey,
>
> The "constant" in this example is only a reference to the char[] array.
> It's content is not. In String, this is a final instance field, which
> behaves similarly inside an instance method (usually it is read only once
> per method invocation).
>
>    b) Explicit Blackholes are not needed, and just returning "int" from
>> @Benchmark method helps readability a lot. Please break this habit as
>> well. Having readable and maintainable benchmarks is a key.
>>
>
> Ok, here's a modified benchmark:
>
> http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench2.java
>
> Which behaves similarly.
>
> Here are it's results:
>
>  * Results on JDK9, Linux, i7-2600K CPU, JMH args: -f 1 -wi 5 -i 8 -gc true
>  *
>  * Benchmark                     Mode  Samples         Score  Score error
> Units
>  * j.t.HashBench2._hashCode     thrpt        8   8308858.217 353019.084
> ops/s
>  * j.t.HashBench2.hashCode0     thrpt        8   8207337.729 217048.634
> ops/s
>  * j.t.HashBench2.hashCode1     thrpt        8  13359572.359 345736.675
> ops/s
>  * j.t.HashBench2.hashCode2     thrpt        8  15310621.202 238369.017
> ops/s
>  * j.t.HashBench2.hashCode3     thrpt        8  17637944.829 232155.847
> ops/s
>  * j.t.HashBench2.hashCode3i    thrpt        8  17724181.444 509913.288
> ops/s
>  * j.t.HashBench2.hashCode3x    thrpt        8   8344128.432 159508.813
> ops/s
>  * j.t.HashBench2.hashCode4     thrpt        8  16526850.489 969549.448
> ops/s
>  * j.t.HashBench2.hashCode5     thrpt        8  17567765.554 917934.885
> ops/s
>  * j.t.HashBench2.hashCode6     thrpt        8  17705074.332 419405.652
> ops/s
>  * j.t.HashBench2.hashCode7     thrpt        8  18805633.563 209181.299
> ops/s
>  * j.t.HashBench2.hashCode8     thrpt        8  18300123.201 376681.550
> ops/s
>
> It would be interesting to see how it behaves on different CPUs.
>
>
>>  This is really great!
>>>>
>>>> Couldn't this be a tweak via HotSpot, instead uglifying and bloating
>>>> the Java and hence the byte code?
>>>>
>>> +1
>>
>>  This is for HotSpot compiler guys to answer. Theoretically I think it is
>>> possible. But it would have to be tailored to the very specific use case
>>> and I don't know if such specific transformation would have wide-enough
>>> applicability. If it would only speed-up String.hashCode and very
>>> similar loops, it is less trouble to do that by hand in one or few
>>> places...
>>>
>> I would think this happens in user-specified hashCode() over arrays.
>> IDEs would routinely inject the loop like that or delegate to
>> Arrays.hashCode, that does the same loop.
>>
>
> Arrays.hasCode() can be "improved" this way too.
>
>
>> In other words, I would like to see this fixed on compiler side. This
>> seems to be the strength-reduction playing tricks with loop unrolling,
>> I'll submit a bug shortly.
>>
>
> As I said, I don't think it has anything to do with loop unrolling. The
> transformation I applied in hashCode1,2,3, ... 8 produces code that
> executes 2, 3, 4, ... 9 independent multiplications in each chunk, which
> allow CPU's pipeline to execute them in parallel. I had to manually unroll
> the loop a bit just to achieve this transformation. But my manual unrolling
> does not bring the speed-up per se. The parallelization of multiplication
> does. This can be seen by observing the score of hashCode3x benchmark,
> which has the same loop structure as hashCode3, but performs
> multiplications in a way where each of them depends on the result of a
> previous one, which prevents the CPU from parallelizing them.
>
> This is not to say that such transformation couldn't be done on the JIT
> side. I just have a feeling that such transformation won't be widely used
> because it is very specific. It can only be used within integer arithmetic
> of the homogeneous width (since it changes the order of operations applied,
> the final result depends on which width is used when overflow happens).
> Floating arithmetic is equally unsiutable for such transformations that
> change order of operations. It can only help when the sequence of
> operations that are dependent on one another are changed into a sequence of
> independent operations and those operations have a weight that matters
> (such as multiplication).
>
> Regards, Peter
>
>
>> -Aleksey.
>>
>>
>>
>


From xueming.shen at oracle.com  Thu Sep 25 16:24:27 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 25 Sep 2014 09:24:27 -0700
Subject: Lower overhead String encoding/decoding
In-Reply-To: <CAMaYbv+Jc_98x7P2gGVEHJLsQq8kiSOx5EmmMjucwMhgKfNV7Q@mail.gmail.com>
References: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>	<54200F07.4070604@oracle.com>
	<CAMaYbv+Jc_98x7P2gGVEHJLsQq8kiSOx5EmmMjucwMhgKfNV7Q@mail.gmail.com>
Message-ID: <542441BB.600@oracle.com>

Hi Richard, couple comments after a quick scan.

(1)  #474, the IOBE probably is no longer needed in case of ByteBuffer. 
parameter.

(2) for methods that have the ByteBuffer as input, it would be desirable 
to specify clearly that
      the bytes are read from "position" to "limit", and whether or not 
the "position" will be advanced
      after decoding/encoding (important).

(3) getBytes(byte[], offset, charset)
      while I understand it might be useful to have such a method in 
certain circumstance, it is
      usually complicated to make it right/easy for user to actually use 
it. Consider the fact that
      the returned number of bytes encoded has no straightforward 
connection to how many
      underlying chars have been encoded (so the user of this method 
really have no idea how
      many underlying "chars" have been encoded into the dest buffer, is 
that enough? how big
      the buffer need to be to encode the whole string? ....) especially 
the possibility that the last
      couple byte space might be short of encoding a "char". Not like 
the getChars(), which has
      a easy, clear and direct link between the out going chars and 
underlying chars. I would
      suggest it might be better to leave it out.

(4) StringCoding.decode() #239  "remaining()" should be used to return 
limit - position?

(5) in case of "untrusted", it might be more straightforward to get all 
"bytes" out of the buffer
      first (you are allocating a byte buffer here anyway, I don;t see 
obvious benefit to get a
      direct buffer, btw) and then pass it to the original/existing 
byte[]->char[] decoding
      implementation. We probably will take a deep look at the 
implementation later when
      the public api settled.

-Sherman


Richard Warburton wrote:
> Hi Alan,
>
> Thanks for the feedback.
>
> The direction seems reasonable but I wonder about the offset/length (and
>> destOffet) parameters as this isn't consistent with how ByteBuffers were
>> originally intended to be used. That is, when you read the bytes from the
>> wire into a ByteBuffer and flip it then the position and limit will delimit
>> the bytes to be decoded.
>>
>> If the constructor is changed to String(ByteBuffer in, Charset cs) and
>> decodes the remaining bytes in the buffer to a String using the specified
>> Charset then I think would be more consistent. Also I think this would give
>> you a solution to the underflow case.
>>
> I've updated the webrev to reflect this, removing the offset and length
> parameters and using position() and limit() instead.
>
> http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-6/
>
> Similarly if getBytes is replaced with with a getBytes or
>> encode(ByteBuffer, Charset cs) then then it would encode as many characters
>> as possible into the output buffer and I think would be more consistent and
>> also help with overflow case.
>>
> I've also applied the this to the getBytes() method. I chose the getBytes()
> method name for consistency with the existing getBytes() method that
> returns a byte[]. To my mind encode() is a more natural name for the
> method, which you mention in your email, do people have a preference here?
>
> regards,
>
>    Richard Warburton
>
>    http://insightfullogic.com
>    @RichardWarburto <http://twitter.com/richardwarburto>



From xueming.shen at oracle.com  Thu Sep 25 16:44:39 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 25 Sep 2014 09:44:39 -0700
Subject: Lower overhead String encoding/decoding
In-Reply-To: <542441BB.600@oracle.com>
References: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>	<54200F07.4070604@oracle.com>	<CAMaYbv+Jc_98x7P2gGVEHJLsQq8kiSOx5EmmMjucwMhgKfNV7Q@mail.gmail.com>
	<542441BB.600@oracle.com>
Message-ID: <54244677.6090402@oracle.com>

On 9/25/14 9:24 AM, Xueming Shen wrote:
> Hi Richard, couple comments after a quick scan.
>
> (1)  #474, the IOBE probably is no longer needed in case of 
> ByteBuffer. parameter.
>
> (2) for methods that have the ByteBuffer as input, it would be 
> desirable to specify clearly that
>      the bytes are read from "position" to "limit", and whether or not 
> the "position" will be advanced
>      after decoding/encoding (important).
>
> (3) getBytes(byte[], offset, charset)
>      while I understand it might be useful to have such a method in 
> certain circumstance, it is
>      usually complicated to make it right/easy for user to actually 
> use it. Consider the fact that
>      the returned number of bytes encoded has no straightforward 
> connection to how many
>      underlying chars have been encoded (so the user of this method 
> really have no idea how
>      many underlying "chars" have been encoded into the dest buffer, 
> is that enough? how big
>      the buffer need to be to encode the whole string? ....) 
> especially the possibility that the last
>      couple byte space might be short of encoding a "char". Not like 
> the getChars(), which has
>      a easy, clear and direct link between the out going chars and 
> underlying chars. I would
>      suggest it might be better to leave it out.

I would assume this is true for the ByteBuffer version as well...just 
doubt the usefulness of
a method that it might only give you the bytes of part of the target 
string object. Given the
getBytes(ByteBuffer) version has the additional position/limit info form 
the buffer itself, a
"workaround" is to return the "number of underlying chars copied"...then 
you need one more
parameter to let user to copy from "index' for next round.

-sherman

>
> (4) StringCoding.decode() #239  "remaining()" should be used to return 
> limit - position?
>
> (5) in case of "untrusted", it might be more straightforward to get 
> all "bytes" out of the buffer
>      first (you are allocating a byte buffer here anyway, I don;t see 
> obvious benefit to get a
>      direct buffer, btw) and then pass it to the original/existing 
> byte[]->char[] decoding
>      implementation. We probably will take a deep look at the 
> implementation later when
>      the public api settled.
>
> -Sherman
>
>
> Richard Warburton wrote:
>> Hi Alan,
>>
>> Thanks for the feedback.
>>
>> The direction seems reasonable but I wonder about the offset/length (and
>>> destOffet) parameters as this isn't consistent with how ByteBuffers 
>>> were
>>> originally intended to be used. That is, when you read the bytes 
>>> from the
>>> wire into a ByteBuffer and flip it then the position and limit will 
>>> delimit
>>> the bytes to be decoded.
>>>
>>> If the constructor is changed to String(ByteBuffer in, Charset cs) and
>>> decodes the remaining bytes in the buffer to a String using the 
>>> specified
>>> Charset then I think would be more consistent. Also I think this 
>>> would give
>>> you a solution to the underflow case.
>>>
>> I've updated the webrev to reflect this, removing the offset and length
>> parameters and using position() and limit() instead.
>>
>> http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-6/
>>
>> Similarly if getBytes is replaced with with a getBytes or
>>> encode(ByteBuffer, Charset cs) then then it would encode as many 
>>> characters
>>> as possible into the output buffer and I think would be more 
>>> consistent and
>>> also help with overflow case.
>>>
>> I've also applied the this to the getBytes() method. I chose the 
>> getBytes()
>> method name for consistency with the existing getBytes() method that
>> returns a byte[]. To my mind encode() is a more natural name for the
>> method, which you mention in your email, do people have a preference 
>> here?
>>
>> regards,
>>
>>    Richard Warburton
>>
>>    http://insightfullogic.com
>>    @RichardWarburto <http://twitter.com/richardwarburto>
>



From peter.levart at gmail.com  Thu Sep 25 16:58:21 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 25 Sep 2014 18:58:21 +0200
Subject: RFR (XS) CR 8058643: (str) Re-examine hashCode implementation
In-Reply-To: <CAHjP37EyT5YM1MCxts98gwatzw6N3yoyY--17_2gYZ32zaGS4Q@mail.gmail.com>
References: <54199AA9.2090804@oracle.com>	<54202D00.3010207@oracle.com>	<54202E81.8070004@oracle.com>	<54203237.5090901@oracle.com>	<542328C5.70303@gmail.com>	<54233A5D.2060003@CoSoCo.de>	<542349BB.3080109@gmail.com>	<5423C6D3.2070002@oracle.com>	<5423F7D9.909@gmail.com>
	<CAHjP37EyT5YM1MCxts98gwatzw6N3yoyY--17_2gYZ32zaGS4Q@mail.gmail.com>
Message-ID: <542449AD.4070603@gmail.com>


On 09/25/2014 06:00 PM, Vitaly Davidovich wrote:
> Note that compiler does not use multiplication here.  This is strength 
> reduced into a bit shift followed by a subtraction (i.e. h * 31 = h * 
> 32 (i.e. sal 5) - h).

I've noticed that in the disassembly files provided by Aleksey. Good to 
know, so one is not bothered to use bit shifts in situations where 
multiplication / division look clearer in source code.

>   The point about allowing execution units to run in parallel (given 
> the break in data dependency) is very valid though.
>
> For kicks and giggles, I looked at what gcc, clang, and icc generate 
> for similar C code at O2 and O3, and did not observe them making any 
> transformations to break the data dependency.

So HotSpot can break the ice here ;-)

>
> While it would be cool if compiler could do this transformation on its 
> own, as you say Peter, the scope of where this transform is applicable 
> is somewhat narrow(?).  If speeding up the non-cached 
> String.hashCode() or Arrays.hashCode() methods is desired, perhaps 
> intrinsics could be implemented (utility for String.hashCode seems low 
> though).  In that case, one could then do this transformation manually 
> and also vectorize it for long inputs.

I see there are multiple options - each with it's own benefits and 
drawbacks. Hard to choose.

Regards, Peter

>
> On Thu, Sep 25, 2014 at 7:09 AM, Peter Levart <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>> wrote:
>
>     On 09/25/2014 09:40 AM, Aleksey Shipilev wrote:
>
>         Hi Peter,
>
>         On 09/25/2014 02:46 AM, Peter Levart wrote:
>
>                     http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench.java
>                     <http://cr.openjdk.java.net/%7Eplevart/misc/StringHash/HashBench.java>
>
>         Interesting.
>
>         I have to say it once again:
>           a) It is *an error* to use static finals as the benchmark
>         input. They
>         are perfectly constant-foldable in way too many cases. Break
>         this habit,
>         please.
>
>
>     Hi Aleksey,
>
>     The "constant" in this example is only a reference to the char[]
>     array. It's content is not. In String, this is a final instance
>     field, which behaves similarly inside an instance method (usually
>     it is read only once per method invocation).
>
>           b) Explicit Blackholes are not needed, and just returning
>         "int" from
>         @Benchmark method helps readability a lot. Please break this
>         habit as
>         well. Having readable and maintainable benchmarks is a key.
>
>
>     Ok, here's a modified benchmark:
>
>     http://cr.openjdk.java.net/~plevart/misc/StringHash/HashBench2.java <http://cr.openjdk.java.net/%7Eplevart/misc/StringHash/HashBench2.java>
>
>     Which behaves similarly.
>
>     Here are it's results:
>
>      * Results on JDK9, Linux, i7-2600K CPU, JMH args: -f 1 -wi 5 -i 8
>     -gc true
>      *
>      * Benchmark                     Mode  Samples  Score  Score
>     error  Units
>      * j.t.HashBench2._hashCode     thrpt        8 8308858.217
>     <tel:8308858.217> 353019.084  ops/s
>      * j.t.HashBench2.hashCode0     thrpt        8   8207337.729
>     217048.634  ops/s
>      * j.t.HashBench2.hashCode1     thrpt        8  13359572.359
>     345736.675  ops/s
>      * j.t.HashBench2.hashCode2     thrpt        8  15310621.202
>     238369.017  ops/s
>      * j.t.HashBench2.hashCode3     thrpt        8 17637944.829
>     <tel:17637944.829> 232155.847  ops/s
>      * j.t.HashBench2.hashCode3i    thrpt        8 17724181.444
>     <tel:17724181.444> 509913.288  ops/s
>      * j.t.HashBench2.hashCode3x    thrpt        8   8344128.432
>     159508.813  ops/s
>      * j.t.HashBench2.hashCode4     thrpt        8  16526850.489
>     969549.448  ops/s
>      * j.t.HashBench2.hashCode5     thrpt        8  17567765.554
>     917934.885  ops/s
>      * j.t.HashBench2.hashCode6     thrpt        8 17705074.332
>     <tel:17705074.332> 419405.652  ops/s
>      * j.t.HashBench2.hashCode7     thrpt        8  18805633.563
>     209181.299  ops/s
>      * j.t.HashBench2.hashCode8     thrpt        8  18300123.201
>     376681.550  ops/s
>
>     It would be interesting to see how it behaves on different CPUs.
>
>
>                 This is really great!
>
>                 Couldn't this be a tweak via HotSpot, instead
>                 uglifying and bloating
>                 the Java and hence the byte code?
>
>         +1
>
>             This is for HotSpot compiler guys to answer. Theoretically
>             I think it is
>             possible. But it would have to be tailored to the very
>             specific use case
>             and I don't know if such specific transformation would
>             have wide-enough
>             applicability. If it would only speed-up String.hashCode
>             and very
>             similar loops, it is less trouble to do that by hand in
>             one or few
>             places...
>
>         I would think this happens in user-specified hashCode() over
>         arrays.
>         IDEs would routinely inject the loop like that or delegate to
>         Arrays.hashCode, that does the same loop.
>
>
>     Arrays.hasCode() can be "improved" this way too.
>
>
>         In other words, I would like to see this fixed on compiler
>         side. This
>         seems to be the strength-reduction playing tricks with loop
>         unrolling,
>         I'll submit a bug shortly.
>
>
>     As I said, I don't think it has anything to do with loop
>     unrolling. The transformation I applied in hashCode1,2,3, ... 8
>     produces code that executes 2, 3, 4, ... 9 independent
>     multiplications in each chunk, which allow CPU's pipeline to
>     execute them in parallel. I had to manually unroll the loop a bit
>     just to achieve this transformation. But my manual unrolling does
>     not bring the speed-up per se. The parallelization of
>     multiplication does. This can be seen by observing the score of
>     hashCode3x benchmark, which has the same loop structure as
>     hashCode3, but performs multiplications in a way where each of
>     them depends on the result of a previous one, which prevents the
>     CPU from parallelizing them.
>
>     This is not to say that such transformation couldn't be done on
>     the JIT side. I just have a feeling that such transformation won't
>     be widely used because it is very specific. It can only be used
>     within integer arithmetic of the homogeneous width (since it
>     changes the order of operations applied, the final result depends
>     on which width is used when overflow happens). Floating arithmetic
>     is equally unsiutable for such transformations that change order
>     of operations. It can only help when the sequence of operations
>     that are dependent on one another are changed into a sequence of
>     independent operations and those operations have a weight that
>     matters (such as multiplication).
>
>     Regards, Peter
>
>
>         -Aleksey.
>
>
>
>



From daniel.fuchs at oracle.com  Fri Sep 26 18:33:44 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 26 Sep 2014 20:33:44 +0200
Subject: RFR: 8059269 - FileHandler may throw NPE if pattern is a simple name
	and the lock file already exists
Message-ID: <5425B188.5050402@oracle.com>

Hi,

Please find below a patch for [1]

8059269: FileHandler may throw NPE if pattern is a simple name and
          the lock file already exists

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

The webrev is here:
http://cr.openjdk.java.net/~dfuchs/webrev_8059269/webrev.00


This is a regression which I unfortunately introduced with my
patch for JDK-8048020 - and which I stumbled upon while writing
another test (which should have failed but didn't).

It happens in the uncommon case where:

  1. a lock file for the given name pattern already exists, and
    hasn't been created by another FileHandler in the same VM, and
  2. the file name pattern is a simple file name (not composite - that
    is, it doesn't contain any file separator).

In that case, FileHandler will attempt to reuse the existing
lock file, but it will first check whether the directory
in which the lock file should be created is writable, which it does
by calling Files.isWritable(lockFilePath.getParent()). We want to
check whether the directory is writable because there's no point
in locking the existing lock file if we can't create
any new file in that directory.

Unfortunately, lockFilePath.getParent() returns null if the file name
is simple, and a NullPointerException is thrown.


best regards,

-- daniel


From Alan.Bateman at oracle.com  Mon Sep 29 03:01:40 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Sep 2014 04:01:40 +0100
Subject: RFR: 8059269 - FileHandler may throw NPE if pattern is a simple
	name and the lock file already exists
In-Reply-To: <5425B188.5050402@oracle.com>
References: <5425B188.5050402@oracle.com>
Message-ID: <5428CB94.1090608@oracle.com>

On 26/09/2014 19:33, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for [1]
>
> 8059269: FileHandler may throw NPE if pattern is a simple name and
>          the lock file already exists
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8059269
>
> The webrev is here:
> http://cr.openjdk.java.net/~dfuchs/webrev_8059269/webrev.00
>
This looks okay to me, maybe an alternative is to just remove the check 
completely.

In the test then the test method could use try-with-resources so that if 
this test does fail then it would be best not to leave a file open.

-Alan




From daniel.fuchs at oracle.com  Mon Sep 29 08:51:24 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 29 Sep 2014 10:51:24 +0200
Subject: RFR: 8059269 - FileHandler may throw NPE if pattern is a simple
	name and the lock file already exists
In-Reply-To: <5428CB94.1090608@oracle.com>
References: <5425B188.5050402@oracle.com> <5428CB94.1090608@oracle.com>
Message-ID: <54291D8C.4040707@oracle.com>

On 29/09/14 05:01, Alan Bateman wrote:
> On 26/09/2014 19:33, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a patch for [1]
>>
>> 8059269: FileHandler may throw NPE if pattern is a simple name and
>>          the lock file already exists
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8059269
>>
>> The webrev is here:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8059269/webrev.00
>>
> This looks okay to me, maybe an alternative is to just remove the check
> completely.

Thanks Alan.

> In the test then the test method could use try-with-resources so that if
> this test does fail then it would be best not to leave a file open.

The files created by the test (both log files and lock files) will be
removed by the finally block at lines 150 - 174 - so the test shouldn't
leave any files open (which I verified by running the test on a JDK that
does not have the fix).

-- daniel
>
> -Alan
>
>



From peter.levart at gmail.com  Mon Sep 29 09:50:54 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 29 Sep 2014 11:50:54 +0200
Subject: Lower overhead String encoding/decoding
In-Reply-To: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>
References: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>
Message-ID: <54292B7E.5070400@gmail.com>

Hi,

On 09/22/2014 01:25 PM, Richard Warburton wrote:
> Hi all,
>
> A long-standing issue with Strings in Java is the ease and performance of
> creating a String from a ByteBuffer. People who are using nio to bring in
> data off the network will be receiving that data in the form of bytebuffers
> and converting it to some form of String. For example restful systems
> receiving XML or Json messages.
>
> The current workaround is to create a byte[] from the ByteBuffer - a
> copying action for any direct bytebuffer - and then pass that to the
> String.

An alternative is to use CharsetDecoder to program a "decoding 
operation" on input ByteBuffer(s), writing the result to CharBuffer(s). 
If the resulting CharBuffer is a single object (big enough), it can be 
converted to String via simple CharBuffer.toString(). Which is a 
copy-ing operation. In situations where the number of resulting 
characters can be anticipated in advance (like when we know in advance 
the number of bytes to be decoded and the charset used has fixed "number 
of bytes per char" or nearly fixed (like with UTF-8), a simple static 
utility method somewhere in java.lang.nio package could be used to 
optimize this operation:

     public static String decodeString(CharsetDecoder dec, ByteBuffer in)
         throws CharacterCodingException {

         CharBuffer cb = dec.decode(in);

         if (cb.length() == cb.hb.length) {
             // optimized no-copy String construction
             return 
SharedSecrets.getJavaLangAccess().newStringUnsafe(cb.hb);
         } else {
             return cb.toString();
         }
     }


>   I'd like to propose that we add an additional constructor to the
> String class that takes a ByteBuffer as an argument, and directly create
> the char[] value inside the String from the ByteBuffer.
>
> Similarly if you have a String that you want to encode onto the wire then
> you need to call String.getBytes(), then write your byte[] into a
> ByteBuffer or send it over the network.

Again, an alternative is to use CharBuffer.wrap(CharSequence cs, int 
start, int end) to wrap a String with a CharBuffer facade and then use 
CharsetEncoder to encode it directly into a resulting ByteBuffer. No 
additional copy-ing needed.

Regards, Peter

> This ends up allocating a byte[] to
> do the copy and also trimming the byte[] back down again, usually
> allocating another byte[]. To address this problem I've added a couple of
> getBytes() overloads that take byte[] and ByteBuffer arguments and write
> directly to those buffers.
>
> I've put together a patch that implements this to demonstrate the overall
> direction.
>
> http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-5/
>
> I'm happy to take any feedback on direction or the patch itself or the
> overall idea/approach. I think there are a number of similar API situations
> in other places as well, for example StringBuffer/StringBuilder instances
> which could have similar appends directly from ByteBuffer instances instead
> of byte[] instances.
>
> I'll also be at Javaone next week, so if you want to talk about this, just
> let me know.
>
> regards,
>
>    Richard Warburton
>
>    http://insightfullogic.com
>    @RichardWarburto <http://twitter.com/richardwarburto>
>
> PS: I appreciate that since I'm adding a method to the public API which
> consequently requires standardisation but I think that this could get
> incorporated into the Java 9 umbrella JSR.



From Alan.Bateman at oracle.com  Mon Sep 29 11:42:51 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Sep 2014 12:42:51 +0100
Subject: RFR: 8059269 - FileHandler may throw NPE if pattern is a simple
	name and the lock file already exists
In-Reply-To: <54291D8C.4040707@oracle.com>
References: <5425B188.5050402@oracle.com> <5428CB94.1090608@oracle.com>
	<54291D8C.4040707@oracle.com>
Message-ID: <542945BB.9070801@oracle.com>

On 29/09/2014 09:51, Daniel Fuchs wrote:
>
> The files created by the test (both log files and lock files) will be
> removed by the finally block at lines 150 - 174 - so the test shouldn't
> leave any files open (which I verified by running the test on a JDK that
> does not have the fix).
It's the lock files created at L233 & L234 that I'm wondering about. 
Suppose creating the second lock fails, that will leave the first lock 
file open (even if it removed).

-Alan.


From daniel.fuchs at oracle.com  Mon Sep 29 12:53:15 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 29 Sep 2014 14:53:15 +0200
Subject: RFR: 8059269 - FileHandler may throw NPE if pattern is a simple
	name and the lock file already exists
In-Reply-To: <542945BB.9070801@oracle.com>
References: <5425B188.5050402@oracle.com> <5428CB94.1090608@oracle.com>
	<54291D8C.4040707@oracle.com> <542945BB.9070801@oracle.com>
Message-ID: <5429563B.5000508@oracle.com>

On 29/09/14 13:42, Alan Bateman wrote:
> On 29/09/2014 09:51, Daniel Fuchs wrote:
>>
>> The files created by the test (both log files and lock files) will be
>> removed by the finally block at lines 150 - 174 - so the test shouldn't
>> leave any files open (which I verified by running the test on a JDK that
>> does not have the fix).
> It's the lock files created at L233 & L234 that I'm wondering about.
> Suppose creating the second lock fails, that will leave the first lock
> file open (even if it removed).

Do you mean that calling delete() will not close the file?

The lock files created at lines 233-234 are those that
are declared at lines 127-130 and they will be deleted
at line 164.

But since all the test wants to do at lines 233-234 is to
create the files, then it could probably close them just
after creating them.
We don't need to leave the file descriptors open.
It's a good point.

- 233   FileChannel.open(Paths.get(file + ".lck"), CREATE_NEW, WRITE);
- 234   FileChannel.open(Paths.get(file + ".1.lck"), CREATE_NEW, WRITE);
+ 233   FileChannel.open(Paths.get(file + ".lck"), CREATE_NEW, WRITE)
            .close();
+ 234  FileChannel.open(Paths.get(file + ".1.lck"), CREATE_NEW, WRITE)
            .close();

http://cr.openjdk.java.net/~dfuchs/webrev_8059269/webrev.01

Thanks!

-- daniel


>
> -Alan.



From Alan.Bateman at oracle.com  Mon Sep 29 13:12:04 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Sep 2014 14:12:04 +0100
Subject: RFR: 8059269 - FileHandler may throw NPE if pattern is a simple
	name and the lock file already exists
In-Reply-To: <5429563B.5000508@oracle.com>
References: <5425B188.5050402@oracle.com> <5428CB94.1090608@oracle.com>
	<54291D8C.4040707@oracle.com> <542945BB.9070801@oracle.com>
	<5429563B.5000508@oracle.com>
Message-ID: <54295AA4.2070305@oracle.com>

On 29/09/2014 13:53, Daniel Fuchs wrote:
>
> Do you mean that calling delete() will not close the file?
That's right.

>
> :
>
> - 233   FileChannel.open(Paths.get(file + ".lck"), CREATE_NEW, WRITE);
> - 234   FileChannel.open(Paths.get(file + ".1.lck"), CREATE_NEW, WRITE);
> + 233   FileChannel.open(Paths.get(file + ".lck"), CREATE_NEW, WRITE)
>            .close();
> + 234  FileChannel.open(Paths.get(file + ".1.lck"), CREATE_NEW, WRITE)
>            .close();
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8059269/webrev.01
That is okay, alternatively just use Files.createFile.

-Alan


From daniel.fuchs at oracle.com  Mon Sep 29 13:47:11 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 29 Sep 2014 15:47:11 +0200
Subject: RFR: 8059269 - FileHandler may throw NPE if pattern is a simple
	name and the lock file already exists
In-Reply-To: <54295AA4.2070305@oracle.com>
References: <5425B188.5050402@oracle.com> <5428CB94.1090608@oracle.com>
	<54291D8C.4040707@oracle.com> <542945BB.9070801@oracle.com>
	<5429563B.5000508@oracle.com> <54295AA4.2070305@oracle.com>
Message-ID: <542962DF.7070903@oracle.com>

On 29/09/14 15:12, Alan Bateman wrote:
> On 29/09/2014 13:53, Daniel Fuchs wrote:
>> - 233   FileChannel.open(Paths.get(file + ".lck"), CREATE_NEW, WRITE);
>> - 234   FileChannel.open(Paths.get(file + ".1.lck"), CREATE_NEW, WRITE);
>> + 233   FileChannel.open(Paths.get(file + ".lck"), CREATE_NEW, WRITE)
>>            .close();
>> + 234  FileChannel.open(Paths.get(file + ".1.lck"), CREATE_NEW, WRITE)
>>            .close();
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8059269/webrev.01
> That is okay, alternatively just use Files.createFile.

Oh, much simpler indeed. What was I thinking?
Done.
http://cr.openjdk.java.net/~dfuchs/webrev_8059269/webrev.02

-- daniel




From pbenedict at apache.org  Mon Sep 29 14:29:13 2014
From: pbenedict at apache.org (Paul Benedict)
Date: Mon, 29 Sep 2014 09:29:13 -0500
Subject: Fwd: No for each loop comment?
In-Reply-To: <CAAFrFhQzkqLACn9WpdqfEEYUs8sAKC3vVT1LKu7Eq6G-870iuw@mail.gmail.com>
References: <CACZkXPwt1Av4LiVGHCvo+596QSXYiuqE-J_LvrAjJzaWbOESZw@mail.gmail.com>
	<CACmp6koAr=Yu0xkHVeQfiEUuNjzpdNJXByv2qJVmy=2VS4kbdw@mail.gmail.com>
	<9D348A16-A49D-4C38-81B0-6E66B86DCB07@gmail.com>
	<58EE9B4F-B192-493F-90DE-E2DD7C329CB5@dslextreme.com>
	<CAAFrFhS7gD8kBco4t3k5RNLBh51jzFo5YE7mGamUDuiZbte3pA@mail.gmail.com>
	<CABLGb9wpuU7RPACLFqCuPqmaDqxbEjOVZO81qK+9c4HRVXXy6Q@mail.gmail.com>
	<F4BC6AAA-3221-4433-84FD-E0A0E81539F4@dslextreme.com>
	<CACZkXPxZsVvN5JcTPSi8ja94gkfBKRhkT5KKtpW40h0RK5wEsQ@mail.gmail.com>
	<CACmp6koOkfS7YcGa50nP4dGa1UY19btfp2AD3hc__F+ATQTssg@mail.gmail.com>
	<CAAFrFhQzkqLACn9WpdqfEEYUs8sAKC3vVT1LKu7Eq6G-870iuw@mail.gmail.com>
Message-ID: <CABLGb9wfKsun2MyycVpzz57H6sdCb5r=KgstC0fgaAPgkBo=Jg@mail.gmail.com>

Open JDKers, I am forwarding an email to get some clarification. It's been
a common understanding that foreach should perform no differently than the
equivalent for-loop . However, some fellow developers claim there is a
noticable difference in their microbenchmarking. Can you help explain what
is really going on? It's either the case there is a true difference (a
result that would surprise me) or the results are within a margin of error
that make the results insignificant. Please advise.

Cheers,
Paul

---------- Forwarded message ----------
From: Remko Popma <remko.popma at gmail.com>
Date: Fri, Sep 26, 2014 at 8:43 AM
Subject: Re: No for each loop comment?
To: Log4J Developers List <log4j-dev at logging.apache.org>


On Windows it looks like normal for loops are slightly faster than for-each
loops, especially for small arrays of primitives. This could be noise,
since we are talking about 5 nanoseconds where the baseline (an empty
method invocation) is 12 nanos.

On Solaris 10 and Red Hat Enterprise Linux the baseline is so large (255
nanos and 1910 nanos respectively) that any difference we are seeing is
just noise.

All benchmarks were run with one fork, one thread, 10 warmup iterations and
10 test iterations.

*Windows 7 (64bit) with Java 1.8.0_05, 2-core Intel i5-3317u CPU @1.70Ghz
with hyperthreading switched on (4 virtual cores)*
Benchmark                                                Mode  Samples
 Score  Score error  Units
o.a.l.l.p.j.LoopsBenchmark.baseline                    sample   154947
12.432        0.550  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray10000ForEachLoop    sample   126597
2759.592        3.431  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray10000ForLoop        sample   126494
2761.729        3.127  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray1000ForEachLoop     sample   154124
 292.880        1.065  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray1000ForLoop         sample   156155
 288.751        1.101  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray100ForEachLoop      sample   191980
41.826        0.870  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray100ForLoop          sample   193770
36.894        0.782  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray10ForEachLoop       sample   190847
22.393        0.618  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray10ForLoop           sample   192552
17.146        0.560  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray10000ForEachLoop    sample   173839
 31959.057       14.341  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray10000ForLoop        sample   171137
 32461.985       14.353  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray1000ForEachLoop     sample    97495
3591.200        4.852  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray1000ForLoop         sample   101560
3445.998        4.010  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray100ForEachLoop      sample   102796
 438.207        1.923  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray100ForLoop          sample   102333
 439.576        2.139  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray10ForEachLoop       sample   113924
58.957        1.247  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray10ForLoop           sample   120416
60.712        1.284  ns/op


// For loops for Object arrays are similar but return the total XOR of the
element hashcodes.

private int forEachLoop(final int[] array) {
    int result = 0;
    for (final int element : array) {
        result ^= element;
    }
    return result;
}

private int forLoop(final int[] array) {
    int result = 0;
    for (int i = 0; i < array.length; i++) {
        result ^= array[i];
    }
    return result;
}



*Solaris 10 (64bit) with JDK1.7.0_06-b24 (Oracle Hotspot), 2 quad-core Xeon
X5570 dual CPUs @2.93Ghz with hyperthreading switched on (16 virtual cores)*
Benchmark                                                Mode  Samples
 Score  Score error  Units
o.a.l.l.p.j.LoopsBenchmark.baseline                    sample   110212
 255.300        0.201  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray10000ForEachLoop    sample   187808
3938.055        1.207  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray10000ForLoop        sample   187897
3937.929        0.748  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray1000ForEachLoop     sample   123989
 606.631        0.626  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray1000ForLoop         sample   123973
 609.565        0.416  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray100ForEachLoop      sample   126933
 294.204        0.280  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray100ForLoop          sample   127070
 296.411        0.223  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray10ForEachLoop       sample   113400
 261.519        0.181  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray10ForLoop           sample   111637
 260.435        0.115  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray10000ForEachLoop    sample   115872
 48154.673       18.846  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray10000ForLoop        sample   116777
 47793.868       17.615  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray1000ForEachLoop     sample   138432
5256.767        2.451  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray1000ForLoop         sample   136644
5325.377        2.388  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray100ForEachLoop      sample   166653
 773.541        0.330  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray100ForLoop          sample   166570
 774.513        0.574  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray10ForEachLoop       sample   178754
 317.232        0.134  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray10ForLoop           sample   180165
 316.189        0.238  ns/op

*64 bit RHEL 6.5 (Linux 2.6.32-431.el6.x86_64) with JDK1.7.0_05-b06 (Oracle
Hotspot), 4 quad-core Xeon X5570 CPUs @2.93GHz with hyperthreading switched
on (16 virtual cores)*
Benchmark                                                Mode  Samples
 Score  Score error  Units
o.a.l.l.p.j.LoopsBenchmark.baseline                    sample   114783
1910.576       29.256  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray10000ForEachLoop    sample   194584
5132.885       25.137  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray10000ForLoop        sample   196672
4811.572       52.072  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray1000ForEachLoop     sample   133119
1967.213       28.970  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray1000ForLoop         sample   133804
2004.501       31.554  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray100ForEachLoop      sample   142439
1575.329        6.457  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray100ForLoop          sample   142215
1957.714       27.815  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray10ForEachLoop       sample   130826
1980.301       30.818  ns/op
o.a.l.l.p.j.LoopsBenchmark.intArray10ForLoop           sample   132654
1589.120        8.449  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray10000ForEachLoop    sample   126947
 43301.320       50.589  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray10000ForLoop        sample   126117
 43574.129       55.272  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray1000ForEachLoop     sample   143697
5831.250       19.667  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray1000ForLoop         sample   163244
4823.096       13.180  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray100ForEachLoop      sample   162502
1930.819       24.136  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray100ForLoop          sample   171619
1625.806       10.385  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray10ForEachLoop       sample   172226
1888.683       22.554  ns/op
o.a.l.l.p.j.LoopsBenchmark.objArray10ForLoop           sample   188838
1581.979        6.322  ns/op




On Fri, Sep 26, 2014 at 2:56 AM, Matt Sicker <boards at gmail.com> wrote:

> The foreach over an array looks like it's supposed to compile to the same
> thing:
>
> https://jcp.org/aboutJava/communityprocess/jsr/tiger/enhanced-for.html
>
> Same goes for .length which is supposed to be a final field which would
> allow for inlining by the JIT I'd imagine (hence why we use final
> everywhere):
>
> http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.7
>
>
>>>> On 24 September 2014 22:12, Gary Gregory <garydgregory at gmail.com>
>>>> wrote:
>>>>
>>>>> Why does this "//noinspection ForLoopReplaceableByForEach" comment
>>>>> mean?
>>>>>
>>>>> Why not for an enhanced for each loop?
>>>>>
>>>>>  private static boolean contains(final Marker parent, final Marker...
>>>>> localParents) {
>>>>>             //noinspection ForLoopReplaceableByForEach
>>>>>             for (int i = 0, localParentsLength = localParents.length;
>>>>> i < localParentsLength; i++) {
>>>>>                 final Marker marker = localParents[i];
>>>>>                 if (marker == parent) {
>>>>>                     return true;
>>>>>                 }
>>>>>             }
>>>>>             return false;
>>>>>         }
>>>>>
>>>>> Thanks,
>>>>> Gary
>>>>>
>>>>>
>>>>>


From aph at redhat.com  Mon Sep 29 15:21:55 2014
From: aph at redhat.com (Andrew Haley)
Date: Mon, 29 Sep 2014 16:21:55 +0100
Subject: Fwd: No for each loop comment?
In-Reply-To: <CABLGb9wfKsun2MyycVpzz57H6sdCb5r=KgstC0fgaAPgkBo=Jg@mail.gmail.com>
References: <CACZkXPwt1Av4LiVGHCvo+596QSXYiuqE-J_LvrAjJzaWbOESZw@mail.gmail.com>	<CACmp6koAr=Yu0xkHVeQfiEUuNjzpdNJXByv2qJVmy=2VS4kbdw@mail.gmail.com>	<9D348A16-A49D-4C38-81B0-6E66B86DCB07@gmail.com>	<58EE9B4F-B192-493F-90DE-E2DD7C329CB5@dslextreme.com>	<CAAFrFhS7gD8kBco4t3k5RNLBh51jzFo5YE7mGamUDuiZbte3pA@mail.gmail.com>	<CABLGb9wpuU7RPACLFqCuPqmaDqxbEjOVZO81qK+9c4HRVXXy6Q@mail.gmail.com>	<F4BC6AAA-3221-4433-84FD-E0A0E81539F4@dslextreme.com>	<CACZkXPxZsVvN5JcTPSi8ja94gkfBKRhkT5KKtpW40h0RK5wEsQ@mail.gmail.com>	<CACmp6koOkfS7YcGa50nP4dGa1UY19btfp2AD3hc__F+ATQTssg@mail.gmail.com>	<CAAFrFhQzkqLACn9WpdqfEEYUs8sAKC3vVT1LKu7Eq6G-870iuw@mail.gmail.com>
	<CABLGb9wfKsun2MyycVpzz57H6sdCb5r=KgstC0fgaAPgkBo=Jg@mail.gmail.com>
Message-ID: <54297913.30706@redhat.com>

On 09/29/2014 03:29 PM, Paul Benedict wrote:
> Open JDKers, I am forwarding an email to get some clarification. It's been
> a common understanding that foreach should perform no differently than the
> equivalent for-loop . However, some fellow developers claim there is a
> noticable difference in their microbenchmarking. Can you help explain what
> is really going on? It's either the case there is a true difference (a
> result that would surprise me) or the results are within a margin of error
> that make the results insignificant. Please advise.

The actual code that such a forEach loop generates is this:

    private int forLoop(final int[] array) {
        int result = 0;
        int[] a = array;
        int len = a.length;
        for (int i = 0; i < len; i++) {
            int element = a[i];
            result ^= element;
        }
        return result;
    }

If you get different timings for this one, then the measurements are
suspect.

Java microbenchmarking is notoriously difficult.  Please try to use
jmh; you'll get better and easier to interpret results.

Andrew.


http://openjdk.java.net/projects/code-tools/jmh/



From vitalyd at gmail.com  Mon Sep 29 16:31:11 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 29 Sep 2014 12:31:11 -0400
Subject: Fwd: No for each loop comment?
In-Reply-To: <54297913.30706@redhat.com>
References: <CACZkXPwt1Av4LiVGHCvo+596QSXYiuqE-J_LvrAjJzaWbOESZw@mail.gmail.com>
	<CACmp6koAr=Yu0xkHVeQfiEUuNjzpdNJXByv2qJVmy=2VS4kbdw@mail.gmail.com>
	<9D348A16-A49D-4C38-81B0-6E66B86DCB07@gmail.com>
	<58EE9B4F-B192-493F-90DE-E2DD7C329CB5@dslextreme.com>
	<CAAFrFhS7gD8kBco4t3k5RNLBh51jzFo5YE7mGamUDuiZbte3pA@mail.gmail.com>
	<CABLGb9wpuU7RPACLFqCuPqmaDqxbEjOVZO81qK+9c4HRVXXy6Q@mail.gmail.com>
	<F4BC6AAA-3221-4433-84FD-E0A0E81539F4@dslextreme.com>
	<CACZkXPxZsVvN5JcTPSi8ja94gkfBKRhkT5KKtpW40h0RK5wEsQ@mail.gmail.com>
	<CACmp6koOkfS7YcGa50nP4dGa1UY19btfp2AD3hc__F+ATQTssg@mail.gmail.com>
	<CAAFrFhQzkqLACn9WpdqfEEYUs8sAKC3vVT1LKu7Eq6G-870iuw@mail.gmail.com>
	<CABLGb9wfKsun2MyycVpzz57H6sdCb5r=KgstC0fgaAPgkBo=Jg@mail.gmail.com>
	<54297913.30706@redhat.com>
Message-ID: <CAHjP37EiznZA2YP4xdBSUTFOCWiEtGNng7eyj3A2Hy97oCK_Yw@mail.gmail.com>

I think Paul's email already has jmh output.

I looked at the generated asm on 7u60 x64 linux, and didn't see any
material difference.

Paul, have you or anyone else looked at the machine code diffs between the
two? Looking at timing is useful, but it's possible to get caught up in
noise; the generated assembly should provide more conclusive data on
whether any real difference is there or not.

On Mon, Sep 29, 2014 at 11:21 AM, Andrew Haley <aph at redhat.com> wrote:

> On 09/29/2014 03:29 PM, Paul Benedict wrote:
> > Open JDKers, I am forwarding an email to get some clarification. It's
> been
> > a common understanding that foreach should perform no differently than
> the
> > equivalent for-loop . However, some fellow developers claim there is a
> > noticable difference in their microbenchmarking. Can you help explain
> what
> > is really going on? It's either the case there is a true difference (a
> > result that would surprise me) or the results are within a margin of
> error
> > that make the results insignificant. Please advise.
>
> The actual code that such a forEach loop generates is this:
>
>     private int forLoop(final int[] array) {
>         int result = 0;
>         int[] a = array;
>         int len = a.length;
>         for (int i = 0; i < len; i++) {
>             int element = a[i];
>             result ^= element;
>         }
>         return result;
>     }
>
> If you get different timings for this one, then the measurements are
> suspect.
>
> Java microbenchmarking is notoriously difficult.  Please try to use
> jmh; you'll get better and easier to interpret results.
>
> Andrew.
>
>
> http://openjdk.java.net/projects/code-tools/jmh/
>
>


From aph at redhat.com  Mon Sep 29 16:48:39 2014
From: aph at redhat.com (Andrew Haley)
Date: Mon, 29 Sep 2014 17:48:39 +0100
Subject: Fwd: No for each loop comment?
In-Reply-To: <CAHjP37EiznZA2YP4xdBSUTFOCWiEtGNng7eyj3A2Hy97oCK_Yw@mail.gmail.com>
References: <CACZkXPwt1Av4LiVGHCvo+596QSXYiuqE-J_LvrAjJzaWbOESZw@mail.gmail.com>	<CACmp6koAr=Yu0xkHVeQfiEUuNjzpdNJXByv2qJVmy=2VS4kbdw@mail.gmail.com>	<9D348A16-A49D-4C38-81B0-6E66B86DCB07@gmail.com>	<58EE9B4F-B192-493F-90DE-E2DD7C329CB5@dslextreme.com>	<CAAFrFhS7gD8kBco4t3k5RNLBh51jzFo5YE7mGamUDuiZbte3pA@mail.gmail.com>	<CABLGb9wpuU7RPACLFqCuPqmaDqxbEjOVZO81qK+9c4HRVXXy6Q@mail.gmail.com>	<F4BC6AAA-3221-4433-84FD-E0A0E81539F4@dslextreme.com>	<CACZkXPxZsVvN5JcTPSi8ja94gkfBKRhkT5KKtpW40h0RK5wEsQ@mail.gmail.com>	<CACmp6koOkfS7YcGa50nP4dGa1UY19btfp2AD3hc__F+ATQTssg@mail.gmail.com>	<CAAFrFhQzkqLACn9WpdqfEEYUs8sAKC3vVT1LKu7Eq6G-870iuw@mail.gmail.com>	<CABLGb9wfKsun2MyycVpzz57H6sdCb5r=KgstC0fgaAPgkBo=Jg@mail.gmail.com>	<54297913.30706@redhat.com>
	<CAHjP37EiznZA2YP4xdBSUTFOCWiEtGNng7eyj3A2Hy97oCK_Yw@mail.gmail.com>
Message-ID: <54298D67.9070004@redhat.com>

On 09/29/2014 05:31 PM, Vitaly Davidovich wrote:
> I think Paul's email already has jmh output.

Oh duh, sorry Paul.

Andrew.



From pbenedict at apache.org  Mon Sep 29 17:58:48 2014
From: pbenedict at apache.org (Paul Benedict)
Date: Mon, 29 Sep 2014 12:58:48 -0500
Subject: Fwd: No for each loop comment?
In-Reply-To: <CAHjP37EiznZA2YP4xdBSUTFOCWiEtGNng7eyj3A2Hy97oCK_Yw@mail.gmail.com>
References: <CACZkXPwt1Av4LiVGHCvo+596QSXYiuqE-J_LvrAjJzaWbOESZw@mail.gmail.com>
	<CACmp6koAr=Yu0xkHVeQfiEUuNjzpdNJXByv2qJVmy=2VS4kbdw@mail.gmail.com>
	<9D348A16-A49D-4C38-81B0-6E66B86DCB07@gmail.com>
	<58EE9B4F-B192-493F-90DE-E2DD7C329CB5@dslextreme.com>
	<CAAFrFhS7gD8kBco4t3k5RNLBh51jzFo5YE7mGamUDuiZbte3pA@mail.gmail.com>
	<CABLGb9wpuU7RPACLFqCuPqmaDqxbEjOVZO81qK+9c4HRVXXy6Q@mail.gmail.com>
	<F4BC6AAA-3221-4433-84FD-E0A0E81539F4@dslextreme.com>
	<CACZkXPxZsVvN5JcTPSi8ja94gkfBKRhkT5KKtpW40h0RK5wEsQ@mail.gmail.com>
	<CACmp6koOkfS7YcGa50nP4dGa1UY19btfp2AD3hc__F+ATQTssg@mail.gmail.com>
	<CAAFrFhQzkqLACn9WpdqfEEYUs8sAKC3vVT1LKu7Eq6G-870iuw@mail.gmail.com>
	<CABLGb9wfKsun2MyycVpzz57H6sdCb5r=KgstC0fgaAPgkBo=Jg@mail.gmail.com>
	<54297913.30706@redhat.com>
	<CAHjP37EiznZA2YP4xdBSUTFOCWiEtGNng7eyj3A2Hy97oCK_Yw@mail.gmail.com>
Message-ID: <CABLGb9zKKUtG3E0qzQ8jL6fHOyUW99a8fo2+TBzOBM3u7VBi-w@mail.gmail.com>

Bytecode output courtesy of Mikael St?ldal:

With standard loop:

  private static boolean contains(org.apache.logging.log4j.Marker,
org.apache.logging.log4j.Marker...);
    Code:
       0: iconst_0
       1: istore_2
       2: aload_1
       3: arraylength
       4: istore_3
       5: iload_2
       6: iload_3
       7: if_icmpge     29
      10: aload_1
      11: iload_2
      12: aaload
      13: astore        4
      15: aload         4
      17: aload_0
      18: if_acmpne     23
      21: iconst_1
      22: ireturn
      23: iinc          2, 1
      26: goto          5
      29: iconst_0
      30: ireturn


With for-each:

  private static boolean contains(org.apache.logging.log4j.Marker,
org.apache.logging.log4j.Marker...);
    Code:
       0: aload_1
       1: astore_2
       2: aload_2
       3: arraylength
       4: istore_3
       5: iconst_0
       6: istore        4
       8: iload         4
      10: iload_3
      11: if_icmpge     34
      14: aload_2
      15: iload         4
      17: aaload
      18: astore        5
      20: aload         5
      22: aload_0
      23: if_acmpne     28
      26: iconst_1
      27: ireturn
      28: iinc          4, 1
      31: goto          8
      34: iconst_0
      35: ireturn



Cheers,
Paul

On Mon, Sep 29, 2014 at 11:31 AM, Vitaly Davidovich <vitalyd at gmail.com>
wrote:

> I think Paul's email already has jmh output.
>
> I looked at the generated asm on 7u60 x64 linux, and didn't see any
> material difference.
>
> Paul, have you or anyone else looked at the machine code diffs between the
> two? Looking at timing is useful, but it's possible to get caught up in
> noise; the generated assembly should provide more conclusive data on
> whether any real difference is there or not.
>
> On Mon, Sep 29, 2014 at 11:21 AM, Andrew Haley <aph at redhat.com> wrote:
>
>> On 09/29/2014 03:29 PM, Paul Benedict wrote:
>> > Open JDKers, I am forwarding an email to get some clarification. It's
>> been
>> > a common understanding that foreach should perform no differently than
>> the
>> > equivalent for-loop . However, some fellow developers claim there is a
>> > noticable difference in their microbenchmarking. Can you help explain
>> what
>> > is really going on? It's either the case there is a true difference (a
>> > result that would surprise me) or the results are within a margin of
>> error
>> > that make the results insignificant. Please advise.
>>
>> The actual code that such a forEach loop generates is this:
>>
>>     private int forLoop(final int[] array) {
>>         int result = 0;
>>         int[] a = array;
>>         int len = a.length;
>>         for (int i = 0; i < len; i++) {
>>             int element = a[i];
>>             result ^= element;
>>         }
>>         return result;
>>     }
>>
>> If you get different timings for this one, then the measurements are
>> suspect.
>>
>> Java microbenchmarking is notoriously difficult.  Please try to use
>> jmh; you'll get better and easier to interpret results.
>>
>> Andrew.
>>
>>
>> http://openjdk.java.net/projects/code-tools/jmh/
>>
>>
>


From vitalyd at gmail.com  Mon Sep 29 18:03:39 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 29 Sep 2014 14:03:39 -0400
Subject: Fwd: No for each loop comment?
In-Reply-To: <CABLGb9zKKUtG3E0qzQ8jL6fHOyUW99a8fo2+TBzOBM3u7VBi-w@mail.gmail.com>
References: <CACZkXPwt1Av4LiVGHCvo+596QSXYiuqE-J_LvrAjJzaWbOESZw@mail.gmail.com>
	<CACmp6koAr=Yu0xkHVeQfiEUuNjzpdNJXByv2qJVmy=2VS4kbdw@mail.gmail.com>
	<9D348A16-A49D-4C38-81B0-6E66B86DCB07@gmail.com>
	<58EE9B4F-B192-493F-90DE-E2DD7C329CB5@dslextreme.com>
	<CAAFrFhS7gD8kBco4t3k5RNLBh51jzFo5YE7mGamUDuiZbte3pA@mail.gmail.com>
	<CABLGb9wpuU7RPACLFqCuPqmaDqxbEjOVZO81qK+9c4HRVXXy6Q@mail.gmail.com>
	<F4BC6AAA-3221-4433-84FD-E0A0E81539F4@dslextreme.com>
	<CACZkXPxZsVvN5JcTPSi8ja94gkfBKRhkT5KKtpW40h0RK5wEsQ@mail.gmail.com>
	<CACmp6koOkfS7YcGa50nP4dGa1UY19btfp2AD3hc__F+ATQTssg@mail.gmail.com>
	<CAAFrFhQzkqLACn9WpdqfEEYUs8sAKC3vVT1LKu7Eq6G-870iuw@mail.gmail.com>
	<CABLGb9wfKsun2MyycVpzz57H6sdCb5r=KgstC0fgaAPgkBo=Jg@mail.gmail.com>
	<54297913.30706@redhat.com>
	<CAHjP37EiznZA2YP4xdBSUTFOCWiEtGNng7eyj3A2Hy97oCK_Yw@mail.gmail.com>
	<CABLGb9zKKUtG3E0qzQ8jL6fHOyUW99a8fo2+TBzOBM3u7VBi-w@mail.gmail.com>
Message-ID: <CAHjP37H4CEgm+xoEJubwzOraCGtTuL8KunVJfrfk7pFxgKon2Q@mail.gmail.com>

Bytecode isn't that interesting when discussing peak performance of jit'd
code.  Do you have assembly dumps?

The only noteworthy aspect of the bytecode is that the enhanced for loop
version is slightly bigger,  and combined with other code in some method,
may inhibit inlining.

Speaking of which, have you tried running the jmh benchmarks with tiered
compilation disabled? If not,  please do as it may introduce variance/noise.

Sent from my phone
On Sep 29, 2014 1:58 PM, "Paul Benedict" <pbenedict at apache.org> wrote:

> Bytecode output courtesy of Mikael St?ldal:
>
> With standard loop:
>
>   private static boolean contains(org.apache.logging.log4j.Marker,
> org.apache.logging.log4j.Marker...);
>     Code:
>        0: iconst_0
>        1: istore_2
>        2: aload_1
>        3: arraylength
>        4: istore_3
>        5: iload_2
>        6: iload_3
>        7: if_icmpge     29
>       10: aload_1
>       11: iload_2
>       12: aaload
>       13: astore        4
>       15: aload         4
>       17: aload_0
>       18: if_acmpne     23
>       21: iconst_1
>       22: ireturn
>       23: iinc          2, 1
>       26: goto          5
>       29: iconst_0
>       30: ireturn
>
>
> With for-each:
>
>   private static boolean contains(org.apache.logging.log4j.Marker,
> org.apache.logging.log4j.Marker...);
>     Code:
>        0: aload_1
>        1: astore_2
>        2: aload_2
>        3: arraylength
>        4: istore_3
>        5: iconst_0
>        6: istore        4
>        8: iload         4
>       10: iload_3
>       11: if_icmpge     34
>       14: aload_2
>       15: iload         4
>       17: aaload
>       18: astore        5
>       20: aload         5
>       22: aload_0
>       23: if_acmpne     28
>       26: iconst_1
>       27: ireturn
>       28: iinc          4, 1
>       31: goto          8
>       34: iconst_0
>       35: ireturn
>
>
>
> Cheers,
> Paul
>
> On Mon, Sep 29, 2014 at 11:31 AM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
>
>> I think Paul's email already has jmh output.
>>
>> I looked at the generated asm on 7u60 x64 linux, and didn't see any
>> material difference.
>>
>> Paul, have you or anyone else looked at the machine code diffs between
>> the two? Looking at timing is useful, but it's possible to get caught up in
>> noise; the generated assembly should provide more conclusive data on
>> whether any real difference is there or not.
>>
>> On Mon, Sep 29, 2014 at 11:21 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>>> On 09/29/2014 03:29 PM, Paul Benedict wrote:
>>> > Open JDKers, I am forwarding an email to get some clarification. It's
>>> been
>>> > a common understanding that foreach should perform no differently than
>>> the
>>> > equivalent for-loop . However, some fellow developers claim there is a
>>> > noticable difference in their microbenchmarking. Can you help explain
>>> what
>>> > is really going on? It's either the case there is a true difference (a
>>> > result that would surprise me) or the results are within a margin of
>>> error
>>> > that make the results insignificant. Please advise.
>>>
>>> The actual code that such a forEach loop generates is this:
>>>
>>>     private int forLoop(final int[] array) {
>>>         int result = 0;
>>>         int[] a = array;
>>>         int len = a.length;
>>>         for (int i = 0; i < len; i++) {
>>>             int element = a[i];
>>>             result ^= element;
>>>         }
>>>         return result;
>>>     }
>>>
>>> If you get different timings for this one, then the measurements are
>>> suspect.
>>>
>>> Java microbenchmarking is notoriously difficult.  Please try to use
>>> jmh; you'll get better and easier to interpret results.
>>>
>>> Andrew.
>>>
>>>
>>> http://openjdk.java.net/projects/code-tools/jmh/
>>>
>>>
>>
>


From lance.andersen at oracle.com  Mon Sep 29 21:21:51 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 29 Sep 2014 17:21:51 -0400
Subject: RFR: 8059411, RowSetWarning does not chain warnings
Message-ID: <465D764F-7621-4D48-906D-0C900F56BB9E@oracle.com>

Hi all,


Need a reviewer for 8059411 which is a simple fix & test for the fact RowSetWarning does not properly chain warnings.    With the fix, the JCK still passes.

The webrev can be found at http://cr.openjdk.java.net/~lancea/8059411/webrev.00/

Best,
Lance


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From mandy.chung at oracle.com  Mon Sep 29 21:48:43 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 29 Sep 2014 14:48:43 -0700
Subject: RFR: 8059411, RowSetWarning does not chain warnings
In-Reply-To: <465D764F-7621-4D48-906D-0C900F56BB9E@oracle.com>
References: <465D764F-7621-4D48-906D-0C900F56BB9E@oracle.com>
Message-ID: <5429D3BB.4030406@oracle.com>

On 9/29/14 2:21 PM, Lance Andersen wrote:
> Hi all,
>
>
> Need a reviewer for 8059411 which is a simple fix & test for the fact RowSetWarning does not properly chain warnings.    With the fix, the JCK still passes.
>
> The webrev can be found at http://cr.openjdk.java.net/~lancea/8059411/webrev.00/

Looks ok.

line 132: an alternative for the type casting is:
      RowSetWarning.class.cast(getNextException());

Mandy



From claes.redestad at oracle.com  Mon Sep 29 21:51:00 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 29 Sep 2014 23:51:00 +0200
Subject: RFR: 8059411, RowSetWarning does not chain warnings
In-Reply-To: <465D764F-7621-4D48-906D-0C900F56BB9E@oracle.com>
References: <465D764F-7621-4D48-906D-0C900F56BB9E@oracle.com>
Message-ID: <5429D444.4060400@oracle.com>

Hi,

the rwarning field seems to be unused after these changes, remove?

Also a System.out.println in test09 which seems excessively verbose.

Otherwise it looks good.

/Claes

On 2014-09-29 23:21, Lance Andersen wrote:
> Hi all,
>
>
> Need a reviewer for 8059411 which is a simple fix & test for the fact RowSetWarning does not properly chain warnings.    With the fix, the JCK still passes.
>
> The webrev can be found at http://cr.openjdk.java.net/~lancea/8059411/webrev.00/
>
> Best,
> Lance
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>



From lance.andersen at oracle.com  Mon Sep 29 22:07:19 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 29 Sep 2014 18:07:19 -0400
Subject: RFR: 8059411, RowSetWarning does not chain warnings
In-Reply-To: <5429D444.4060400@oracle.com>
References: <465D764F-7621-4D48-906D-0C900F56BB9E@oracle.com>
	<5429D444.4060400@oracle.com>
Message-ID: <C00BB54B-AF8C-467B-B0DE-8D28758A1AD7@oracle.com>


On Sep 29, 2014, at 5:51 PM, Claes Redestad <claes.redestad at oracle.com> wrote:

> Hi,
> 
> the rwarning field seems to be unused after these changes, remove?

It is but given the class is Serializable, it should stay 
> 
> Also a System.out.println in test09 which seems excessively verbose.

I removed it.

http://cr.openjdk.java.net/~lancea/8059411/webrev.01/

Best,
Lance
> 
> Otherwise it looks good.
> 
> /Claes
> 
> On 2014-09-29 23:21, Lance Andersen wrote:
>> Hi all,
>> 
>> 
>> Need a reviewer for 8059411 which is a simple fix & test for the fact RowSetWarning does not properly chain warnings.    With the fix, the JCK still passes.
>> 
>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8059411/webrev.00/
>> 
>> Best,
>> Lance
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 
> 



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From lance.andersen at oracle.com  Mon Sep 29 22:08:14 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 29 Sep 2014 18:08:14 -0400
Subject: RFR: 8059411, RowSetWarning does not chain warnings
In-Reply-To: <5429D3BB.4030406@oracle.com>
References: <465D764F-7621-4D48-906D-0C900F56BB9E@oracle.com>
	<5429D3BB.4030406@oracle.com>
Message-ID: <05A7E39A-E410-4C90-BB1E-EB4C4ABE6BB3@oracle.com>

Thank you Mandy

I made the change you suggested

http://cr.openjdk.java.net/~lancea/8059411/webrev.01/ 

and verified all is still good as expected with the tests.

Best
Lance
On Sep 29, 2014, at 5:48 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> On 9/29/14 2:21 PM, Lance Andersen wrote:
>> Hi all,
>> 
>> 
>> Need a reviewer for 8059411 which is a simple fix & test for the fact RowSetWarning does not properly chain warnings.    With the fix, the JCK still passes.
>> 
>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8059411/webrev.00/
> 
> Looks ok.
> 
> line 132: an alternative for the type casting is:
>     RowSetWarning.class.cast(getNextException());
> 
> Mandy
> 



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From mandy.chung at oracle.com  Mon Sep 29 23:18:06 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 29 Sep 2014 16:18:06 -0700
Subject: RFR: 8059411, RowSetWarning does not chain warnings
In-Reply-To: <05A7E39A-E410-4C90-BB1E-EB4C4ABE6BB3@oracle.com>
References: <465D764F-7621-4D48-906D-0C900F56BB9E@oracle.com>
	<5429D3BB.4030406@oracle.com>
	<05A7E39A-E410-4C90-BB1E-EB4C4ABE6BB3@oracle.com>
Message-ID: <5429E8AE.7030809@oracle.com>

About the rwarning field, if it's removed, would it break anything if 
it's filled with the default value when deserializing the new version on 
an older version?  It seems okay for this case and you should verify.

Otherwise, looks okay.

Mandy

On 9/29/14 3:08 PM, Lance Andersen wrote:
> Thank you Mandy
>
> I made the change you suggested
>
> http://cr.openjdk.java.net/~lancea/8059411/webrev.01/ 
> <http://cr.openjdk.java.net/%7Elancea/8059411/webrev.01/>
>
> and verified all is still good as expected with the tests.
>
> Best
> Lance
> On Sep 29, 2014, at 5:48 PM, Mandy Chung <mandy.chung at oracle.com 
> <mailto:mandy.chung at oracle.com>> wrote:
>
>> On 9/29/14 2:21 PM, Lance Andersen wrote:
>>> Hi all,
>>>
>>>
>>> Need a reviewer for 8059411 which is a simple fix & test for the 
>>> fact RowSetWarning does not properly chain warnings.    With the 
>>> fix, the JCK still passes.
>>>
>>> The webrev can be found at 
>>> http://cr.openjdk.java.net/~lancea/8059411/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Elancea/8059411/webrev.00/>
>>
>> Looks ok.
>>
>> line 132: an alternative for the type casting is:
>>     RowSetWarning.class.cast(getNextException());
>>
>> Mandy
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From daniel.fuchs at oracle.com  Tue Sep 30 14:04:35 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 30 Sep 2014 16:04:35 +0200
Subject: 8025690: Default FileHandler constructor doesn't throw
	NullPointerException if pattern is empty and count > 1
Message-ID: <542AB873.1070005@oracle.com>

Hi,

Please find below a fix for

8025690: Default FileHandler constructor doesn't
          throw NullPointerException if pattern is empty and count > 1
https://bugs.openjdk.java.net/browse/JDK-8025690

The default constructor of FileHandler is specified to throw
a NullPointerException if the pattern property string is an
empty string.
(see 
<http://docs.oracle.com/javase/8/docs/api/java/util/logging/FileHandler.html#FileHandler-->) 

However it strangely does so only when count=1

The fix adds an additional check in openFiles() to verify that
the pattern is not empty. At this point the other constructors
(which take a pattern as parameter) will already have thrown an
IAE if the pattern was empty (or an NPE if it was null).

http://cr.openjdk.java.net/~dfuchs/webrev_8025690/webrev.00

best regards,

-- daniel


From lance.andersen at oracle.com  Tue Sep 30 19:09:49 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 30 Sep 2014 15:09:49 -0400
Subject: 8025690: Default FileHandler constructor doesn't throw
	NullPointerException if pattern is empty and count > 1
In-Reply-To: <542AB873.1070005@oracle.com>
References: <542AB873.1070005@oracle.com>
Message-ID: <BB695171-0864-4BC1-B1A5-4994BA55F282@oracle.com>

Hi Daniel,

Shouldn't the other constructors indicate that an NPE will occur similar to the default constructor if the pattern is null?

Just curious why you chose to put the check into openFiles() if the issue is just with the default constructor?

Best,
Lance
On Sep 30, 2014, at 10:04 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Hi,
> 
> Please find below a fix for
> 
> 8025690: Default FileHandler constructor doesn't
>         throw NullPointerException if pattern is empty and count > 1
> https://bugs.openjdk.java.net/browse/JDK-8025690
> 
> The default constructor of FileHandler is specified to throw
> a NullPointerException if the pattern property string is an
> empty string.
> (see <http://docs.oracle.com/javase/8/docs/api/java/util/logging/FileHandler.html#FileHandler-->) 
> However it strangely does so only when count=1
> 
> The fix adds an additional check in openFiles() to verify that
> the pattern is not empty. At this point the other constructors
> (which take a pattern as parameter) will already have thrown an
> IAE if the pattern was empty (or an NPE if it was null).
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8025690/webrev.00
> 
> best regards,
> 
> -- daniel



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From daniel.fuchs at oracle.com  Tue Sep 30 21:20:52 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 30 Sep 2014 23:20:52 +0200
Subject: 8025690: Default FileHandler constructor doesn't throw
	NullPointerException if pattern is empty and count > 1
In-Reply-To: <BB695171-0864-4BC1-B1A5-4994BA55F282@oracle.com>
References: <542AB873.1070005@oracle.com>
	<BB695171-0864-4BC1-B1A5-4994BA55F282@oracle.com>
Message-ID: <542B1EB4.10508@oracle.com>

Hi Lance,

Thanks for the comments!

On 9/30/14 9:09 PM, Lance Andersen wrote:
> Hi Daniel,
>
> Shouldn't the other constructors indicate that an NPE will occur 
> similar to the default constructor if the pattern is null?

I assume that for the other constructors the NPE falls in the category
"parameters should not be null unless otherwise specified" which is
the usual rule for java.util.logging.
The only difference is that the default constructor reads the value
of 'pattern' from the configuration, whereas the other constructor get
the value supplied by the caller,

So I am more curious about why the default constructor is not specified to
throw IllegalArgumentException if the pattern is empty - as all the other
constructor do... Possibly it's because the original author thought
that NPE would always be throw by openFile() if the pattern was empty.

In this case I believe it's better to make the implementation
conform to the spec - even if the spec looks odd - rather than trying
to change the spec.

> Just curious why you chose to put the check into openFiles() if the 
> issue is just with the default constructor?
It was not possible to do the check in configure() since all the 
constructors
call configure - but only the default constructor use the actual value
set by configure() - the other constructors simply reset the value of
'pattern' after configure() has been called, thus overriding the default
value read by the configuration.

I could have placed the check in the default constructor between
the call to configure() and the call to openFiles() - but I thought
it was better to put it in openFiles() - since the spirit of the spec
seems to be that pattern should be neither null nor empty
when openFiles() is called.

best regards,

-- daniel
>
> Best,
> Lance
> On Sep 30, 2014, at 10:04 AM, Daniel Fuchs <daniel.fuchs at oracle.com 
> <mailto:daniel.fuchs at oracle.com>> wrote:
>
>> Hi,
>>
>> Please find below a fix for
>>
>> 8025690: Default FileHandler constructor doesn't
>>         throw NullPointerException if pattern is empty and count > 1
>> https://bugs.openjdk.java.net/browse/JDK-8025690
>>
>> The default constructor of FileHandler is specified to throw
>> a NullPointerException if the pattern property string is an
>> empty string.
>> (see 
>> <http://docs.oracle.com/javase/8/docs/api/java/util/logging/FileHandler.html#FileHandler-->) 
>>
>> However it strangely does so only when count=1
>>
>> The fix adds an additional check in openFiles() to verify that
>> the pattern is not empty. At this point the other constructors
>> (which take a pattern as parameter) will already have thrown an
>> IAE if the pattern was empty (or an NPE if it was null).
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8025690/webrev.00
>>
>> best regards,
>>
>> -- daniel
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From lance.andersen at oracle.com  Tue Sep 30 21:55:47 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 30 Sep 2014 17:55:47 -0400
Subject: 8025690: Default FileHandler constructor doesn't throw
	NullPointerException if pattern is empty and count > 1
In-Reply-To: <542B1EB4.10508@oracle.com>
References: <542AB873.1070005@oracle.com>
	<BB695171-0864-4BC1-B1A5-4994BA55F282@oracle.com>
	<542B1EB4.10508@oracle.com>
Message-ID: <BAF6AA3D-E6FD-4B3C-A8F8-F5C6562A1AF8@oracle.com>

Hi Daniel,

On Sep 30, 2014, at 5:20 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Hi Lance,
> 
> Thanks for the comments!
> 
> On 9/30/14 9:09 PM, Lance Andersen wrote:
>> Hi Daniel,
>> 
>> Shouldn't the other constructors indicate that an NPE will occur similar to the default constructor if the pattern is null?
> 
> I assume that for the other constructors the NPE falls in the category
> "parameters should not be null unless otherwise specified" which is 
> the usual rule for java.util.logging.

I have gotten mixed views on this and have gone and clarified this in some cases.  Just think consistency would be good but your call
> The only difference is that the default constructor reads the value
> of 'pattern' from the configuration, whereas the other constructor get
> the value supplied by the caller, 
> 
> So I am more curious about why the default constructor is not specified to
> throw IllegalArgumentException if the pattern is empty - as all the other
> constructor do... Possibly it's because the original author thought
> that NPE would always be throw by openFile() if the pattern was empty.
> 
> In this case I believe it's better to make the implementation
> conform to the spec - even if the spec looks odd - rather than trying
> to change the spec.
> 
>> Just curious why you chose to put the check into openFiles() if the issue is just with the default constructor?
> It was not possible to do the check in configure() since all the constructors
> call configure - but only the default constructor use the actual value
> set by configure() - the other constructors simply reset the value of
> 'pattern' after configure() has been called, thus overriding the default
> value read by the configuration.
> 
> I could have placed the check in the default constructor between
> the call to configure() and the call to openFiles() - but I thought
> it was better to put it in openFiles() - since the spirit of the spec
> seems to be that pattern should be neither null nor empty
> when openFiles() is called.

Guess the question is whether you feel the check is redundant for the other code paths to openFiles().  Your call either way as the change seems fine otherwise

Best
Lance
> 
> best regards,
> 
> -- daniel
>> 
>> Best,
>> Lance
>> On Sep 30, 2014, at 10:04 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>> 
>>> Hi,
>>> 
>>> Please find below a fix for
>>> 
>>> 8025690: Default FileHandler constructor doesn't
>>>         throw NullPointerException if pattern is empty and count > 1
>>> https://bugs.openjdk.java.net/browse/JDK-8025690
>>> 
>>> The default constructor of FileHandler is specified to throw
>>> a NullPointerException if the pattern property string is an
>>> empty string.
>>> (see <http://docs.oracle.com/javase/8/docs/api/java/util/logging/FileHandler.html#FileHandler-->) 
>>> However it strangely does so only when count=1
>>> 
>>> The fix adds an additional check in openFiles() to verify that
>>> the pattern is not empty. At this point the other constructors
>>> (which take a pattern as parameter) will already have thrown an
>>> IAE if the pattern was empty (or an NPE if it was null).
>>> 
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8025690/webrev.00
>>> 
>>> best regards,
>>> 
>>> -- daniel
>> 
>> <Mail Attachment.gif>
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 
> 



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From garydgregory at gmail.com  Mon Sep 29 15:39:27 2014
From: garydgregory at gmail.com (Gary Gregory)
Date: Mon, 29 Sep 2014 11:39:27 -0400
Subject: No for each loop comment?
In-Reply-To: <CABLGb9wfKsun2MyycVpzz57H6sdCb5r=KgstC0fgaAPgkBo=Jg@mail.gmail.com>
References: <CACZkXPwt1Av4LiVGHCvo+596QSXYiuqE-J_LvrAjJzaWbOESZw@mail.gmail.com>
	<CACmp6koAr=Yu0xkHVeQfiEUuNjzpdNJXByv2qJVmy=2VS4kbdw@mail.gmail.com>
	<9D348A16-A49D-4C38-81B0-6E66B86DCB07@gmail.com>
	<58EE9B4F-B192-493F-90DE-E2DD7C329CB5@dslextreme.com>
	<CAAFrFhS7gD8kBco4t3k5RNLBh51jzFo5YE7mGamUDuiZbte3pA@mail.gmail.com>
	<CABLGb9wpuU7RPACLFqCuPqmaDqxbEjOVZO81qK+9c4HRVXXy6Q@mail.gmail.com>
	<F4BC6AAA-3221-4433-84FD-E0A0E81539F4@dslextreme.com>
	<CACZkXPxZsVvN5JcTPSi8ja94gkfBKRhkT5KKtpW40h0RK5wEsQ@mail.gmail.com>
	<CACmp6koOkfS7YcGa50nP4dGa1UY19btfp2AD3hc__F+ATQTssg@mail.gmail.com>
	<CAAFrFhQzkqLACn9WpdqfEEYUs8sAKC3vVT1LKu7Eq6G-870iuw@mail.gmail.com>
	<CABLGb9wfKsun2MyycVpzz57H6sdCb5r=KgstC0fgaAPgkBo=Jg@mail.gmail.com>
Message-ID: <CACZkXPxDm4HZmPo+fC_HWioObpqZBG+1F3TBc5cBmh1tZBWLzg@mail.gmail.com>

It's important to note that our experiments show that the byte codes are
different.

Gary

On Mon, Sep 29, 2014 at 10:29 AM, Paul Benedict <pbenedict at apache.org>
wrote:

> Open JDKers, I am forwarding an email to get some clarification. It's been
> a common understanding that foreach should perform no differently than the
> equivalent for-loop . However, some fellow developers claim there is a
> noticable difference in their microbenchmarking. Can you help explain what
> is really going on? It's either the case there is a true difference (a
> result that would surprise me) or the results are within a margin of error
> that make the results insignificant. Please advise.
>
> Cheers,
> Paul
>
> ---------- Forwarded message ----------
> From: Remko Popma <remko.popma at gmail.com>
> Date: Fri, Sep 26, 2014 at 8:43 AM
> Subject: Re: No for each loop comment?
> To: Log4J Developers List <log4j-dev at logging.apache.org>
>
>
> On Windows it looks like normal for loops are slightly faster than
> for-each loops, especially for small arrays of primitives. This could be
> noise, since we are talking about 5 nanoseconds where the baseline (an
> empty method invocation) is 12 nanos.
>
> On Solaris 10 and Red Hat Enterprise Linux the baseline is so large (255
> nanos and 1910 nanos respectively) that any difference we are seeing is
> just noise.
>
> All benchmarks were run with one fork, one thread, 10 warmup iterations
> and 10 test iterations.
>
> *Windows 7 (64bit) with Java 1.8.0_05, 2-core Intel i5-3317u CPU @1.70Ghz
> with hyperthreading switched on (4 virtual cores)*
> Benchmark                                                Mode  Samples
>  Score  Score error  Units
> o.a.l.l.p.j.LoopsBenchmark.baseline                    sample   154947
> 12.432        0.550  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray10000ForEachLoop    sample   126597
> 2759.592        3.431  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray10000ForLoop        sample   126494
> 2761.729        3.127  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray1000ForEachLoop     sample   154124
>  292.880        1.065  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray1000ForLoop         sample   156155
>  288.751        1.101  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray100ForEachLoop      sample   191980
> 41.826        0.870  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray100ForLoop          sample   193770
> 36.894        0.782  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray10ForEachLoop       sample   190847
> 22.393        0.618  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray10ForLoop           sample   192552
> 17.146        0.560  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray10000ForEachLoop    sample   173839
>  31959.057       14.341  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray10000ForLoop        sample   171137
>  32461.985       14.353  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray1000ForEachLoop     sample    97495
> 3591.200        4.852  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray1000ForLoop         sample   101560
> 3445.998        4.010  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray100ForEachLoop      sample   102796
>  438.207        1.923  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray100ForLoop          sample   102333
>  439.576        2.139  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray10ForEachLoop       sample   113924
> 58.957        1.247  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray10ForLoop           sample   120416
> 60.712        1.284  ns/op
>
>
> // For loops for Object arrays are similar but return the total XOR of the
> element hashcodes.
>
> private int forEachLoop(final int[] array) {
>     int result = 0;
>     for (final int element : array) {
>         result ^= element;
>     }
>     return result;
> }
>
> private int forLoop(final int[] array) {
>     int result = 0;
>     for (int i = 0; i < array.length; i++) {
>         result ^= array[i];
>     }
>     return result;
> }
>
>
>
> *Solaris 10 (64bit) with JDK1.7.0_06-b24 (Oracle Hotspot), 2 quad-core
> Xeon X5570 dual CPUs @2.93Ghz with hyperthreading switched on (16 virtual
> cores)*
> Benchmark                                                Mode  Samples
>  Score  Score error  Units
> o.a.l.l.p.j.LoopsBenchmark.baseline                    sample   110212
>  255.300        0.201  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray10000ForEachLoop    sample   187808
> 3938.055        1.207  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray10000ForLoop        sample   187897
> 3937.929        0.748  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray1000ForEachLoop     sample   123989
>  606.631        0.626  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray1000ForLoop         sample   123973
>  609.565        0.416  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray100ForEachLoop      sample   126933
>  294.204        0.280  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray100ForLoop          sample   127070
>  296.411        0.223  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray10ForEachLoop       sample   113400
>  261.519        0.181  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray10ForLoop           sample   111637
>  260.435        0.115  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray10000ForEachLoop    sample   115872
>  48154.673       18.846  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray10000ForLoop        sample   116777
>  47793.868       17.615  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray1000ForEachLoop     sample   138432
> 5256.767        2.451  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray1000ForLoop         sample   136644
> 5325.377        2.388  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray100ForEachLoop      sample   166653
>  773.541        0.330  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray100ForLoop          sample   166570
>  774.513        0.574  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray10ForEachLoop       sample   178754
>  317.232        0.134  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray10ForLoop           sample   180165
>  316.189        0.238  ns/op
>
> *64 bit RHEL 6.5 (Linux 2.6.32-431.el6.x86_64) with JDK1.7.0_05-b06
> (Oracle Hotspot), 4 quad-core Xeon X5570 CPUs @2.93GHz with hyperthreading
> switched on (16 virtual cores)*
> Benchmark                                                Mode  Samples
>  Score  Score error  Units
> o.a.l.l.p.j.LoopsBenchmark.baseline                    sample   114783
> 1910.576       29.256  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray10000ForEachLoop    sample   194584
> 5132.885       25.137  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray10000ForLoop        sample   196672
> 4811.572       52.072  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray1000ForEachLoop     sample   133119
> 1967.213       28.970  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray1000ForLoop         sample   133804
> 2004.501       31.554  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray100ForEachLoop      sample   142439
> 1575.329        6.457  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray100ForLoop          sample   142215
> 1957.714       27.815  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray10ForEachLoop       sample   130826
> 1980.301       30.818  ns/op
> o.a.l.l.p.j.LoopsBenchmark.intArray10ForLoop           sample   132654
> 1589.120        8.449  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray10000ForEachLoop    sample   126947
>  43301.320       50.589  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray10000ForLoop        sample   126117
>  43574.129       55.272  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray1000ForEachLoop     sample   143697
> 5831.250       19.667  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray1000ForLoop         sample   163244
> 4823.096       13.180  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray100ForEachLoop      sample   162502
> 1930.819       24.136  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray100ForLoop          sample   171619
> 1625.806       10.385  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray10ForEachLoop       sample   172226
> 1888.683       22.554  ns/op
> o.a.l.l.p.j.LoopsBenchmark.objArray10ForLoop           sample   188838
> 1581.979        6.322  ns/op
>
>
>
>
> On Fri, Sep 26, 2014 at 2:56 AM, Matt Sicker <boards at gmail.com> wrote:
>
>> The foreach over an array looks like it's supposed to compile to the same
>> thing:
>>
>> https://jcp.org/aboutJava/communityprocess/jsr/tiger/enhanced-for.html
>>
>> Same goes for .length which is supposed to be a final field which would
>> allow for inlining by the JIT I'd imagine (hence why we use final
>> everywhere):
>>
>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html#jls-10.7
>>
>>
>>>>> On 24 September 2014 22:12, Gary Gregory <garydgregory at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Why does this "//noinspection ForLoopReplaceableByForEach" comment
>>>>>> mean?
>>>>>>
>>>>>> Why not for an enhanced for each loop?
>>>>>>
>>>>>>  private static boolean contains(final Marker parent, final Marker...
>>>>>> localParents) {
>>>>>>             //noinspection ForLoopReplaceableByForEach
>>>>>>             for (int i = 0, localParentsLength = localParents.length;
>>>>>> i < localParentsLength; i++) {
>>>>>>                 final Marker marker = localParents[i];
>>>>>>                 if (marker == parent) {
>>>>>>                     return true;
>>>>>>                 }
>>>>>>             }
>>>>>>             return false;
>>>>>>         }
>>>>>>
>>>>>> Thanks,
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>


-- 
E-Mail: garydgregory at gmail.com | ggregory at apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory


From garydgregory at gmail.com  Mon Sep 29 19:42:24 2014
From: garydgregory at gmail.com (Gary Gregory)
Date: Mon, 29 Sep 2014 15:42:24 -0400
Subject: Fwd: No for each loop comment?
In-Reply-To: <CABLGb9zKKUtG3E0qzQ8jL6fHOyUW99a8fo2+TBzOBM3u7VBi-w@mail.gmail.com>
References: <CACZkXPwt1Av4LiVGHCvo+596QSXYiuqE-J_LvrAjJzaWbOESZw@mail.gmail.com>
	<CACmp6koAr=Yu0xkHVeQfiEUuNjzpdNJXByv2qJVmy=2VS4kbdw@mail.gmail.com>
	<9D348A16-A49D-4C38-81B0-6E66B86DCB07@gmail.com>
	<58EE9B4F-B192-493F-90DE-E2DD7C329CB5@dslextreme.com>
	<CAAFrFhS7gD8kBco4t3k5RNLBh51jzFo5YE7mGamUDuiZbte3pA@mail.gmail.com>
	<CABLGb9wpuU7RPACLFqCuPqmaDqxbEjOVZO81qK+9c4HRVXXy6Q@mail.gmail.com>
	<F4BC6AAA-3221-4433-84FD-E0A0E81539F4@dslextreme.com>
	<CACZkXPxZsVvN5JcTPSi8ja94gkfBKRhkT5KKtpW40h0RK5wEsQ@mail.gmail.com>
	<CACmp6koOkfS7YcGa50nP4dGa1UY19btfp2AD3hc__F+ATQTssg@mail.gmail.com>
	<CAAFrFhQzkqLACn9WpdqfEEYUs8sAKC3vVT1LKu7Eq6G-870iuw@mail.gmail.com>
	<CABLGb9wfKsun2MyycVpzz57H6sdCb5r=KgstC0fgaAPgkBo=Jg@mail.gmail.com>
	<54297913.30706@redhat.com>
	<CAHjP37EiznZA2YP4xdBSUTFOCWiEtGNng7eyj3A2Hy97oCK_Yw@mail.gmail.com>
	<CABLGb9zKKUtG3E0qzQ8jL6fHOyUW99a8fo2+TBzOBM3u7VBi-w@mail.gmail.com>
Message-ID: <CACZkXPzogwDcjNDBkOLkXnUN=e0yJ4O-XNnx_TBLiFw_vbVBDQ@mail.gmail.com>

FWIW, I've verified the same byte codes on Oracle Java 7 and 8 on Windows 7
(all 64 bit).

Gary

On Mon, Sep 29, 2014 at 1:58 PM, Paul Benedict <pbenedict at apache.org> wrote:

> Bytecode output courtesy of Mikael St?ldal:
>
> With standard loop:
>
>   private static boolean contains(org.apache.logging.log4j.Marker,
> org.apache.logging.log4j.Marker...);
>     Code:
>        0: iconst_0
>        1: istore_2
>        2: aload_1
>        3: arraylength
>        4: istore_3
>        5: iload_2
>        6: iload_3
>        7: if_icmpge     29
>       10: aload_1
>       11: iload_2
>       12: aaload
>       13: astore        4
>       15: aload         4
>       17: aload_0
>       18: if_acmpne     23
>       21: iconst_1
>       22: ireturn
>       23: iinc          2, 1
>       26: goto          5
>       29: iconst_0
>       30: ireturn
>
>
> With for-each:
>
>   private static boolean contains(org.apache.logging.log4j.Marker,
> org.apache.logging.log4j.Marker...);
>     Code:
>        0: aload_1
>        1: astore_2
>        2: aload_2
>        3: arraylength
>        4: istore_3
>        5: iconst_0
>        6: istore        4
>        8: iload         4
>       10: iload_3
>       11: if_icmpge     34
>       14: aload_2
>       15: iload         4
>       17: aaload
>       18: astore        5
>       20: aload         5
>       22: aload_0
>       23: if_acmpne     28
>       26: iconst_1
>       27: ireturn
>       28: iinc          4, 1
>       31: goto          8
>       34: iconst_0
>       35: ireturn
>
>
>
> Cheers,
> Paul
>
> On Mon, Sep 29, 2014 at 11:31 AM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
>
>> I think Paul's email already has jmh output.
>>
>> I looked at the generated asm on 7u60 x64 linux, and didn't see any
>> material difference.
>>
>> Paul, have you or anyone else looked at the machine code diffs between
>> the two? Looking at timing is useful, but it's possible to get caught up in
>> noise; the generated assembly should provide more conclusive data on
>> whether any real difference is there or not.
>>
>> On Mon, Sep 29, 2014 at 11:21 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>>> On 09/29/2014 03:29 PM, Paul Benedict wrote:
>>> > Open JDKers, I am forwarding an email to get some clarification. It's
>>> been
>>> > a common understanding that foreach should perform no differently than
>>> the
>>> > equivalent for-loop . However, some fellow developers claim there is a
>>> > noticable difference in their microbenchmarking. Can you help explain
>>> what
>>> > is really going on? It's either the case there is a true difference (a
>>> > result that would surprise me) or the results are within a margin of
>>> error
>>> > that make the results insignificant. Please advise.
>>>
>>> The actual code that such a forEach loop generates is this:
>>>
>>>     private int forLoop(final int[] array) {
>>>         int result = 0;
>>>         int[] a = array;
>>>         int len = a.length;
>>>         for (int i = 0; i < len; i++) {
>>>             int element = a[i];
>>>             result ^= element;
>>>         }
>>>         return result;
>>>     }
>>>
>>> If you get different timings for this one, then the measurements are
>>> suspect.
>>>
>>> Java microbenchmarking is notoriously difficult.  Please try to use
>>> jmh; you'll get better and easier to interpret results.
>>>
>>> Andrew.
>>>
>>>
>>> http://openjdk.java.net/projects/code-tools/jmh/
>>>
>>>
>>
>


-- 
E-Mail: garydgregory at gmail.com | ggregory at apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory