8179527: Ineffective use of volatile hurts performance of Charset.atBugLevel()

[Peter Levart]

Hi Ogata,

The change looks good.

But I think this needs to go through CSR. The CSR FAQ page at:

https://wiki.openjdk.java.net/display/csr/CSR+FAQs

writes...

Q: What sort of changes require CSR review?
A: Any change to a JDK interface meant to be used outside of the JDK 
itself requires CSR review. In this context "interface" isn't limited to 
the Java programing language definition of an interface, but encompasses 
the broader concept of a protocol between the JDK and users of the JDK. 
Examples of interfaces by this definition include:

     ...
*    Changing or defining a new system or security property*


The FAQ also writes:

Q: How do I create a CSR ?
A: Do not directly create a CSR from the Create Menu. JIRA will let you 
do this right up until the moment you try to save it and find your 
typing was in vain.
Instead you should go to the target bug, select "More", and from the 
drop down menu select "Create CSR". This is required to properly 
associate the CSR with the main bug, just as is done for backports.

Since Christoph has already volunteered to be your sponsor, you could 
ask him to file the CSR for you. Or I can volunteer to file it (and 
learn how this goes) if Christoph doesn't have the time. It's Christophs 
call...

Regards, Peter

On 06/28/2017 08:20 AM, Kazunori Ogata wrote:
> Hi Christoph,
>
> Thank you for your suggestions and offering to sponsor my changes.
>
> Here is the updated webrev that removes the atBugLevel() definition in
> Charset.java and its call sites in Charset.java and
> Charset-X-Coder.java.template.  Please review this:
>
> http://cr.openjdk.java.net/~horii/8179527/webrev.01/
>
>
> Regards,
> Ogata
>
>
> "Langer, Christoph" <christoph.langer at sap.com> wrote on 2017/06/28
> 03:32:51:
>
>> From: "Langer, Christoph" <christoph.langer at sap.com>
>> To: Alan Bateman <Alan.Bateman at oracle.com>, Kazunori Ogata
> <OGATAK at jp.ibm.com>
>> Cc: "ppc-aix-port-dev at openjdk.java.net" <ppc-aix-port-
>> dev at openjdk.java.net>, Claes Redestad <claes.redestad at oracle.com>, core-
>> libs-dev <core-libs-dev at openjdk.java.net>, "nio-dev at openjdk.java.net"
>> <nio-dev at openjdk.java.net>
>> Date: 2017/06/28 03:32
>> Subject: RE: 8179527: Ineffective use of volatile hurts performance of
>> Charset.atBugLevel()
>>
>> Hi Ogata,
>>
>> I think I agree with Alan that the Charset.atBugLevel() method can
>> completely be eliminated from java/nio/charset.
>>
>> Ogata, would you respin your change to remove it and post it for review?
> I
>> can then sponsor it for you.
>>
>> @Alan: Do we need a CSR ("Compatibility & Specification Review") request
>> here since support for "sun.nio.cs.bugLevel" will be removed?
>>
>> Best regards
>> Christoph
>>
>>> -----Original Message-----
>>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
>>> Sent: Dienstag, 27. Juni 2017 10:13
>>> To: Claes Redestad <claes.redestad at oracle.com>; Langer, Christoph
>>> <christoph.langer at sap.com>; Kazunori Ogata <OGATAK at jp.ibm.com>;
>>> core-libs-dev <core-libs-dev at openjdk.java.net>;
> nio-dev at openjdk.java.net
>>> Cc: ppc-aix-port-dev at openjdk.java.net
>>> Subject: Re: 8179527: Ineffective use of volatile hurts performance of
>>> Charset.atBugLevel()
>>>
>>> On 27/06/2017 08:36, Claes Redestad wrote:
>>>> The check of Charset.atBugLevel in checkName should no longer happen
>>>> for the majority of situations, as that test is now only done if the
>>>> charset name is "" (see
>>>> https://bugs.openjdk.java.net/browse/JDK-8174831),
>>> Kazunori's mail didn't mention the JDK build he is using, it may have
>>> been JDK 8 rather than JDK 9.
>>>
>>>> since what differs between 1.4 and 1.5 was apparently whether or not
>>>> the empty string was to be accepted as a valid Charset...
>>>>
>>>> So yes, if we can get rid of the test altogether, we'll be even
> better
>>>> off!
>>> JDK-4786884 is the original issue. If there was any code dependent on
>>> the broken behavior in 1.4 then I would expect it should have been
> fixed
>>> by now. So I think it can be removed.
>>>
>>> -Alan
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20170628/0f9c0cc6/attachment.html>