From eric at metricspace.net  Mon Oct  2 18:44:26 2017
From: eric at metricspace.net (Eric McCorkle)
Date: Mon, 2 Oct 2017 14:44:26 -0400
Subject: Confirm bug in java.lang.reflect.Proxy wrt static methods in
 interfaces
Message-ID: <7d47fec6-879c-e47d-4bd1-dee2b22cf000@metricspace.net>

Hello everyone,

A colleague of mine discovered what seems to be a bug in
java.lang.reflect.Proxy#newProxyInstance.  I'd like to confirm that this
is indeed incorrect behavior before I go and fix it.

Consider the following two interfaces:

interface I1 {
  static I1 foo() {
    return null;
  }
}

interface I2 {
  static I2 foo() {
    return null;
  }
}

JLS 9.4.1 states that static methods are not inherited in interfaces,
thus it should be perfectly legal to define some class which inherits I1
and I2.

The following proxy creation fails:

public class ProxyBug {
  public static void main(String... args) {
    I2 i2 =(I2)Proxy.newProxyInstance(
                 ClassLoader.getSystemClassLoader(),
                 new Class[] {I1.class, I2.class},
                 new InvocationHandler() {
                   @Override
                   public Object invoke(Object proxy,
                                        Method method,
                                        Object[] args)
                     throws Throwable {
                     return null;
                   }
                 });
  }
}

The exception generated is as follows:

Exception in thread "main" java.lang.IllegalArgumentException: methods
with same signature foo() but incompatible return types: [interface I1,
interface I2]
	at sun.misc.ProxyGenerator.checkReturnTypes(ProxyGenerator.java:712)
	at sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:461)
	at sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:339)
	at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:639)
	at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:557)
	at java.lang.reflect.WeakCache$Factory.get(WeakCache.java:230)
	at java.lang.reflect.WeakCache.get(WeakCache.java:127)
	at java.lang.reflect.Proxy.getProxyClass0(Proxy.java:419)
	at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:719)
	at ProxyBug.main(ProxyBug.java:19)

So it would seem that newProxyInstance is incorrectly including static
methods in its check for incompatible return types.

Can I get someone from core-libs to confirm that this is not intended
before I file a bug and start on the fix?

From forax at univ-mlv.fr  Mon Oct  2 20:30:32 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 2 Oct 2017 22:30:32 +0200 (CEST)
Subject: Confirm bug in java.lang.reflect.Proxy wrt static methods in
 interfaces
In-Reply-To: <7d47fec6-879c-e47d-4bd1-dee2b22cf000@metricspace.net>
References: <7d47fec6-879c-e47d-4bd1-dee2b22cf000@metricspace.net>
Message-ID: <2044907244.779710.1506976232957.JavaMail.zimbra@u-pem.fr>

Hi Eric,
I can reproduce the bug,
as you said, in ProxyGenerator.generateClassFile() only the instance methods should be collected.

cheers,
R?mi

----- Mail original -----
> De: "Eric McCorkle" <eric at metricspace.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 2 Octobre 2017 20:44:26
> Objet: Confirm bug in java.lang.reflect.Proxy wrt static methods in interfaces

> Hello everyone,
> 
> A colleague of mine discovered what seems to be a bug in
> java.lang.reflect.Proxy#newProxyInstance.  I'd like to confirm that this
> is indeed incorrect behavior before I go and fix it.
> 
> Consider the following two interfaces:
> 
> interface I1 {
>  static I1 foo() {
>    return null;
>  }
> }
> 
> interface I2 {
>  static I2 foo() {
>    return null;
>  }
> }
> 
> JLS 9.4.1 states that static methods are not inherited in interfaces,
> thus it should be perfectly legal to define some class which inherits I1
> and I2.
> 
> The following proxy creation fails:
> 
> public class ProxyBug {
>  public static void main(String... args) {
>    I2 i2 =(I2)Proxy.newProxyInstance(
>                 ClassLoader.getSystemClassLoader(),
>                 new Class[] {I1.class, I2.class},
>                 new InvocationHandler() {
>                   @Override
>                   public Object invoke(Object proxy,
>                                        Method method,
>                                        Object[] args)
>                     throws Throwable {
>                     return null;
>                   }
>                 });
>  }
> }
> 
> The exception generated is as follows:
> 
> Exception in thread "main" java.lang.IllegalArgumentException: methods
> with same signature foo() but incompatible return types: [interface I1,
> interface I2]
>	at sun.misc.ProxyGenerator.checkReturnTypes(ProxyGenerator.java:712)
>	at sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:461)
>	at sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:339)
>	at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:639)
>	at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:557)
>	at java.lang.reflect.WeakCache$Factory.get(WeakCache.java:230)
>	at java.lang.reflect.WeakCache.get(WeakCache.java:127)
>	at java.lang.reflect.Proxy.getProxyClass0(Proxy.java:419)
>	at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:719)
>	at ProxyBug.main(ProxyBug.java:19)
> 
> So it would seem that newProxyInstance is incorrectly including static
> methods in its check for incompatible return types.
> 
> Can I get someone from core-libs to confirm that this is not intended
> before I file a bug and start on the fix?

From mandy.chung at oracle.com  Mon Oct  2 20:33:10 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 2 Oct 2017 13:33:10 -0700
Subject: Confirm bug in java.lang.reflect.Proxy wrt static methods in
 interfaces
In-Reply-To: <7d47fec6-879c-e47d-4bd1-dee2b22cf000@metricspace.net>
References: <7d47fec6-879c-e47d-4bd1-dee2b22cf000@metricspace.net>
Message-ID: <b7da1e40-c56a-0c68-7f3b-2193fe6b042e@oracle.com>

I believe it is a bug. ? To invoke a static method in the proxy 
interface, it will have to do "I1.foo()" or "I2.foo()".? It won't invoke 
through the proxy object, i.e. it's not interceptible.? Even creating a 
proxy for I1, the generated proxy class includes an instance method 
named "foo" and no static method is generated in the proxy class.

Mandy

On 10/2/17 11:44 AM, Eric McCorkle wrote:
> Hello everyone,
>
> A colleague of mine discovered what seems to be a bug in
> java.lang.reflect.Proxy#newProxyInstance.  I'd like to confirm that this
> is indeed incorrect behavior before I go and fix it.
>
> Consider the following two interfaces:
>
> interface I1 {
>    static I1 foo() {
>      return null;
>    }
> }
>
> interface I2 {
>    static I2 foo() {
>      return null;
>    }
> }
>
> JLS 9.4.1 states that static methods are not inherited in interfaces,
> thus it should be perfectly legal to define some class which inherits I1
> and I2.
>
> The following proxy creation fails:
>
> public class ProxyBug {
>    public static void main(String... args) {
>      I2 i2 =(I2)Proxy.newProxyInstance(
>                   ClassLoader.getSystemClassLoader(),
>                   new Class[] {I1.class, I2.class},
>                   new InvocationHandler() {
>                     @Override
>                     public Object invoke(Object proxy,
>                                          Method method,
>                                          Object[] args)
>                       throws Throwable {
>                       return null;
>                     }
>                   });
>    }
> }
>
> The exception generated is as follows:
>
> Exception in thread "main" java.lang.IllegalArgumentException: methods
> with same signature foo() but incompatible return types: [interface I1,
> interface I2]
> 	at sun.misc.ProxyGenerator.checkReturnTypes(ProxyGenerator.java:712)
> 	at sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:461)
> 	at sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:339)
> 	at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:639)
> 	at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:557)
> 	at java.lang.reflect.WeakCache$Factory.get(WeakCache.java:230)
> 	at java.lang.reflect.WeakCache.get(WeakCache.java:127)
> 	at java.lang.reflect.Proxy.getProxyClass0(Proxy.java:419)
> 	at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:719)
> 	at ProxyBug.main(ProxyBug.java:19)
>
> So it would seem that newProxyInstance is incorrectly including static
> methods in its check for incompatible return types.
>
> Can I get someone from core-libs to confirm that this is not intended
> before I file a bug and start on the fix?


From mandy.chung at oracle.com  Mon Oct  2 20:39:01 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 2 Oct 2017 13:39:01 -0700
Subject: Confirm bug in java.lang.reflect.Proxy wrt static methods in
 interfaces
In-Reply-To: <b7da1e40-c56a-0c68-7f3b-2193fe6b042e@oracle.com>
References: <7d47fec6-879c-e47d-4bd1-dee2b22cf000@metricspace.net>
 <b7da1e40-c56a-0c68-7f3b-2193fe6b042e@oracle.com>
Message-ID: <3487ca12-1d56-c42c-6ae5-a1bbe1646f08@oracle.com>

FYI. I created https://bugs.openjdk.java.net/browse/JDK-8188240 for this 
issue.

Mandy

On 10/2/17 1:33 PM, mandy chung wrote:
> I believe it is a bug. ? To invoke a static method in the proxy 
> interface, it will have to do "I1.foo()" or "I2.foo()".? It won't 
> invoke through the proxy object, i.e. it's not interceptible. Even 
> creating a proxy for I1, the generated proxy class includes an 
> instance method named "foo" and no static method is generated in the 
> proxy class.
>
> Mandy
>
> On 10/2/17 11:44 AM, Eric McCorkle wrote:
>> Hello everyone,
>>
>> A colleague of mine discovered what seems to be a bug in
>> java.lang.reflect.Proxy#newProxyInstance.? I'd like to confirm that this
>> is indeed incorrect behavior before I go and fix it.
>>
>> Consider the following two interfaces:
>>
>> interface I1 {
>> ?? static I1 foo() {
>> ???? return null;
>> ?? }
>> }
>>
>> interface I2 {
>> ?? static I2 foo() {
>> ???? return null;
>> ?? }
>> }
>>
>> JLS 9.4.1 states that static methods are not inherited in interfaces,
>> thus it should be perfectly legal to define some class which inherits I1
>> and I2.
>>
>> The following proxy creation fails:
>>
>> public class ProxyBug {
>> ?? public static void main(String... args) {
>> ???? I2 i2 =(I2)Proxy.newProxyInstance(
>> ????????????????? ClassLoader.getSystemClassLoader(),
>> ????????????????? new Class[] {I1.class, I2.class},
>> ????????????????? new InvocationHandler() {
>> ??????????????????? @Override
>> ??????????????????? public Object invoke(Object proxy,
>> ???????????????????????????????????????? Method method,
>> ???????????????????????????????????????? Object[] args)
>> ????????????????????? throws Throwable {
>> ????????????????????? return null;
>> ??????????????????? }
>> ????????????????? });
>> ?? }
>> }
>>
>> The exception generated is as follows:
>>
>> Exception in thread "main" java.lang.IllegalArgumentException: methods
>> with same signature foo() but incompatible return types: [interface I1,
>> interface I2]
>> ????at sun.misc.ProxyGenerator.checkReturnTypes(ProxyGenerator.java:712)
>> ????at 
>> sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:461)
>> ????at 
>> sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:339)
>> ????at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:639)
>> ????at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:557)
>> ????at java.lang.reflect.WeakCache$Factory.get(WeakCache.java:230)
>> ????at java.lang.reflect.WeakCache.get(WeakCache.java:127)
>> ????at java.lang.reflect.Proxy.getProxyClass0(Proxy.java:419)
>> ????at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:719)
>> ????at ProxyBug.main(ProxyBug.java:19)
>>
>> So it would seem that newProxyInstance is incorrectly including static
>> methods in its check for incompatible return types.
>>
>> Can I get someone from core-libs to confirm that this is not intended
>> before I file a bug and start on the fix?
>


From eric at metricspace.net  Mon Oct  2 20:44:20 2017
From: eric at metricspace.net (Eric McCorkle)
Date: Mon, 2 Oct 2017 16:44:20 -0400
Subject: Confirm bug in java.lang.reflect.Proxy wrt static methods in
 interfaces
In-Reply-To: <3487ca12-1d56-c42c-6ae5-a1bbe1646f08@oracle.com>
References: <7d47fec6-879c-e47d-4bd1-dee2b22cf000@metricspace.net>
 <b7da1e40-c56a-0c68-7f3b-2193fe6b042e@oracle.com>
 <3487ca12-1d56-c42c-6ae5-a1bbe1646f08@oracle.com>
Message-ID: <1db57d47-b8c6-8866-6031-bd8603fd4e7e@metricspace.net>

You beat me to it :D

I will see if I can fix it myself (though it's been a some time since I
committed any changes).

On 10/02/2017 16:39, mandy chung wrote:
> FYI. I created https://bugs.openjdk.java.net/browse/JDK-8188240 for this
> issue.
> 
> Mandy
> 
> On 10/2/17 1:33 PM, mandy chung wrote:
>> I believe it is a bug.   To invoke a static method in the proxy
>> interface, it will have to do "I1.foo()" or "I2.foo()".  It won't
>> invoke through the proxy object, i.e. it's not interceptible. Even
>> creating a proxy for I1, the generated proxy class includes an
>> instance method named "foo" and no static method is generated in the
>> proxy class.
>>
>> Mandy
>>
>> On 10/2/17 11:44 AM, Eric McCorkle wrote:
>>> Hello everyone,
>>>
>>> A colleague of mine discovered what seems to be a bug in
>>> java.lang.reflect.Proxy#newProxyInstance.  I'd like to confirm that this
>>> is indeed incorrect behavior before I go and fix it.
>>>
>>> Consider the following two interfaces:
>>>
>>> interface I1 {
>>>    static I1 foo() {
>>>      return null;
>>>    }
>>> }
>>>
>>> interface I2 {
>>>    static I2 foo() {
>>>      return null;
>>>    }
>>> }
>>>
>>> JLS 9.4.1 states that static methods are not inherited in interfaces,
>>> thus it should be perfectly legal to define some class which inherits I1
>>> and I2.
>>>
>>> The following proxy creation fails:
>>>
>>> public class ProxyBug {
>>>    public static void main(String... args) {
>>>      I2 i2 =(I2)Proxy.newProxyInstance(
>>>                   ClassLoader.getSystemClassLoader(),
>>>                   new Class[] {I1.class, I2.class},
>>>                   new InvocationHandler() {
>>>                     @Override
>>>                     public Object invoke(Object proxy,
>>>                                          Method method,
>>>                                          Object[] args)
>>>                       throws Throwable {
>>>                       return null;
>>>                     }
>>>                   });
>>>    }
>>> }
>>>
>>> The exception generated is as follows:
>>>
>>> Exception in thread "main" java.lang.IllegalArgumentException: methods
>>> with same signature foo() but incompatible return types: [interface I1,
>>> interface I2]
>>>     at sun.misc.ProxyGenerator.checkReturnTypes(ProxyGenerator.java:712)
>>>     at
>>> sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:461)
>>>     at
>>> sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:339)
>>>     at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:639)
>>>     at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:557)
>>>     at java.lang.reflect.WeakCache$Factory.get(WeakCache.java:230)
>>>     at java.lang.reflect.WeakCache.get(WeakCache.java:127)
>>>     at java.lang.reflect.Proxy.getProxyClass0(Proxy.java:419)
>>>     at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:719)
>>>     at ProxyBug.main(ProxyBug.java:19)
>>>
>>> So it would seem that newProxyInstance is incorrectly including static
>>> methods in its check for incompatible return types.
>>>
>>> Can I get someone from core-libs to confirm that this is not intended
>>> before I file a bug and start on the fix?
>>
> 

From mandy.chung at oracle.com  Mon Oct  2 20:50:57 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 2 Oct 2017 13:50:57 -0700
Subject: Confirm bug in java.lang.reflect.Proxy wrt static methods in
 interfaces
In-Reply-To: <1db57d47-b8c6-8866-6031-bd8603fd4e7e@metricspace.net>
References: <7d47fec6-879c-e47d-4bd1-dee2b22cf000@metricspace.net>
 <b7da1e40-c56a-0c68-7f3b-2193fe6b042e@oracle.com>
 <3487ca12-1d56-c42c-6ae5-a1bbe1646f08@oracle.com>
 <1db57d47-b8c6-8866-6031-bd8603fd4e7e@metricspace.net>
Message-ID: <308901bc-9a0f-f588-51b9-3cb1f4ad7853@oracle.com>

Your contribution is welcome and I can sponsor it.

Mandy

On 10/2/17 1:44 PM, Eric McCorkle wrote:
> You beat me to it :D
>
> I will see if I can fix it myself (though it's been a some time since I
> committed any changes).
>
> On 10/02/2017 16:39, mandy chung wrote:
>> FYI. I created https://bugs.openjdk.java.net/browse/JDK-8188240 for this
>> issue.
>>
>> Mandy
>>
>> On 10/2/17 1:33 PM, mandy chung wrote:
>>> I believe it is a bug.   To invoke a static method in the proxy
>>> interface, it will have to do "I1.foo()" or "I2.foo()".  It won't
>>> invoke through the proxy object, i.e. it's not interceptible. Even
>>> creating a proxy for I1, the generated proxy class includes an
>>> instance method named "foo" and no static method is generated in the
>>> proxy class.
>>>
>>> Mandy
>>>
>>> On 10/2/17 11:44 AM, Eric McCorkle wrote:
>>>> Hello everyone,
>>>>
>>>> A colleague of mine discovered what seems to be a bug in
>>>> java.lang.reflect.Proxy#newProxyInstance.  I'd like to confirm that this
>>>> is indeed incorrect behavior before I go and fix it.
>>>>
>>>> Consider the following two interfaces:
>>>>
>>>> interface I1 {
>>>>     static I1 foo() {
>>>>       return null;
>>>>     }
>>>> }
>>>>
>>>> interface I2 {
>>>>     static I2 foo() {
>>>>       return null;
>>>>     }
>>>> }
>>>>
>>>> JLS 9.4.1 states that static methods are not inherited in interfaces,
>>>> thus it should be perfectly legal to define some class which inherits I1
>>>> and I2.
>>>>
>>>> The following proxy creation fails:
>>>>
>>>> public class ProxyBug {
>>>>     public static void main(String... args) {
>>>>       I2 i2 =(I2)Proxy.newProxyInstance(
>>>>                    ClassLoader.getSystemClassLoader(),
>>>>                    new Class[] {I1.class, I2.class},
>>>>                    new InvocationHandler() {
>>>>                      @Override
>>>>                      public Object invoke(Object proxy,
>>>>                                           Method method,
>>>>                                           Object[] args)
>>>>                        throws Throwable {
>>>>                        return null;
>>>>                      }
>>>>                    });
>>>>     }
>>>> }
>>>>
>>>> The exception generated is as follows:
>>>>
>>>> Exception in thread "main" java.lang.IllegalArgumentException: methods
>>>> with same signature foo() but incompatible return types: [interface I1,
>>>> interface I2]
>>>>      at sun.misc.ProxyGenerator.checkReturnTypes(ProxyGenerator.java:712)
>>>>      at
>>>> sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:461)
>>>>      at
>>>> sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:339)
>>>>      at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:639)
>>>>      at java.lang.reflect.Proxy$ProxyClassFactory.apply(Proxy.java:557)
>>>>      at java.lang.reflect.WeakCache$Factory.get(WeakCache.java:230)
>>>>      at java.lang.reflect.WeakCache.get(WeakCache.java:127)
>>>>      at java.lang.reflect.Proxy.getProxyClass0(Proxy.java:419)
>>>>      at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:719)
>>>>      at ProxyBug.main(ProxyBug.java:19)
>>>>
>>>> So it would seem that newProxyInstance is incorrectly including static
>>>> methods in its check for incompatible return types.
>>>>
>>>> Can I get someone from core-libs to confirm that this is not intended
>>>> before I file a bug and start on the fix?


From Lance.Andersen at oracle.com  Tue Oct  3 18:09:20 2017
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Tue, 3 Oct 2017 14:09:20 -0400
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
Message-ID: <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>

Hi Jack,

Is this change correct:

-------------
--- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
+++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
@@ -373,7 +373,7 @@
      *      If the {@link ValidationEventHandler ValidationEventHandler}
      *      returns false from its {@code handleEvent} method or the
      *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
-     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
+     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
      *      Marshalling a JAXB element</a>.

------------

The URL that is being changed currently works

Best
Lance
On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com> wrote:

> Hi,
> 
> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>
> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>
> 
> Summary of changes:
> 
> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
> 
> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
> And also contains the fixes for importing nodes for SOAPDocumentFragment
> 
> 
> Patch also contains several small bugfixes, not tracked in JBS.
> 
> ----------------
> Best regards
> Jack Li
> 
> 
> 
> 
> 
> 




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  Tue Oct  3 19:07:46 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 3 Oct 2017 12:07:46 -0700
Subject: Review Request JDK-8188321:(jdeps) help message should say "requires
 transitive" rather than "requires public"
Message-ID: <03d32dae-43ae-8fc0-4248-a87bed3c13f4@oracle.com>

http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8188321/webrev.00/

This changes the jdeps help message fixing the typo, move -q and
-version to the first section and group the module-related options
together in a new section.

thanks
Mandy


From Lance.Andersen at oracle.com  Tue Oct  3 19:59:15 2017
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Tue, 3 Oct 2017 15:59:15 -0400
Subject: Review Request JDK-8188321:(jdeps) help message should say
 "requires transitive" rather than "requires public"
In-Reply-To: <03d32dae-43ae-8fc0-4248-a87bed3c13f4@oracle.com>
References: <03d32dae-43ae-8fc0-4248-a87bed3c13f4@oracle.com>
Message-ID: <464D0E96-FEDA-405F-ABD8-DA4A1D0AC6FF@oracle.com>

looks fine Mandy

Best
Lance
On Oct 3, 2017, at 3:07 PM, mandy chung <mandy.chung at oracle.com> wrote:

> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8188321/webrev.00/
> 
> This changes the jdeps help message fixing the typo, move -q and
> -version to the first section and group the module-related options
> together in a new section.
> 
> thanks
> 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  Tue Oct  3 23:17:17 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 3 Oct 2017 16:17:17 -0700
Subject: RFR 8080225: FileInputStream cleanup should be improved
In-Reply-To: <abbc6122-e6fa-71eb-fa85-01a419cfbfd1@Oracle.com>
References: <abbc6122-e6fa-71eb-fa85-01a419cfbfd1@Oracle.com>
Message-ID: <410d0712-5ff6-5821-482a-389d6a6ac69b@oracle.com>

Hi Roger,

This looks good overall.

53 * unreachable should explicitly override {@link #finalize} and call 
{@code close}.

Since finalize is deprecated, I would not recommend to have the subclass 
adding the finalize method.? I suggest to take that phrase out (I gave a 
similar comment to JDK-8185582 [1]).?? Users should use 
try-with-resource or register the instances in a cleaner.

As for the tests, FinalizeShdCallClose.java implements finalize.? I 
think it'd be good to convert them to try-with-resource.

I'm not close to java.io implementation.? Would registerCleanup be 
called more than once? line 220 in the registerCleanup will create a new 
cleanup if it's invoked the second time - is it intentional?

216 synchronized void registerCleanup() {
217 if (cleanup != null) {
218 cleanup.clear();
219 }
220 cleanup = FDCleanup.create(this);
221 } thanks Mandy

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049362.html

On 9/29/17 10:17 AM, Roger Riggs wrote:
> Replacing finalizers in FileInputStream, FileOutputStream, and adding 
> cleanup to RandomAccessFile
> and NIO File Channels with Cleaner based implementations required 
> changes to FileDescriptor.
>
> The specification of FileInputStream and FileOutputStream is changed 
> to remove the finalizer
> behavior that required their respective close methods to be called.
> This change to the behavior is tracked with CSR 8187325 [3].
>
> The FileDescriptor implementations (Unix and Windows) provide a 
> cleanup function that is now used by
> FIS, FOS, RAF, and async and normal FileChannels.? Each requests 
> FileDescriptor to register a cleanup function
> when the fd or handle is assigned and delegates to 
> FileDescriptor.close.? If the respective
> FileDescriptor.close method is not called, the fd or handle will be 
> closed when the FileDescriptor
> is determined to be phantom reachable.
>
> The other uses of FileDescriptor are not intended to be changed, for 
> example in sockets and datagrams.
>
> Some tests were modified to not rely on finalization; new tests are 
> provided.
>
> Comments are appreciated on both the CSR [3] and the implementation [1].
>
> [1] webrev: 
> http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/
>
> [2] Issue:?? https://bugs.openjdk.java.net/browse/JDK-8080225
>
> [3] CSR:? 8187325? FileInputStream/FileOutputStream should use the 
> Cleaner instead of finalize
> ? https://bugs.openjdk.java.net/browse/JDK-8187325
>
> Thanks, Roger
>
>


From sundararajan.athijegannathan at oracle.com  Wed Oct  4 01:58:07 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Wed, 04 Oct 2017 07:28:07 +0530
Subject: Review Request JDK-8188321:(jdeps) help message should say
 "requires transitive" rather than "requires public"
In-Reply-To: <03d32dae-43ae-8fc0-4248-a87bed3c13f4@oracle.com>
References: <03d32dae-43ae-8fc0-4248-a87bed3c13f4@oracle.com>
Message-ID: <59D4402F.8070708@oracle.com>

+1

-Sundar

On 04/10/17, 12:37 AM, mandy chung wrote:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8188321/webrev.00/
>
> This changes the jdeps help message fixing the typo, move -q and
> -version to the first section and group the module-related options
> together in a new section.
>
> thanks
> Mandy
>

From Roger.Riggs at Oracle.com  Wed Oct  4 14:35:25 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 4 Oct 2017 10:35:25 -0400
Subject: RFR 8080225: FileInputStream cleanup should be improved
In-Reply-To: <410d0712-5ff6-5821-482a-389d6a6ac69b@oracle.com>
References: <abbc6122-e6fa-71eb-fa85-01a419cfbfd1@Oracle.com>
 <410d0712-5ff6-5821-482a-389d6a6ac69b@oracle.com>
Message-ID: <c31522d5-60ff-0a69-88f5-01a68049bd32@Oracle.com>

Hi Mandy,

Updated the webrev in place:
 ?? http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/


On 10/3/2017 7:17 PM, mandy chung wrote:
> Hi Roger,
>
> This looks good overall.
>
> 53 * unreachable should explicitly override {@link #finalize} and call 
> {@code close}.
>
> Since finalize is deprecated, I would not recommend to have the 
> subclass adding the finalize method.? I suggest to take that phrase 
> out (I gave a similar comment to JDK-8185582 [1]). Users should use 
> try-with-resource or register the instances in a cleaner.
ok, but neither t-w-r or cleaner can completely replace the behavior of 
finalize.
In some cases, significant refactoring of the application class may be 
needed.
>
> As for the tests, FinalizeShdCallClose.java implements finalize.? I 
> think it'd be good to convert them to try-with-resource.
The new tests Unreferenced*ClosesFd incorporate the original 
FinalizeShdCallClose tests cases
except the case where the subclass does override finalize to call 
closed; behavior that is deprecated
but still supported.
I refactored the Unreferenced*ClosesFd tests to make the 
FinalizeShdCallClose tests unnecessary and
will remove them. [If the CSR requires greater behavioral compatibility, 
the tests may be needed again].

>
> I'm not close to java.io implementation.? Would registerCleanup be 
> called more than once? line 220 in the registerCleanup will create a 
> new cleanup if it's invoked the second time - is it intentional?
> 216 synchronized void registerCleanup() {
> 217 if (cleanup != null) {
> 218 cleanup.clear();
> 219 }
> 220 cleanup = FDCleanup.create(this);
> 221 }
Re-registering *clears* not cleans the previous cleanup and then creates 
a new one.
If the native fd has changed a new cleanup is needed.
There no cases currently where registerCleanup is called twice on the 
same FileDescriptor.

Thanks, Roger

> thanks Mandy
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049362.html
>
> On 9/29/17 10:17 AM, Roger Riggs wrote:
>> Replacing finalizers in FileInputStream, FileOutputStream, and adding 
>> cleanup to RandomAccessFile
>> and NIO File Channels with Cleaner based implementations required 
>> changes to FileDescriptor.
>>
>> The specification of FileInputStream and FileOutputStream is changed 
>> to remove the finalizer
>> behavior that required their respective close methods to be called.
>> This change to the behavior is tracked with CSR 8187325 [3].
>>
>> The FileDescriptor implementations (Unix and Windows) provide a 
>> cleanup function that is now used by
>> FIS, FOS, RAF, and async and normal FileChannels.? Each requests 
>> FileDescriptor to register a cleanup function
>> when the fd or handle is assigned and delegates to 
>> FileDescriptor.close.? If the respective
>> FileDescriptor.close method is not called, the fd or handle will be 
>> closed when the FileDescriptor
>> is determined to be phantom reachable.
>>
>> The other uses of FileDescriptor are not intended to be changed, for 
>> example in sockets and datagrams.
>>
>> Some tests were modified to not rely on finalization; new tests are 
>> provided.
>>
>> Comments are appreciated on both the CSR [3] and the implementation [1].
>>
>> [1] webrev: 
>> http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/
>>
>> [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8080225
>>
>> [3] CSR:? 8187325? FileInputStream/FileOutputStream should use the 
>> Cleaner instead of finalize
>> https://bugs.openjdk.java.net/browse/JDK-8187325
>>
>> Thanks, Roger
>>
>>
>


From mandy.chung at oracle.com  Wed Oct  4 18:12:04 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 4 Oct 2017 11:12:04 -0700
Subject: Review Request JDK-8188052: JNI_FindClass needs to specify the class
 loading context used for library lifecycle hooks
Message-ID: <20f86e9c-06b2-a6e5-273d-8536d62e9d64@oracle.com>

This patch separates the JNI `FindClass` issue from the review thread 
for JDK-8188052 [1] into a different issue.

webrev: 
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8188052/webrev.00/index.html

This patch changes `FindClass` to specify the class loading context used 
for the load and unload hook. `FindClass` when called from JNI_OnUnload 
is changed to use the system class loader as the context. This is an 
incompatible behavioral change and this bumps the version so that a 
native library can determine the new behavior if desire.? This change 
proposes to defines JNI_VERSION_10 and I expect this name will be 
revisited along with the version string for the proposed new release 
cadence [2].

CSR:? https://bugs.openjdk.java.net/browse/JDK-8188069

Thanks David for the suggested spec wordings.

thanks
Mandy
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049292.html
[2] 
http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html

From vladimir.kozlov at oracle.com  Wed Oct  4 23:05:33 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 4 Oct 2017 16:05:33 -0700
Subject: [10] RFR(S) 8188775: Module jdk.internal.vm.compiler.management has
 not been granted accessClassInPackage.org.graalvm.compiler.hotspot
Message-ID: <a374f47d-c4a5-0fb4-8674-dba65624532f@oracle.com>

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

Changes for 8182701[1] missed changes in default.policy for new module jdk.internal.vm.compiler.management.

Add missing code:

src/java.base/share/lib/security/default.policy
@@ -154,6 +154,10 @@
      permission java.security.AllPermission;
  };

+grant codeBase "jrt:/jdk.internal.vm.compiler.management" {
+    permission java.security.AllPermission;
+};
+
  grant codeBase "jrt:/jdk.jsobject" {
      permission java.security.AllPermission;
  };

Verified with failed test.

Thanks,
Vladimir

[1] http://hg.openjdk.java.net/jdk10/hs/rev/8b2054b7d02c

From mandy.chung at oracle.com  Wed Oct  4 23:07:07 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 4 Oct 2017 16:07:07 -0700
Subject: [10] RFR(S) 8188775: Module jdk.internal.vm.compiler.management
 has not been granted accessClassInPackage.org.graalvm.compiler.hotspot
In-Reply-To: <a374f47d-c4a5-0fb4-8674-dba65624532f@oracle.com>
References: <a374f47d-c4a5-0fb4-8674-dba65624532f@oracle.com>
Message-ID: <2e050a60-0f6e-503f-df39-31108f0da6d1@oracle.com>

+1

Mandy

On 10/4/17 4:05 PM, Vladimir Kozlov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8188775
>
> Changes for 8182701[1] missed changes in default.policy for new module 
> jdk.internal.vm.compiler.management.
>
> Add missing code:
>
> src/java.base/share/lib/security/default.policy
> @@ -154,6 +154,10 @@
> ???? permission java.security.AllPermission;
> ?};
>
> +grant codeBase "jrt:/jdk.internal.vm.compiler.management" {
> +??? permission java.security.AllPermission;
> +};
> +
> ?grant codeBase "jrt:/jdk.jsobject" {
> ???? permission java.security.AllPermission;
> ?};
>
> Verified with failed test.
>
> Thanks,
> Vladimir
>
> [1] http://hg.openjdk.java.net/jdk10/hs/rev/8b2054b7d02c


From vladimir.kozlov at oracle.com  Wed Oct  4 23:12:27 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 4 Oct 2017 16:12:27 -0700
Subject: [10] RFR(XS) 8188776: jdk.internal.vm.ci can't export package to
 upgradeable modules
Message-ID: <c651ff90-1e1a-a830-907a-88075aeb983b@oracle.com>

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

8182701 added exports for jdk.vm.ci.runtime package [1] but did not add new exception in the test.

Added missing exception in JdkQualifiedExportTest.java test:

--- a/test/jdk/jdk/modules/etc/JdkQualifiedExportTest.java
+++ b/test/jdk/jdk/modules/etc/JdkQualifiedExportTest.java
@@ -70,6 +70,7 @@

      static Set<String> KNOWN_EXCEPTIONS =
          Set.of("jdk.internal.vm.ci/jdk.vm.ci.services",
+               "jdk.internal.vm.ci/jdk.vm.ci.runtime",
                 "jdk.jsobject/jdk.internal.netscape.javascript.spi");

      static void checkExports(ModuleDescriptor md) {

Verified with this test.

Thanks,
Vladimir

[1] http://hg.openjdk.java.net/jdk10/hs/rev/8b2054b7d02c#l3.1

From vladimir.kozlov at oracle.com  Wed Oct  4 23:12:55 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 4 Oct 2017 16:12:55 -0700
Subject: [10] RFR(S) 8188775: Module jdk.internal.vm.compiler.management
 has not been granted accessClassInPackage.org.graalvm.compiler.hotspot
In-Reply-To: <2e050a60-0f6e-503f-df39-31108f0da6d1@oracle.com>
References: <a374f47d-c4a5-0fb4-8674-dba65624532f@oracle.com>
 <2e050a60-0f6e-503f-df39-31108f0da6d1@oracle.com>
Message-ID: <7a5e843d-4da1-25e8-d21c-908977707d4c@oracle.com>

Thank you, Mandy

Vladimir

On 10/4/17 4:07 PM, mandy chung wrote:
> +1
> 
> Mandy
> 
> On 10/4/17 4:05 PM, Vladimir Kozlov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8188775
>>
>> Changes for 8182701[1] missed changes in default.policy for new module jdk.internal.vm.compiler.management.
>>
>> Add missing code:
>>
>> src/java.base/share/lib/security/default.policy
>> @@ -154,6 +154,10 @@
>> ???? permission java.security.AllPermission;
>> ?};
>>
>> +grant codeBase "jrt:/jdk.internal.vm.compiler.management" {
>> +??? permission java.security.AllPermission;
>> +};
>> +
>> ?grant codeBase "jrt:/jdk.jsobject" {
>> ???? permission java.security.AllPermission;
>> ?};
>>
>> Verified with failed test.
>>
>> Thanks,
>> Vladimir
>>
>> [1] http://hg.openjdk.java.net/jdk10/hs/rev/8b2054b7d02c
> 

From mandy.chung at oracle.com  Wed Oct  4 23:15:43 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 4 Oct 2017 16:15:43 -0700
Subject: [10] RFR(XS) 8188776: jdk.internal.vm.ci can't export package to
 upgradeable modules
In-Reply-To: <c651ff90-1e1a-a830-907a-88075aeb983b@oracle.com>
References: <c651ff90-1e1a-a830-907a-88075aeb983b@oracle.com>
Message-ID: <1f6bdab4-8c1d-61a4-4abf-f294590e2eff@oracle.com>

+1

Looks like JDK regression tests were not run before pushing JDK-8182701?

Mandy

On 10/4/17 4:12 PM, Vladimir Kozlov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8188776
>
> 8182701 added exports for jdk.vm.ci.runtime package [1] but did not 
> add new exception in the test.
>
> Added missing exception in JdkQualifiedExportTest.java test:
>
> --- a/test/jdk/jdk/modules/etc/JdkQualifiedExportTest.java
> +++ b/test/jdk/jdk/modules/etc/JdkQualifiedExportTest.java
> @@ -70,6 +70,7 @@
>
> ???? static Set<String> KNOWN_EXCEPTIONS =
> ???????? Set.of("jdk.internal.vm.ci/jdk.vm.ci.services",
> +?????????????? "jdk.internal.vm.ci/jdk.vm.ci.runtime",
> "jdk.jsobject/jdk.internal.netscape.javascript.spi");
>
> ???? static void checkExports(ModuleDescriptor md) {
>
> Verified with this test.
>
> Thanks,
> Vladimir
>
> [1] http://hg.openjdk.java.net/jdk10/hs/rev/8b2054b7d02c#l3.1


From mandy.chung at oracle.com  Wed Oct  4 23:24:15 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 4 Oct 2017 16:24:15 -0700
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
Message-ID: <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>

Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.01/

JNI FindClass change has been separated from this patch [1]. I made 
further clean up to the NativeLibrary implementation and replaced the 
use of Vector/Stack.? I also added a native test to verify the native 
library can be unloaded and reloaded.

Summary: The patch replaces the ClassLoader use of finalizer with 
phantom reference, specifically Cleaner, for unloading native 
libraries.? It registers the class loader for cleanup only if it's not a 
builtin class loader which will never be unloaded.

thanks
Mandy
[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049389.html


From vladimir.kozlov at oracle.com  Wed Oct  4 23:34:23 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 4 Oct 2017 16:34:23 -0700
Subject: [10] RFR(XS) 8188776: jdk.internal.vm.ci can't export package to
 upgradeable modules
In-Reply-To: <1f6bdab4-8c1d-61a4-4abf-f294590e2eff@oracle.com>
References: <c651ff90-1e1a-a830-907a-88075aeb983b@oracle.com>
 <1f6bdab4-8c1d-61a4-4abf-f294590e2eff@oracle.com>
Message-ID: <deba104e-88c3-bba2-4204-f4f1f9afe5ef@oracle.com>

Thank you, Mandy

On 10/4/17 4:15 PM, mandy chung wrote:
> +1
> 
> Looks like JDK regression tests were not run before pushing JDK-8182701?

Yes, only hotspot jtreg tests were run unfortunately before the push.
We do run jdk_lang regularly in tier5 Nightly testing.

Thanks,
Vladimir

> 
> Mandy
> 
> On 10/4/17 4:12 PM, Vladimir Kozlov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8188776
>>
>> 8182701 added exports for jdk.vm.ci.runtime package [1] but did not add new exception in the test.
>>
>> Added missing exception in JdkQualifiedExportTest.java test:
>>
>> --- a/test/jdk/jdk/modules/etc/JdkQualifiedExportTest.java
>> +++ b/test/jdk/jdk/modules/etc/JdkQualifiedExportTest.java
>> @@ -70,6 +70,7 @@
>>
>> ???? static Set<String> KNOWN_EXCEPTIONS =
>> ???????? Set.of("jdk.internal.vm.ci/jdk.vm.ci.services",
>> +?????????????? "jdk.internal.vm.ci/jdk.vm.ci.runtime",
>> "jdk.jsobject/jdk.internal.netscape.javascript.spi");
>>
>> ???? static void checkExports(ModuleDescriptor md) {
>>
>> Verified with this test.
>>
>> Thanks,
>> Vladimir
>>
>> [1] http://hg.openjdk.java.net/jdk10/hs/rev/8b2054b7d02c#l3.1
> 

From david.holmes at oracle.com  Thu Oct  5 00:44:32 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Oct 2017 10:44:32 +1000
Subject: Review Request JDK-8188052: JNI_FindClass needs to specify the
 class loading context used for library lifecycle hooks
In-Reply-To: <20f86e9c-06b2-a6e5-273d-8536d62e9d64@oracle.com>
References: <20f86e9c-06b2-a6e5-273d-8536d62e9d64@oracle.com>
Message-ID: <18eeaeed-164a-1d02-1546-93cf77c0d771@oracle.com>

Hi Mandy,

On 5/10/2017 4:12 AM, mandy chung wrote:
> This patch separates the JNI `FindClass` issue from the review thread 
> for JDK-8188052 [1] into a different issue.
> 
> webrev: 
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8188052/webrev.00/index.html 

src/hotspot/share/prims/jni.cpp

Okay ... so by nulling fromClass in the classloader during finalization 
(soon to be moved to the Cleaner) you can now distinguish between the 
OnLoad case and the OnUnload case, within FindClass - a comment to 
clarify that would be good, please.

However you still have:

  407     if (loader.is_null() &&

but you deleted the initialization of loader:

- 404     loader = Handle(THREAD, k->class_loader());

so it will by default be null. I suppose checking the loader is only a 
potential optimization as the name of the class will be uniquely 
determined anyway. But the code should be cleaned up.

---

Otherwise all seems fine.

Thanks,
David

> 
> This patch changes `FindClass` to specify the class loading context used 
> for the load and unload hook. `FindClass` when called from JNI_OnUnload 
> is changed to use the system class loader as the context. This is an 
> incompatible behavioral change and this bumps the version so that a 
> native library can determine the new behavior if desire.? This change 
> proposes to defines JNI_VERSION_10 and I expect this name will be 
> revisited along with the version string for the proposed new release 
> cadence [2].
> 
> CSR:? https://bugs.openjdk.java.net/browse/JDK-8188069
> 
> Thanks David for the suggested spec wordings.
> 
> thanks
> Mandy
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049292.html 
> 
> [2] 
> http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html

From david.holmes at oracle.com  Thu Oct  5 01:21:27 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Oct 2017 11:21:27 +1000
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
Message-ID: <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>

Hi Mandy

On 5/10/2017 9:24 AM, mandy chung wrote:
> Updated webrev:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.01/
> 
> JNI FindClass change has been separated from this patch [1]. I made 
> further clean up to the NativeLibrary implementation and replaced the 
> use of Vector/Stack.? I also added a native test to verify the native 
> library can be unloaded and reloaded.
> 
> Summary: The patch replaces the ClassLoader use of finalizer with 
> phantom reference, specifically Cleaner, for unloading native 
> libraries.? It registers the class loader for cleanup only if it's not a 
> builtin class loader which will never be unloaded.

src/java.base/share/classes/java/lang/ClassLoader.java

This comment is not a sentence:

2442                 /* If the library is being loaded (must be by the 
same thread,
2443                  * because Runtime.load and Runtime.loadLibrary are
2444                  * synchronous).

Overall the changes seem fine, but I do have a concern about the use of 
ConcurrentHashMap. This would seem to be a significant change in the 
initialization order - and I'm wondering how libjava itself actually 
gets loaded ??

---

I assume the tests will be updated to use JNI_VERSION_10, assuming you 
push the FindClass changes first?

libnativeLibraryTest.c:

Not sure I see the point in the FindClass("java/lang/ClassLoader") as if 
it fails to find it then surely it already failed to find 
"java/lang/Error" and you'll possibly crash trying to throw.

NativeLibraryTest.java:

Not clear how/if this actually verifies any unloading actually takes 
place? Also if the OnUnload throws an error and that happens in the 
Cleaner thread, how would that exception result in the test reporting a 
failure ??

I think OnUnload has to update some state stored in the main test class 
so that it can confirm the unloading occurred successfully, or not.

Thanks,
David

> thanks
> Mandy
> [1] 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049389.html 
> 
> 

From mandy.chung at oracle.com  Thu Oct  5 02:09:26 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 4 Oct 2017 19:09:26 -0700
Subject: Review Request JDK-8188052: JNI_FindClass needs to specify the
 class loading context used for library lifecycle hooks
In-Reply-To: <18eeaeed-164a-1d02-1546-93cf77c0d771@oracle.com>
References: <20f86e9c-06b2-a6e5-273d-8536d62e9d64@oracle.com>
 <18eeaeed-164a-1d02-1546-93cf77c0d771@oracle.com>
Message-ID: <90f72a9f-14cc-9c4c-4499-9ff6b48ce3e2@oracle.com>



On 10/4/17 5:44 PM, David Holmes wrote:
> Hi Mandy,
>
> On 5/10/2017 4:12 AM, mandy chung wrote:
>> This patch separates the JNI `FindClass` issue from the review thread 
>> for JDK-8188052 [1] into a different issue.
>>
>> webrev: 
>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8188052/webrev.00/index.html 
>
>
> src/hotspot/share/prims/jni.cpp
>
> Okay ... so by nulling fromClass in the classloader during 
> finalization (soon to be moved to the Cleaner) you can now distinguish 
> between the OnLoad case and the OnUnload case, within FindClass - a 
> comment to clarify that would be good, please.

Added.

> However you still have:
>
> ?407???? if (loader.is_null() &&
>
> but you deleted the initialization of loader:
>
> - 404???? loader = Handle(THREAD, k->class_loader());
>
> so it will by default be null. I suppose checking the loader is only a 
> potential optimization as the name of the class will be uniquely 
> determined anyway. But the code should be cleaned up.
>

Good catch.?? Yes it's an optimization to avoid making the Java call 
unnecessary.

Updated:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8188052/webrev.01/src/hotspot/share/prims/jni.cpp.sdiff.html

Mandy


From david.holmes at oracle.com  Thu Oct  5 02:50:45 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Oct 2017 12:50:45 +1000
Subject: Review Request JDK-8188052: JNI_FindClass needs to specify the
 class loading context used for library lifecycle hooks
In-Reply-To: <90f72a9f-14cc-9c4c-4499-9ff6b48ce3e2@oracle.com>
References: <20f86e9c-06b2-a6e5-273d-8536d62e9d64@oracle.com>
 <18eeaeed-164a-1d02-1546-93cf77c0d771@oracle.com>
 <90f72a9f-14cc-9c4c-4499-9ff6b48ce3e2@oracle.com>
Message-ID: <db4e2480-1742-df42-18a9-477fced9eda2@oracle.com>

Looks good.

Thanks,
David

On 5/10/2017 12:09 PM, mandy chung wrote:
> 
> 
> On 10/4/17 5:44 PM, David Holmes wrote:
>> Hi Mandy,
>>
>> On 5/10/2017 4:12 AM, mandy chung wrote:
>>> This patch separates the JNI `FindClass` issue from the review thread 
>>> for JDK-8188052 [1] into a different issue.
>>>
>>> webrev: 
>>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8188052/webrev.00/index.html 
>>
>>
>>
>> src/hotspot/share/prims/jni.cpp
>>
>> Okay ... so by nulling fromClass in the classloader during 
>> finalization (soon to be moved to the Cleaner) you can now distinguish 
>> between the OnLoad case and the OnUnload case, within FindClass - a 
>> comment to clarify that would be good, please.
> 
> Added.
> 
>> However you still have:
>>
>> ?407???? if (loader.is_null() &&
>>
>> but you deleted the initialization of loader:
>>
>> - 404???? loader = Handle(THREAD, k->class_loader());
>>
>> so it will by default be null. I suppose checking the loader is only a 
>> potential optimization as the name of the class will be uniquely 
>> determined anyway. But the code should be cleaned up.
>>
> 
> Good catch.?? Yes it's an optimization to avoid making the Java call 
> unnecessary.
> 
> Updated:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8188052/webrev.01/src/hotspot/share/prims/jni.cpp.sdiff.html 
> 
> 
> Mandy
> 

From mandy.chung at oracle.com  Thu Oct  5 05:14:13 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 4 Oct 2017 22:14:13 -0700
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
Message-ID: <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>



On 10/4/17 6:21 PM, David Holmes wrote:
> Hi Mandy
>
> On 5/10/2017 9:24 AM, mandy chung wrote:
>> Updated webrev:
>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.01/
>>
>> JNI FindClass change has been separated from this patch [1]. I made 
>> further clean up to the NativeLibrary implementation and replaced the 
>> use of Vector/Stack.? I also added a native test to verify the native 
>> library can be unloaded and reloaded.
>>
>> Summary: The patch replaces the ClassLoader use of finalizer with 
>> phantom reference, specifically Cleaner, for unloading native 
>> libraries.? It registers the class loader for cleanup only if it's 
>> not a builtin class loader which will never be unloaded.
>
> src/java.base/share/classes/java/lang/ClassLoader.java
>
> This comment is not a sentence:
>
> 2442???????????????? /* If the library is being loaded (must be by the 
> same thread,
> 2443????????????????? * because Runtime.load and Runtime.loadLibrary are
> 2444????????????????? * synchronous).
>
This is an existing comment.? I rewrite it in the updated webrev.
> Overall the changes seem fine, but I do have a concern about the use 
> of ConcurrentHashMap. This would seem to be a significant change in 
> the initialization order - 

ConcurrentHashMap is referenced in ClassLoader but actually not loaded 
until later.? So it does change the initialization order. ? I now change 
the implementation to lazily create CHM.? This saves the footprint when 
a class loader does not load any native library.

> and I'm wondering how libjava itself actually gets loaded ??
>

 ?os::native_java_library() which is called by JDK_Version_init() at VM 
creation time.

> ---
>
> I assume the tests will be updated to use JNI_VERSION_10, assuming you 
> push the FindClass changes first?

JDK-8188052 will be pushed first to jdk10/hs.? This fix will have to 
wait until JDK-8188052 is integrated to jdk10/master.?? I will update 
the test to use JNI_VERSION_10 before I push.

>
> libnativeLibraryTest.c:
>
> Not sure I see the point in the FindClass("java/lang/ClassLoader") as 
> if it fails to find it then surely it already failed to find 
> "java/lang/Error" and you'll possibly crash trying to throw.
>
I agree that should be cleaned up.? I took out 
FindClass("java/lang/ClassLoader") case.
> NativeLibraryTest.java:
>
> Not clear how/if this actually verifies any unloading actually takes 
> place? 

If the native library is not unloaded, p.Test.<clinit> will fail when 
reloading the native library.? I think this is adequate. I added further 
checks to verify the number of times the native library is unloaded as 
you suggest below.

> Also if the OnUnload throws an error and that happens in the Cleaner 
> thread, how would that exception result in the test reporting a 
> failure ??
>

Good point.? Cleaner ignores all exceptions.? I change it to be a fatal 
error.
> I think OnUnload has to update some state stored in the main test 
> class so that it can confirm the unloading occurred successfully, or not.
>

I added this per your suggestion to enhance the verification.

Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.02/

Mandy


From david.holmes at oracle.com  Thu Oct  5 06:06:15 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Oct 2017 16:06:15 +1000
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
Message-ID: <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>

Hi Mandy,

On 5/10/2017 3:14 PM, mandy chung wrote:
> On 10/4/17 6:21 PM, David Holmes wrote:
>> Hi Mandy
>>
>> On 5/10/2017 9:24 AM, mandy chung wrote:
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.01/
>>>
>>> JNI FindClass change has been separated from this patch [1]. I made 
>>> further clean up to the NativeLibrary implementation and replaced the 
>>> use of Vector/Stack.? I also added a native test to verify the native 
>>> library can be unloaded and reloaded.
>>>
>>> Summary: The patch replaces the ClassLoader use of finalizer with 
>>> phantom reference, specifically Cleaner, for unloading native 
>>> libraries.? It registers the class loader for cleanup only if it's 
>>> not a builtin class loader which will never be unloaded.
>>
>> src/java.base/share/classes/java/lang/ClassLoader.java
>>
>> This comment is not a sentence:
>>
>> 2442???????????????? /* If the library is being loaded (must be by the 
>> same thread,
>> 2443????????????????? * because Runtime.load and Runtime.loadLibrary are
>> 2444????????????????? * synchronous).
>>
> This is an existing comment.? I rewrite it in the updated webrev.

Sorry I didn't notice that was refactored code. Thanks for the rewrite.

>> Overall the changes seem fine, but I do have a concern about the use 
>> of ConcurrentHashMap. This would seem to be a significant change in 
>> the initialization order - 
> 
> ConcurrentHashMap is referenced in ClassLoader but actually not loaded 

It was loaded in clinit:

2689     private static Map<String, NativeLibrary> systemNativeLibraries
2690         = new ConcurrentHashMap<>();

which was my concern.

> until later.? So it does change the initialization order. ? I now change 
> the implementation to lazily create CHM.? This saves the footprint when 
> a class loader does not load any native library.

Okay. But now I'm wondering about whether 
systemNativeLibraries/nativeLibraries need to be volatile? Just looking 
in ClassLoader it would seem yes, but if the only paths to loading a 
library are through Runtime, and those methods are synchronized on the 
Runtime instance, then everything is serialized anyway. Are there other 
paths that might allow concurrent access? (If the synchronization in 
Runtime guarantees only a single library can ever be loaded at a time 
across all classloaders, then you don't even need the synchronization on 
the loadedLibraryNames ??).

>> and I'm wondering how libjava itself actually gets loaded ??
>>
> 
>  ?os::native_java_library() which is called by JDK_Version_init() at VM 
> creation time.

Okay a different mechanism - and presumably no JNI_OnLoad function to 
execute :)

>> ---
>>
>> I assume the tests will be updated to use JNI_VERSION_10, assuming you 
>> push the FindClass changes first?
> 
> JDK-8188052 will be pushed first to jdk10/hs.? This fix will have to 
> wait until JDK-8188052 is integrated to jdk10/master.?? I will update 
> the test to use JNI_VERSION_10 before I push.

Ok.

>>
>> libnativeLibraryTest.c:
>>
>> Not sure I see the point in the FindClass("java/lang/ClassLoader") as 
>> if it fails to find it then surely it already failed to find 
>> "java/lang/Error" and you'll possibly crash trying to throw.
>>
> I agree that should be cleaned up.? I took out 
> FindClass("java/lang/ClassLoader") case.

So is:

   68     excls = (*env)->FindClass(env, "java/lang/Error");
   69     if (excls == NULL) {
   70         (*env)->FatalError(env, "Error class not found");
   71     }

just a sanity check that you can in fact load a class?

  75         (*env)->FatalError(env, "Error class not found");

That's the wrong error message.

>> NativeLibraryTest.java:
>>
>> Not clear how/if this actually verifies any unloading actually takes 
>> place? 
> 
> If the native library is not unloaded, p.Test.<clinit> will fail when 
> reloading the native library.? I think this is adequate. I added further 

Ah I hadn't realized that part.

> checks to verify the number of times the native library is unloaded as 
> you suggest below.
> 
>> Also if the OnUnload throws an error and that happens in the Cleaner 
>> thread, how would that exception result in the test reporting a 
>> failure ??
>>
> 
> Good point.? Cleaner ignores all exceptions.? I change it to be a fatal 
> error.
>> I think OnUnload has to update some state stored in the main test 
>> class so that it can confirm the unloading occurred successfully, or not.
>>
> 
> I added this per your suggestion to enhance the verification.

Okay. Not sure why you needed to introduce q.Bridge - I find the test 
logic rather hard to follow, not clear who calls what method from where 
and when. I was thinking of a simple

public int loadedCount;
public int unloadedCount;

that onLoad/OnUnload would increment.

Thanks,
David
-----

> Updated webrev:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.02/
> 
> Mandy
> 

From jaroslav.tulach at oracle.com  Thu Oct  5 15:32:39 2017
From: jaroslav.tulach at oracle.com (Jaroslav Tulach)
Date: Thu, 05 Oct 2017 17:32:39 +0200
Subject: [10] RFR(S) 8188775: Module jdk.internal.vm.compiler.management
 has not been granted accessClassInPackage.org.graalvm.compiler.hotspot
In-Reply-To: <a374f47d-c4a5-0fb4-8674-dba65624532f@oracle.com>
References: <a374f47d-c4a5-0fb4-8674-dba65624532f@oracle.com>
Message-ID: <2799842.XxlxnWyqlB@pracovni>

Opps. Sorry for causing the problem. I haven't executed the test in question 
and thus I thought everything is OK.

Thanks Vladimir for creating the fix.
-jt

On st?eda 4. ??jna 2017 16:05:33 CEST Vladimir Kozlov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8188775
> 
> Changes for 8182701[1] missed changes in default.policy for new module
> jdk.internal.vm.compiler.management.
> 
> Add missing code:
> 
> src/java.base/share/lib/security/default.policy
> @@ -154,6 +154,10 @@
>       permission java.security.AllPermission;
>   };
> 
> +grant codeBase "jrt:/jdk.internal.vm.compiler.management" {
> +    permission java.security.AllPermission;
> +};
> +
>   grant codeBase "jrt:/jdk.jsobject" {
>       permission java.security.AllPermission;
>   };
> 
> Verified with failed test.
> 
> Thanks,
> Vladimir
> 
> [1] http://hg.openjdk.java.net/jdk10/hs/rev/8b2054b7d02c



From mandy.chung at oracle.com  Thu Oct  5 22:24:22 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 5 Oct 2017 15:24:22 -0700
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
Message-ID: <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>

Hi David,

This version only modifies ClassLoader.java and the new test:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.03/

On 10/4/17 11:06 PM, David Holmes wrote:
> Hi Mandy,
>
>>> Overall the changes seem fine, but I do have a concern about the use 
>>> of ConcurrentHashMap. This would seem to be a significant change in 
>>> the initialization order - 
>>
>> ConcurrentHashMap is referenced in ClassLoader but actually not loaded 

I missed the first sentence "I misread the source previously that CHM is 
already loaded at clinit time.? But I figure that ....".?? So I fixed it 
to lazily initialize it when the first native library is loaded.
>
> It was loaded in clinit:
>
> 2689???? private static Map<String, NativeLibrary> systemNativeLibraries
> 2690???????? = new ConcurrentHashMap<>();
>
> which was my concern.

I got that.? Thanks for bringing this up.
>
>> until later.? So it does change the initialization order. ? I now 
>> change the implementation to lazily create CHM.? This saves the 
>> footprint when a class loader does not load any native library.
>
> Okay. But now I'm wondering about whether 
> systemNativeLibraries/nativeLibraries need to be volatile?

It's read for JNI native method binding (ClassLoader::findNative method) 
and therefore I used double-locking idiom instead to avoid any 
performance impact.?? I simplified this further.? The native libraries 
map is created with the loadedLibraryNames lock.

> Just looking in ClassLoader it would seem yes, but if the only paths 
> to loading a library are through Runtime, and those methods are 
> synchronized on the Runtime instance, then everything is serialized 
> anyway. Are there other paths that might allow concurrent access? (If 
> the synchronization in Runtime guarantees only a single library can 
> ever be loaded at a time across all classloaders, then you don't even 
> need the synchronization on the loadedLibraryNames ??).

That's a good point.? This code including the synchronization on 
loadedLibraryNames was written long ago.? I prefer to file a JBS issue 
to study the locking more closely.


>>>
>>> libnativeLibraryTest.c:
>>>
>>> Not sure I see the point in the FindClass("java/lang/ClassLoader") 
>>> as if it fails to find it then surely it already failed to find 
>>> "java/lang/Error" and you'll possibly crash trying to throw.
>>>
>> I agree that should be cleaned up.? I took out 
>> FindClass("java/lang/ClassLoader") case.
>
> So is:
>
> ? 68???? excls = (*env)->FindClass(env, "java/lang/Error");
> ? 69???? if (excls == NULL) {
> ? 70???????? (*env)->FatalError(env, "Error class not found");
> ? 71???? }
>
> just a sanity check that you can in fact load a class?
> ?75???????? (*env)->FatalError(env, "Error class not found");
>
> That's the wrong error message.

Thanks for catching this.? I revised the test and fixed the above.

>
> Okay. Not sure why you needed to introduce q.Bridge - 

I agree it's not needed any more.? Initially I was trying to have a 
method to return a count.? But later modified to a different method.

> I find the test logic rather hard to follow, not clear who calls what 
> method from where and when. I was thinking of a simple
>
> public int loadedCount;
> public int unloadedCount;
>
> that onLoad/OnUnload would increment.
Well the test intends to verify if the native library can be reloaded 
(i.e. it has to be unloaded before reloading; otherwise 
UnsatifisedLinkError will be thrown).?? It has a native count method and 
it would fail if it is not loaded.

I revise the test a little.? p.Test.run() loads the native library. The 
test checks if the native count method returns the correct value (i.e. 
the native library is loaded and OnLoad is invoked).? Calling run() 
again should get ULE since it can't be reloaded if already loaded.

I keep the unloadedCount which is not strictly necessary but it is an 
additional sanity check.? I added more comment and hope it is clearer now.


Mandy

From david.holmes at oracle.com  Fri Oct  6 02:48:43 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Oct 2017 12:48:43 +1000
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
Message-ID: <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>

Hi Mandy,

On 6/10/2017 8:24 AM, mandy chung wrote:
> Hi David,
> 
> This version only modifies ClassLoader.java and the new test:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.03/

This seems mostly fine now - thanks for simplifying and clarifying the 
test operation.

I agree we can look at the overall locking strategy separately.

Regarding the need for volatile to make the double-checked locking 
correct ... I can't quite convince myself that any thread that tries to 
execute a native method and so calls back to findNative from the VM, 
must have already gone through the code that ensured the native library 
maps have been initialized. I think they must, but I can't quite 
convince myself of it. :( Unless you can dispel my doubts I think we 
need to make the fields volatile to be strictly safe.

That said I'm not sure lazy initialization is really worthwhile in the 
first place. Is the CHM creation very costly? Should we be sizing them 
explicitly? (More like the default Vector size used previously?)

Thanks,
David
-----

> On 10/4/17 11:06 PM, David Holmes wrote:
>> Hi Mandy,
>>
>>>> Overall the changes seem fine, but I do have a concern about the use 
>>>> of ConcurrentHashMap. This would seem to be a significant change in 
>>>> the initialization order - 
>>>
>>> ConcurrentHashMap is referenced in ClassLoader but actually not loaded 
> 
> I missed the first sentence "I misread the source previously that CHM is 
> already loaded at clinit time.? But I figure that ....".?? So I fixed it 
> to lazily initialize it when the first native library is loaded.
>>
>> It was loaded in clinit:
>>
>> 2689???? private static Map<String, NativeLibrary> systemNativeLibraries
>> 2690???????? = new ConcurrentHashMap<>();
>>
>> which was my concern.
> 
> I got that.? Thanks for bringing this up.
>>
>>> until later.? So it does change the initialization order. ? I now 
>>> change the implementation to lazily create CHM.? This saves the 
>>> footprint when a class loader does not load any native library.
>>
>> Okay. But now I'm wondering about whether 
>> systemNativeLibraries/nativeLibraries need to be volatile?
> 
> It's read for JNI native method binding (ClassLoader::findNative method) 
> and therefore I used double-locking idiom instead to avoid any 
> performance impact.?? I simplified this further.? The native libraries 
> map is created with the loadedLibraryNames lock.
> 
>> Just looking in ClassLoader it would seem yes, but if the only paths 
>> to loading a library are through Runtime, and those methods are 
>> synchronized on the Runtime instance, then everything is serialized 
>> anyway. Are there other paths that might allow concurrent access? (If 
>> the synchronization in Runtime guarantees only a single library can 
>> ever be loaded at a time across all classloaders, then you don't even 
>> need the synchronization on the loadedLibraryNames ??).
> 
> That's a good point.? This code including the synchronization on 
> loadedLibraryNames was written long ago.? I prefer to file a JBS issue 
> to study the locking more closely.
> 
> 
>>>>
>>>> libnativeLibraryTest.c:
>>>>
>>>> Not sure I see the point in the FindClass("java/lang/ClassLoader") 
>>>> as if it fails to find it then surely it already failed to find 
>>>> "java/lang/Error" and you'll possibly crash trying to throw.
>>>>
>>> I agree that should be cleaned up.? I took out 
>>> FindClass("java/lang/ClassLoader") case.
>>
>> So is:
>>
>> ? 68???? excls = (*env)->FindClass(env, "java/lang/Error");
>> ? 69???? if (excls == NULL) {
>> ? 70???????? (*env)->FatalError(env, "Error class not found");
>> ? 71???? }
>>
>> just a sanity check that you can in fact load a class?
>> ?75???????? (*env)->FatalError(env, "Error class not found");
>>
>> That's the wrong error message.
> 
> Thanks for catching this.? I revised the test and fixed the above.
> 
>>
>> Okay. Not sure why you needed to introduce q.Bridge - 
> 
> I agree it's not needed any more.? Initially I was trying to have a 
> method to return a count.? But later modified to a different method.
> 
>> I find the test logic rather hard to follow, not clear who calls what 
>> method from where and when. I was thinking of a simple
>>
>> public int loadedCount;
>> public int unloadedCount;
>>
>> that onLoad/OnUnload would increment.
> Well the test intends to verify if the native library can be reloaded 
> (i.e. it has to be unloaded before reloading; otherwise 
> UnsatifisedLinkError will be thrown).?? It has a native count method and 
> it would fail if it is not loaded.
> 
> I revise the test a little.? p.Test.run() loads the native library. The 
> test checks if the native count method returns the correct value (i.e. 
> the native library is loaded and OnLoad is invoked).? Calling run() 
> again should get ULE since it can't be reloaded if already loaded.
> 
> I keep the unloadedCount which is not strictly necessary but it is an 
> additional sanity check.? I added more comment and hope it is clearer now.
> 
> 
> Mandy

From OGATAK at jp.ibm.com  Fri Oct  6 10:34:22 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Fri, 6 Oct 2017 19:34:22 +0900
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
Message-ID: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>

Hi all,

Please review a change for JDK-8188858.

Bug report: https://bugs.openjdk.java.net/browse/JDK-8188858
Webrev: http://cr.openjdk.java.net/~horii/8188858/webrev.00/

This change caches the result of latestUserDefinedLoader() when objects 
are deserialized, so the decerializer can avoid redundant stack walking to 
resolve classes of deserializing objects.  This change improved maxjOPS of 
SPECjbb2015 by 6% on a POWER8 machine.


Regards,
Ogata


From matthias.baesken at sap.com  Fri Oct  6 12:24:53 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 6 Oct 2017 12:24:53 +0000
Subject: jdk9/10 reject zip/jar files where seconds value of timestamp is out
 of supported range 0 - 59
Message-ID: <daf3d8ef302944cb8d2c34898b5d87be@sap.com>

Hello,

When iterating on the zip entries (and printing the time stamps)  of an old  sqljdbc.jar    the exception

"java.time.DateTimeException: Invalid value for SecondOfMinute (valid values 0 - 59): 60"
occured (issue has been seen on Windows).

Looks like the  dosToJavaTime function in  ZipUtils.java  of jdk9/jdk10 is a bit more "sensitive"
about the input it gets, compared to jdk8.
In both implementations :

java.base/share/classes/java/util/zip/ZipUtils.java
jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java


the computation of the "seconds" values is done by

public static long dosToJavaTime(long dtime) {
...
(int) ((dtime << 1) & 0x3e));
...
}

0x3e is  binary 111110 or  decimal 62,  so larger values than the supported maximum 59 can occur
(maybe only with old/problematic archives but still we had such an example).

When looking a bit more closely into it, we found that the "second = 60" value  was coming from a  long value  930973758
that was passed to  ZipUtils.dosToJavaTime as  dtime argument.

(found this out by adding an enhanced chained exception to jdk9 showing the dtime value passed to dosToJavaTime).

Here is an example of the iteration on entries of such a "bad" zip file :

C:\JVM\openjdk10\bin\java  ZipIterate

Iterate von ZipFile:
--------------------------------------
name of ZipEntry:com/microsoft/sqlserver/jdbc/AppDTVImpl$SetValueOp.class
Exception in thread "main" java.time.DateTimeException: Invalid value for SecondOfMinute (valid values 0 - 59): 60
        at java.base/java.time.temporal.ValueRange.checkValidValue(ValueRange.java:311)
        at java.base/java.time.temporal.ChronoField.checkValidValue(ChronoField.java:714)
        at java.base/java.time.LocalTime.of(LocalTime.java:322)
        at java.base/java.time.LocalDateTime.of(LocalDateTime.java:337)
        at java.base/java.util.zip.ZipUtils.dosToJavaTime(ZipUtils.java:101)
        at java.base/java.util.zip.ZipUtils.extendedDosToJavaTime(ZipUtils.java:114)
        at java.base/java.util.zip.ZipEntry.getTime(ZipEntry.java:198)
        at ZipIterate.main(ZipIterate.java:37)



A similar problem (dealing with days/months not seconds out of supported range) is described here :
https://bugs.openjdk.java.net/browse/JDK-8184940
"JDK 9 rejects zip files where the modified day or month is 0"


Compared to jdk8,  this is a regression so I think it would be good to have a better handling of problematic out of range seconds-values.

Do you think it would be sufficient to adjust the out of range seconds to the supported max-value 59 ?
Or is something more sophisticated prefered ?
I found the enhanced chained exception showing the  dtime long values helpful too, should I submit it ?

Best regards,
            Matthias

From claes.redestad at oracle.com  Fri Oct  6 14:02:19 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 6 Oct 2017 16:02:19 +0200
Subject: jdk9/10 reject zip/jar files where seconds value of timestamp is
 out of supported range 0 - 59
In-Reply-To: <daf3d8ef302944cb8d2c34898b5d87be@sap.com>
References: <daf3d8ef302944cb8d2c34898b5d87be@sap.com>
Message-ID: <e915d444-5f5f-0b88-649c-ef3c567d346c@oracle.com>

Hi,

it appears this is a difference where java.util.Date is carrying the 
overflow(s), while the
java.time-based implementation is more strict.? Same issue assumedly 
exist for most
fields in the dos format (minutes can be 0-63, hours 0-31, days 0-31...).

The dosToJavaTime implementation was changed to use java.time mostly as 
a cleanup
(https://bugs.openjdk.java.net/browse/JDK-8066644), but this difference 
in strictness was
overlooked..

Most compelling option for now might be to revert to the code in 8:

 ??? public static long dosToJavaTime8(long dtime) {
 ??????? @SuppressWarnings("deprecation") // Use of date constructor.
 ??????? Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
 ????????????????????????? (int)(((dtime >> 21) & 0x0f) - 1),
 ????????????????????????? (int)((dtime >> 16) & 0x1f),
 ????????????????????????? (int)((dtime >> 11) & 0x1f),
 ????????????????????????? (int)((dtime >> 5) & 0x3f),
 ????????????????????????? (int)((dtime << 1) & 0x3e));
 ??????? return d.getTime();
 ??? }

/Claes

On 2017-10-06 14:24, Baesken, Matthias wrote:
> Hello,
>
> When iterating on the zip entries (and printing the time stamps)  of an old  sqljdbc.jar    the exception
>
> "java.time.DateTimeException: Invalid value for SecondOfMinute (valid values 0 - 59): 60"
> occured (issue has been seen on Windows).
>
> Looks like the  dosToJavaTime function in  ZipUtils.java  of jdk9/jdk10 is a bit more "sensitive"
> about the input it gets, compared to jdk8.
> In both implementations :
>
> java.base/share/classes/java/util/zip/ZipUtils.java
> jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java
>
>
> the computation of the "seconds" values is done by
>
> public static long dosToJavaTime(long dtime) {
> ...
> (int) ((dtime << 1) & 0x3e));
> ...
> }
>
> 0x3e is  binary 111110 or  decimal 62,  so larger values than the supported maximum 59 can occur
> (maybe only with old/problematic archives but still we had such an example).
>
> When looking a bit more closely into it, we found that the "second = 60" value  was coming from a  long value  930973758
> that was passed to  ZipUtils.dosToJavaTime as  dtime argument.
>
> (found this out by adding an enhanced chained exception to jdk9 showing the dtime value passed to dosToJavaTime).
>
> Here is an example of the iteration on entries of such a "bad" zip file :
>
> C:\JVM\openjdk10\bin\java  ZipIterate
>
> Iterate von ZipFile:
> --------------------------------------
> name of ZipEntry:com/microsoft/sqlserver/jdbc/AppDTVImpl$SetValueOp.class
> Exception in thread "main" java.time.DateTimeException: Invalid value for SecondOfMinute (valid values 0 - 59): 60
>          at java.base/java.time.temporal.ValueRange.checkValidValue(ValueRange.java:311)
>          at java.base/java.time.temporal.ChronoField.checkValidValue(ChronoField.java:714)
>          at java.base/java.time.LocalTime.of(LocalTime.java:322)
>          at java.base/java.time.LocalDateTime.of(LocalDateTime.java:337)
>          at java.base/java.util.zip.ZipUtils.dosToJavaTime(ZipUtils.java:101)
>          at java.base/java.util.zip.ZipUtils.extendedDosToJavaTime(ZipUtils.java:114)
>          at java.base/java.util.zip.ZipEntry.getTime(ZipEntry.java:198)
>          at ZipIterate.main(ZipIterate.java:37)
>
>
>
> A similar problem (dealing with days/months not seconds out of supported range) is described here :
> https://bugs.openjdk.java.net/browse/JDK-8184940
> "JDK 9 rejects zip files where the modified day or month is 0"
>
>
> Compared to jdk8,  this is a regression so I think it would be good to have a better handling of problematic out of range seconds-values.
>
> Do you think it would be sufficient to adjust the out of range seconds to the supported max-value 59 ?
> Or is something more sophisticated prefered ?
> I found the enhanced chained exception showing the  dtime long values helpful too, should I submit it ?
>
> Best regards,
>              Matthias


From xueming.shen at oracle.com  Fri Oct  6 14:55:05 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 06 Oct 2017 07:55:05 -0700
Subject: jdk9/10 reject zip/jar files where seconds value of timestamp
 is out of supported range 0 - 59
In-Reply-To: <e915d444-5f5f-0b88-649c-ef3c567d346c@oracle.com>
References: <daf3d8ef302944cb8d2c34898b5d87be@sap.com>
 <e915d444-5f5f-0b88-649c-ef3c567d346c@oracle.com>
Message-ID: <59D79949.80602@oracle.com>

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

really wanted to suggest to just unzip/jar & jar those jar files again, 
as a workaround ...

-sherman

On 10/6/17, 7:02 AM, Claes Redestad wrote:
> Hi,
>
> it appears this is a difference where java.util.Date is carrying the 
> overflow(s), while the
> java.time-based implementation is more strict.  Same issue assumedly 
> exist for most
> fields in the dos format (minutes can be 0-63, hours 0-31, days 0-31...).
>
> The dosToJavaTime implementation was changed to use java.time mostly 
> as a cleanup
> (https://bugs.openjdk.java.net/browse/JDK-8066644), but this 
> difference in strictness was
> overlooked..
>
> Most compelling option for now might be to revert to the code in 8:
>
>     public static long dosToJavaTime8(long dtime) {
>         @SuppressWarnings("deprecation") // Use of date constructor.
>         Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
>                           (int)(((dtime >> 21) & 0x0f) - 1),
>                           (int)((dtime >> 16) & 0x1f),
>                           (int)((dtime >> 11) & 0x1f),
>                           (int)((dtime >> 5) & 0x3f),
>                           (int)((dtime << 1) & 0x3e));
>         return d.getTime();
>     }
>
> /Claes
>
> On 2017-10-06 14:24, Baesken, Matthias wrote:
>> Hello,
>>
>> When iterating on the zip entries (and printing the time stamps)  of 
>> an old  sqljdbc.jar    the exception
>>
>> "java.time.DateTimeException: Invalid value for SecondOfMinute (valid 
>> values 0 - 59): 60"
>> occured (issue has been seen on Windows).
>>
>> Looks like the  dosToJavaTime function in  ZipUtils.java  of 
>> jdk9/jdk10 is a bit more "sensitive"
>> about the input it gets, compared to jdk8.
>> In both implementations :
>>
>> java.base/share/classes/java/util/zip/ZipUtils.java
>> jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java
>>
>>
>> the computation of the "seconds" values is done by
>>
>> public static long dosToJavaTime(long dtime) {
>> ...
>> (int) ((dtime << 1) & 0x3e));
>> ...
>> }
>>
>> 0x3e is  binary 111110 or  decimal 62,  so larger values than the 
>> supported maximum 59 can occur
>> (maybe only with old/problematic archives but still we had such an 
>> example).
>>
>> When looking a bit more closely into it, we found that the "second = 
>> 60" value  was coming from a  long value  930973758
>> that was passed to  ZipUtils.dosToJavaTime as  dtime argument.
>>
>> (found this out by adding an enhanced chained exception to jdk9 
>> showing the dtime value passed to dosToJavaTime).
>>
>> Here is an example of the iteration on entries of such a "bad" zip 
>> file :
>>
>> C:\JVM\openjdk10\bin\java  ZipIterate
>>
>> Iterate von ZipFile:
>> --------------------------------------
>> name of 
>> ZipEntry:com/microsoft/sqlserver/jdbc/AppDTVImpl$SetValueOp.class
>> Exception in thread "main" java.time.DateTimeException: Invalid value 
>> for SecondOfMinute (valid values 0 - 59): 60
>>          at 
>> java.base/java.time.temporal.ValueRange.checkValidValue(ValueRange.java:311)
>>          at 
>> java.base/java.time.temporal.ChronoField.checkValidValue(ChronoField.java:714)
>>          at java.base/java.time.LocalTime.of(LocalTime.java:322)
>>          at java.base/java.time.LocalDateTime.of(LocalDateTime.java:337)
>>          at 
>> java.base/java.util.zip.ZipUtils.dosToJavaTime(ZipUtils.java:101)
>>          at 
>> java.base/java.util.zip.ZipUtils.extendedDosToJavaTime(ZipUtils.java:114)
>>          at java.base/java.util.zip.ZipEntry.getTime(ZipEntry.java:198)
>>          at ZipIterate.main(ZipIterate.java:37)
>>
>>
>>
>> A similar problem (dealing with days/months not seconds out of 
>> supported range) is described here :
>> https://bugs.openjdk.java.net/browse/JDK-8184940
>> "JDK 9 rejects zip files where the modified day or month is 0"
>>
>>
>> Compared to jdk8,  this is a regression so I think it would be good 
>> to have a better handling of problematic out of range seconds-values.
>>
>> Do you think it would be sufficient to adjust the out of range 
>> seconds to the supported max-value 59 ?
>> Or is something more sophisticated prefered ?
>> I found the enhanced chained exception showing the  dtime long values 
>> helpful too, should I submit it ?
>>
>> Best regards,
>>              Matthias
>


From mandy.chung at oracle.com  Fri Oct  6 19:37:55 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 6 Oct 2017 12:37:55 -0700
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
 <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
Message-ID: <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>

Hi David,

Thanks for raising the lazy initialization issue.? The recent version of 
ClassLoader.java in webrev.03 is uploaded in place:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.03/

The native libraries map is now created lazily with synchronization.??? 
I keep the lazy initialization that will save to create a CHM as many 
custom class loaders don't have native code.? I think it's a good 
saving.?? In addition, if we iniitialize the static 
systemNativeLibraries at <clinit> time, it may want to avoid using CHM 
as it changes the class initialization order.

thanks
Mandy

From ioi.lam at oracle.com  Fri Oct  6 20:19:20 2017
From: ioi.lam at oracle.com (Ioi Lam)
Date: Fri, 6 Oct 2017 13:19:20 -0700
Subject: RFR (XS) 8188828 Intermittent ClassNotFoundException:
 jdk.test.lib.Platform for compiler tests
Message-ID: <1be927fa-fa4b-1964-93f3-1c72386acf7b@oracle.com>

Please review this very simple change:

https://bugs.openjdk.java.net/browse/JDK-8188828
http://ioilinux.us.oracle.com/webrev/jdk10/8188828_compiler_test_class_not_found.v01/

The dependency of

 ??? FileInstaller -> Utils -> JDKToolLauncher -> Platform

has caused many intermittent ClassNotFoundException in the hotspot 
nightly runs.
While this fix does not address the root cause (proper dependencies are not
specified in the test cases -- which we are planning to fix), we will 
hopefully
see much fewer occurrences of this annoying failure scenario.

Thanks a lot to Igor for suggesting the simple fix!

- Ioi


From igor.ignatyev at oracle.com  Fri Oct  6 20:28:58 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 6 Oct 2017 13:28:58 -0700
Subject: RFR (XS) 8188828 Intermittent ClassNotFoundException:
 jdk.test.lib.Platform for compiler tests
In-Reply-To: <1be927fa-fa4b-1964-93f3-1c72386acf7b@oracle.com>
References: <1be927fa-fa4b-1964-93f3-1c72386acf7b@oracle.com>
Message-ID: <56725166-18B0-47B4-A8FB-DED8B149604D@oracle.com>

Hi Ioi,

I'm really happy we found such a simple workaround for this annoying problem and hope it'll greatly reduce CNFE in our test runs.  

the fix looks good to me.

Thanks,
-- Igor

> On Oct 6, 2017, at 1:19 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> Please review this very simple change:
> 
> https://bugs.openjdk.java.net/browse/JDK-8188828
> http://ioilinux.us.oracle.com/webrev/jdk10/8188828_compiler_test_class_not_found.v01/
> 
> The dependency of
> 
>     FileInstaller -> Utils -> JDKToolLauncher -> Platform
> 
> has caused many intermittent ClassNotFoundException in the hotspot nightly runs.
> While this fix does not address the root cause (proper dependencies are not
> specified in the test cases -- which we are planning to fix), we will hopefully
> see much fewer occurrences of this annoying failure scenario.
> 
> Thanks a lot to Igor for suggesting the simple fix!
> 
> - Ioi
> 


From vladimir.kozlov at oracle.com  Fri Oct  6 23:35:30 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 6 Oct 2017 16:35:30 -0700
Subject: RFR (XS) 8188828 Intermittent ClassNotFoundException:
 jdk.test.lib.Platform for compiler tests
In-Reply-To: <56725166-18B0-47B4-A8FB-DED8B149604D@oracle.com>
References: <1be927fa-fa4b-1964-93f3-1c72386acf7b@oracle.com>
 <56725166-18B0-47B4-A8FB-DED8B149604D@oracle.com>
Message-ID: <e760f913-4aa4-bea3-74e4-755db67423fd@oracle.com>

Looks good.

Thanks,
Vladimir

On 10/6/17 1:28 PM, Igor Ignatyev wrote:
> Hi Ioi,
> 
> I'm really happy we found such a simple workaround for this annoying problem and hope it'll greatly reduce CNFE in our test runs.
> 
> the fix looks good to me.
> 
> Thanks,
> -- Igor
> 
>> On Oct 6, 2017, at 1:19 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
>>
>> Please review this very simple change:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8188828
>> http://ioilinux.us.oracle.com/webrev/jdk10/8188828_compiler_test_class_not_found.v01/
>>
>> The dependency of
>>
>>      FileInstaller -> Utils -> JDKToolLauncher -> Platform
>>
>> has caused many intermittent ClassNotFoundException in the hotspot nightly runs.
>> While this fix does not address the root cause (proper dependencies are not
>> specified in the test cases -- which we are planning to fix), we will hopefully
>> see much fewer occurrences of this annoying failure scenario.
>>
>> Thanks a lot to Igor for suggesting the simple fix!
>>
>> - Ioi
>>
> 

From david.holmes at oracle.com  Mon Oct  9 01:14:40 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Oct 2017 11:14:40 +1000
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
 <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
 <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
Message-ID: <fa754475-972f-3d78-fa25-5fe85bceed6a@oracle.com>

Hi Mandy,

This all looks fine to me now.

Thanks,
David

On 7/10/2017 5:37 AM, mandy chung wrote:
> Hi David,
> 
> Thanks for raising the lazy initialization issue.? The recent version of 
> ClassLoader.java in webrev.03 is uploaded in place:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.03/
> 
> The native libraries map is now created lazily with synchronization. I 
> keep the lazy initialization that will save to create a CHM as many 
> custom class loaders don't have native code.? I think it's a good 
> saving.?? In addition, if we iniitialize the static 
> systemNativeLibraries at <clinit> time, it may want to avoid using CHM 
> as it changes the class initialization order.
> 
> thanks
> Mandy

From zheng.jun.li at oracle.com  Mon Oct  9 01:22:14 2017
From: zheng.jun.li at oracle.com (Jack Li)
Date: Mon, 9 Oct 2017 09:22:14 +0800
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
 <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
Message-ID: <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>

Hi Lance,

the change is incorrect, it should be ?javax/xml/bind?.
thanks a lot for your finding, do you think I need to fix it and resubmit the webrev this time?
or can you skip this file this time and I fix it in next integration?

> On Oct 4, 2017, at 02:09, Lance Andersen <Lance.Andersen at oracle.com> wrote:
> 
> Hi Jack,
> 
> Is this change correct:
> 
> -------------
> --- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
> +++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
> @@ -373,7 +373,7 @@
>       *      If the {@link ValidationEventHandler ValidationEventHandler}
>       *      returns false from its {@code handleEvent} method or the
>       *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
> -     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
> +     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
>       *      Marshalling a JAXB element</a>.
> 
> ------------
> 
> The URL that is being changed currently works
> 
> Best
> Lance
> On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
> 
>> Hi,
>> 
>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>>
>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>>
>> 
>> Summary of changes:
>> 
>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>> 
>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>> 
>> 
>> Patch also contains several small bugfixes, not tracked in JBS.
>> 
>> ----------------
>> Best regards
>> Jack Li
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> <oracle_sig_logo.gif>
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering?
> 1 Network Drive?
> Burlington, MA 01803
>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>

----------------
Best regards
Jack Li







From david.holmes at oracle.com  Mon Oct  9 01:33:57 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Oct 2017 11:33:57 +1000
Subject: RFR (XS) 8188828 Intermittent ClassNotFoundException:
 jdk.test.lib.Platform for compiler tests
In-Reply-To: <1be927fa-fa4b-1964-93f3-1c72386acf7b@oracle.com>
References: <1be927fa-fa4b-1964-93f3-1c72386acf7b@oracle.com>
Message-ID: <4dea8e6c-34fc-83b6-8fe3-2905ec15b72b@oracle.com>

Hi Ioi,

This seems like a temporary workaround - fine for now - but what is the 
real fix here? It's crazy that one test library class can't use another 
class from the same test library!

Thanks,
David

On 7/10/2017 6:19 AM, Ioi Lam wrote:
> Please review this very simple change:
> 
> https://bugs.openjdk.java.net/browse/JDK-8188828
> http://ioilinux.us.oracle.com/webrev/jdk10/8188828_compiler_test_class_not_found.v01/ 
> 
> 
> The dependency of
> 
>  ??? FileInstaller -> Utils -> JDKToolLauncher -> Platform
> 
> has caused many intermittent ClassNotFoundException in the hotspot 
> nightly runs.
> While this fix does not address the root cause (proper dependencies are not
> specified in the test cases -- which we are planning to fix), we will 
> hopefully
> see much fewer occurrences of this annoying failure scenario.
> 
> Thanks a lot to Igor for suggesting the simple fix!
> 
> - Ioi
> 

From frank.yuan at oracle.com  Mon Oct  9 06:48:15 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Mon, 9 Oct 2017 14:48:15 +0800
Subject: [10] [testbug] RFR of JDK-8187700 SetAuthenticator tests should
 handle the proxy port
In-Reply-To: <011801d33835$0f245da0$2d6d18e0$@oracle.com>
References: <011801d33835$0f245da0$2d6d18e0$@oracle.com>
Message-ID: <031001d340ca$96bf7ea0$c43e7be0$@oracle.com>

Hi Daniel and all

 

Would you like to have a look on this review? It's the same issue as JDK-8188086 but in SetAuthenticator tests. The fix's verified
by running the test in loop.

 

Thanks

Frank

 

 

From: Frank Yuan [mailto:frank.yuan at oracle.com] 
Subject: [10] [testbug] RFR of JDK-8187700 SetAuthenticator tests should handle the proxy port

 

Hi Daniel and all

 

Would you like to review http://cr.openjdk.java.net/~fyuan/8187700/webrev.00/?

Bug: https://bugs.openjdk.java.net/browse/JDK-8187700

 

I applied the fix for proxy port reusing issue, which was reviewed in bug JDK-8187507. And made a few code cleaning in
HTTPSetAuthenticatorTest.java

 

Thanks

Frank


From matthias.baesken at sap.com  Mon Oct  9 07:49:02 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 9 Oct 2017 07:49:02 +0000
Subject: jdk9/10 reject zip/jar files where seconds value of timestamp is
 out of supported range 0 - 59
Message-ID: <370c795a79fc4273a3181279a7cbfb50@sap.com>

Hi Claes, thanks for your feedback.

Hello, 
     I opened a bug :  JDK-8188901   jdk9/10 reject zip/jar files where seconds value of timestamp is out of supported range 0 - 59

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

In case  the dosToJavaTime change  was  to use java.time  was really just a cleanup,
 I would  like to submit a change and go back  to  Date, is that  ok ?

The  suggested workaround by  Xueming Shen

>really wanted to suggest to just unzip/jar & jar those jar files again, 
>as a workaround ...

Is a good idea for some people,  however in complex sceanarios  people do not even currently get  the name of the archive in the exception  .
So it is an issue to identify what to unpack/pack for them .
Another issue might be the usage of signed archives .



Best regards, 
                Matthias


> 
> Message: 2
> Date: Fri, 6 Oct 2017 16:02:19 +0200
> From: Claes Redestad <claes.redestad at oracle.com>
> To: core-libs-dev at openjdk.java.net
> Subject: Re: jdk9/10 reject zip/jar files where seconds value of
> 	timestamp is out of supported range 0 - 59
> Message-ID: <e915d444-5f5f-0b88-649c-ef3c567d346c at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hi,
> 
> it appears this is a difference where java.util.Date is carrying the
> overflow(s), while the
> java.time-based implementation is more strict.? Same issue assumedly
> exist for most
> fields in the dos format (minutes can be 0-63, hours 0-31, days 0-31...).
> 
> The dosToJavaTime implementation was changed to use java.time mostly as
> a cleanup
> (https://bugs.openjdk.java.net/browse/JDK-8066644), but this difference
> in strictness was
> overlooked..
> 
> Most compelling option for now might be to revert to the code in 8:
> 
>  ??? public static long dosToJavaTime8(long dtime) {
>  ??????? @SuppressWarnings("deprecation") // Use of date constructor.
>  ??????? Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
>  ????????????????????????? (int)(((dtime >> 21) & 0x0f) - 1),
>  ????????????????????????? (int)((dtime >> 16) & 0x1f),
>  ????????????????????????? (int)((dtime >> 11) & 0x1f),
>  ????????????????????????? (int)((dtime >> 5) & 0x3f),
>  ????????????????????????? (int)((dtime << 1) & 0x3e));
>  ??????? return d.getTime();
>  ??? }
> 
> /Claes
> 
> On 2017-10-06 14:24, Baesken, Matthias wrote:
> > Hello,
> >
> > When iterating on the zip entries (and printing the time stamps)  of an old
> sqljdbc.jar    the exception
> >
> > "java.time.DateTimeException: Invalid value for SecondOfMinute (valid
> values 0 - 59): 60"
> > occured (issue has been seen on Windows).
> >
> > Looks like the  dosToJavaTime function in  ZipUtils.java  of jdk9/jdk10 is a bit
> more "sensitive"
> > about the input it gets, compared to jdk8.
> > In both implementations :
> >
> > java.base/share/classes/java/util/zip/ZipUtils.java
> > jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java
> >
> >
> > the computation of the "seconds" values is done by
> >
> > public static long dosToJavaTime(long dtime) {
> > ...
> > (int) ((dtime << 1) & 0x3e));
> > ...
> > }
> >
> > 0x3e is  binary 111110 or  decimal 62,  so larger values than the supported
> maximum 59 can occur
> > (maybe only with old/problematic archives but still we had such an
> example).
> >
> > When looking a bit more closely into it, we found that the "second = 60"
> value  was coming from a  long value  930973758
> > that was passed to  ZipUtils.dosToJavaTime as  dtime argument.
> >
> > (found this out by adding an enhanced chained exception to jdk9 showing
> the dtime value passed to dosToJavaTime).
> >
> > Here is an example of the iteration on entries of such a "bad" zip file :
> >
> > C:\JVM\openjdk10\bin\java  ZipIterate
> >
> > Iterate von ZipFile:
> > --------------------------------------
> > name of
> ZipEntry:com/microsoft/sqlserver/jdbc/AppDTVImpl$SetValueOp.class
> > Exception in thread "main" java.time.DateTimeException: Invalid value for
> SecondOfMinute (valid values 0 - 59): 60
> >          at
> java.base/java.time.temporal.ValueRange.checkValidValue(ValueRange.java
> :311)
> >          at
> java.base/java.time.temporal.ChronoField.checkValidValue(ChronoField.jav
> a:714)
> >          at java.base/java.time.LocalTime.of(LocalTime.java:322)
> >          at java.base/java.time.LocalDateTime.of(LocalDateTime.java:337)
> >          at java.base/java.util.zip.ZipUtils.dosToJavaTime(ZipUtils.java:101)
> >          at
> java.base/java.util.zip.ZipUtils.extendedDosToJavaTime(ZipUtils.java:114)
> >          at java.base/java.util.zip.ZipEntry.getTime(ZipEntry.java:198)
> >          at ZipIterate.main(ZipIterate.java:37)
> >
> >
> >
> > A similar problem (dealing with days/months not seconds out of supported
> range) is described here :
> > https://bugs.openjdk.java.net/browse/JDK-8184940
> > "JDK 9 rejects zip files where the modified day or month is 0"
> >
> >
> > Compared to jdk8,  this is a regression so I think it would be good to have a
> better handling of problematic out of range seconds-values.
> >
> > Do you think it would be sufficient to adjust the out of range seconds to
> the supported max-value 59 ?
> > Or is something more sophisticated prefered ?
> > I found the enhanced chained exception showing the  dtime long values
> helpful too, should I submit it ?
> >
> > Best regards,
> >              Matthias
> 
> 
> 

From Alan.Bateman at oracle.com  Mon Oct  9 07:55:49 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 9 Oct 2017 08:55:49 +0100
Subject: [10] RFR(S) 8188775: Module jdk.internal.vm.compiler.management
 has not been granted accessClassInPackage.org.graalvm.compiler.hotspot
In-Reply-To: <a374f47d-c4a5-0fb4-8674-dba65624532f@oracle.com>
References: <a374f47d-c4a5-0fb4-8674-dba65624532f@oracle.com>
Message-ID: <b21ce89d-dd4d-2dec-d3ba-6e157718d929@oracle.com>

On 05/10/2017 00:05, Vladimir Kozlov wrote:
> https://bugs.openjdk.java.net/browse/JDK-8188775
>
> Changes for 8182701[1] missed changes in default.policy for new module 
> jdk.internal.vm.compiler.management.
>
> Add missing code:
>
> src/java.base/share/lib/security/default.policy
> @@ -154,6 +154,10 @@
> ???? permission java.security.AllPermission;
> ?};
>
> +grant codeBase "jrt:/jdk.internal.vm.compiler.management" {
> +??? permission java.security.AllPermission;
> +};
> +
This looks okay to me although it would be nice if we could identify the 
minimal permissions rather than granting it AllPermission.

-Alan

From Alan.Bateman at oracle.com  Mon Oct  9 08:20:46 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 9 Oct 2017 09:20:46 +0100
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
 <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
 <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
Message-ID: <b73b681e-efd7-edaa-9c92-9da2f63de847@oracle.com>

On 06/10/2017 20:37, mandy chung wrote:
> :
>
> The native libraries map is now created lazily with 
> synchronization.??? I keep the lazy initialization that will save to 
> create a CHM as many custom class loaders don't have native code.? I 
> think it's a good saving.?? In addition, if we iniitialize the static 
> systemNativeLibraries at <clinit> time, it may want to avoid using CHM 
> as it changes the class initialization order.
>
Alternatively change nativeLibraries and systemNativeLibraries to 
volatile so the synchronization is only needed to initialize them. 
Otherwise this version (webrev.03) looks good to me.

-Alan

From daniel.fuchs at oracle.com  Mon Oct  9 09:22:12 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 9 Oct 2017 10:22:12 +0100
Subject: [10] [testbug] RFR of JDK-8187700 SetAuthenticator tests should
 handle the proxy port
In-Reply-To: <011301d33835$0e0929a0$2a1b7ce0$@oracle.com>
References: <011301d33835$0e0929a0$2a1b7ce0$@oracle.com>
Message-ID: <69e49b60-4f4e-c17b-1803-7149cf441acc@oracle.com>

Hi Frank,

This looks good to me.

best regards,

-- daniel

On 28/09/2017 09:37, Frank Yuan wrote:
> Hi Daniel and all
> 
> Would you like to review 
> http://cr.openjdk.java.net/~fyuan/8187700/webrev.00/?
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187700
> 
> I applied the fix for proxy port reusing issue, which was reviewed in 
> bug JDK-8187507. And made a few code cleaning in 
> HTTPSetAuthenticatorTest.java
> 
> Thanks
> 
> Frank
> 


From frank.yuan at oracle.com  Mon Oct  9 09:47:34 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Mon, 9 Oct 2017 17:47:34 +0800
Subject: [10] [testbug] RFR of JDK-8187700 SetAuthenticator tests should
 handle the proxy port
In-Reply-To: <69e49b60-4f4e-c17b-1803-7149cf441acc@oracle.com>
References: <011301d33835$0e0929a0$2a1b7ce0$@oracle.com>
 <69e49b60-4f4e-c17b-1803-7149cf441acc@oracle.com>
Message-ID: <039401d340e3$a4c2a590$ee47f0b0$@oracle.com>

Hi Daniel

Thank you very much! I pushed it.

Frank

-----Original Message-----
From: Daniel Fuchs [mailto:daniel.fuchs at oracle.com] 
Subject: Re: [10] [testbug] RFR of JDK-8187700 SetAuthenticator tests should handle the proxy port

Hi Frank,

This looks good to me.

best regards,

-- daniel

On 28/09/2017 09:37, Frank Yuan wrote:
> Hi Daniel and all
> 
> Would you like to review 
> http://cr.openjdk.java.net/~fyuan/8187700/webrev.00/?
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187700
> 
> I applied the fix for proxy port reusing issue, which was reviewed in 
> bug JDK-8187507. And made a few code cleaning in 
> HTTPSetAuthenticatorTest.java
> 
> Thanks
> 
> Frank
> 



From christoph.langer at sap.com  Mon Oct  9 09:52:01 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 9 Oct 2017 09:52:01 +0000
Subject: jdk9/10 reject zip/jar files where seconds value of timestamp is
 out of supported range 0 - 59
In-Reply-To: <370c795a79fc4273a3181279a7cbfb50@sap.com>
References: <370c795a79fc4273a3181279a7cbfb50@sap.com>
Message-ID: <ae0a3eede2f74ec3bd107e0f30869f31@sap.com>

Hi Matthias,

I have closed your bug JDK-8188901 in favor of the bug that Sherman had opened before: https://bugs.openjdk.java.net/browse/JDK-8188869.

Please post a webrev for the change as suggested by Claes.

Thanks & Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> Behalf Of Baesken, Matthias
> Sent: Montag, 9. Oktober 2017 09:49
> To: core-libs-dev at openjdk.java.net
> Subject: RE: jdk9/10 reject zip/jar files where seconds value of timestamp is
> out of supported range 0 - 59
> 
> Hi Claes, thanks for your feedback.
> 
> Hello,
>      I opened a bug :  JDK-8188901   jdk9/10 reject zip/jar files where seconds
> value of timestamp is out of supported range 0 - 59
> 
> https://bugs.openjdk.java.net/browse/JDK-8188901
> 
> In case  the dosToJavaTime change  was  to use java.time  was really just a
> cleanup,
>  I would  like to submit a change and go back  to  Date, is that  ok ?
> 
> The  suggested workaround by  Xueming Shen
> 
> >really wanted to suggest to just unzip/jar & jar those jar files again,
> >as a workaround ...
> 
> Is a good idea for some people,  however in complex sceanarios  people do
> not even currently get  the name of the archive in the exception  .
> So it is an issue to identify what to unpack/pack for them .
> Another issue might be the usage of signed archives .
> 
> 
> 
> Best regards,
>                 Matthias
> 
> 
> >
> > Message: 2
> > Date: Fri, 6 Oct 2017 16:02:19 +0200
> > From: Claes Redestad <claes.redestad at oracle.com>
> > To: core-libs-dev at openjdk.java.net
> > Subject: Re: jdk9/10 reject zip/jar files where seconds value of
> > 	timestamp is out of supported range 0 - 59
> > Message-ID: <e915d444-5f5f-0b88-649c-ef3c567d346c at oracle.com>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > Hi,
> >
> > it appears this is a difference where java.util.Date is carrying the
> > overflow(s), while the
> > java.time-based implementation is more strict.? Same issue assumedly
> > exist for most
> > fields in the dos format (minutes can be 0-63, hours 0-31, days 0-31...).
> >
> > The dosToJavaTime implementation was changed to use java.time mostly
> as
> > a cleanup
> > (https://bugs.openjdk.java.net/browse/JDK-8066644), but this difference
> > in strictness was
> > overlooked..
> >
> > Most compelling option for now might be to revert to the code in 8:
> >
> >  ??? public static long dosToJavaTime8(long dtime) {
> >  ??????? @SuppressWarnings("deprecation") // Use of date constructor.
> >  ??????? Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
> >  ????????????????????????? (int)(((dtime >> 21) & 0x0f) - 1),
> >  ????????????????????????? (int)((dtime >> 16) & 0x1f),
> >  ????????????????????????? (int)((dtime >> 11) & 0x1f),
> >  ????????????????????????? (int)((dtime >> 5) & 0x3f),
> >  ????????????????????????? (int)((dtime << 1) & 0x3e));
> >  ??????? return d.getTime();
> >  ??? }
> >
> > /Claes
> >
> > On 2017-10-06 14:24, Baesken, Matthias wrote:
> > > Hello,
> > >
> > > When iterating on the zip entries (and printing the time stamps)  of an old
> > sqljdbc.jar    the exception
> > >
> > > "java.time.DateTimeException: Invalid value for SecondOfMinute (valid
> > values 0 - 59): 60"
> > > occured (issue has been seen on Windows).
> > >
> > > Looks like the  dosToJavaTime function in  ZipUtils.java  of jdk9/jdk10 is a
> bit
> > more "sensitive"
> > > about the input it gets, compared to jdk8.
> > > In both implementations :
> > >
> > > java.base/share/classes/java/util/zip/ZipUtils.java
> > > jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java
> > >
> > >
> > > the computation of the "seconds" values is done by
> > >
> > > public static long dosToJavaTime(long dtime) {
> > > ...
> > > (int) ((dtime << 1) & 0x3e));
> > > ...
> > > }
> > >
> > > 0x3e is  binary 111110 or  decimal 62,  so larger values than the supported
> > maximum 59 can occur
> > > (maybe only with old/problematic archives but still we had such an
> > example).
> > >
> > > When looking a bit more closely into it, we found that the "second = 60"
> > value  was coming from a  long value  930973758
> > > that was passed to  ZipUtils.dosToJavaTime as  dtime argument.
> > >
> > > (found this out by adding an enhanced chained exception to jdk9
> showing
> > the dtime value passed to dosToJavaTime).
> > >
> > > Here is an example of the iteration on entries of such a "bad" zip file :
> > >
> > > C:\JVM\openjdk10\bin\java  ZipIterate
> > >
> > > Iterate von ZipFile:
> > > --------------------------------------
> > > name of
> > ZipEntry:com/microsoft/sqlserver/jdbc/AppDTVImpl$SetValueOp.class
> > > Exception in thread "main" java.time.DateTimeException: Invalid value
> for
> > SecondOfMinute (valid values 0 - 59): 60
> > >          at
> >
> java.base/java.time.temporal.ValueRange.checkValidValue(ValueRange.java
> > :311)
> > >          at
> >
> java.base/java.time.temporal.ChronoField.checkValidValue(ChronoField.jav
> > a:714)
> > >          at java.base/java.time.LocalTime.of(LocalTime.java:322)
> > >          at java.base/java.time.LocalDateTime.of(LocalDateTime.java:337)
> > >          at java.base/java.util.zip.ZipUtils.dosToJavaTime(ZipUtils.java:101)
> > >          at
> > java.base/java.util.zip.ZipUtils.extendedDosToJavaTime(ZipUtils.java:114)
> > >          at java.base/java.util.zip.ZipEntry.getTime(ZipEntry.java:198)
> > >          at ZipIterate.main(ZipIterate.java:37)
> > >
> > >
> > >
> > > A similar problem (dealing with days/months not seconds out of
> supported
> > range) is described here :
> > > https://bugs.openjdk.java.net/browse/JDK-8184940
> > > "JDK 9 rejects zip files where the modified day or month is 0"
> > >
> > >
> > > Compared to jdk8,  this is a regression so I think it would be good to have
> a
> > better handling of problematic out of range seconds-values.
> > >
> > > Do you think it would be sufficient to adjust the out of range seconds to
> > the supported max-value 59 ?
> > > Or is something more sophisticated prefered ?
> > > I found the enhanced chained exception showing the  dtime long values
> > helpful too, should I submit it ?
> > >
> > > Best regards,
> > >              Matthias
> >
> >
> >

From peter.levart at gmail.com  Mon Oct  9 10:47:31 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 9 Oct 2017 12:47:31 +0200
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <b73b681e-efd7-edaa-9c92-9da2f63de847@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
 <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
 <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
 <b73b681e-efd7-edaa-9c92-9da2f63de847@oracle.com>
Message-ID: <8f1ec049-52ad-9fec-ca86-57c32e76514e@gmail.com>



On 10/09/2017 10:20 AM, Alan Bateman wrote:
> On 06/10/2017 20:37, mandy chung wrote:
>> :
>>
>> The native libraries map is now created lazily with 
>> synchronization.??? I keep the lazy initialization that will save to 
>> create a CHM as many custom class loaders don't have native code.? I 
>> think it's a good saving.?? In addition, if we iniitialize the static 
>> systemNativeLibraries at <clinit> time, it may want to avoid using 
>> CHM as it changes the class initialization order.
>>
> Alternatively change nativeLibraries and systemNativeLibraries to 
> volatile so the synchronization is only needed to initialize them. 
> Otherwise this version (webrev.03) looks good to me.
>
> -Alan

Yes Mandy, you could use volatile fields + double checked locking for 
initialization. In addition, the initializers to 'null' value are not 
needed / are a waste of instructions (the default is guaranteed by JLS):

2695???? // Native libraries belonging to system classes.
2696???? private static Map<String, NativeLibrary> systemNativeLibraries 
= null;
2697
2698???? // Native libraries associated with the class loader.
2699???? private Map<String, NativeLibrary> nativeLibraries = null;

Regards, Peter


From Alan.Bateman at oracle.com  Mon Oct  9 11:24:20 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 9 Oct 2017 12:24:20 +0100
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
Message-ID: <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>

On 06/10/2017 11:34, Kazunori Ogata wrote:
> Hi all,
>
> Please review a change for JDK-8188858.
>
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8188858
> Webrev: http://cr.openjdk.java.net/~horii/8188858/webrev.00/
>
> This change caches the result of latestUserDefinedLoader() when objects
> are deserialized, so the decerializer can avoid redundant stack walking to
> resolve classes of deserializing objects.
Some of the bugs/abuses of OIS come about from calling it on different 
threads with different contexts. So I think this optimization can only 
work if to confine it to the thread calling readUnshared, meaning 
readResolve cannot skip latestUserDefinedLoader() when called on other 
threads.

-Alan

From lance.andersen at oracle.com  Mon Oct  9 11:35:40 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 9 Oct 2017 07:35:40 -0400
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
 <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
 <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>
Message-ID: <B53D7902-137F-4082-930F-713D427E3CDF@oracle.com>

Hi Jack,

UnMarshaller also has the same issue.  I would update the webrev given the number of places to help sanity check for omissions

Best
Lance
> On Oct 8, 2017, at 9:22 PM, Jack Li <zheng.jun.li at oracle.com> wrote:
> 
> Hi Lance,
> 
> the change is incorrect, it should be ?javax/xml/bind?.
> thanks a lot for your finding, do you think I need to fix it and resubmit the webrev this time?
> or can you skip this file this time and I fix it in next integration?
> 
>> On Oct 4, 2017, at 02:09, Lance Andersen <Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>> wrote:
>> 
>> Hi Jack,
>> 
>> Is this change correct:
>> 
>> -------------
>> --- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
>> +++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
>> @@ -373,7 +373,7 @@
>>       *      If the {@link ValidationEventHandler ValidationEventHandler}
>>       *      returns false from its {@code handleEvent} method or the
>>       *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
>> -     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
>> +     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
>>       *      Marshalling a JAXB element</a>.
>> 
>> ------------
>> 
>> The URL that is being changed currently works
>> 
>> Best
>> Lance
>> On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>> 
>>> Hi,
>>> 
>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>>
>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>>
>>> 
>>> Summary of changes:
>>> 
>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>> 
>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>> 
>>> 
>>> Patch also contains several small bugfixes, not tracked in JBS.
>>> 
>>> ----------------
>>> Best regards
>>> Jack Li
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> <oracle_sig_logo.gif>
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle?Java Engineering?
>> 1 Network Drive?
>> Burlington, MA 01803
>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> 
> ----------------
> Best regards
> Jack Li
> 
> 
> 
> 
> 
> 

 <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 claes.redestad at oracle.com  Mon Oct  9 13:40:28 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 9 Oct 2017 15:40:28 +0200
Subject: jdk9/10 reject zip/jar files where seconds value of timestamp is
 out of supported range 0 - 59
In-Reply-To: <ae0a3eede2f74ec3bd107e0f30869f31@sap.com>
References: <370c795a79fc4273a3181279a7cbfb50@sap.com>
 <ae0a3eede2f74ec3bd107e0f30869f31@sap.com>
Message-ID: <81f6773d-7b07-0652-94d0-25925ab1ac85@oracle.com>

On 2017-10-09 11:52, Langer, Christoph wrote:
> Hi Matthias,
>
> I have closed your bug JDK-8188901 in favor of the bug that Sherman had opened before: https://bugs.openjdk.java.net/browse/JDK-8188869.
>
> Please post a webrev for the change as suggested by Claes.

Sounds good to me.

In addition to being a cleanup, the move to use java.time did provide a 
speedup, however, which
might become significant when loading lots of jar files.

I've not found my notes on how big this speed-up was (I recall ~3x in 
micros), but if anyone has time
to fix (and test) the overflows without reverting to java.util.Date then 
we might be able to keep most
of that gain intact.? This can of course be considered a follow-up, or 
ignored.

/Claes

From scolebourne at joda.org  Mon Oct  9 14:24:36 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 9 Oct 2017 15:24:36 +0100
Subject: jdk9/10 reject zip/jar files where seconds value of timestamp is
 out of supported range 0 - 59
In-Reply-To: <81f6773d-7b07-0652-94d0-25925ab1ac85@oracle.com>
References: <370c795a79fc4273a3181279a7cbfb50@sap.com>
 <ae0a3eede2f74ec3bd107e0f30869f31@sap.com>
 <81f6773d-7b07-0652-94d0-25925ab1ac85@oracle.com>
Message-ID: <CACzrW9DFBeCF7Z=faEZdWizbxRB7Vi4-LSkzzq1CZUwbEpERdg@mail.gmail.com>

On 9 October 2017 at 14:40, Claes Redestad <claes.redestad at oracle.com> wrote:
> In addition to being a cleanup, the move to use java.time did provide a
> speedup, however, which
> might become significant when loading lots of jar files.
>
> I've not found my notes on how big this speed-up was (I recall ~3x in
> micros), but if anyone has time
> to fix (and test) the overflows without reverting to java.util.Date then we
> might be able to keep most
> of that gain intact.  This can of course be considered a follow-up, or
> ignored.

In theory, this code should be equivalent, although I've not tested it:

```
int year = (int) (((dtime >> 25) & 0x7f) + 1980);
int month = (int) ((dtime >> 21) & 0x0f);
int day = ((int) ((dtime >> 16) & 0x1f)) - 1;
int hour = (int) ((dtime >> 11) & 0x1f);
int min = (int) ((dtime >> 5) & 0x3f);
int sec = (int) ((dtime << 1) & 0x3e);
long secs = day * 86400 + hour * 3600 + min * 60 + sec;

LocalDateTime ldt = LocalDateTime.of(year, month, 1).plusSeconds(secs);

return TimeUnit.MILLISECONDS.convert(ldt.toEpochSecond(
            ZoneId.systemDefault().getRules().getOffset(ldt)),
TimeUnit.SECONDS);
```

It could be further enhanced if the day was known to be in range, but
this code assumes that can't be guaranteed.

Another option would be to add a method `ofLenient(...)` to
`LocalDate`, `LocalTime`, `LocalDateTime` etc, as the problem is a
generally applicable one.

Stephen

From claes.redestad at oracle.com  Mon Oct  9 15:26:16 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 9 Oct 2017 17:26:16 +0200
Subject: jdk9/10 reject zip/jar files where seconds value of timestamp is
 out of supported range 0 - 59
In-Reply-To: <CACzrW9DFBeCF7Z=faEZdWizbxRB7Vi4-LSkzzq1CZUwbEpERdg@mail.gmail.com>
References: <370c795a79fc4273a3181279a7cbfb50@sap.com>
 <ae0a3eede2f74ec3bd107e0f30869f31@sap.com>
 <81f6773d-7b07-0652-94d0-25925ab1ac85@oracle.com>
 <CACzrW9DFBeCF7Z=faEZdWizbxRB7Vi4-LSkzzq1CZUwbEpERdg@mail.gmail.com>
Message-ID: <472a4a9d-4c62-13b0-2b83-c056b5a21557@oracle.com>



On 2017-10-09 16:24, Stephen Colebourne wrote:
> On 9 October 2017 at 14:40, Claes Redestad <claes.redestad at oracle.com> wrote:
>> In addition to being a cleanup, the move to use java.time did provide a
>> speedup, however, which
>> might become significant when loading lots of jar files.
>>
>> I've not found my notes on how big this speed-up was (I recall ~3x in
>> micros), but if anyone has time
>> to fix (and test) the overflows without reverting to java.util.Date then we
>> might be able to keep most
>> of that gain intact.  This can of course be considered a follow-up, or
>> ignored.
> In theory, this code should be equivalent, although I've not tested it:
>
> ```
> int year = (int) (((dtime >> 25) & 0x7f) + 1980);
> int month = (int) ((dtime >> 21) & 0x0f);
> int day = ((int) ((dtime >> 16) & 0x1f)) - 1;
> int hour = (int) ((dtime >> 11) & 0x1f);
> int min = (int) ((dtime >> 5) & 0x3f);
> int sec = (int) ((dtime << 1) & 0x3e);
> long secs = day * 86400 + hour * 3600 + min * 60 + sec;
>
> LocalDateTime ldt = LocalDateTime.of(year, month, 1).plusSeconds(secs);
>
> return TimeUnit.MILLISECONDS.convert(ldt.toEpochSecond(
>              ZoneId.systemDefault().getRules().getOffset(ldt)),
> TimeUnit.SECONDS);
> ```
>
> It could be further enhanced if the day was known to be in range, but
> this code assumes that can't be guaranteed.

Chaining (of(..).plusSeconds(..)) possibly makes this slower than
using Date() during startup (which is often where ZipUtils.dosToJavaTime
might show up), and still doesn't deal with the cases where month is zero
(or 13, or 14, or 15), which JDK-8184940 dealt with partially.

>
> Another option would be to add a method `ofLenient(...)` to
> `LocalDate`, `LocalTime`, `LocalDateTime` etc, as the problem is a
> generally applicable one.

This might be the best option, long-term.

I was fiddling a bit with the idea of outlining odd cases, but since
the DOS format allows all manner of odd dates that a sane date
library deals with exceptionally(!) then I guess the best we could
do to maintain performance for the common cases now is
something like:

 ??? /**
 ???? * Converts DOS time to Java time (number of milliseconds since epoch).
 ???? */
 ??? public static long dosToJavaTime(long dtime) {
 ??????? int year = (int) (((dtime >> 25) & 0x7f) + 1980);
 ??????? int month = (int) ((dtime >> 21) & 0x0f);
 ??????? int day = (int) ((dtime >> 16) & 0x1f);
 ??????? int hour = (int) ((dtime >> 11) & 0x1f);
 ??????? int minute = (int) ((dtime >> 5) & 0x3f);
 ??????? int second = (int) ((dtime << 1) & 0x3e);

 ??????? try {
 ??????????? LocalDateTime ldt = LocalDateTime.of(year, month, day, 
hour, minute, second);
 ??????????? return TimeUnit.MILLISECONDS.convert(ldt.toEpochSecond(
ZoneId.systemDefault().getRules().getOffset(ldt)), TimeUnit.SECONDS);
 ??????? } catch (DateTimeException dte) {
 ??????????? return overflowDosToJavaTime(year, month, day, hour, 
minute, second);
 ??????? }
 ??? }

 ??? /**
 ???? * Deal with corner cases where an arguably mal-formed DOS time is used
 ???? */
 ??? @SuppressWarnings("deprecation") // Use of date constructor
 ??? private static long overflowDosToJavaTime(int year, int month, int 
day, int hour, int minute, int second) {
 ??????? return new Date(year - 1900, month - 1, day, hour, minute, 
second).getTime();
 ??? }

/Claes

From xueming.shen at oracle.com  Mon Oct  9 16:22:07 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 09 Oct 2017 09:22:07 -0700
Subject: jdk9/10 reject zip/jar files where seconds value of timestamp
 is out of supported range 0 - 59
In-Reply-To: <472a4a9d-4c62-13b0-2b83-c056b5a21557@oracle.com>
References: <370c795a79fc4273a3181279a7cbfb50@sap.com>
 <ae0a3eede2f74ec3bd107e0f30869f31@sap.com>
 <81f6773d-7b07-0652-94d0-25925ab1ac85@oracle.com>
 <CACzrW9DFBeCF7Z=faEZdWizbxRB7Vi4-LSkzzq1CZUwbEpERdg@mail.gmail.com>
 <472a4a9d-4c62-13b0-2b83-c056b5a21557@oracle.com>
Message-ID: <59DBA22F.209@oracle.com>

+1,

for 8u/9u we will have to deal with it without any new apis from java.time.

i would assume exception-catch is now fast enough that will not add any
extra measurable burden here.

can some arithmetic calculations + if-else make the cost smaller? not sure
though.

jshell> ((month - 1) | (12- month) | (day - 1) | (31-day) | (24 - hr) | 
(59 - min) | (59 - sec)) < 0
$10 ==> false

-sherman

On 10/9/17, 8:26 AM, Claes Redestad wrote:
>
>>
>> Another option would be to add a method `ofLenient(...)` to
>> `LocalDate`, `LocalTime`, `LocalDateTime` etc, as the problem is a
>> generally applicable one.
>
> This might be the best option, long-term.
>
> I was fiddling a bit with the idea of outlining odd cases, but since
> the DOS format allows all manner of odd dates that a sane date
> library deals with exceptionally(!) then I guess the best we could
> do to maintain performance for the common cases now is
> something like:
>
>     /**
>      * Converts DOS time to Java time (number of milliseconds since 
> epoch).
>      */
>     public static long dosToJavaTime(long dtime) {
>         int year = (int) (((dtime >> 25) & 0x7f) + 1980);
>         int month = (int) ((dtime >> 21) & 0x0f);
>         int day = (int) ((dtime >> 16) & 0x1f);
>         int hour = (int) ((dtime >> 11) & 0x1f);
>         int minute = (int) ((dtime >> 5) & 0x3f);
>         int second = (int) ((dtime << 1) & 0x3e);
>
>         try {
>             LocalDateTime ldt = LocalDateTime.of(year, month, day, 
> hour, minute, second);
>             return TimeUnit.MILLISECONDS.convert(ldt.toEpochSecond(
> ZoneId.systemDefault().getRules().getOffset(ldt)), TimeUnit.SECONDS);
>         } catch (DateTimeException dte) {
>             return overflowDosToJavaTime(year, month, day, hour, 
> minute, second);
>         }
>     }
>
>     /**
>      * Deal with corner cases where an arguably mal-formed DOS time is 
> used
>      */
>     @SuppressWarnings("deprecation") // Use of date constructor
>     private static long overflowDosToJavaTime(int year, int month, int 
> day, int hour, int minute, int second) {
>         return new Date(year - 1900, month - 1, day, hour, minute, 
> second).getTime();
>     }
>
> /Claes


From mandy.chung at oracle.com  Mon Oct  9 16:39:04 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 9 Oct 2017 09:39:04 -0700
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <8f1ec049-52ad-9fec-ca86-57c32e76514e@gmail.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
 <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
 <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
 <b73b681e-efd7-edaa-9c92-9da2f63de847@oracle.com>
 <8f1ec049-52ad-9fec-ca86-57c32e76514e@gmail.com>
Message-ID: <6bf283ec-186f-6bb4-a5df-f4ba946f4ea2@oracle.com>



On 10/9/17 3:47 AM, Peter Levart wrote:
>
>
> On 10/09/2017 10:20 AM, Alan Bateman wrote:
>> On 06/10/2017 20:37, mandy chung wrote:
>>> :
>>>
>>> The native libraries map is now created lazily with 
>>> synchronization.??? I keep the lazy initialization that will save to 
>>> create a CHM as many custom class loaders don't have native code.? I 
>>> think it's a good saving.?? In addition, if we iniitialize the 
>>> static systemNativeLibraries at <clinit> time, it may want to avoid 
>>> using CHM as it changes the class initialization order.
>>>
>> Alternatively change nativeLibraries and systemNativeLibraries to 
>> volatile so the synchronization is only needed to initialize them. 
>> Otherwise this version (webrev.03) looks good to me.
>>
>> -Alan
>
> Yes Mandy, you could use volatile fields + double checked locking for 
> initialization.


Since this might affect JNI binding, I have avoided changing it to 
volatile in this patch until we get some performance number (I might be 
overly conversative).? I prefer to follow up this together in the lock 
cleanup RFE that David suggests.

> In addition, the initializers to 'null' value are not needed / are a 
> waste of instructions (the default is guaranteed by JLS):
>
> 2695???? // Native libraries belonging to system classes.
> 2696???? private static Map<String, NativeLibrary> 
> systemNativeLibraries = null;
> 2697
> 2698???? // Native libraries associated with the class loader.
> 2699???? private Map<String, NativeLibrary> nativeLibraries = null;

sure.
Mandy

From ioi.lam at oracle.com  Mon Oct  9 17:54:26 2017
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 9 Oct 2017 10:54:26 -0700
Subject: RFR (XS) 8188828 Intermittent ClassNotFoundException:
 jdk.test.lib.Platform for compiler tests
In-Reply-To: <4dea8e6c-34fc-83b6-8fe3-2905ec15b72b@oracle.com>
References: <1be927fa-fa4b-1964-93f3-1c72386acf7b@oracle.com>
 <4dea8e6c-34fc-83b6-8fe3-2905ec15b72b@oracle.com>
Message-ID: <f1ba03b3-ab6e-d6f4-9697-9a91cb050c80@oracle.com>

There are several possibilities. One is to pre-compile a bunch of 
libraries during the build time, and put them in the classpath using the 
jtreg -cpa: option.

Another possibility is to change jtreg to better express the dependency 
between different classes compiled by jtreg.

Thanks

- Ioi


On 10/8/17 6:33 PM, David Holmes wrote:
> Hi Ioi,
>
> This seems like a temporary workaround - fine for now - but what is 
> the real fix here? It's crazy that one test library class can't use 
> another class from the same test library!
>
> Thanks,
> David
>
> On 7/10/2017 6:19 AM, Ioi Lam wrote:
>> Please review this very simple change:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8188828
>> http://ioilinux.us.oracle.com/webrev/jdk10/8188828_compiler_test_class_not_found.v01/ 
>>
>>
>> The dependency of
>>
>> ???? FileInstaller -> Utils -> JDKToolLauncher -> Platform
>>
>> has caused many intermittent ClassNotFoundException in the hotspot 
>> nightly runs.
>> While this fix does not address the root cause (proper dependencies 
>> are not
>> specified in the test cases -- which we are planning to fix), we will 
>> hopefully
>> see much fewer occurrences of this annoying failure scenario.
>>
>> Thanks a lot to Igor for suggesting the simple fix!
>>
>> - Ioi
>>


From ioi.lam at oracle.com  Mon Oct  9 17:55:34 2017
From: ioi.lam at oracle.com (Ioi Lam)
Date: Mon, 9 Oct 2017 10:55:34 -0700
Subject: RFR (XS) 8188828 Intermittent ClassNotFoundException:
 jdk.test.lib.Platform for compiler tests
In-Reply-To: <1be927fa-fa4b-1964-93f3-1c72386acf7b@oracle.com>
References: <1be927fa-fa4b-1964-93f3-1c72386acf7b@oracle.com>
Message-ID: <1b6a6353-9db6-9e1f-7b03-85bc3773055a@oracle.com>

Sorry I used an internal URL. Here's the proper openjdk URL:

http://cr.openjdk.java.net/~iklam/jdk10/8188828_compiler_test_class_not_found.v01/

Thanks

- Ioi


On 10/6/17 1:19 PM, Ioi Lam wrote:
> Please review this very simple change:
>
> https://bugs.openjdk.java.net/browse/JDK-8188828
> http://ioilinux.us.oracle.com/webrev/jdk10/8188828_compiler_test_class_not_found.v01/ 
>
>
> The dependency of
>
> ??? FileInstaller -> Utils -> JDKToolLauncher -> Platform
>
> has caused many intermittent ClassNotFoundException in the hotspot 
> nightly runs.
> While this fix does not address the root cause (proper dependencies 
> are not
> specified in the test cases -- which we are planning to fix), we will 
> hopefully
> see much fewer occurrences of this annoying failure scenario.
>
> Thanks a lot to Igor for suggesting the simple fix!
>
> - Ioi
>


From jonathan.gibbons at oracle.com  Mon Oct  9 18:07:54 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 9 Oct 2017 11:07:54 -0700
Subject: RFR (XS) 8188828 Intermittent ClassNotFoundException:
 jdk.test.lib.Platform for compiler tests
In-Reply-To: <f1ba03b3-ab6e-d6f4-9697-9a91cb050c80@oracle.com>
References: <1be927fa-fa4b-1964-93f3-1c72386acf7b@oracle.com>
 <4dea8e6c-34fc-83b6-8fe3-2905ec15b72b@oracle.com>
 <f1ba03b3-ab6e-d6f4-9697-9a91cb050c80@oracle.com>
Message-ID: <9dceef95-09e8-7e05-df7a-f50f5dbce18d@oracle.com>

Another possibility is to design the libraries so that they can be built 
with a wildcard build, as in @build mypackage.*

I don't see that we will (or want to) ever get to a point in jtreg where 
each library class can identify its own dependencies, such as suggested 
below.

If the libraries can be prebuilt ahead of time, I don't see why they 
can't be built by jtreg.

-- Jon


On 10/9/17 10:54 AM, Ioi Lam wrote:
> There are several possibilities. One is to pre-compile a bunch of 
> libraries during the build time, and put them in the classpath using 
> the jtreg -cpa: option.
>
> Another possibility is to change jtreg to better express the 
> dependency between different classes compiled by jtreg.
>
> Thanks
>
> - Ioi
>
>
> On 10/8/17 6:33 PM, David Holmes wrote:
>> Hi Ioi,
>>
>> This seems like a temporary workaround - fine for now - but what is 
>> the real fix here? It's crazy that one test library class can't use 
>> another class from the same test library!
>>
>> Thanks,
>> David
>>
>> On 7/10/2017 6:19 AM, Ioi Lam wrote:
>>> Please review this very simple change:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8188828
>>> http://ioilinux.us.oracle.com/webrev/jdk10/8188828_compiler_test_class_not_found.v01/ 
>>>
>>>
>>> The dependency of
>>>
>>>      FileInstaller -> Utils -> JDKToolLauncher -> Platform
>>>
>>> has caused many intermittent ClassNotFoundException in the hotspot 
>>> nightly runs.
>>> While this fix does not address the root cause (proper dependencies 
>>> are not
>>> specified in the test cases -- which we are planning to fix), we 
>>> will hopefully
>>> see much fewer occurrences of this annoying failure scenario.
>>>
>>> Thanks a lot to Igor for suggesting the simple fix!
>>>
>>> - Ioi
>>>
>


From claes.redestad at oracle.com  Mon Oct  9 18:09:12 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 9 Oct 2017 20:09:12 +0200
Subject: jdk9/10 reject zip/jar files where seconds value of timestamp is
 out of supported range 0 - 59
In-Reply-To: <59DBA22F.209@oracle.com>
References: <370c795a79fc4273a3181279a7cbfb50@sap.com>
 <ae0a3eede2f74ec3bd107e0f30869f31@sap.com>
 <81f6773d-7b07-0652-94d0-25925ab1ac85@oracle.com>
 <CACzrW9DFBeCF7Z=faEZdWizbxRB7Vi4-LSkzzq1CZUwbEpERdg@mail.gmail.com>
 <472a4a9d-4c62-13b0-2b83-c056b5a21557@oracle.com> <59DBA22F.209@oracle.com>
Message-ID: <75e2d578-a7d3-ecd9-9fb1-90a38a6307c6@oracle.com>



On 2017-10-09 18:22, Xueming Shen wrote:
> can some arithmetic calculations + if-else make the cost smaller? not 
> sure
> though.
>
> jshell> ((month - 1) | (12- month) | (day - 1) | (31-day) | (24 - hr) 
> | (59 - min) | (59 - sec)) < 0
> $10 ==> false

Possibly, but given it took almost two years for issues with the unexpected
strictness to be reported then I think we should favor not penalizing
well-formed entries over optimizing for malformed files.

I guess the special treatment for cases where the date part is zero
(time >> 16 == 0) might be common enough to warrant some special
treatment, though.

/Claes

From mandy.chung at oracle.com  Mon Oct  9 20:17:36 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 9 Oct 2017 13:17:36 -0700
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <b73b681e-efd7-edaa-9c92-9da2f63de847@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
 <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
 <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
 <b73b681e-efd7-edaa-9c92-9da2f63de847@oracle.com>
Message-ID: <57e0b49a-bed6-25c2-7d01-b87f08d82a75@oracle.com>

David, Peter, Alan

The VM has a fast path to search the symbol from libjava.so first for 
bootstrap loader.? That was the case I mostly concern about performance 
and it's not impacted by this change.?? Also I consulted with Claes on 
the performance impact.?? I took your suggestion and made 
systemNativeLibraries and nativeLibraries volatile.

Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.04

thanks
Mandy

On 10/9/17 1:20 AM, Alan Bateman wrote:
> Alternatively change nativeLibraries and systemNativeLibraries to 
> volatile so the synchronization is only needed to initialize them. 
> Otherwise this version (webrev.03) looks good to me.
>
> -Alan


From david.holmes at oracle.com  Tue Oct 10 03:27:54 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Oct 2017 13:27:54 +1000
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <57e0b49a-bed6-25c2-7d01-b87f08d82a75@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
 <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
 <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
 <b73b681e-efd7-edaa-9c92-9da2f63de847@oracle.com>
 <57e0b49a-bed6-25c2-7d01-b87f08d82a75@oracle.com>
Message-ID: <ce7ba5d8-e977-a39f-d326-dda2dec676c4@oracle.com>

On 10/10/2017 6:17 AM, mandy chung wrote:
> David, Peter, Alan
> 
> The VM has a fast path to search the symbol from libjava.so first for 
> bootstrap loader.? That was the case I mostly concern about performance 
> and it's not impacted by this change.?? Also I consulted with Claes on 
> the performance impact.?? I took your suggestion and made 
> systemNativeLibraries and nativeLibraries volatile.
> 
> Updated webrev:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.04

Looks good.

Thanks,
David
-----

> thanks
> Mandy
> 
> On 10/9/17 1:20 AM, Alan Bateman wrote:
>> Alternatively change nativeLibraries and systemNativeLibraries to 
>> volatile so the synchronization is only needed to initialize them. 
>> Otherwise this version (webrev.03) looks good to me.
>>
>> -Alan
> 

From Alan.Bateman at oracle.com  Tue Oct 10 08:44:19 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Oct 2017 09:44:19 +0100
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <57e0b49a-bed6-25c2-7d01-b87f08d82a75@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
 <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
 <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
 <b73b681e-efd7-edaa-9c92-9da2f63de847@oracle.com>
 <57e0b49a-bed6-25c2-7d01-b87f08d82a75@oracle.com>
Message-ID: <16afc01d-016e-b77c-58b9-cefcdf62a03d@oracle.com>



On 09/10/2017 21:17, mandy chung wrote:
> David, Peter, Alan
>
> The VM has a fast path to search the symbol from libjava.so first for 
> bootstrap loader.? That was the case I mostly concern about 
> performance and it's not impacted by this change.?? Also I consulted 
> with Claes on the performance impact.?? I took your suggestion and 
> made systemNativeLibraries and nativeLibraries volatile.
>
> Updated webrev:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.04
This update looks good to me.

-Alan

From peter.levart at gmail.com  Tue Oct 10 09:29:04 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 10 Oct 2017 11:29:04 +0200
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <57e0b49a-bed6-25c2-7d01-b87f08d82a75@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
 <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
 <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
 <b73b681e-efd7-edaa-9c92-9da2f63de847@oracle.com>
 <57e0b49a-bed6-25c2-7d01-b87f08d82a75@oracle.com>
Message-ID: <376a0876-d94b-8775-873c-bfd741614273@gmail.com>


On 10/09/2017 10:17 PM, mandy chung wrote:
> David, Peter, Alan
>
> The VM has a fast path to search the symbol from libjava.so first for 
> bootstrap loader.? That was the case I mostly concern about 
> performance and it's not impacted by this change.?? Also I consulted 
> with Claes on the performance impact.?? I took your suggestion and 
> made systemNativeLibraries and nativeLibraries volatile.
>
> Updated webrev:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.04
>

Looks good now. Just one question (for a possible follow-up future 
optimization):

2674???? private static long findNative(ClassLoader loader, String name) {
2675???????? Map<String, NativeLibrary> libs =
2676???????????? loader != null ? loader.nativeLibraries() : 
systemNativeLibraries();
2677???????? if (libs.isEmpty())
2678???????????? return 0;
2679
2680???????? // the native libraries map may be updated in another thread
2681???????? // when a native library is being loaded.? No symbol will be
2682???????? // searched from it yet.
2683???????? for (NativeLibrary lib : libs.values()) {
2684???????????? long entry = lib.findEntry(name);
2685???????????? if (entry != 0) return entry;
2686???????? }
2687???????? return 0;
2688???? }

Now that (system)nativeLibraries is a Map, is it still necessary to 
iterate it and call lib.findEntry(name) on each NativeLibrary until the 
one that returns a non-zero entry or would it be semantically equivalent 
to 1st look-up the Map by the 'name' key to get the correct NativeLibrary?

Regards, Peter


From OGATAK at jp.ibm.com  Tue Oct 10 09:50:59 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Tue, 10 Oct 2017 18:50:59 +0900
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
Message-ID: <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>

Hi Alan,

Thank you for your comment.

I agree that the current code is not thread safe, but I think OIS itself 
is not thread safe either.  The issue you pointed out occurs when two 
threads calls readObject()/readUnshared() simultaneously, and the result 
of such situation is undefined in any way in my understanding.  Do we need 
to ensure the same behavior for such an error case?


Regarding readResolve,

I think readResolve() won't use the cached loader because readResolve() of 
a deserialized class can't call OIS.resolveClass(). 

Regards,
Ogata


Alan Bateman <Alan.Bateman at oracle.com> wrote on 2017/10/09 20:24:20:

> From: Alan Bateman <Alan.Bateman at oracle.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>, core-libs-dev at openjdk.java.net
> Date: 2017/10/09 20:24
> Subject: Re: RFR: 8188858: Caching latestUserDefinedLoader() results in 
> ObjectInputStream.readObject()
> 
> On 06/10/2017 11:34, Kazunori Ogata wrote:
> > Hi all,
> >
> > Please review a change for JDK-8188858.
> >
> > Bug report: https://bugs.openjdk.java.net/browse/JDK-8188858
> > Webrev: http://cr.openjdk.java.net/~horii/8188858/webrev.00/
> >
> > This change caches the result of latestUserDefinedLoader() when 
objects
> > are deserialized, so the decerializer can avoid redundant stack 
walking to
> > resolve classes of deserializing objects.
> Some of the bugs/abuses of OIS come about from calling it on different 
> threads with different contexts. So I think this optimization can only 
> work if to confine it to the thread calling readUnshared, meaning 
> readResolve cannot skip latestUserDefinedLoader() when called on other 
> threads.
> 
> -Alan
> 



From sean.mullan at oracle.com  Tue Oct 10 12:25:40 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 10 Oct 2017 08:25:40 -0400
Subject: [10] RFR(S) 8188775: Module jdk.internal.vm.compiler.management
 has not been granted accessClassInPackage.org.graalvm.compiler.hotspot
In-Reply-To: <b21ce89d-dd4d-2dec-d3ba-6e157718d929@oracle.com>
References: <a374f47d-c4a5-0fb4-8674-dba65624532f@oracle.com>
 <b21ce89d-dd4d-2dec-d3ba-6e157718d929@oracle.com>
Message-ID: <a5e5117c-2cf0-4673-a583-aefdf3235c14@oracle.com>

On 10/9/17 3:55 AM, Alan Bateman wrote:
> On 05/10/2017 00:05, Vladimir Kozlov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8188775
>>
>> Changes for 8182701[1] missed changes in default.policy for new module 
>> jdk.internal.vm.compiler.management.
>>
>> Add missing code:
>>
>> src/java.base/share/lib/security/default.policy
>> @@ -154,6 +154,10 @@
>> ???? permission java.security.AllPermission;
>> ?};
>>
>> +grant codeBase "jrt:/jdk.internal.vm.compiler.management" {
>> +??? permission java.security.AllPermission;
>> +};
>> +
> This looks okay to me although it would be nice if we could identify the 
> minimal permissions rather than granting it AllPermission.

+1.

Is there any reason you did not just grant it RuntimePermission 
"accessClassInPackage.org.graalvm.compiler.hotspot"?

I see you have already pushed the fix, so I would recommend opening 
another issue to only grant the required permissions to the 
jdk.internal.vm.compiler.management module.

Thanks,
Sean



From sean.mullan at oracle.com  Tue Oct 10 12:26:12 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 10 Oct 2017 08:26:12 -0400
Subject: [10] RFR(S) 8188775: Module jdk.internal.vm.compiler.management
 has not been granted accessClassInPackage.org.graalvm.compiler.hotspot
In-Reply-To: <b21ce89d-dd4d-2dec-d3ba-6e157718d929@oracle.com>
References: <a374f47d-c4a5-0fb4-8674-dba65624532f@oracle.com>
 <b21ce89d-dd4d-2dec-d3ba-6e157718d929@oracle.com>
Message-ID: <449d883b-1208-9708-2da7-9cd6393a8db7@oracle.com>

On 10/9/17 3:55 AM, Alan Bateman wrote:
> On 05/10/2017 00:05, Vladimir Kozlov wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8188775
>>
>> Changes for 8182701[1] missed changes in default.policy for new module 
>> jdk.internal.vm.compiler.management.
>>
>> Add missing code:
>>
>> src/java.base/share/lib/security/default.policy
>> @@ -154,6 +154,10 @@
>> ???? permission java.security.AllPermission;
>> ?};
>>
>> +grant codeBase "jrt:/jdk.internal.vm.compiler.management" {
>> +??? permission java.security.AllPermission;
>> +};
>> +
> This looks okay to me although it would be nice if we could identify the 
> minimal permissions rather than granting it AllPermission.

+1.

Is there any reason you did not just grant it RuntimePermission 
"accessClassInPackage.org.graalvm.compiler.hotspot"?

I see you have already pushed the fix, so I would recommend opening 
another issue to only grant the required permissions to the 
jdk.internal.vm.compiler.management module.

Thanks,
Sean

From Alan.Bateman at oracle.com  Tue Oct 10 12:41:59 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 10 Oct 2017 13:41:59 +0100
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
 <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
Message-ID: <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>

On 10/10/2017 10:50, Kazunori Ogata wrote:
> Hi Alan,
>
> Thank you for your comment.
>
> I agree that the current code is not thread safe, but I think OIS itself
> is not thread safe either.  The issue you pointed out occurs when two
> threads calls readObject()/readUnshared() simultaneously, and the result
> of such situation is undefined in any way in my understanding.  Do we need
> to ensure the same behavior for such an error case?
OIS is very interesting to attackers so you will need to take deliberate 
abuses of the API into account. I realize it's a pain but it's one of 
the reasons why we have to be cautious about optimizations in this area.

-Alan

From mandy.chung at oracle.com  Tue Oct 10 15:00:37 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 10 Oct 2017 08:00:37 -0700
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <376a0876-d94b-8775-873c-bfd741614273@gmail.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
 <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
 <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
 <b73b681e-efd7-edaa-9c92-9da2f63de847@oracle.com>
 <57e0b49a-bed6-25c2-7d01-b87f08d82a75@oracle.com>
 <376a0876-d94b-8775-873c-bfd741614273@gmail.com>
Message-ID: <96cf434b-aa72-158f-515f-089a63c25c4d@oracle.com>



On 10/10/17 2:29 AM, Peter Levart wrote:
>
> On 10/09/2017 10:17 PM, mandy chung wrote:
>> David, Peter, Alan
>>
>> The VM has a fast path to search the symbol from libjava.so first for 
>> bootstrap loader.? That was the case I mostly concern about 
>> performance and it's not impacted by this change.?? Also I consulted 
>> with Claes on the performance impact.?? I took your suggestion and 
>> made systemNativeLibraries and nativeLibraries volatile.
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8164512/webrev.04
>>
>
> Looks good now. Just one question (for a possible follow-up future 
> optimization):
>
> 2674???? private static long findNative(ClassLoader loader, String name) {
> 2675???????? Map<String, NativeLibrary> libs =
> 2676???????????? loader != null ? loader.nativeLibraries() : 
> systemNativeLibraries();
> 2677???????? if (libs.isEmpty())
> 2678???????????? return 0;
> 2679
> 2680???????? // the native libraries map may be updated in another thread
> 2681???????? // when a native library is being loaded.? No symbol will be
> 2682???????? // searched from it yet.
> 2683???????? for (NativeLibrary lib : libs.values()) {
> 2684???????????? long entry = lib.findEntry(name);
> 2685???????????? if (entry != 0) return entry;
> 2686???????? }
> 2687???????? return 0;
> 2688???? }
>
> Now that (system)nativeLibraries is a Map, is it still necessary to 
> iterate it and call lib.findEntry(name) on each NativeLibrary until 
> the one that returns a non-zero entry or would it be semantically 
> equivalent to 1st look-up the Map by the 'name' key to get the correct 
> NativeLibrary?
>
The name parameter is the symbol name but not the library name. It's 
confusing and therefore I renamed NativeLibrary::find to 
NativeLibrary::findEntry.?? I could rename the name parameter to 
entryName to make it clearer.

Mandy

From vladimir.kozlov at oracle.com  Tue Oct 10 15:29:29 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 10 Oct 2017 08:29:29 -0700
Subject: [10] RFR(S) 8188775: Module jdk.internal.vm.compiler.management
 has not been granted accessClassInPackage.org.graalvm.compiler.hotspot
In-Reply-To: <449d883b-1208-9708-2da7-9cd6393a8db7@oracle.com>
References: <a374f47d-c4a5-0fb4-8674-dba65624532f@oracle.com>
 <b21ce89d-dd4d-2dec-d3ba-6e157718d929@oracle.com>
 <449d883b-1208-9708-2da7-9cd6393a8db7@oracle.com>
Message-ID: <3fad30f1-0050-12c5-4e61-4bda9852457b@oracle.com>

Thank you Alan and Sean,

I copied preceding code for jdk.internal.vm.compiler because it is not clear for me if accessClassInPackage is enough 
for all cases. Anyway, I filed next issue to find minimum required permission as you suggested.

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

Thanks,
Vladimir

On 10/10/17 5:26 AM, Sean Mullan wrote:
> On 10/9/17 3:55 AM, Alan Bateman wrote:
>> On 05/10/2017 00:05, Vladimir Kozlov wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-8188775
>>>
>>> Changes for 8182701[1] missed changes in default.policy for new module jdk.internal.vm.compiler.management.
>>>
>>> Add missing code:
>>>
>>> src/java.base/share/lib/security/default.policy
>>> @@ -154,6 +154,10 @@
>>> ???? permission java.security.AllPermission;
>>> ?};
>>>
>>> +grant codeBase "jrt:/jdk.internal.vm.compiler.management" {
>>> +??? permission java.security.AllPermission;
>>> +};
>>> +
>> This looks okay to me although it would be nice if we could identify the minimal permissions rather than granting it 
>> AllPermission.
> 
> +1.
> 
> Is there any reason you did not just grant it RuntimePermission "accessClassInPackage.org.graalvm.compiler.hotspot"?
> 
> I see you have already pushed the fix, so I would recommend opening another issue to only grant the required permissions 
> to the jdk.internal.vm.compiler.management module.
> 
> Thanks,
> Sean

From matthias.baesken at sap.com  Tue Oct 10 16:23:11 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 10 Oct 2017 16:23:11 +0000
Subject: jdk9/10 reject zip/jar files where seconds value of timestamp is
 out of supported range 0 - 59 
Message-ID: <3adeb1f29fb14b958be0d2e63bacefeb@sap.com>

>> Hi Matthias,

>>

>> I have closed your bug JDK-8188901 in favor of the bug that Sherman had opened before: https://bugs.openjdk.java.net/browse/JDK-8188869.

>>

>> Please post a webrev for the change as suggested by Claes.

>

>Sounds good to me.

>

>In addition to being a cleanup, the move to use java.time did provide a

>speedup, however, which

>might become significant when loading lots of jar files.

>

>I've not found my notes on how big this speed-up was (I recall ~3x in

> micros), but if anyone has time

> to fix (and test) the overflows without reverting to java.util.Date then

> we might be able to keep most

> of that gain intact.? This can of course be considered a follow-up, or

> ignored.

>



Hi Claes, to me it looks like the old jdk8 coding is not slower than the jdk9/10 coding .



Best regards, Matthias














From christoph.dreis at freenet.de  Tue Oct 10 17:59:23 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Tue, 10 Oct 2017 19:59:23 +0200
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
 reflection
Message-ID: <000001d341f1$82764870$8762d950$@freenet.de>

Hi Claes,

with JDK 9 being out - congrats to everyone - I'll try my chance to raise issue https://bugs.openjdk.java.net/browse/JDK-8029019 again.

A little recap: In November 2016 I reported the unnecessary allocation of Method.getParameterTypes() in AnnotationInvocationHandler.invoke() and a patch that would fix this. As it turned out, this and other improvements were already suggested by Peter in above mentioned ticket. Because it was reasonably late in February 2017 to cover the complete story for 9, I suggested to only include the low-risk patch, which was understandably also too late.

So I'm trying again to bring this into the JDK - I hope you don't mind me being so persistent on this one. 

For completeness find the initial patch attached below for the initial problem I was trying to solve.

Cheers,
Christoph

================================
Reduce allocations in sun.reflect.annotation.AnnotationInvocationHandler.invoke()

diff -r ba70dcd8de76 -r 86bbc5442c1d src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
--- a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java     Fri Nov 11 13:11:27 2016 +0000
+++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java  Mon Nov 14 19:04:33 2016 +0100
@@ -57,13 +57,13 @@

     public Object invoke(Object proxy, Method method, Object[] args) {
         String member = method.getName();
-        Class<?>[] paramTypes = method.getParameterTypes();
+        int parameterCount = method.getParameterCount();

         // Handle Object and Annotation methods
-        if (member.equals("equals") && paramTypes.length == 1 &&
-            paramTypes[0] == Object.class)
+        if (parameterCount == 1 && member.equals("equals") &&
+            method.getParameterTypes()[0] == Object.class)
             return equalsImpl(proxy, args[0]);
-        if (paramTypes.length != 0)
+        if (parameterCount != 0)
             throw new AssertionError("Too many parameters for an annotation method");

         switch(member) {

> -----Original Message-----
> From: Christoph Dreis [mailto:christoph.dreis at freenet.de]
> Sent: Friday, February 10, 2017 11:22 AM
> To: 'Claes Redestad' <claes.redestad at oracle.com>; 'Peter Levart'
> <peter.levart at gmail.com>; 'Core-Libs-Dev' <core-libs-
> dev at openjdk.java.net>
> Subject: RE: RFR: 8029019: (ann) Optimize annotation handling in core
> reflection
> 
> Hi Claes,
> 
> >
> > I think this all seems reasonable, but subtle behavior changes like
> > this needs more scrutiny than I can provide.  I've discussed this
> > offline with Joe and sadly concluded it's probably too much, too late
> > for 9 at this point.
> >
> > Hope you don't mind re-targetting this to JDK 10.
> 
> Do you mean the error handling change or the ticket in general? In case of
> the latter, may I start a proposal?
> 
> As the original issue for me was to reduce the allocations coming from
> AnnotationInvocationHandler.invoke() caused by
> Method.getParameterTypes(), what about creating a sub-ticket of 8029019
> and just take care of the low-risk change below? That would eventually allow
> a backbort to JDK 8 as well, although I'm not quite sure yet how the backport
> process is working.
> 
> What do you think?
> 
> Cheers,
> Christoph
> 
> ========= PATCH ===========
> diff --git
> a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation
> Handler.java
> b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation
> Handler.java
> ---
> a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation
> Handler.java
> +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvoc
> +++ ationHandler.java
> @@ -57,13 +57,13 @@
> 
>      public Object invoke(Object proxy, Method method, Object[] args) {
>          String member = method.getName();
> -        Class<?>[] paramTypes = method.getParameterTypes();
> +        int parameterCount = method.getParameterCount();
> 
>          // Handle Object and Annotation methods
> -        if (member.equals("equals") && paramTypes.length == 1 &&
> -            paramTypes[0] == Object.class)
> +        if (parameterCount == 1 && member.equals("equals") &&
> +            method.getParameterTypes()[0] == Object.class)
>              return equalsImpl(proxy, args[0]);
> -        if (paramTypes.length != 0)
> +        if (parameterCount != 0)
>              throw new AssertionError("Too many parameters for an annotation
> method");
> 
>          switch(member) {


From chris.hegarty at oracle.com  Tue Oct 10 18:58:28 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 10 Oct 2017 19:58:28 +0100
Subject: RFR 8145635 : Add TCP_QUICKACK socket option
In-Reply-To: <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com>
References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com>
 <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com>
 <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com>
 <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com>
Message-ID: <F179D102-14DA-4239-811E-A95CC41ED3D8@oracle.com>

Vyom,

What about suggestion 1) below, the name of the socket option?

-Chris.

> On 27 Sep 2017, at 09:56, vyom tewari <vyom.tewari at oracle.com> wrote:
> 
> Hi Chris,
> 
> Thanks for review, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.2/index.html). I incorporated review comments from you and re-base the patch to our consolidated repo(jdk10/master).
> 
> Thanks,
> 
> Vyom
> 
> 
> On Monday 25 September 2017 01:57 AM, Chris Hegarty wrote:
>> Vyom,
>> 
>>> On 11 Sep 2017, at 16:38, vyom tewari <vyom.tewari at oracle.com> wrote:
>>> 
>>> Hi All,
>>> 
>>> As jdk.net API already moved out of java.base, Please review the below code change for jdk10.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145635
>>> Webrev: http://cr.openjdk.java.net/~vtewari/8145635/webrev0.1/index.html
>>> 
>> This looks quite good. Some comments:
>> 
>> 1) I wonder if we should just call the option TCP_QUICKACK, rather than SO_QUICKACK? Similar to TCP_NODELAY.
>> 
>> 2) I think LinuxSocketOptions.h is largely unnecessary, if we do 1) above.
>> 
>> 3) Java_jdk_net_LinuxSocketOptions_getQuickAck could return jint, rather than jobject, thus avoiding the need for createBoolean. The conversation can happen in the Java layer.  Can you please reduce the lint length in this file, by wrapping similar to the style of the Solaris version.
>> 
>> 4) ExtendedSocketOptions.java
>>   - drop the <p>, they are unnecessary.
>>   - I think, similar to TCP_NODELAY, the spec should say that the options is TCP specific. From TCP_NODELAY: "The socket option is specific to stream-oriented sockets using the TCP/IP protocol.?
>>   - "In TCP_QUICKACK mode?, maybe ?When the option is enabled??
>> 
>> -Chris.
>> 
>> 
> 


From joel.borggren.franck at gmail.com  Tue Oct 10 19:51:11 2017
From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=)
Date: Tue, 10 Oct 2017 19:51:11 +0000
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
 reflection
In-Reply-To: <000001d341f1$82764870$8762d950$@freenet.de>
References: <000001d341f1$82764870$8762d950$@freenet.de>
Message-ID: <CAFG0kMaKLn=+G_312CpiW3cA3BaV=kW8dEkgwHoZ3mchTvxE1Q@mail.gmail.com>

This looks fine to me. None of the gotchas I could remember that may or may
not apply to Peters bigger change  applies to this one.

You should get a second opinon from Joe or Peter though.

cheers
/Joel

On Tue, 10 Oct 2017 at 20:02 Christoph Dreis <christoph.dreis at freenet.de>
wrote:

> Hi Claes,
>
> with JDK 9 being out - congrats to everyone - I'll try my chance to raise
> issue https://bugs.openjdk.java.net/browse/JDK-8029019 again.
>
> A little recap: In November 2016 I reported the unnecessary allocation of
> Method.getParameterTypes() in AnnotationInvocationHandler.invoke() and a
> patch that would fix this. As it turned out, this and other improvements
> were already suggested by Peter in above mentioned ticket. Because it was
> reasonably late in February 2017 to cover the complete story for 9, I
> suggested to only include the low-risk patch, which was understandably also
> too late.
>
> So I'm trying again to bring this into the JDK - I hope you don't mind me
> being so persistent on this one.
>
> For completeness find the initial patch attached below for the initial
> problem I was trying to solve.
>
> Cheers,
> Christoph
>
> ================================
> Reduce allocations in
> sun.reflect.annotation.AnnotationInvocationHandler.invoke()
>
> diff -r ba70dcd8de76 -r 86bbc5442c1d
> src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
> ---
> a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
>    Fri Nov 11 13:11:27 2016 +0000
> +++
> b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
> Mon Nov 14 19:04:33 2016 +0100
> @@ -57,13 +57,13 @@
>
>      public Object invoke(Object proxy, Method method, Object[] args) {
>          String member = method.getName();
> -        Class<?>[] paramTypes = method.getParameterTypes();
> +        int parameterCount = method.getParameterCount();
>
>          // Handle Object and Annotation methods
> -        if (member.equals("equals") && paramTypes.length == 1 &&
> -            paramTypes[0] == Object.class)
> +        if (parameterCount == 1 && member.equals("equals") &&
> +            method.getParameterTypes()[0] == Object.class)
>              return equalsImpl(proxy, args[0]);
> -        if (paramTypes.length != 0)
> +        if (parameterCount != 0)
>              throw new AssertionError("Too many parameters for an
> annotation method");
>
>          switch(member) {
>
> > -----Original Message-----
> > From: Christoph Dreis [mailto:christoph.dreis at freenet.de]
> > Sent: Friday, February 10, 2017 11:22 AM
> > To: 'Claes Redestad' <claes.redestad at oracle.com>; 'Peter Levart'
> > <peter.levart at gmail.com>; 'Core-Libs-Dev' <core-libs-
> > dev at openjdk.java.net>
> > Subject: RE: RFR: 8029019: (ann) Optimize annotation handling in core
> > reflection
> >
> > Hi Claes,
> >
> > >
> > > I think this all seems reasonable, but subtle behavior changes like
> > > this needs more scrutiny than I can provide.  I've discussed this
> > > offline with Joe and sadly concluded it's probably too much, too late
> > > for 9 at this point.
> > >
> > > Hope you don't mind re-targetting this to JDK 10.
> >
> > Do you mean the error handling change or the ticket in general? In case
> of
> > the latter, may I start a proposal?
> >
> > As the original issue for me was to reduce the allocations coming from
> > AnnotationInvocationHandler.invoke() caused by
> > Method.getParameterTypes(), what about creating a sub-ticket of 8029019
> > and just take care of the low-risk change below? That would eventually
> allow
> > a backbort to JDK 8 as well, although I'm not quite sure yet how the
> backport
> > process is working.
> >
> > What do you think?
> >
> > Cheers,
> > Christoph
> >
> > ========= PATCH ===========
> > diff --git
> > a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation
> > Handler.java
> > b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation
> > Handler.java
> > ---
> > a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation
> > Handler.java
> > +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvoc
> > +++ ationHandler.java
> > @@ -57,13 +57,13 @@
> >
> >      public Object invoke(Object proxy, Method method, Object[] args) {
> >          String member = method.getName();
> > -        Class<?>[] paramTypes = method.getParameterTypes();
> > +        int parameterCount = method.getParameterCount();
> >
> >          // Handle Object and Annotation methods
> > -        if (member.equals("equals") && paramTypes.length == 1 &&
> > -            paramTypes[0] == Object.class)
> > +        if (parameterCount == 1 && member.equals("equals") &&
> > +            method.getParameterTypes()[0] == Object.class)
> >              return equalsImpl(proxy, args[0]);
> > -        if (paramTypes.length != 0)
> > +        if (parameterCount != 0)
> >              throw new AssertionError("Too many parameters for an
> annotation
> > method");
> >
> >          switch(member) {
>
>

From sean.mullan at oracle.com  Tue Oct 10 20:30:48 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 10 Oct 2017 16:30:48 -0400
Subject: Request for Review: Attributes.map generic types
In-Reply-To: <845306f0-7855-fe01-a017-53e96fdafb31@paratix.ch>
References: <845306f0-7855-fe01-a017-53e96fdafb31@paratix.ch>
Message-ID: <1d212c50-7a35-0a2d-992c-edd1a36068fa@oracle.com>

Cross-posting to core-libs-dev as this proposal is really more 
appropriate for review on that list.

--Sean

On 10/3/17 1:48 AM, Philipp Kunz wrote:
> Hi
> 
> This has not been asked for and there is also no bug yet but 
> nevertheless let me propose to change Attributes.map to specific generic 
> types. It looks like the type parameters were added automatically with 
> their introduction in java 5. I figure that no specific test is required 
> in this particular case because it's a pure compile-time issue which is 
> already sufficiently covered with existing code and there are also tests 
> that already now involve manifests with attributes at run-time.
> 
> Any feedback or thoughts? Would someone volunteer to sponsor it?
> 
> Regards,
> Philipp
> 
> 
> 
> ----- BEGIN PATCH -----
> diff -r 2e947e1bd907 
> src/java.base/share/classes/java/util/jar/Attributes.java
> --- a/src/java.base/share/classes/java/util/jar/Attributes.java Mon Oct 
> 02 10:04:22 2017 -0700
> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Tue Oct 
> 03 07:41:40 2017 +0200
> @@ -1,5 +1,5 @@
>  ?/*
> - * Copyright (c) 1997, 2015, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights 
> reserved.
>  ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  ? *
>  ? * This code is free software; you can redistribute it and/or modify it
> @@ -54,11 +54,11 @@
>  ? * @see???? Manifest
>  ? * @since?? 1.2
>  ? */
> -public class Attributes implements Map<Object,Object>, Cloneable {
> +public class Attributes implements Map<Attributes.Name, String>, 
> Cloneable {
>  ???? /**
>  ????? * The attribute name-value mappings.
>  ????? */
> -??? protected Map<Object,Object> map;
> +??? protected Map<Name, String> map;
> 
>  ???? /**
>  ????? * Constructs a new, empty Attributes object with default size.
> @@ -87,7 +87,6 @@
>  ???????? map = new LinkedHashMap<>(attr);
>  ???? }
> 
> -
>  ???? /**
>  ????? * Returns the value of the specified attribute name, or null if the
>  ????? * attribute name was not found.
> @@ -96,7 +95,7 @@
>  ????? * @return the value of the specified attribute name, or null if
>  ????? *???????? not found.
>  ????? */
> -??? public Object get(Object name) {
> +??? public String get(Object name) {
>  ???????? return map.get(name);
>  ???? }
> 
> @@ -116,7 +115,7 @@
>  ????? * @throws IllegalArgumentException if the attribute name is invalid
>  ????? */
>  ???? public String getValue(String name) {
> -??????? return (String)get(new Attributes.Name(name));
> +??????? return get(new Attributes.Name(name));
>  ???? }
> 
>  ???? /**
> @@ -133,7 +132,7 @@
>  ????? *???????? not found.
>  ????? */
>  ???? public String getValue(Name name) {
> -??????? return (String)get(name);
> +??????? return get(name);
>  ???? }
> 
>  ???? /**
> @@ -144,11 +143,9 @@
>  ????? * @param name the attribute name
>  ????? * @param value the attribute value
>  ????? * @return the previous value of the attribute, or null if none
> -???? * @exception ClassCastException if the name is not a Attributes.Name
> -???? *??????????? or the value is not a String
>  ????? */
> -??? public Object put(Object name, Object value) {
> -??????? return map.put((Attributes.Name)name, (String)value);
> +??? public String put(Attributes.Name name, String value) {
> +??????? return map.put(name, value);
>  ???? }
> 
>  ???? /**
> @@ -168,7 +165,7 @@
>  ????? * @exception IllegalArgumentException if the attribute name is 
> invalid
>  ????? */
>  ???? public String putValue(String name, String value) {
> -??????? return (String)put(new Name(name), value);
> +??????? return put(new Name(name), value);
>  ???? }
> 
>  ???? /**
> @@ -178,7 +175,7 @@
>  ????? * @param name attribute name
>  ????? * @return the previous value of the attribute, or null if none
>  ????? */
> -??? public Object remove(Object name) {
> +??? public String remove(Object name) {
>  ???????? return map.remove(name);
>  ???? }
> 
> @@ -208,15 +205,14 @@
>  ????? * Copies all of the attribute name-value mappings from the specified
>  ????? * Attributes to this Map. Duplicate mappings will be replaced.
>  ????? *
> -???? * @param attr the Attributes to be stored in this map
> -???? * @exception ClassCastException if attr is not an Attributes
> +???? * @param attr the attributes to be stored in this map, may also be of
> +???? *???????????? type {@link Attributes}
>  ????? */
> -??? public void putAll(Map<?,?> attr) {
> -??????? // ## javac bug?
> -??????? if (!Attributes.class.isInstance(attr))
> -??????????? throw new ClassCastException();
> -??????? for (Map.Entry<?,?> me : (attr).entrySet())
> +??? public void putAll(Map<? extends Name, ? extends String> attr) {
> +??????? for (Map.Entry<? extends Name, ? extends String> me
> +??????? ??? ??? : attr.entrySet()) {
>  ???????????? put(me.getKey(), me.getValue());
> +??????? }
>  ???? }
> 
>  ???? /**
> @@ -243,14 +239,14 @@
>  ???? /**
>  ????? * Returns a Set view of the attribute names (keys) contained in 
> this Map.
>  ????? */
> -??? public Set<Object> keySet() {
> +??? public Set<Name> keySet() {
>  ???????? return map.keySet();
>  ???? }
> 
>  ???? /**
>  ????? * Returns a Collection view of the attribute values contained in 
> this Map.
>  ????? */
> -??? public Collection<Object> values() {
> +??? public Collection<String> values() {
>  ???????? return map.values();
>  ???? }
> 
> @@ -258,7 +254,7 @@
>  ????? * Returns a Collection view of the attribute name-value mappings
>  ????? * contained in this Map.
>  ????? */
> -??? public Set<Map.Entry<Object,Object>> entrySet() {
> +??? public Set<Map.Entry<Name, String>> entrySet() {
>  ???????? return map.entrySet();
>  ???? }
> 
> @@ -290,7 +286,7 @@
>  ????? * the Attributes returned can be safely modified without affecting
>  ????? * the original.
>  ????? */
> -??? public Object clone() {
> +??? public Attributes clone() {
>  ???????? return new Attributes(this);
>  ???? }
> 
> @@ -300,12 +296,12 @@
>  ????? */
>  ????? @SuppressWarnings("deprecation")
>  ????? void write(DataOutputStream os) throws IOException {
> -???????? for (Entry<Object, Object> e : entrySet()) {
> +???????? for (Entry<Name, String> e : entrySet()) {
>  ????????????? StringBuffer buffer = new StringBuffer(
> -???????????????????????????????????????? ((Name) e.getKey()).toString());
> +???????????????? e.getKey().toString());
>  ????????????? buffer.append(": ");
> 
> -???????????? String value = (String) e.getValue();
> +???????????? String value = e.getValue();
>  ????????????? if (value != null) {
>  ????????????????? byte[] vb = value.getBytes("UTF8");
>  ????????????????? value = new String(vb, 0, 0, vb.length);
> @@ -343,14 +339,14 @@
> 
>  ???????? // write out all attributes except for the version
>  ???????? // we wrote out earlier
> -??????? for (Entry<Object, Object> e : entrySet()) {
> -??????????? String name = ((Name) e.getKey()).toString();
> +??????? for (Entry<Name, String> e : entrySet()) {
> +??????????? String name = e.getKey().toString();
>  ???????????? if ((version != null) && !(name.equalsIgnoreCase(vername))) {
> 
>  ???????????????? StringBuffer buffer = new StringBuffer(name);
>  ???????????????? buffer.append(": ");
> 
> -??????????????? String value = (String) e.getValue();
> +??????????????? String value = e.getValue();
>  ???????????????? if (value != null) {
>  ???????????????????? byte[] vb = value.getBytes("UTF8");
>  ???????????????????? value = new String(vb, 0, 0, vb.length);
> diff -r 2e947e1bd907 
> src/java.base/share/classes/sun/net/www/protocol/jar/URLJarFile.java
> --- 
> a/src/java.base/share/classes/sun/net/www/protocol/jar/URLJarFile.java 
> Mon Oct 02 10:04:22 2017 -0700
> +++ 
> b/src/java.base/share/classes/sun/net/www/protocol/jar/URLJarFile.java 
> Tue Oct 03 07:41:40 2017 +0200
> @@ -1,5 +1,5 @@
>  ?/*
> - * Copyright (c) 2001, 2016, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 2001, 2017, Oracle and/or its affiliates. All rights 
> reserved.
>  ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  ? *
>  ? * This code is free software; you can redistribute it and/or modify it
> @@ -148,14 +148,14 @@
> 
>  ???????? Manifest man = new Manifest();
>  ???????? Attributes attr = man.getMainAttributes();
> -??????? attr.putAll((Map)superAttr.clone());
> +??????? attr.putAll(superAttr.clone());
> 
>  ???????? // now deep copy the manifest entries
>  ???????? if (superEntries != null) {
>  ???????????? Map<String, Attributes> entries = man.getEntries();
>  ???????????? for (String key : superEntries.keySet()) {
>  ???????????????? Attributes at = superEntries.get(key);
> -??????????????? entries.put(key, (Attributes) at.clone());
> +??????????????? entries.put(key, at.clone());
>  ???????????? }
>  ???????? }
> 
> @@ -261,7 +261,7 @@
>  ???????????????? if (e != null) {
>  ???????????????????? Attributes a = e.get(getName());
>  ???????????????????? if (a != null)
> -??????????????????????? return? (Attributes)a.clone();
> +??????????????????????? return a.clone();
>  ???????????????? }
>  ???????????? }
>  ???????????? return null;
> diff -r 2e947e1bd907 
> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java
> --- 
> a/src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java 
> Mon Oct 02 10:04:22 2017 -0700
> +++ 
> b/src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java 
> Tue Oct 03 07:41:40 2017 +0200
> @@ -30,6 +30,7 @@
>  ?import java.security.CodeSigner;
>  ?import java.util.*;
>  ?import java.util.jar.*;
> +import java.util.jar.Attributes.Name;
> 
>  ?import java.util.Base64;
> 
> @@ -122,7 +123,7 @@
>  ???????????? }
>  ???????? }
> 
> -??????? for (Map.Entry<Object,Object> se : attr.entrySet()) {
> +??????? for (Map.Entry<Name, String> se : attr.entrySet()) {
>  ???????????? String key = se.getKey().toString();
> 
>  ???????????? if (key.toUpperCase(Locale.ENGLISH).endsWith("-DIGEST")) {
> @@ -146,7 +147,7 @@
>  ???????????????????? digest.reset();
>  ???????????????????? digests.add(digest);
>  ???????????????????? manifestHashes.add(
> - Base64.getMimeDecoder().decode((String)se.getValue()));
> + Base64.getMimeDecoder().decode(se.getValue()));
>  ???????????????? }
>  ???????????? }
>  ???????? }
> diff -r 2e947e1bd907 
> src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java
> --- 
> a/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java 
> Mon Oct 02 10:04:22 2017 -0700
> +++ 
> b/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java 
> Tue Oct 03 07:41:40 2017 +0200
> @@ -46,6 +46,7 @@
>  ?import java.util.Locale;
>  ?import java.util.Map;
>  ?import java.util.jar.Attributes;
> +import java.util.jar.Attributes.Name;
>  ?import java.util.jar.JarException;
>  ?import java.util.jar.JarFile;
>  ?import java.util.jar.Manifest;
> @@ -445,7 +446,7 @@
>  ???????? boolean validEntry = false;
> 
>  ???????? // go through all the attributes and process *-Digest-Manifest 
> entries
> -??????? for (Map.Entry<Object,Object> se : mattr.entrySet()) {
> +??????? for (Map.Entry<Name, String> se : mattr.entrySet()) {
> 
>  ???????????? String key = se.getKey().toString();
> 
> @@ -469,7 +470,7 @@
>  ???????????????? if (digest != null) {
>  ???????????????????? byte[] computedHash = md.manifestDigest(digest);
>  ???????????????????? byte[] expectedHash =
> - Base64.getMimeDecoder().decode((String)se.getValue());
> + Base64.getMimeDecoder().decode(se.getValue());
> 
>  ???????????????????? if (debug != null) {
>  ???????????????????????? debug.println("Signature File: Manifest digest " +
> @@ -517,7 +518,7 @@
> 
>  ???????? // go through all the attributes and process
>  ???????? // digest entries for the manifest main attributes
> -??????? for (Map.Entry<Object,Object> se : mattr.entrySet()) {
> +??????? for (Map.Entry<Name, String> se : mattr.entrySet()) {
>  ???????????? String key = se.getKey().toString();
> 
>  ???????????? if (key.toUpperCase(Locale.ENGLISH).endsWith(ATTR_DIGEST)) {
> @@ -540,7 +541,7 @@
>  ???????????????????????? md.get(ManifestDigester.MF_MAIN_ATTRS, false);
>  ???????????????????? byte[] computedHash = mde.digest(digest);
>  ???????????????????? byte[] expectedHash =
> - Base64.getMimeDecoder().decode((String)se.getValue());
> + Base64.getMimeDecoder().decode(se.getValue());
> 
>  ???????????????????? if (debug != null) {
>  ????????????????????? debug.println("Signature File: " +
> @@ -620,7 +621,7 @@
>  ???????????? //hex.encodeBuffer(data, System.out);
> 
>  ???????????? // go through all the attributes and process *-Digest entries
> -??????????? for (Map.Entry<Object,Object> se : sfAttr.entrySet()) {
> +??????????? for (Map.Entry<Name, String> se : sfAttr.entrySet()) {
>  ???????????????? String key = se.getKey().toString();
> 
>  ???????????????? if (key.toUpperCase(Locale.ENGLISH).endsWith("-DIGEST")) {
> @@ -643,7 +644,7 @@
>  ???????????????????????? boolean ok = false;
> 
>  ???????????????????????? byte[] expected =
> - Base64.getMimeDecoder().decode((String)se.getValue());
> + Base64.getMimeDecoder().decode(se.getValue());
>  ???????????????????????? byte[] computed;
>  ???????????????????????? if (workaround) {
>  ???????????????????????????? computed = mde.digestWorkaround(digest);
> diff -r 2e947e1bd907 
> src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
> --- 
> a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java 
> Mon Oct 02 10:04:22 2017 -0700
> +++ 
> b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java 
> Tue Oct 03 07:41:40 2017 +0200
> @@ -685,7 +685,7 @@
>  ???????????? // Manifest exists. Read its raw bytes.
>  ???????????? mfRawBytes = zipFile.getInputStream(mfFile).readAllBytes();
>  ???????????? manifest.read(new ByteArrayInputStream(mfRawBytes));
> -??????????? oldAttr = (Attributes) (manifest.getMainAttributes().clone());
> +??????????? oldAttr = manifest.getMainAttributes().clone();
>  ???????? } else {
>  ???????????? // Create new manifest
>  ???????????? Attributes mattr = manifest.getMainAttributes();
> ----- END PATCH -----
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Paratix GmbH
> St Peterhofstatt 11
> 8001 Z?rich
> 
> +41 (0)76 397 79 35
> philipp.kunz at paratix.ch <mailto:philipp.kunz at paratix.ch>

From peter.levart at gmail.com  Tue Oct 10 21:28:51 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 10 Oct 2017 23:28:51 +0200
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <96cf434b-aa72-158f-515f-089a63c25c4d@oracle.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
 <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
 <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
 <b73b681e-efd7-edaa-9c92-9da2f63de847@oracle.com>
 <57e0b49a-bed6-25c2-7d01-b87f08d82a75@oracle.com>
 <376a0876-d94b-8775-873c-bfd741614273@gmail.com>
 <96cf434b-aa72-158f-515f-089a63c25c4d@oracle.com>
Message-ID: <d630b43e-06c9-1581-b19f-c9176e3c0914@gmail.com>

Hi Mandy,

On 10/10/17 17:00, mandy chung wrote:
>> Now that (system)nativeLibraries is a Map, is it still necessary to 
>> iterate it and call lib.findEntry(name) on each NativeLibrary until 
>> the one that returns a non-zero entry or would it be semantically 
>> equivalent to 1st look-up the Map by the 'name' key to get the 
>> correct NativeLibrary?
>>
> The name parameter is the symbol name but not the library name. It's 
> confusing and therefore I renamed NativeLibrary::find to 
> NativeLibrary::findEntry.?? I could rename the name parameter to 
> entryName to make it clearer.
>
> Mandy

Oh, I see. I haven't checked the findNative VM call-back method purpose 
before. It's reasonable to try all the native libraries of a ClassLoader 
when looking for a symbol that links to native method implementation. 
Constructing and keeping an index of symbols for each native library on 
the Java side is probably not worth since there might be lots of them in 
libraries and only some of them link to native method implementations 
and there's typically not many native libraries loaded.

Regards, Peter


From mandy.chung at oracle.com  Tue Oct 10 21:31:55 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 10 Oct 2017 14:31:55 -0700
Subject: Review Request JDK-8164512: Replace ClassLoader use of finalizer
 with phantom reference to unload native library
In-Reply-To: <d630b43e-06c9-1581-b19f-c9176e3c0914@gmail.com>
References: <1643128c-8714-4d6d-253a-b7413a5eb8ef@oracle.com>
 <859f3acc-2330-9c9c-39c8-be894f007585@oracle.com>
 <8d22132f-b8f4-a65e-88ad-f9af3a6d49a4@oracle.com>
 <c3fce8fb-9daa-b9fd-35ec-f2a1ce5990f5@oracle.com>
 <d3a5b12a-d97d-df4c-6227-96d04bf57c26@oracle.com>
 <2cadf6bf-6fd5-5c7a-f9f3-53031ee50a9b@oracle.com>
 <4eeb8628-28af-3c19-7ed6-feb179ed5620@oracle.com>
 <33edcd76-d057-45cf-2edd-b461d27214b5@oracle.com>
 <b73b681e-efd7-edaa-9c92-9da2f63de847@oracle.com>
 <57e0b49a-bed6-25c2-7d01-b87f08d82a75@oracle.com>
 <376a0876-d94b-8775-873c-bfd741614273@gmail.com>
 <96cf434b-aa72-158f-515f-089a63c25c4d@oracle.com>
 <d630b43e-06c9-1581-b19f-c9176e3c0914@gmail.com>
Message-ID: <c552fcf5-e852-5aa4-05d5-eb4ce318809c@oracle.com>



On 10/10/17 2:28 PM, Peter Levart wrote:
> Hi Mandy,
>
> On 10/10/17 17:00, mandy chung wrote:
>>> Now that (system)nativeLibraries is a Map, is it still necessary to 
>>> iterate it and call lib.findEntry(name) on each NativeLibrary until 
>>> the one that returns a non-zero entry or would it be semantically 
>>> equivalent to 1st look-up the Map by the 'name' key to get the 
>>> correct NativeLibrary?
>>>
>> The name parameter is the symbol name but not the library name. It's 
>> confusing and therefore I renamed NativeLibrary::find to 
>> NativeLibrary::findEntry.?? I could rename the name parameter to 
>> entryName to make it clearer.
>>
>> Mandy
>
> Oh, I see. I haven't checked the findNative VM call-back method 
> purpose before. It's reasonable to try all the native libraries of a 
> ClassLoader when looking for a symbol that links to native method 
> implementation. Constructing and keeping an index of symbols for each 
> native library on the Java side is probably not worth since there 
> might be lots of them in libraries and only some of them link to 
> native method implementations and there's typically not many native 
> libraries loaded.
Exactly.

Mandy

From xueming.shen at oracle.com  Tue Oct 10 22:22:08 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 10 Oct 2017 15:22:08 -0700
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <b4b860b8-93a1-e3cc-19c0-f7239d74a8d9@gmail.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com>
 <32f3d1cc-0423-f28e-279f-900a8df564e2@gmail.com> <59CEDF26.60301@oracle.com>
 <b4b860b8-93a1-e3cc-19c0-f7239d74a8d9@gmail.com>
Message-ID: <59DD4810.3090405@oracle.com>


Peter,

Webrev has been updated accordingly to remove the "inflater" from the
"streams" as the "value" of the map. As suggested, the "streams" now
itself is a "set".

And, a package private "Infater()" has been added to avoid registering the
inflater to Cleaner for those inflaters from ZipFile.

Many,

The @apiNote has been updated accordingly to remove the words regarding
"finalize() overriding".

http://cr.openjdk.java.net/~sherman/8185582/webrev/

Thanks,
Sherman

On 9/30/17, 12:41 AM, Peter Levart wrote:
>
>
> Right, the Inflater is captured by the cleaning function for the 
> ZipFileInflaterInputStream and is kept strongly reachable until the 
> function fires, which may happen automatically or manually. At that 
> time, it is returned to the inflaters cache, which is rooted at the 
> ZipFile instance and also captured by the ZipFile cleaning function - 
> the Releaser, which is strongly reachable until fired. So I claim that 
> there is no possibility for Inflaters used in ZipFile to ever get 
> cleaned-up (ended) automatically by their cleaner functions as a 
> result of getting phantom reachable. The situation has changed. It 
> could even be beneficial to create a package-private Inflater 
> constructor for this case, which creates Inflaters without cleaner 
> registration.
>
> Regards, Peter
>


From forax at univ-mlv.fr  Tue Oct 10 22:24:03 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 11 Oct 2017 00:24:03 +0200 (CEST)
Subject: Request for Review: Attributes.map generic types
In-Reply-To: <1d212c50-7a35-0a2d-992c-edd1a36068fa@oracle.com>
References: <845306f0-7855-fe01-a017-53e96fdafb31@paratix.ch>
 <1d212c50-7a35-0a2d-992c-edd1a36068fa@oracle.com>
Message-ID: <910995174.1064389.1507674243972.JavaMail.zimbra@u-pem.fr>

Hi Philipp,
a simple code like this will break !

Attributes attrs = ...
Map<Object,Object> map = attrs;

And to answer to your question, no ! type parameters were not introduced automatically but carefully by hand in order to be backward compatible.
Attributes was introduced before 1.5 so people wrote codes putting any attributes dynamically into the map, by example a pair of String. So you can not change the type arguments without breaking a lot of codes.
Exposing Attributes as a Map or declaring the field 'map' as protected were mistakes because it shows too many details of the implementation. (java.util.Properties was retrofitted the same way for the same reason).

regards,
R?mi

----- Mail original -----
> De: "Sean Mullan" <sean.mullan at oracle.com>
> ?: "Philipp Kunz" <philipp.kunz at paratix.ch>, security-dev at openjdk.java.net
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 10 Octobre 2017 22:30:48
> Objet: Re: Request for Review: Attributes.map generic types

> Cross-posting to core-libs-dev as this proposal is really more
> appropriate for review on that list.
> 
> --Sean
> 
> On 10/3/17 1:48 AM, Philipp Kunz wrote:
>> Hi
>> 
>> This has not been asked for and there is also no bug yet but
>> nevertheless let me propose to change Attributes.map to specific generic
>> types. It looks like the type parameters were added automatically with
>> their introduction in java 5. I figure that no specific test is required
>> in this particular case because it's a pure compile-time issue which is
>> already sufficiently covered with existing code and there are also tests
>> that already now involve manifests with attributes at run-time.
>> 
>> Any feedback or thoughts? Would someone volunteer to sponsor it?
>> 
>> Regards,
>> Philipp
>> 
>> 
>> 
>> ----- BEGIN PATCH -----
>> diff -r 2e947e1bd907
>> src/java.base/share/classes/java/util/jar/Attributes.java
>> --- a/src/java.base/share/classes/java/util/jar/Attributes.java Mon Oct
>> 02 10:04:22 2017 -0700
>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Tue Oct
>> 03 07:41:40 2017 +0200
>> @@ -1,5 +1,5 @@
>>  ?/*
>> - * Copyright (c) 1997, 2015, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights
>> reserved.
>>  ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  ? *
>>  ? * This code is free software; you can redistribute it and/or modify it
>> @@ -54,11 +54,11 @@
>>  ? * @see???? Manifest
>>  ? * @since?? 1.2
>>  ? */
>> -public class Attributes implements Map<Object,Object>, Cloneable {
>> +public class Attributes implements Map<Attributes.Name, String>,
>> Cloneable {
>>  ???? /**
>>  ????? * The attribute name-value mappings.
>>  ????? */
>> -??? protected Map<Object,Object> map;
>> +??? protected Map<Name, String> map;
>> 
>>  ???? /**
>>  ????? * Constructs a new, empty Attributes object with default size.
>> @@ -87,7 +87,6 @@
>>  ???????? map = new LinkedHashMap<>(attr);
>>  ???? }
>> 
>> -
>>  ???? /**
>>  ????? * Returns the value of the specified attribute name, or null if the
>>  ????? * attribute name was not found.
>> @@ -96,7 +95,7 @@
>>  ????? * @return the value of the specified attribute name, or null if
>>  ????? *???????? not found.
>>  ????? */
>> -??? public Object get(Object name) {
>> +??? public String get(Object name) {
>>  ???????? return map.get(name);
>>  ???? }
>> 
>> @@ -116,7 +115,7 @@
>>  ????? * @throws IllegalArgumentException if the attribute name is invalid
>>  ????? */
>>  ???? public String getValue(String name) {
>> -??????? return (String)get(new Attributes.Name(name));
>> +??????? return get(new Attributes.Name(name));
>>  ???? }
>> 
>>  ???? /**
>> @@ -133,7 +132,7 @@
>>  ????? *???????? not found.
>>  ????? */
>>  ???? public String getValue(Name name) {
>> -??????? return (String)get(name);
>> +??????? return get(name);
>>  ???? }
>> 
>>  ???? /**
>> @@ -144,11 +143,9 @@
>>  ????? * @param name the attribute name
>>  ????? * @param value the attribute value
>>  ????? * @return the previous value of the attribute, or null if none
>> -???? * @exception ClassCastException if the name is not a Attributes.Name
>> -???? *??????????? or the value is not a String
>>  ????? */
>> -??? public Object put(Object name, Object value) {
>> -??????? return map.put((Attributes.Name)name, (String)value);
>> +??? public String put(Attributes.Name name, String value) {
>> +??????? return map.put(name, value);
>>  ???? }
>> 
>>  ???? /**
>> @@ -168,7 +165,7 @@
>>  ????? * @exception IllegalArgumentException if the attribute name is
>> invalid
>>  ????? */
>>  ???? public String putValue(String name, String value) {
>> -??????? return (String)put(new Name(name), value);
>> +??????? return put(new Name(name), value);
>>  ???? }
>> 
>>  ???? /**
>> @@ -178,7 +175,7 @@
>>  ????? * @param name attribute name
>>  ????? * @return the previous value of the attribute, or null if none
>>  ????? */
>> -??? public Object remove(Object name) {
>> +??? public String remove(Object name) {
>>  ???????? return map.remove(name);
>>  ???? }
>> 
>> @@ -208,15 +205,14 @@
>>  ????? * Copies all of the attribute name-value mappings from the specified
>>  ????? * Attributes to this Map. Duplicate mappings will be replaced.
>>  ????? *
>> -???? * @param attr the Attributes to be stored in this map
>> -???? * @exception ClassCastException if attr is not an Attributes
>> +???? * @param attr the attributes to be stored in this map, may also be of
>> +???? *???????????? type {@link Attributes}
>>  ????? */
>> -??? public void putAll(Map<?,?> attr) {
>> -??????? // ## javac bug?
>> -??????? if (!Attributes.class.isInstance(attr))
>> -??????????? throw new ClassCastException();
>> -??????? for (Map.Entry<?,?> me : (attr).entrySet())
>> +??? public void putAll(Map<? extends Name, ? extends String> attr) {
>> +??????? for (Map.Entry<? extends Name, ? extends String> me
>> +??????? ??? ??? : attr.entrySet()) {
>>  ???????????? put(me.getKey(), me.getValue());
>> +??????? }
>>  ???? }
>> 
>>  ???? /**
>> @@ -243,14 +239,14 @@
>>  ???? /**
>>  ????? * Returns a Set view of the attribute names (keys) contained in
>> this Map.
>>  ????? */
>> -??? public Set<Object> keySet() {
>> +??? public Set<Name> keySet() {
>>  ???????? return map.keySet();
>>  ???? }
>> 
>>  ???? /**
>>  ????? * Returns a Collection view of the attribute values contained in
>> this Map.
>>  ????? */
>> -??? public Collection<Object> values() {
>> +??? public Collection<String> values() {
>>  ???????? return map.values();
>>  ???? }
>> 
>> @@ -258,7 +254,7 @@
>>  ????? * Returns a Collection view of the attribute name-value mappings
>>  ????? * contained in this Map.
>>  ????? */
>> -??? public Set<Map.Entry<Object,Object>> entrySet() {
>> +??? public Set<Map.Entry<Name, String>> entrySet() {
>>  ???????? return map.entrySet();
>>  ???? }
>> 
>> @@ -290,7 +286,7 @@
>>  ????? * the Attributes returned can be safely modified without affecting
>>  ????? * the original.
>>  ????? */
>> -??? public Object clone() {
>> +??? public Attributes clone() {
>>  ???????? return new Attributes(this);
>>  ???? }
>> 
>> @@ -300,12 +296,12 @@
>>  ????? */
>>  ????? @SuppressWarnings("deprecation")
>>  ????? void write(DataOutputStream os) throws IOException {
>> -???????? for (Entry<Object, Object> e : entrySet()) {
>> +???????? for (Entry<Name, String> e : entrySet()) {
>>  ????????????? StringBuffer buffer = new StringBuffer(
>> -???????????????????????????????????????? ((Name) e.getKey()).toString());
>> +???????????????? e.getKey().toString());
>>  ????????????? buffer.append(": ");
>> 
>> -???????????? String value = (String) e.getValue();
>> +???????????? String value = e.getValue();
>>  ????????????? if (value != null) {
>>  ????????????????? byte[] vb = value.getBytes("UTF8");
>>  ????????????????? value = new String(vb, 0, 0, vb.length);
>> @@ -343,14 +339,14 @@
>> 
>>  ???????? // write out all attributes except for the version
>>  ???????? // we wrote out earlier
>> -??????? for (Entry<Object, Object> e : entrySet()) {
>> -??????????? String name = ((Name) e.getKey()).toString();
>> +??????? for (Entry<Name, String> e : entrySet()) {
>> +??????????? String name = e.getKey().toString();
>>  ???????????? if ((version != null) && !(name.equalsIgnoreCase(vername))) {
>> 
>>  ???????????????? StringBuffer buffer = new StringBuffer(name);
>>  ???????????????? buffer.append(": ");
>> 
>> -??????????????? String value = (String) e.getValue();
>> +??????????????? String value = e.getValue();
>>  ???????????????? if (value != null) {
>>  ???????????????????? byte[] vb = value.getBytes("UTF8");
>>  ???????????????????? value = new String(vb, 0, 0, vb.length);
>> diff -r 2e947e1bd907
>> src/java.base/share/classes/sun/net/www/protocol/jar/URLJarFile.java
>> ---
>> a/src/java.base/share/classes/sun/net/www/protocol/jar/URLJarFile.java
>> Mon Oct 02 10:04:22 2017 -0700
>> +++
>> b/src/java.base/share/classes/sun/net/www/protocol/jar/URLJarFile.java
>> Tue Oct 03 07:41:40 2017 +0200
>> @@ -1,5 +1,5 @@
>>  ?/*
>> - * Copyright (c) 2001, 2016, Oracle and/or its affiliates. All rights
>> reserved.
>> + * Copyright (c) 2001, 2017, Oracle and/or its affiliates. All rights
>> reserved.
>>  ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  ? *
>>  ? * This code is free software; you can redistribute it and/or modify it
>> @@ -148,14 +148,14 @@
>> 
>>  ???????? Manifest man = new Manifest();
>>  ???????? Attributes attr = man.getMainAttributes();
>> -??????? attr.putAll((Map)superAttr.clone());
>> +??????? attr.putAll(superAttr.clone());
>> 
>>  ???????? // now deep copy the manifest entries
>>  ???????? if (superEntries != null) {
>>  ???????????? Map<String, Attributes> entries = man.getEntries();
>>  ???????????? for (String key : superEntries.keySet()) {
>>  ???????????????? Attributes at = superEntries.get(key);
>> -??????????????? entries.put(key, (Attributes) at.clone());
>> +??????????????? entries.put(key, at.clone());
>>  ???????????? }
>>  ???????? }
>> 
>> @@ -261,7 +261,7 @@
>>  ???????????????? if (e != null) {
>>  ???????????????????? Attributes a = e.get(getName());
>>  ???????????????????? if (a != null)
>> -??????????????????????? return? (Attributes)a.clone();
>> +??????????????????????? return a.clone();
>>  ???????????????? }
>>  ???????????? }
>>  ???????????? return null;
>> diff -r 2e947e1bd907
>> src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java
>> ---
>> a/src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java
>> Mon Oct 02 10:04:22 2017 -0700
>> +++
>> b/src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java
>> Tue Oct 03 07:41:40 2017 +0200
>> @@ -30,6 +30,7 @@
>>  ?import java.security.CodeSigner;
>>  ?import java.util.*;
>>  ?import java.util.jar.*;
>> +import java.util.jar.Attributes.Name;
>> 
>>  ?import java.util.Base64;
>> 
>> @@ -122,7 +123,7 @@
>>  ???????????? }
>>  ???????? }
>> 
>> -??????? for (Map.Entry<Object,Object> se : attr.entrySet()) {
>> +??????? for (Map.Entry<Name, String> se : attr.entrySet()) {
>>  ???????????? String key = se.getKey().toString();
>> 
>>  ???????????? if (key.toUpperCase(Locale.ENGLISH).endsWith("-DIGEST")) {
>> @@ -146,7 +147,7 @@
>>  ???????????????????? digest.reset();
>>  ???????????????????? digests.add(digest);
>>  ???????????????????? manifestHashes.add(
>> - Base64.getMimeDecoder().decode((String)se.getValue()));
>> + Base64.getMimeDecoder().decode(se.getValue()));
>>  ???????????????? }
>>  ???????????? }
>>  ???????? }
>> diff -r 2e947e1bd907
>> src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java
>> ---
>> a/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java
>> Mon Oct 02 10:04:22 2017 -0700
>> +++
>> b/src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java
>> Tue Oct 03 07:41:40 2017 +0200
>> @@ -46,6 +46,7 @@
>>  ?import java.util.Locale;
>>  ?import java.util.Map;
>>  ?import java.util.jar.Attributes;
>> +import java.util.jar.Attributes.Name;
>>  ?import java.util.jar.JarException;
>>  ?import java.util.jar.JarFile;
>>  ?import java.util.jar.Manifest;
>> @@ -445,7 +446,7 @@
>>  ???????? boolean validEntry = false;
>> 
>>  ???????? // go through all the attributes and process *-Digest-Manifest
>> entries
>> -??????? for (Map.Entry<Object,Object> se : mattr.entrySet()) {
>> +??????? for (Map.Entry<Name, String> se : mattr.entrySet()) {
>> 
>>  ???????????? String key = se.getKey().toString();
>> 
>> @@ -469,7 +470,7 @@
>>  ???????????????? if (digest != null) {
>>  ???????????????????? byte[] computedHash = md.manifestDigest(digest);
>>  ???????????????????? byte[] expectedHash =
>> - Base64.getMimeDecoder().decode((String)se.getValue());
>> + Base64.getMimeDecoder().decode(se.getValue());
>> 
>>  ???????????????????? if (debug != null) {
>>  ???????????????????????? debug.println("Signature File: Manifest digest " +
>> @@ -517,7 +518,7 @@
>> 
>>  ???????? // go through all the attributes and process
>>  ???????? // digest entries for the manifest main attributes
>> -??????? for (Map.Entry<Object,Object> se : mattr.entrySet()) {
>> +??????? for (Map.Entry<Name, String> se : mattr.entrySet()) {
>>  ???????????? String key = se.getKey().toString();
>> 
>>  ???????????? if (key.toUpperCase(Locale.ENGLISH).endsWith(ATTR_DIGEST)) {
>> @@ -540,7 +541,7 @@
>>  ???????????????????????? md.get(ManifestDigester.MF_MAIN_ATTRS, false);
>>  ???????????????????? byte[] computedHash = mde.digest(digest);
>>  ???????????????????? byte[] expectedHash =
>> - Base64.getMimeDecoder().decode((String)se.getValue());
>> + Base64.getMimeDecoder().decode(se.getValue());
>> 
>>  ???????????????????? if (debug != null) {
>>  ????????????????????? debug.println("Signature File: " +
>> @@ -620,7 +621,7 @@
>>  ???????????? //hex.encodeBuffer(data, System.out);
>> 
>>  ???????????? // go through all the attributes and process *-Digest entries
>> -??????????? for (Map.Entry<Object,Object> se : sfAttr.entrySet()) {
>> +??????????? for (Map.Entry<Name, String> se : sfAttr.entrySet()) {
>>  ???????????????? String key = se.getKey().toString();
>> 
>>  ???????????????? if (key.toUpperCase(Locale.ENGLISH).endsWith("-DIGEST")) {
>> @@ -643,7 +644,7 @@
>>  ???????????????????????? boolean ok = false;
>> 
>>  ???????????????????????? byte[] expected =
>> - Base64.getMimeDecoder().decode((String)se.getValue());
>> + Base64.getMimeDecoder().decode(se.getValue());
>>  ???????????????????????? byte[] computed;
>>  ???????????????????????? if (workaround) {
>>  ???????????????????????????? computed = mde.digestWorkaround(digest);
>> diff -r 2e947e1bd907
>> src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
>> ---
>> a/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
>> Mon Oct 02 10:04:22 2017 -0700
>> +++
>> b/src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
>> Tue Oct 03 07:41:40 2017 +0200
>> @@ -685,7 +685,7 @@
>>  ???????????? // Manifest exists. Read its raw bytes.
>>  ???????????? mfRawBytes = zipFile.getInputStream(mfFile).readAllBytes();
>>  ???????????? manifest.read(new ByteArrayInputStream(mfRawBytes));
>> -??????????? oldAttr = (Attributes) (manifest.getMainAttributes().clone());
>> +??????????? oldAttr = manifest.getMainAttributes().clone();
>>  ???????? } else {
>>  ???????????? // Create new manifest
>>  ???????????? Attributes mattr = manifest.getMainAttributes();
>> ----- END PATCH -----
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> 
>> 
>> Paratix GmbH
>> St Peterhofstatt 11
>> 8001 Z?rich
>> 
>> +41 (0)76 397 79 35
> > philipp.kunz at paratix.ch <mailto:philipp.kunz at paratix.ch>

From amy.lu at oracle.com  Wed Oct 11 03:30:17 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 11 Oct 2017 11:30:17 +0800
Subject: [10] RFR of JDK-8173411: Some testng tests check nothing in java time
Message-ID: <ad99a750-1fb9-82b2-dce5-490b4ff9b856@oracle.com>

Please review the patch to change TestNG.dirs and lib.dirs (def and file 
structure) for test/jdk/java/time.

test/jdk/java/time contains three sets of tests:
nontestng/
tck/
test/

Tests from directory "tck" and "test" are testng tests with properties:
TestNG.dirs = ..
lib.dirs = ../../../lib/testlibrary
lib.build = jdk.testlibrary.RandomFactory

But not all files under "TestNG.dirs" are real tests, some of them are 
"libraries" thus should not be put under "TestNG.dirs" (thus be run as 
testng test). Moreover, due to this def, when one runs tests from "test" 
directory, extra files (nontestng/* and tck/*) will also be compiled 
(which are unnecessary compiling).

In this patch:
Non-test files ("libraries") are moved to "lib" directory;
Real tests previously under "test" dir are moved to test/jdk/, and tests 
under "tck" dir are moved to test/tck/;
test/jdk/ and test/tck/ each has TEST.properties with def:
 ??? TestNG.dirs = .
 ??? lib.dirs = /java/time/lib /lib/testlibrary
MockIOExceptionAppendable.java is not used anywhere, removed.
MockSimplePeriod.java previously exist in both "tck" and "test", now it 
is under "lib".

With this change, non-test file then won't be run as testng test and no 
unnecessary compiling.

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

Thanks,
Amy


From zheng.jun.li at oracle.com  Wed Oct 11 07:26:48 2017
From: zheng.jun.li at oracle.com (Jack Li)
Date: Wed, 11 Oct 2017 15:26:48 +0800
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <B53D7902-137F-4082-930F-713D427E3CDF@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
 <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
 <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>
 <B53D7902-137F-4082-930F-713D427E3CDF@oracle.com>
Message-ID: <95066DA9-03A6-4BF1-8895-6A442548EC60@oracle.com>

Hi Lance

I will update them in Metro repository, do I need to regenerate webrev?
or can you skip the files this time and I fix it in next integration?

> On Oct 9, 2017, at 19:35, Lance Andersen <lance.andersen at oracle.com> wrote:
> 
> Hi Jack,
> 
> UnMarshaller also has the same issue.  I would update the webrev given the number of places to help sanity check for omissions
> 
> Best
> Lance
>> On Oct 8, 2017, at 9:22 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>> 
>> Hi Lance,
>> 
>> the change is incorrect, it should be ?javax/xml/bind?.
>> thanks a lot for your finding, do you think I need to fix it and resubmit the webrev this time?
>> or can you skip this file this time and I fix it in next integration?
>> 
>>> On Oct 4, 2017, at 02:09, Lance Andersen <Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>> wrote:
>>> 
>>> Hi Jack,
>>> 
>>> Is this change correct:
>>> 
>>> -------------
>>> --- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
>>> +++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
>>> @@ -373,7 +373,7 @@
>>>       *      If the {@link ValidationEventHandler ValidationEventHandler}
>>>       *      returns false from its {@code handleEvent} method or the
>>>       *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
>>> -     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
>>> +     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
>>>       *      Marshalling a JAXB element</a>.
>>> 
>>> ------------
>>> 
>>> The URL that is being changed currently works
>>> 
>>> Best
>>> Lance
>>> On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>> 
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>>
>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>>
>>>> 
>>>> Summary of changes:
>>>> 
>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>> 
>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>> 
>>>> 
>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>> 
>>>> ----------------
>>>> Best regards
>>>> Jack Li
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> <oracle_sig_logo.gif>
>>> 
>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle?Java Engineering?
>>> 1 Network Drive?
>>> Burlington, MA 01803
>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>> 
>> ----------------
>> Best regards
>> Jack Li
>> 
>> 
>> 
>> 
>> 
>> 
> 
> <oracle_sig_logo.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>
>  <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>
> 
> 
> 


----------------
Best regards
Jack Li







From lance.andersen at oracle.com  Wed Oct 11 10:47:51 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 11 Oct 2017 06:47:51 -0400
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <95066DA9-03A6-4BF1-8895-6A442548EC60@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
 <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
 <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>
 <B53D7902-137F-4082-930F-713D427E3CDF@oracle.com>
 <95066DA9-03A6-4BF1-8895-6A442548EC60@oracle.com>
Message-ID: <50F96A1B-78C3-4FC4-82E5-691E06749F29@oracle.com>

Hi Jack,

I would prefer to see an updated webrev so that we do not inadvertently
push these changes.

Best
Lance
> On Oct 11, 2017, at 3:26 AM, Jack Li <zheng.jun.li at oracle.com> wrote:
> 
> Hi Lance
> 
> I will update them in Metro repository, do I need to regenerate webrev?
> or can you skip the files this time and I fix it in next integration?
> 
>> On Oct 9, 2017, at 19:35, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>> 
>> Hi Jack,
>> 
>> UnMarshaller also has the same issue.  I would update the webrev given the number of places to help sanity check for omissions
>> 
>> Best
>> Lance
>>> On Oct 8, 2017, at 9:22 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>> 
>>> Hi Lance,
>>> 
>>> the change is incorrect, it should be ?javax/xml/bind?.
>>> thanks a lot for your finding, do you think I need to fix it and resubmit the webrev this time?
>>> or can you skip this file this time and I fix it in next integration?
>>> 
>>>> On Oct 4, 2017, at 02:09, Lance Andersen <Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>> wrote:
>>>> 
>>>> Hi Jack,
>>>> 
>>>> Is this change correct:
>>>> 
>>>> -------------
>>>> --- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
>>>> +++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
>>>> @@ -373,7 +373,7 @@
>>>>       *      If the {@link ValidationEventHandler ValidationEventHandler}
>>>>       *      returns false from its {@code handleEvent} method or the
>>>>       *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
>>>> -     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
>>>> +     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
>>>>       *      Marshalling a JAXB element</a>.
>>>> 
>>>> ------------
>>>> 
>>>> The URL that is being changed currently works
>>>> 
>>>> Best
>>>> Lance
>>>> On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>>> 
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>>
>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>>
>>>>> 
>>>>> Summary of changes:
>>>>> 
>>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>>> 
>>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>>> 
>>>>> 
>>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>>> 
>>>>> ----------------
>>>>> Best regards
>>>>> Jack Li
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> <oracle_sig_logo.gif>
>>>> 
>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle?Java Engineering?
>>>> 1 Network Drive?
>>>> Burlington, MA 01803
>>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>> 
>>> ----------------
>>> Best regards
>>> Jack Li
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> <oracle_sig_logo.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>
>>  <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>
>> 
>> 
>> 
> 
> 
> ----------------
> Best regards
> Jack Li

 <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 claes.redestad at oracle.com  Wed Oct 11 13:22:32 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 11 Oct 2017 15:22:32 +0200
Subject: jdk9/10 reject zip/jar files where seconds value of timestamp is
 out of supported range 0 - 59
In-Reply-To: <3adeb1f29fb14b958be0d2e63bacefeb@sap.com>
References: <3adeb1f29fb14b958be0d2e63bacefeb@sap.com>
Message-ID: <2d2003ff-dca4-4e39-deca-232e35d76bb1@oracle.com>

Hi Matthias,


On 2017-10-10 18:23, Baesken, Matthias wrote:
> Hi Claes, to me it looks like the old jdk8 coding is not slower than the jdk9/10 coding .

a simple and somewhat na?ve JMH benchmark to assess performance:
http://cr.openjdk.java.net/~redestad/scratch/ZipUtils.java

I've benchmarked the code I proposed to fall back to, adding a variant 
to do some
quick sanity checking to avoid exceptional control flow on common mal-formed
cases (dosToJavaTime9Bench2), and can show it doesn't hurt performance 
too much:

Benchmark???????????????????????? (dosTime)?? Mode? Cnt?? Score Error?? 
Units
ZipUtils.dosToJavaTime8Bench?? 677456332112? thrpt?? 10?? 3.723 ? 0.103? 
ops/us
ZipUtils.dosToJavaTime9Bench?? 677456332112? thrpt?? 10? 15.207 ? 0.540? 
ops/us
ZipUtils.dosToJavaTime9Bench2? 677456332112? thrpt?? 10? 14.241 ? 1.193? 
ops/us

As I recalled it's about a 4x difference.

Running this benchmark with more threads (4) shows that the JDK 8 impl 
hides a
scalability issue (Date() uses a shared calendar object, with 
synchronization to keep
it thread safe):

Benchmark???????????????????????? (dosTime)?? Mode? Cnt?? Score Error?? 
Units
ZipUtils.dosToJavaTime8Bench?? 677456332112? thrpt?? 10?? 1.441 ? 0.112? 
ops/us
ZipUtils.dosToJavaTime9Bench?? 677456332112? thrpt?? 10? 53.166 ? 0.886? 
ops/us
ZipUtils.dosToJavaTime9Bench2? 677456332112? thrpt?? 10? 52.238 ? 0.865? 
ops/us

We can see that we're slightly worse on the odd corner case of dosTime=0:

Benchmark????????????????????? (dosTime)?? Mode? Cnt?? Score Error?? Units
ZipUtils.dosToJavaTime8Bench?????????? 0? thrpt?? 10? 40.069 ? 0.719? ops/us
ZipUtils.dosToJavaTime9Bench?????????? 0? thrpt?? 10?? 2.177 ? 0.032? ops/us
ZipUtils.dosToJavaTime9Bench2????????? 0? thrpt?? 10? 33.439 ? 0.842? ops/us

... but a na?ve variant testing mixed valid/invalid inputs shows we're 
still much better
off with dosToJavaTime9Bench2:

Benchmark ? ? ? ?????????????????????? (dosTime)? (dosTime2)?? Mode 
Cnt????? Score????? Error?? Units
ZipUtilsMixed.dosToJavaTime8Bench?? 677456332112?????????? 0 thrpt??? 
5?? 1467.281 ?? 328.030? ops/ms
ZipUtilsMixed.dosToJavaTime9Bench?? 677456332112?????????? 0 thrpt??? 5? 
24412.943 ? 1151.896? ops/ms
ZipUtilsMixed.dosToJavaTime9Bench2? 677456332112?????????? 0 thrpt??? 5? 
20687.981 ? 1535.571? ops/ms

http://cr.openjdk.java.net/~redestad/scratch/ZipUtilsMixed.java

Finally we can see that we're generally faster in interpreted mode (this 
code is of
general interest to startup on many internal startup benchmarks):

Benchmark???????????????????????? (dosTime)?? Mode? Cnt??? Score Error?? 
Units
ZipUtils.dosToJavaTime8Bench?? 677456332112? thrpt??? 5? 152.447 ? 
5.899? ops/ms
ZipUtils.dosToJavaTime9Bench?? 677456332112? thrpt??? 5? 263.718 ? 
19.450? ops/ms
ZipUtils.dosToJavaTime9Bench2? 677456332112? thrpt??? 5? 266.059 ? 
5.003? ops/ms

I'll send out a RFR for an implementation similar to the 
dosToJavaTime9Bench2
experiment soon, so that we can be both backwards compatible and avoid
scalability bottlenecks.

Thanks!

/Claes

From Roger.Riggs at Oracle.com  Wed Oct 11 15:16:43 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 11 Oct 2017 11:16:43 -0400
Subject: RFR 8145635 : Add TCP_QUICKACK socket option
In-Reply-To: <F179D102-14DA-4239-811E-A95CC41ED3D8@oracle.com>
References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com>
 <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com>
 <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com>
 <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com>
 <F179D102-14DA-4239-811E-A95CC41ED3D8@oracle.com>
Message-ID: <fcf8718b-83a2-6b83-680d-f859a014e7c9@Oracle.com>

Hi Vyom,

Comments:

 ?- update copyright
 ?- use @since 18.3 instead of @since 10

- ExtendedSocketOptions.java: 265,269? include the "TCP_QUICKACK" in the 
exception messages.

 ??? Line 144: if you are going to keep the assert, add a explanation 
about how it could happen.
 ??? I'd remove the assert.

 ?- The first sentence should be a complete sentence:? "TCP_QUICKACK 
socket option enables sending TCP/IP acks immediately" or similar.

 ?- A reference to the appropriate TCP/IP spec for quickack would be a 
good addition. At least the RFC # and section.
 ?- 85: space after "."? The phrasing is a bit odd in places in the javadoc.
 ?- line 81/82 the value is true to enable and false to disable.
 ?- This phrase is confusing: "it only enables a switch to or from 
TCP_QUICKACK mode";
 ?? Since it is set on a socket, it should remain set on that socket 
until it is changed.

 ?- 203: be consistent in using enable/disable in parameters, etc even 
for private methods.
 ??? "on" -> "enable"

PlainDatagramSocketImpl: 89:
 ? Why create a new set with zero or one items just to throw it away?
 ? Use the iterator to add only the non-TCP_QUICKACK options to the 
supported options.
 ?Also, you can use ExtendedSocketOptions.TCP_QUICKACK to check for the 
option to omit without
 ?embedding the name.


Sockets.java:
 ? - The initialization of isQuickAckAvailable might be cleaner as an 
nested static class
 ??? that initializes the value in its static initializer. That would 
delay the init til needed
 ??? and avoid extra flags.

LinuxSocketOptions.java:
 ?? - the native methods should be static; since the instance is unused.

 ?- line 41: the return type should be Boolean

 ?- line 46: the return type of getQuickAck0 should be Boolean like the 
argument to set.

 ?- line 34:? using JNU_ThrowByNameWithLastError directly is sufficient; 
if the errno does not have a string unix supplies "unknown error nnn".


Regards, Roger

On 10/10/2017 2:58 PM, Chris Hegarty wrote:
> Vyom,
>
> What about suggestion 1) below, the name of the socket option?
>
> -Chris.
>
>> On 27 Sep 2017, at 09:56, vyom tewari <vyom.tewari at oracle.com> wrote:
>>
>> Hi Chris,
>>
>> Thanks for review, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.2/index.html). I incorporated review comments from you and re-base the patch to our consolidated repo(jdk10/master).
>>
>> Thanks,
>>
>> Vyom
>>
>>
>> On Monday 25 September 2017 01:57 AM, Chris Hegarty wrote:
>>> Vyom,
>>>
>>>> On 11 Sep 2017, at 16:38, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>
>>>> Hi All,
>>>>
>>>> As jdk.net API already moved out of java.base, Please review the below code change for jdk10.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145635
>>>> Webrev: http://cr.openjdk.java.net/~vtewari/8145635/webrev0.1/index.html
>>>>
>>> This looks quite good. Some comments:
>>>
>>> 1) I wonder if we should just call the option TCP_QUICKACK, rather than SO_QUICKACK? Similar to TCP_NODELAY.
>>>
>>> 2) I think LinuxSocketOptions.h is largely unnecessary, if we do 1) above.
>>>
>>> 3) Java_jdk_net_LinuxSocketOptions_getQuickAck could return jint, rather than jobject, thus avoiding the need for createBoolean. The conversation can happen in the Java layer.  Can you please reduce the lint length in this file, by wrapping similar to the style of the Solaris version.
>>>
>>> 4) ExtendedSocketOptions.java
>>>    - drop the <p>, they are unnecessary.
>>>    - I think, similar to TCP_NODELAY, the spec should say that the options is TCP specific. From TCP_NODELAY: "The socket option is specific to stream-oriented sockets using the TCP/IP protocol.?
>>>    - "In TCP_QUICKACK mode?, maybe ?When the option is enabled??
>>>
>>> -Chris.
>>>
>>>


From claes.redestad at oracle.com  Wed Oct 11 16:15:27 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 11 Oct 2017 18:15:27 +0200
Subject: RFR: 8188869: jdk9/10 reject zip/jar files where seconds value of
 timestamp is out of supported range 0 - 59
Message-ID: <61602d67-53be-cc4e-7abb-d9d85e24e678@oracle.com>

Hi,

please review this bug fix to ensure we don't reject jar
and zip files due to entries having malformed timestamps.

Webrev: http://cr.openjdk.java.net/~redestad/8188869/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8188869

I opted to only fall back to the more lenient JDK 8 version when
we need to, which is important to not re-introduce a scalability
bottleneck, see micros and results here:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049458.html

Thanks!

/Claes

From naoto.sato at oracle.com  Wed Oct 11 17:50:28 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 11 Oct 2017 10:50:28 -0700
Subject: java 9 AKST timezone parsing
In-Reply-To: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
References: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
Message-ID: <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>

(replying to appropriate aliases, instead of generic jdk9-dev alias)

Hi Cl?ment,

The locale data, where those time zone names are derived from, have been 
switched to use Unicode Consortium's CLDR, instead of the ones that are 
previously used prior to JDK9. So there will be some differences you may 
encounter. However it seems not right to parse "AKST" to SystemV time 
zone. I'd appreciate it if you file a JIRA issue for this.

In the mean time, you can revert to the JDK8 behavior by setting the 
system property "-Djava.locale.providers=COMPAT" to the command line.

HTH,
Naoto

On 10/10/17 7:37 PM, Cl?ment Guillaume wrote:
> Hello,
> 
> When parsing a date time string that contains a time zone like AKST, AKDT,
> HST or AST with a DateTimeFormatter built from a pattern containing 'z',
> java 9 returns the SystemV variant of those timezone, which then behave
> differently as the "modern" ones. Looks like it's also an issue with long
> time zone ("Alaska Standard Time")
> 
>  From my digging I noticed that the PrefixTree generated
> by ZoneTextPrinterParser.getTree is different in java 8 and java 9, and
> this may be caused by a different order in the content returned
> by TimeZoneNameUtility.getZoneStrings(Locale.getDefault())
> 
> Is this an expected behavior of java 9? (other american time zones are
> parsed to the modern version: PST -> America/Los_Angeles)
> 
> I tested it with java 9 build 9+181 and java 8 build 1.8.0_131-b11 (both
> linux 64 with en_US as local) on this code:
> 
> import java.time.ZoneOffset;
> import java.time.format.DateTimeFormatter;
> import java.time.temporal.TemporalAccessor;
> 
> public class Main{
> 
> public static void main(String[] args){
> DateTimeFormatter timezoneFormatter = DateTimeFormatter.ofPattern("z");
> TemporalAccessor temporalAccessor = timezoneFormatter.parse("AKST");
> System.out.println(temporalAccessor);
> temporalAccessor = timezoneFormatter.parse("AKDT");
> System.out.println(temporalAccessor);
> temporalAccessor = timezoneFormatter.parse("HST");
> System.out.println(temporalAccessor);
> temporalAccessor = timezoneFormatter.parse("AST");
> System.out.println(temporalAccessor);
> 
> DateTimeFormatter isoFormatter =
> DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mmX").withZone(ZoneOffset.UTC);
> temporalAccessor =
> DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSz").parse("2017-09-13T06:30:33.123AKST");
> System.out.println(temporalAccessor);
> System.out.println(isoFormatter.format(temporalAccessor));
> temporalAccessor =
> DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSVV").parse("2017-09-13T06:30:33.123America/Anchorage");
> System.out.println(temporalAccessor);
> System.out.println(isoFormatter.format(temporalAccessor));
> }
> 
> }
> 

From claes.redestad at oracle.com  Wed Oct 11 18:13:17 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 11 Oct 2017 20:13:17 +0200
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
 reflection
In-Reply-To: <000001d341f1$82764870$8762d950$@freenet.de>
References: <000001d341f1$82764870$8762d950$@freenet.de>
Message-ID: <b6524f36-29f0-452e-bf34-b4d463d3fe1d@oracle.com>

Hi,

sure, with the 6-month cadence it makes sense to push this partial fix 
to 8029019 now,
and not hinge it on whether Peter (or anyone) picks up and provides a 
satisfactory
solution to 8029019 in time.

Let's file a separate RFE and push this.? I assume you need a sponsor to 
do both?

Thanks!

/Claes

On 2017-10-10 19:59, Christoph Dreis wrote:
> Hi Claes,
>
> with JDK 9 being out - congrats to everyone - I'll try my chance to raise issue https://bugs.openjdk.java.net/browse/JDK-8029019 again.
>
> A little recap: In November 2016 I reported the unnecessary allocation of Method.getParameterTypes() in AnnotationInvocationHandler.invoke() and a patch that would fix this. As it turned out, this and other improvements were already suggested by Peter in above mentioned ticket. Because it was reasonably late in February 2017 to cover the complete story for 9, I suggested to only include the low-risk patch, which was understandably also too late.
>
> So I'm trying again to bring this into the JDK - I hope you don't mind me being so persistent on this one.
>
> For completeness find the initial patch attached below for the initial problem I was trying to solve.
>
> Cheers,
> Christoph
>
> ================================
> Reduce allocations in sun.reflect.annotation.AnnotationInvocationHandler.invoke()
>
> diff -r ba70dcd8de76 -r 86bbc5442c1d src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
> --- a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java     Fri Nov 11 13:11:27 2016 +0000
> +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java  Mon Nov 14 19:04:33 2016 +0100
> @@ -57,13 +57,13 @@
>
>       public Object invoke(Object proxy, Method method, Object[] args) {
>           String member = method.getName();
> -        Class<?>[] paramTypes = method.getParameterTypes();
> +        int parameterCount = method.getParameterCount();
>
>           // Handle Object and Annotation methods
> -        if (member.equals("equals") && paramTypes.length == 1 &&
> -            paramTypes[0] == Object.class)
> +        if (parameterCount == 1 && member.equals("equals") &&
> +            method.getParameterTypes()[0] == Object.class)
>               return equalsImpl(proxy, args[0]);
> -        if (paramTypes.length != 0)
> +        if (parameterCount != 0)
>               throw new AssertionError("Too many parameters for an annotation method");
>
>           switch(member) {
>
>> -----Original Message-----
>> From: Christoph Dreis [mailto:christoph.dreis at freenet.de]
>> Sent: Friday, February 10, 2017 11:22 AM
>> To: 'Claes Redestad' <claes.redestad at oracle.com>; 'Peter Levart'
>> <peter.levart at gmail.com>; 'Core-Libs-Dev' <core-libs-
>> dev at openjdk.java.net>
>> Subject: RE: RFR: 8029019: (ann) Optimize annotation handling in core
>> reflection
>>
>> Hi Claes,
>>
>>> I think this all seems reasonable, but subtle behavior changes like
>>> this needs more scrutiny than I can provide.  I've discussed this
>>> offline with Joe and sadly concluded it's probably too much, too late
>>> for 9 at this point.
>>>
>>> Hope you don't mind re-targetting this to JDK 10.
>> Do you mean the error handling change or the ticket in general? In case of
>> the latter, may I start a proposal?
>>
>> As the original issue for me was to reduce the allocations coming from
>> AnnotationInvocationHandler.invoke() caused by
>> Method.getParameterTypes(), what about creating a sub-ticket of 8029019
>> and just take care of the low-risk change below? That would eventually allow
>> a backbort to JDK 8 as well, although I'm not quite sure yet how the backport
>> process is working.
>>
>> What do you think?
>>
>> Cheers,
>> Christoph
>>
>> ========= PATCH ===========
>> diff --git
>> a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation
>> Handler.java
>> b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation
>> Handler.java
>> ---
>> a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation
>> Handler.java
>> +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvoc
>> +++ ationHandler.java
>> @@ -57,13 +57,13 @@
>>
>>       public Object invoke(Object proxy, Method method, Object[] args) {
>>           String member = method.getName();
>> -        Class<?>[] paramTypes = method.getParameterTypes();
>> +        int parameterCount = method.getParameterCount();
>>
>>           // Handle Object and Annotation methods
>> -        if (member.equals("equals") && paramTypes.length == 1 &&
>> -            paramTypes[0] == Object.class)
>> +        if (parameterCount == 1 && member.equals("equals") &&
>> +            method.getParameterTypes()[0] == Object.class)
>>               return equalsImpl(proxy, args[0]);
>> -        if (paramTypes.length != 0)
>> +        if (parameterCount != 0)
>>               throw new AssertionError("Too many parameters for an annotation
>> method");
>>
>>           switch(member) {


From xueming.shen at oracle.com  Wed Oct 11 20:19:26 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 11 Oct 2017 13:19:26 -0700
Subject: RFR: 8188869: jdk9/10 reject zip/jar files where seconds value
 of timestamp is out of supported range 0 - 59
In-Reply-To: <61602d67-53be-cc4e-7abb-d9d85e24e678@oracle.com>
References: <61602d67-53be-cc4e-7abb-d9d85e24e678@oracle.com>
Message-ID: <59DE7CCE.6090306@oracle.com>

+1

On 10/11/17, 9:15 AM, Claes Redestad wrote:
> Hi,
>
> please review this bug fix to ensure we don't reject jar
> and zip files due to entries having malformed timestamps.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8188869/jdk.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8188869
>
> I opted to only fall back to the more lenient JDK 8 version when
> we need to, which is important to not re-introduce a scalability
> bottleneck, see micros and results here:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049458.html 
>
>
> Thanks!
>
> /Claes


From peter.levart at gmail.com  Wed Oct 11 20:55:10 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 11 Oct 2017 22:55:10 +0200
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
 reflection
In-Reply-To: <000001d341f1$82764870$8762d950$@freenet.de>
References: <000001d341f1$82764870$8762d950$@freenet.de>
Message-ID: <58df9bf3-fb5d-958e-b4fb-1baf3d86248b@gmail.com>

Hi Christoph,

I agree to bring-in optimizations in small chunks. So your proposed 
handler invoke() method is as follows:

 ??? public Object invoke(Object proxy, Method method, Object[] args) {
 ??????? String member = method.getName();
 ??????? int parameterCount = method.getParameterCount();

 ??????? // Handle Object and Annotation methods
 ??????? if (parameterCount == 1 && member.equals("equals") &&
 ??????????? method.getParameterTypes()[0] == Object.class)
 ??????????? return equalsImpl(proxy, args[0]);
 ??????? if (parameterCount != 0)
 ??????????? throw new AssertionError("Too many parameters for an 
annotation method");

 ??????? switch(member) {
 ??????? case "toString":
 ??????????? return toStringImpl();
 ??????? case "hashCode":
 ??????????? return hashCodeImpl();
 ??????? case "annotationType":
 ??????????? return type;
 ??????? }

 ??????? // Handle annotation member accessors
 ??????? Object result = memberValues.get(member);

 ??????? if (result == null)
 ??????????? throw new IncompleteAnnotationException(type, member);

 ??????? if (result instanceof ExceptionProxy)
 ??????????? throw ((ExceptionProxy) result).generateException();

 ??????? if (result.getClass().isArray() && Array.getLength(result) != 0)
 ??????????? result = cloneArray(result);

 ??????? return result;
 ??? }


This is good, because it only retrieves/clones the parameterTypes array 
for equals() method invocation. But we might do even slightly better if 
we consider the following:

- Method.getName() returns an interned String and String literals are 
interned strings. Reference comparison is therefore possible
- The pair (declaringClass, methodName) uniquely identifies the method 
for a bunch of interesting methods when declaringClass is either 
java.lang.Object or java.lang.annotation.Annotation, so we don't need to 
obtain method's parameterTypes even for equals().


For example:

 ??? public Object invoke(Object proxy, Method method, Object[] args) {

 ??????? String memberName = method.getName(); // guaranteed interned String
 ??????? Class<?> dtype = method.getDeclaringClass();

 ??????? if (dtype == Object.class ||? // equals/hashCode/toString
 ??????????? dtype == Annotation.class // 
annotationType/equals/hashCode/toString
 ??????????? ) {
 ??????????????? assert memberName == "equals" && 
method.getParameterCount() == 1 ||
 ???????????? ????????? memberName != "equals" && 
method.getParameterCount() == 0;

 ??????????? if (memberName == "equals") return equalsImpl(proxy, args[0]);
 ??????????? if (memberName == "hashCode") return hashCodeImpl();
 ??????????? if (memberName == "annotationType") return type;
 ??????????? if (memberName == "toString") return toStringImpl();

 ??????????? // unreachable statement
 ??????????? throw new AssertionError("Invalid method: " + method);
 ??????? }

 ??????? assert dtype == type;
 ??????? assert method.getParameterCount() == 0;

 ??????? // Handle annotation member accessors
 ??????? Object result = memberValues.get(memberName);

 ??????? if (result == null)
 ??????????? throw new IncompleteAnnotationException(type, memberName);

 ??????? if (result instanceof ExceptionProxy)
 ??????????? throw ((ExceptionProxy) result).generateException();

 ??????? if (result.getClass().isArray() && Array.getLength(result) != 0)
 ??????????? result = cloneArray(result);

 ??????? return result;
 ??? }


What do you think?

Regards, Peter

On 10/10/17 19:59, Christoph Dreis wrote:
> Hi Claes,
>
> with JDK 9 being out - congrats to everyone - I'll try my chance to raise issue https://bugs.openjdk.java.net/browse/JDK-8029019 again.
>
> A little recap: In November 2016 I reported the unnecessary allocation of Method.getParameterTypes() in AnnotationInvocationHandler.invoke() and a patch that would fix this. As it turned out, this and other improvements were already suggested by Peter in above mentioned ticket. Because it was reasonably late in February 2017 to cover the complete story for 9, I suggested to only include the low-risk patch, which was understandably also too late.
>
> So I'm trying again to bring this into the JDK - I hope you don't mind me being so persistent on this one.
>
> For completeness find the initial patch attached below for the initial problem I was trying to solve.
>
> Cheers,
> Christoph
>
> ================================
> Reduce allocations in sun.reflect.annotation.AnnotationInvocationHandler.invoke()
>
> diff -r ba70dcd8de76 -r 86bbc5442c1d src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java
> --- a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java     Fri Nov 11 13:11:27 2016 +0000
> +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java  Mon Nov 14 19:04:33 2016 +0100
> @@ -57,13 +57,13 @@
>
>       public Object invoke(Object proxy, Method method, Object[] args) {
>           String member = method.getName();
> -        Class<?>[] paramTypes = method.getParameterTypes();
> +        int parameterCount = method.getParameterCount();
>
>           // Handle Object and Annotation methods
> -        if (member.equals("equals") && paramTypes.length == 1 &&
> -            paramTypes[0] == Object.class)
> +        if (parameterCount == 1 && member.equals("equals") &&
> +            method.getParameterTypes()[0] == Object.class)
>               return equalsImpl(proxy, args[0]);
> -        if (paramTypes.length != 0)
> +        if (parameterCount != 0)
>               throw new AssertionError("Too many parameters for an annotation method");
>
>           switch(member) {
>
>> -----Original Message-----
>> From: Christoph Dreis [mailto:christoph.dreis at freenet.de]
>> Sent: Friday, February 10, 2017 11:22 AM
>> To: 'Claes Redestad' <claes.redestad at oracle.com>; 'Peter Levart'
>> <peter.levart at gmail.com>; 'Core-Libs-Dev' <core-libs-
>> dev at openjdk.java.net>
>> Subject: RE: RFR: 8029019: (ann) Optimize annotation handling in core
>> reflection
>>
>> Hi Claes,
>>
>>> I think this all seems reasonable, but subtle behavior changes like
>>> this needs more scrutiny than I can provide.  I've discussed this
>>> offline with Joe and sadly concluded it's probably too much, too late
>>> for 9 at this point.
>>>
>>> Hope you don't mind re-targetting this to JDK 10.
>> Do you mean the error handling change or the ticket in general? In case of
>> the latter, may I start a proposal?
>>
>> As the original issue for me was to reduce the allocations coming from
>> AnnotationInvocationHandler.invoke() caused by
>> Method.getParameterTypes(), what about creating a sub-ticket of 8029019
>> and just take care of the low-risk change below? That would eventually allow
>> a backbort to JDK 8 as well, although I'm not quite sure yet how the backport
>> process is working.
>>
>> What do you think?
>>
>> Cheers,
>> Christoph
>>
>> ========= PATCH ===========
>> diff --git
>> a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation
>> Handler.java
>> b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation
>> Handler.java
>> ---
>> a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation
>> Handler.java
>> +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvoc
>> +++ ationHandler.java
>> @@ -57,13 +57,13 @@
>>
>>       public Object invoke(Object proxy, Method method, Object[] args) {
>>           String member = method.getName();
>> -        Class<?>[] paramTypes = method.getParameterTypes();
>> +        int parameterCount = method.getParameterCount();
>>
>>           // Handle Object and Annotation methods
>> -        if (member.equals("equals") && paramTypes.length == 1 &&
>> -            paramTypes[0] == Object.class)
>> +        if (parameterCount == 1 && member.equals("equals") &&
>> +            method.getParameterTypes()[0] == Object.class)
>>               return equalsImpl(proxy, args[0]);
>> -        if (paramTypes.length != 0)
>> +        if (parameterCount != 0)
>>               throw new AssertionError("Too many parameters for an annotation
>> method");
>>
>>           switch(member) {


From martinrb at google.com  Wed Oct 11 21:42:31 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 11 Oct 2017 14:42:31 -0700
Subject: RFR: jsr166 jdk10 integration wave 4
Message-ID: <CA+kOe0-ApLWMdA-6rAwTEysN8P7Q4Dmp9==H=t10BF8FTX9nSg@mail.gmail.com>

This wave introduces a more clickable overview Home Page:

http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html

8188900: ConcurrentLinkedDeque linearizability
8188853: java/util/concurrent/ExecutorService/Invoke.java Assertion failure
8188047: Add SplittableRandom.nextBytes
8187941: Add StampedLock stamp inspection methods
8188575: Miscellaneous changes imported from jsr166 CVS 2017-10

From naoto.sato at oracle.com  Thu Oct 12 00:11:24 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 11 Oct 2017 17:11:24 -0700
Subject: java 9 AKST timezone parsing
In-Reply-To: <CABYWF2o=cfs3-xmzR4dnVC_jHyWXHm+y6DnDQjcKLoqQvfCsGw@mail.gmail.com>
References: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
 <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>
 <CABYWF2o=cfs3-xmzR4dnVC_jHyWXHm+y6DnDQjcKLoqQvfCsGw@mail.gmail.com>
Message-ID: <b3771125-0d5a-aca1-47e8-7f163c4565f0@oracle.com>

Yes. Please go ahead and file a bug report. Thanks.

Naoto

On 10/11/17 5:04 PM, Cl?ment Guillaume wrote:
> Hi,
> 
> I verified that using java.locale.providers=COMPAT with java 9 makes the 
> AKST to be parsed as?America/Juneau
> 
> Is http://bugreport.java.com/?the correct way to file a jira?
> 
> Le?mer. 11 oct. 2017 ??10:50, Naoto Sato <naoto.sato at oracle.com 
> <mailto:naoto.sato at oracle.com>> a ?crit?:
> 
>     (replying to appropriate aliases, instead of generic jdk9-dev alias)
> 
>     Hi Cl?ment,
> 
>     The locale data, where those time zone names are derived from, have been
>     switched to use Unicode Consortium's CLDR, instead of the ones that are
>     previously used prior to JDK9. So there will be some differences you may
>     encounter. However it seems not right to parse "AKST" to SystemV time
>     zone. I'd appreciate it if you file a JIRA issue for this.
> 
>     In the mean time, you can revert to the JDK8 behavior by setting the
>     system property "-Djava.locale.providers=COMPAT" to the command line.
> 
>     HTH,
>     Naoto
> 
>     On 10/10/17 7:37 PM, Cl?ment Guillaume wrote:
>      > Hello,
>      >
>      > When parsing a date time string that contains a time zone like
>     AKST, AKDT,
>      > HST or AST with a DateTimeFormatter built from a pattern
>     containing 'z',
>      > java 9 returns the SystemV variant of those timezone, which then
>     behave
>      > differently as the "modern" ones. Looks like it's also an issue
>     with long
>      > time zone ("Alaska Standard Time")
>      >
>      >? From my digging I noticed that the PrefixTree generated
>      > by ZoneTextPrinterParser.getTree is different in java 8 and java
>     9, and
>      > this may be caused by a different order in the content returned
>      > by TimeZoneNameUtility.getZoneStrings(Locale.getDefault())
>      >
>      > Is this an expected behavior of java 9? (other american time
>     zones are
>      > parsed to the modern version: PST -> America/Los_Angeles)
>      >
>      > I tested it with java 9 build 9+181 and java 8 build
>     1.8.0_131-b11 (both
>      > linux 64 with en_US as local) on this code:
>      >
>      > import java.time.ZoneOffset;
>      > import java.time.format.DateTimeFormatter;
>      > import java.time.temporal.TemporalAccessor;
>      >
>      > public class Main{
>      >
>      > public static void main(String[] args){
>      > DateTimeFormatter timezoneFormatter =
>     DateTimeFormatter.ofPattern("z");
>      > TemporalAccessor temporalAccessor = timezoneFormatter.parse("AKST");
>      > System.out.println(temporalAccessor);
>      > temporalAccessor = timezoneFormatter.parse("AKDT");
>      > System.out.println(temporalAccessor);
>      > temporalAccessor = timezoneFormatter.parse("HST");
>      > System.out.println(temporalAccessor);
>      > temporalAccessor = timezoneFormatter.parse("AST");
>      > System.out.println(temporalAccessor);
>      >
>      > DateTimeFormatter isoFormatter =
>      >
>     DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mmX").withZone(ZoneOffset.UTC);
>      > temporalAccessor =
>      >
>     DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSz").parse("2017-09-13T06:30:33.123AKST");
>      > System.out.println(temporalAccessor);
>      > System.out.println(isoFormatter.format(temporalAccessor));
>      > temporalAccessor =
>      >
>     DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSVV").parse("2017-09-13T06:30:33.123America/Anchorage");
>      > System.out.println(temporalAccessor);
>      > System.out.println(isoFormatter.format(temporalAccessor));
>      > }
>      >
>      > }
>      >
> 

From OGATAK at jp.ibm.com  Thu Oct 12 06:07:59 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Thu, 12 Oct 2017 15:07:59 +0900
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
 <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
Message-ID: <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>

Hi Alan,

Thank you for your comment.  I was not fully aware of the possibility of 
attacking...

I updated the patch to check if the current thread is the same as the 
thread cached the loader.

Updated webreb: http://cr.openjdk.java.net/~horii/8188858/webrev.01/


Regards,
Ogata



From:   Alan Bateman <Alan.Bateman at oracle.com>
To:     Kazunori Ogata <OGATAK at jp.ibm.com>
Cc:     core-libs-dev at openjdk.java.net
Date:   2017/10/10 21:41
Subject:        Re: RFR: 8188858: Caching latestUserDefinedLoader() 
results in ObjectInputStream.readObject()



On 10/10/2017 10:50, Kazunori Ogata wrote:
> Hi Alan,
>
> Thank you for your comment.
>
> I agree that the current code is not thread safe, but I think OIS itself
> is not thread safe either.  The issue you pointed out occurs when two
> threads calls readObject()/readUnshared() simultaneously, and the result
> of such situation is undefined in any way in my understanding.  Do we 
need
> to ensure the same behavior for such an error case?
OIS is very interesting to attackers so you will need to take deliberate 
abuses of the API into account. I realize it's a pain but it's one of 
the reasons why we have to be cautious about optimizations in this area.

-Alan





From vyom.tewari at oracle.com  Thu Oct 12 09:01:42 2017
From: vyom.tewari at oracle.com (vyom tewari)
Date: Thu, 12 Oct 2017 14:31:42 +0530
Subject: RFR 8145635 : Add TCP_QUICKACK socket option
In-Reply-To: <fcf8718b-83a2-6b83-680d-f859a014e7c9@Oracle.com>
References: <56CD74E1.60309@oracle.com> <56CD7C0A.2080402@oracle.com>
 <0b0989b5-c791-a476-a82f-6c686b19c9d3@oracle.com>
 <54CDCFD4-97F5-480C-A4D9-03CEA58803B5@oracle.com>
 <82e35025-cd86-5119-3556-f0989eb3a785@oracle.com>
 <F179D102-14DA-4239-811E-A95CC41ED3D8@oracle.com>
 <fcf8718b-83a2-6b83-680d-f859a014e7c9@Oracle.com>
Message-ID: <81600a54-f514-8a47-e719-10864f59f612@oracle.com>

Hi Roger,

Thanks for the review, i incorporated all review comments from you 
except("you can use ExtendedSocketOptions.TCP_QUICKACK to check for the 
option to omit without
 ?embedding the name."). ExtendedSocketOptions.java is part of 
"jdk.net"? so we can not directly use it in java.base, hence i used the 
option name to filter "TCP_QUICKACK".

Please find the update 
webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.4/index.html).

Thanks,

Vyom


On Wednesday 11 October 2017 08:46 PM, Roger Riggs wrote:
> Hi Vyom,
>
> Comments:
>
> ?- update copyright
> ?- use @since 18.3 instead of @since 10
>
> - ExtendedSocketOptions.java: 265,269? include the "TCP_QUICKACK" in 
> the exception messages.
>
> ??? Line 144: if you are going to keep the assert, add a explanation 
> about how it could happen.
> ??? I'd remove the assert.
>
> ?- The first sentence should be a complete sentence: "TCP_QUICKACK 
> socket option enables sending TCP/IP acks immediately" or similar.
>
> ?- A reference to the appropriate TCP/IP spec for quickack would be a 
> good addition. At least the RFC # and section.
> ?- 85: space after "."? The phrasing is a bit odd in places in the 
> javadoc.
> ?- line 81/82 the value is true to enable and false to disable.
> ?- This phrase is confusing: "it only enables a switch to or from 
> TCP_QUICKACK mode";
> ?? Since it is set on a socket, it should remain set on that socket 
> until it is changed.
>
> ?- 203: be consistent in using enable/disable in parameters, etc even 
> for private methods.
> ??? "on" -> "enable"
>
> PlainDatagramSocketImpl: 89:
> ? Why create a new set with zero or one items just to throw it away?
> ? Use the iterator to add only the non-TCP_QUICKACK options to the 
> supported options.
> ?Also, you can use ExtendedSocketOptions.TCP_QUICKACK to check for the 
> option to omit without
> ?embedding the name.
>
>
> Sockets.java:
> ? - The initialization of isQuickAckAvailable might be cleaner as an 
> nested static class
> ??? that initializes the value in its static initializer. That would 
> delay the init til needed
> ??? and avoid extra flags.
>
> LinuxSocketOptions.java:
> ?? - the native methods should be static; since the instance is unused.
>
> ?- line 41: the return type should be Boolean
>
> ?- line 46: the return type of getQuickAck0 should be Boolean like the 
> argument to set.
>
> ?- line 34:? using JNU_ThrowByNameWithLastError directly is 
> sufficient; if the errno does not have a string unix supplies "unknown 
> error nnn".
>
>
> Regards, Roger
>
> On 10/10/2017 2:58 PM, Chris Hegarty wrote:
>> Vyom,
>>
>> What about suggestion 1) below, the name of the socket option?
>>
>> -Chris.
>>
>>> On 27 Sep 2017, at 09:56, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>
>>> Hi Chris,
>>>
>>> Thanks for review, please find the latest 
>>> webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.2/index.html). 
>>> I incorporated review comments from you and re-base the patch to our 
>>> consolidated repo(jdk10/master).
>>>
>>> Thanks,
>>>
>>> Vyom
>>>
>>>
>>> On Monday 25 September 2017 01:57 AM, Chris Hegarty wrote:
>>>> Vyom,
>>>>
>>>>> On 11 Sep 2017, at 16:38, vyom tewari <vyom.tewari at oracle.com> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> As jdk.net API already moved out of java.base, Please review the 
>>>>> below code change for jdk10.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145635
>>>>> Webrev: 
>>>>> http://cr.openjdk.java.net/~vtewari/8145635/webrev0.1/index.html
>>>>>
>>>> This looks quite good. Some comments:
>>>>
>>>> 1) I wonder if we should just call the option TCP_QUICKACK, rather 
>>>> than SO_QUICKACK? Similar to TCP_NODELAY.
>>>>
>>>> 2) I think LinuxSocketOptions.h is largely unnecessary, if we do 1) 
>>>> above.
>>>>
>>>> 3) Java_jdk_net_LinuxSocketOptions_getQuickAck could return jint, 
>>>> rather than jobject, thus avoiding the need for createBoolean. The 
>>>> conversation can happen in the Java layer.? Can you please reduce 
>>>> the lint length in this file, by wrapping similar to the style of 
>>>> the Solaris version.
>>>>
>>>> 4) ExtendedSocketOptions.java
>>>> ?? - drop the <p>, they are unnecessary.
>>>> ?? - I think, similar to TCP_NODELAY, the spec should say that the 
>>>> options is TCP specific. From TCP_NODELAY: "The socket option is 
>>>> specific to stream-oriented sockets using the TCP/IP protocol.?
>>>> ?? - "In TCP_QUICKACK mode?, maybe ?When the option is enabled??
>>>>
>>>> -Chris.
>>>>
>>>>
>


From cedric.champeau at gmail.com  Thu Oct 12 09:58:43 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Thu, 12 Oct 2017 11:58:43 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <8A666ED1-DC0F-43AE-B451-1122A5C498D8@oracle.com>
References: <CADQzvmmGEGDCOO1uTBF-RraMuNA9DU_3ZChFKQtBL+nebthuEA@mail.gmail.com>
 <CA+kOe08C1oWNdnijaj6k34On1BJYjFPv2azBLy4r7Yycur_9Pg@mail.gmail.com>
 <CADQzvmnDBx_UF0J0=1NvxT6T+x3+x942aV0L9xJOZ_8gC04g_g@mail.gmail.com>
 <00f301d2ce6c$55611020$00233060$@apache.org>
 <CADQzvmnX8+jcjD4zCSHoXu4cbZMQJZ2JzuFY5hR2YCWb81vdKQ@mail.gmail.com>
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 <CADQzvm=yZD0QczjWv2O3sQb=syeT8ZsXHjD=U7mTA=3aQPaEvQ@mail.gmail.com>
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
 <CA+kOe0_3J-ebfojgbtdHp5UFmd0Qn9QyH_TFWUOuSxvU5U_K7Q@mail.gmail.com>
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
 <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>
 <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>
 <8A666ED1-DC0F-43AE-B451-1122A5C498D8@oracle.com>
Message-ID: <CADQzvmmj2V3Crun+Vih4kQcZh_5givde1cuM1V89-pfSaWKMYA@mail.gmail.com>

Hi folks,

Let me resurrect this thread now that Java 9 is out (congrats to the
team!). We still have the problem, and actually some users complained about
the poor performance of Gradle under JDK 9, and it turned out to be exactly
the problem I mentioned in this thread. Now with JDK 9, everytime an
environment variable is mutated we have no choice but spawning a new
daemon, which kills performance (as well as leaves idle ones in memory
until we decide we can discard them).

We have 2 options that seem reasonable:

1. an API in 18.3 which would let us refresh the environment variables,
even if inherently unsafe (we can take the risk, if the Javadocs explains
that if you're really unlucky calling such a method could kill your VM).
2. we change the way Gradle works and force explicit declaration of all
environment variables a user script can use. Then, we would only spawn a
new VM if the current daemon environment variables do not match those
required found by the client.

But before implementing this (2) we'd like to know if others have the
problem (I feel like we're not the only ones), and if the JDK team here is
willing to provide an API for us.

Thanks a lot!

2017-05-18 10:25 GMT+02:00 Chris Hegarty <chris.hegarty at oracle.com>:

>
> > On 18 May 2017, at 09:07, David Holmes <david.holmes at oracle.com> wrote:
> >> ...
> >> The reason to use a daemon is to avoid multiple starts of a JVM
> in-between steps in a build.
> >
> > Yes, though I've been looking at this from the actual API proposal
> perspective, not the "how can we avoid the need for this API" perspective.
> >
> >> It is a great idea but the proposed implementation is at issue because
> it requires a highly questionable API be added to the JDK.
> >
> > I'm quite surprised by some of the reactions here. Given the read-once
> nature of System.getenv was never documented I expected most people to be
> surprised that it took a snapshot-on-first-use, and that reading the actual
> process environment at the time System.getenv was called would be the
> natural expectation as to how this API works.
>
> Agreed. To make sure that the spec aspect of this doesn?t fall through
> the cracks, I filed 8180592 [1] to track it.
>
> To help move the discussion forward, I think it would be useful to at least
> have an idea with a rough prototype of an API to refresh might look like.
> To that end, I put together the following webrev:
>
>   http://cr.openjdk.java.net/~chegar/refreshEnv/
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8180592

From Alan.Bateman at oracle.com  Thu Oct 12 12:35:54 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Oct 2017 13:35:54 +0100
Subject: RFR 8080225: FileInputStream cleanup should be improved
In-Reply-To: <c31522d5-60ff-0a69-88f5-01a68049bd32@Oracle.com>
References: <abbc6122-e6fa-71eb-fa85-01a419cfbfd1@Oracle.com>
 <410d0712-5ff6-5821-482a-389d6a6ac69b@oracle.com>
 <c31522d5-60ff-0a69-88f5-01a68049bd32@Oracle.com>
Message-ID: <e8edb14b-4ea1-10ca-5e12-92cde3cbe514@oracle.com>

On 04/10/2017 15:35, Roger Riggs wrote:
> Hi Mandy,
>
> Updated the webrev in place:
> ?? http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/
I skimmed the latest webrev.

The @apiNote in FIS is copied from FOS so it needs 
s/FileOutputStream/FileInputStream/.

I assume in FIS that we should skip registerCleanup when the fd is 
FileDescriptor.in, ditto in FOS and RAF where we shouldn't register for 
cleanup when the fd is one of the standard streams. Alternatively handle 
this in FileDescriptor.

I'm curious why registerCleaner invoke clears and create a new cleanup. 
There are cases where we create a FileDescriptor and set the fd or 
handle lazily but these won't be registered until set.

Otherwise I think this looks quite good.

-Alan


From neugens.limasoftware at gmail.com  Thu Oct 12 12:54:03 2017
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Thu, 12 Oct 2017 14:54:03 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <CADQzvmmj2V3Crun+Vih4kQcZh_5givde1cuM1V89-pfSaWKMYA@mail.gmail.com>
References: <CADQzvmmGEGDCOO1uTBF-RraMuNA9DU_3ZChFKQtBL+nebthuEA@mail.gmail.com>
 <CA+kOe08C1oWNdnijaj6k34On1BJYjFPv2azBLy4r7Yycur_9Pg@mail.gmail.com>
 <CADQzvmnDBx_UF0J0=1NvxT6T+x3+x942aV0L9xJOZ_8gC04g_g@mail.gmail.com>
 <00f301d2ce6c$55611020$00233060$@apache.org>
 <CADQzvmnX8+jcjD4zCSHoXu4cbZMQJZ2JzuFY5hR2YCWb81vdKQ@mail.gmail.com>
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 <CADQzvm=yZD0QczjWv2O3sQb=syeT8ZsXHjD=U7mTA=3aQPaEvQ@mail.gmail.com>
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
 <CA+kOe0_3J-ebfojgbtdHp5UFmd0Qn9QyH_TFWUOuSxvU5U_K7Q@mail.gmail.com>
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
 <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>
 <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>
 <8A666ED1-DC0F-43AE-B451-1122A5C498D8@oracle.com>
 <CADQzvmmj2V3Crun+Vih4kQcZh_5givde1cuM1V89-pfSaWKMYA@mail.gmail.com>
Message-ID: <CAGUMyaQCQXEqof74yOyqniBMCr6jJuPUnj+8QpEsY5SpJB+O0w@mail.gmail.com>

2017-10-12 11:58 GMT+02:00 C?dric Champeau <cedric.champeau at gmail.com>:

> 1. an API in 18.3 which would let us refresh the environment variables,
> even if inherently unsafe (we can take the risk, if the Javadocs explains
> that if you're really unlucky calling such a method could kill your VM).

Being a public API we would expose everyone to this risk, and the API
should be supported on all platforms maybe forever. I know other
people have different opinion here, but this seems to be high risk,
high impact to be worth.

> 2. we change the way Gradle works and force explicit declaration of all
> environment variables a user script can use. Then, we would only spawn a
> new VM if the current daemon environment variables do not match those
> required found by the client.

This.

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From Alan.Bateman at oracle.com  Thu Oct 12 13:17:48 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Oct 2017 14:17:48 +0100
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
 <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
Message-ID: <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>

On 12/10/2017 07:07, Kazunori Ogata wrote:
> Hi Alan,
>
> Thank you for your comment.  I was not fully aware of the possibility of
> attacking...
>
> I updated the patch to check if the current thread is the same as the
> thread cached the loader.
>
> Updated webreb: http://cr.openjdk.java.net/~horii/8188858/webrev.01/
>
This is better but it still not safe. You'll have to atomically set/get 
the cachedLoader or put it into a thread local to ensure that 
resolveClass picks up the loader cached by the current thread. A thread 
local could work too although (needs study) it might need a reference to 
the OIS to guard against nested deserialization with a different stream.

-Alan

From Alan.Bateman at oracle.com  Thu Oct 12 13:48:10 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 12 Oct 2017 14:48:10 +0100
Subject: RFR: 8188869: jdk9/10 reject zip/jar files where seconds value of
 timestamp is out of supported range 0 - 59
In-Reply-To: <61602d67-53be-cc4e-7abb-d9d85e24e678@oracle.com>
References: <61602d67-53be-cc4e-7abb-d9d85e24e678@oracle.com>
Message-ID: <30900ef1-b068-4bfc-f9f4-d86ee0cf5806@oracle.com>



On 11/10/2017 17:15, Claes Redestad wrote:
> Hi,
>
> please review this bug fix to ensure we don't reject jar
> and zip files due to entries having malformed timestamps.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8188869/jdk.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8188869
>
> I opted to only fall back to the more lenient JDK 8 version when
> we need to, which is important to not re-introduce a scalability
> bottleneck, see micros and results here:
>
I think this looks okay. Minor typo s/date/Date in "Use of date 
constructor".

-Alan


From claes.redestad at oracle.com  Thu Oct 12 14:01:20 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 12 Oct 2017 16:01:20 +0200
Subject: RFR: 8188869: jdk9/10 reject zip/jar files where seconds value of
 timestamp is out of supported range 0 - 59
In-Reply-To: <30900ef1-b068-4bfc-f9f4-d86ee0cf5806@oracle.com>
References: <61602d67-53be-cc4e-7abb-d9d85e24e678@oracle.com>
 <30900ef1-b068-4bfc-f9f4-d86ee0cf5806@oracle.com>
Message-ID: <a8dea392-1f75-06b7-fff4-fa272f0d1991@oracle.com>

Sherman, Alan,

thanks for reviewing!


On 2017-10-12 15:48, Alan Bateman wrote:
> I think this looks okay. Minor typo s/date/Date in "Use of date 
> constructor".

Will fix before push, thanks!

/Claes


From matthias.baesken at sap.com  Thu Oct 12 14:01:11 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 12 Oct 2017 14:01:11 +0000
Subject: RFR: 8188869: jdk9/10 reject zip/jar files where seconds value of
 timestamp is out of supported range 0 - 59
Message-ID: <261110d0aad94e56b2820fd143ce0fe1@sap.com>




> Hi,

>

> please review this bug fix to ensure we don't reject jar

> and zip files due to entries having malformed timestamps.

>

> Webrev: http://cr.openjdk.java.net/~redestad/8188869/jdk.00/

> Bug: https://bugs.openjdk.java.net/browse/JDK-8188869

>

> I opted to only fall back to the more lenient JDK 8 version when

> we need to, which is important to not re-introduce a scalability

> bottleneck, see micros and results here:

>

> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049458.html

>

>

> Thanks!

>

> /Claes



Not a Reviewer, but looks good to me.



Best regards, Matthias






From kirk.pepperdine at gmail.com  Thu Oct 12 14:23:22 2017
From: kirk.pepperdine at gmail.com (Kirk Pepperdine)
Date: Thu, 12 Oct 2017 16:23:22 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <CAGUMyaQCQXEqof74yOyqniBMCr6jJuPUnj+8QpEsY5SpJB+O0w@mail.gmail.com>
References: <CADQzvmmGEGDCOO1uTBF-RraMuNA9DU_3ZChFKQtBL+nebthuEA@mail.gmail.com>
 <CA+kOe08C1oWNdnijaj6k34On1BJYjFPv2azBLy4r7Yycur_9Pg@mail.gmail.com>
 <CADQzvmnDBx_UF0J0=1NvxT6T+x3+x942aV0L9xJOZ_8gC04g_g@mail.gmail.com>
 <00f301d2ce6c$55611020$00233060$@apache.org>
 <CADQzvmnX8+jcjD4zCSHoXu4cbZMQJZ2JzuFY5hR2YCWb81vdKQ@mail.gmail.com>
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 <CADQzvm=yZD0QczjWv2O3sQb=syeT8ZsXHjD=U7mTA=3aQPaEvQ@mail.gmail.com>
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
 <CA+kOe0_3J-ebfojgbtdHp5UFmd0Qn9QyH_TFWUOuSxvU5U_K7Q@mail.gmail.com>
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
 <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>
 <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>
 <8A666ED1-DC0F-43AE-B451-1122A5C498D8@oracle.com>
 <CADQzvmmj2V3Crun+Vih4kQcZh_5givde1cuM1V89-pfSaWKMYA@mail.gmail.com>
 <CAGUMyaQCQXEqof74yOyqniBMCr6jJuPUnj+8QpEsY5SpJB+O0w@mail.gmail.com>
Message-ID: <8342ED1F-C4B6-4E66-BEE1-4F70CE69D4A7@gmail.com>

Hi,

> On Oct 12, 2017, at 2:54 PM, Mario Torre <neugens.limasoftware at gmail.com> wrote:
> 
> 2017-10-12 11:58 GMT+02:00 C?dric Champeau <cedric.champeau at gmail.com>:
> 
>> 1. an API in 18.3 which would let us refresh the environment variables,
>> even if inherently unsafe (we can take the risk, if the Javadocs explains
>> that if you're really unlucky calling such a method could kill your VM).
> 
> Being a public API we would expose everyone to this risk, and the API
> should be supported on all platforms maybe forever. I know other
> people have different opinion here, but this seems to be high risk,
> high impact to be worth.

As I have stated in post postings, this is behavior is unexpected and IMHO shouldn?t be supported.
> 
>> 2. we change the way Gradle works and force explicit declaration of all
>> environment variables a user script can use. Then, we would only spawn a
>> new VM if the current daemon environment variables do not match those
>> required found by the client.

This describes a more appropriate behavior.

Kind regards,
Kirk Pepperdine


From peter.levart at gmail.com  Thu Oct 12 15:05:56 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 12 Oct 2017 17:05:56 +0200
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <59DD4810.3090405@oracle.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com>
 <32f3d1cc-0423-f28e-279f-900a8df564e2@gmail.com> <59CEDF26.60301@oracle.com>
 <b4b860b8-93a1-e3cc-19c0-f7239d74a8d9@gmail.com>
 <59DD4810.3090405@oracle.com>
Message-ID: <d1c9b581-403b-e8ef-f0fd-50bfeda413d9@gmail.com>

Hi Sherman,

On 10/11/2017 12:22 AM, Xueming Shen wrote:
>
> Peter,
>
> Webrev has been updated accordingly to remove the "inflater" from the
> "streams" as the "value" of the map. As suggested, the "streams" now
> itself is a "set".
>
> And, a package private "Infater()" has been added to avoid registering the
> inflater to Cleaner for those inflaters from ZipFile.
>
> Many,
>
> The @apiNote has been updated accordingly to remove the words regarding
> "finalize() overriding".
>
> http://cr.openjdk.java.net/~sherman/8185582/webrev/
>
> Thanks,
> Sherman

This looks good to me.

Regards, Peter

>
> On 9/30/17, 12:41 AM, Peter Levart wrote:
>>
>>
>> Right, the Inflater is captured by the cleaning function for the 
>> ZipFileInflaterInputStream and is kept strongly reachable until the 
>> function fires, which may happen automatically or manually. At that 
>> time, it is returned to the inflaters cache, which is rooted at the 
>> ZipFile instance and also captured by the ZipFile cleaning function - 
>> the Releaser, which is strongly reachable until fired. So I claim 
>> that there is no possibility for Inflaters used in ZipFile to ever 
>> get cleaned-up (ended) automatically by their cleaner functions as a 
>> result of getting phantom reachable. The situation has changed. It 
>> could even be beneficial to create a package-private Inflater 
>> constructor for this case, which creates Inflaters without cleaner 
>> registration.
>>
>> Regards, Peter
>>
>


From forax at univ-mlv.fr  Thu Oct 12 15:59:06 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 12 Oct 2017 17:59:06 +0200 (CEST)
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <8342ED1F-C4B6-4E66-BEE1-4F70CE69D4A7@gmail.com>
References: <CADQzvmmGEGDCOO1uTBF-RraMuNA9DU_3ZChFKQtBL+nebthuEA@mail.gmail.com>
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
 <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>
 <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>
 <8A666ED1-DC0F-43AE-B451-1122A5C498D8@oracle.com>
 <CADQzvmmj2V3Crun+Vih4kQcZh_5givde1cuM1V89-pfSaWKMYA@mail.gmail.com>
 <CAGUMyaQCQXEqof74yOyqniBMCr6jJuPUnj+8QpEsY5SpJB+O0w@mail.gmail.com>
 <8342ED1F-C4B6-4E66-BEE1-4F70CE69D4A7@gmail.com>
Message-ID: <49042529.2005265.1507823946299.JavaMail.zimbra@u-pem.fr>

Hi Cedric,
I think you should play like the JDK 9 i.e. help users to transition from th old world to the new world where env variables need to be declared explicitly. 
So warn user that the env variables should now be declared explicitly, use an agent to simulate the old getenv+grapefruit, create a Gradle.getenv that verifies that the env variable are explicitly declared and fork if the env variable are not declared.

In two steps:
step 1. write an agent that redefine System.getenv() to run a code before the official code of getenv,
        the code return the patched environment instead, so you can simulate what grapefruit was doing.
        Also emit a warning saying Grade.getenv should be used instead.
        Gradle.getenv is like getenv, but it check that the env variable is explicitly declared (not unlike the module directive uses with the ServiceLoader)
        Detect at runtime if the agent is present, if it's not fork.

step 2. retire the agent and profit

cheers,
R?mi

----- Mail original -----
> De: "Kirk Pepperdine" <kirk.pepperdine at gmail.com>
> ?: "Mario Torre" <neugens.limasoftware at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Jeudi 12 Octobre 2017 16:23:22
> Objet: Re: Getting a live view of environment variables (Gradle and JDK 9)

> Hi,
> 
>> On Oct 12, 2017, at 2:54 PM, Mario Torre <neugens.limasoftware at gmail.com> wrote:
>> 
>> 2017-10-12 11:58 GMT+02:00 C?dric Champeau <cedric.champeau at gmail.com>:
>> 
>>> 1. an API in 18.3 which would let us refresh the environment variables,
>>> even if inherently unsafe (we can take the risk, if the Javadocs explains
>>> that if you're really unlucky calling such a method could kill your VM).
>> 
>> Being a public API we would expose everyone to this risk, and the API
>> should be supported on all platforms maybe forever. I know other
>> people have different opinion here, but this seems to be high risk,
>> high impact to be worth.
> 
> As I have stated in post postings, this is behavior is unexpected and IMHO
> shouldn?t be supported.
>> 
>>> 2. we change the way Gradle works and force explicit declaration of all
>>> environment variables a user script can use. Then, we would only spawn a
>>> new VM if the current daemon environment variables do not match those
>>> required found by the client.
> 
> This describes a more appropriate behavior.
> 
> Kind regards,
> Kirk Pepperdine

From cedric.champeau at gmail.com  Thu Oct 12 16:04:11 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Thu, 12 Oct 2017 18:04:11 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <49042529.2005265.1507823946299.JavaMail.zimbra@u-pem.fr>
References: <CADQzvmmGEGDCOO1uTBF-RraMuNA9DU_3ZChFKQtBL+nebthuEA@mail.gmail.com>
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
 <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>
 <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>
 <8A666ED1-DC0F-43AE-B451-1122A5C498D8@oracle.com>
 <CADQzvmmj2V3Crun+Vih4kQcZh_5givde1cuM1V89-pfSaWKMYA@mail.gmail.com>
 <CAGUMyaQCQXEqof74yOyqniBMCr6jJuPUnj+8QpEsY5SpJB+O0w@mail.gmail.com>
 <8342ED1F-C4B6-4E66-BEE1-4F70CE69D4A7@gmail.com>
 <49042529.2005265.1507823946299.JavaMail.zimbra@u-pem.fr>
Message-ID: <CADQzvmmHKwsP3vGwNrUWRfurLvN6OY79QHCASauKg=_aVji8pg@mail.gmail.com>

Yes that's one option. Note that declaring environment variables is not a
small change. It has consequences on the project layout. Typically, if they
need to be in the settings.gradle file, then now the client would have to
compile, parse and potentially partially execute code. Similarly if it's in
the `build.gradle` file or any of its dependents (which is clearly a no go
here). Lighter weight options are to use `gradle.properties` or a new file.
Because, in the end, we want the client to be spawned and disposed as fast
as possible.

2017-10-12 17:59 GMT+02:00 Remi Forax <forax at univ-mlv.fr>:

> Hi Cedric,
> I think you should play like the JDK 9 i.e. help users to transition from
> th old world to the new world where env variables need to be declared
> explicitly.
> So warn user that the env variables should now be declared explicitly, use
> an agent to simulate the old getenv+grapefruit, create a Gradle.getenv that
> verifies that the env variable are explicitly declared and fork if the env
> variable are not declared.
>
> In two steps:
> step 1. write an agent that redefine System.getenv() to run a code before
> the official code of getenv,
>         the code return the patched environment instead, so you can
> simulate what grapefruit was doing.
>         Also emit a warning saying Grade.getenv should be used instead.
>         Gradle.getenv is like getenv, but it check that the env variable
> is explicitly declared (not unlike the module directive uses with the
> ServiceLoader)
>         Detect at runtime if the agent is present, if it's not fork.
>
> step 2. retire the agent and profit
>
> cheers,
> R?mi
>
> ----- Mail original -----
> > De: "Kirk Pepperdine" <kirk.pepperdine at gmail.com>
> > ?: "Mario Torre" <neugens.limasoftware at gmail.com>
> > Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoy?: Jeudi 12 Octobre 2017 16:23:22
> > Objet: Re: Getting a live view of environment variables (Gradle and JDK
> 9)
>
> > Hi,
> >
> >> On Oct 12, 2017, at 2:54 PM, Mario Torre <neugens.limasoftware at gmail.
> com> wrote:
> >>
> >> 2017-10-12 11:58 GMT+02:00 C?dric Champeau <cedric.champeau at gmail.com>:
> >>
> >>> 1. an API in 18.3 which would let us refresh the environment variables,
> >>> even if inherently unsafe (we can take the risk, if the Javadocs
> explains
> >>> that if you're really unlucky calling such a method could kill your
> VM).
> >>
> >> Being a public API we would expose everyone to this risk, and the API
> >> should be supported on all platforms maybe forever. I know other
> >> people have different opinion here, but this seems to be high risk,
> >> high impact to be worth.
> >
> > As I have stated in post postings, this is behavior is unexpected and
> IMHO
> > shouldn?t be supported.
> >>
> >>> 2. we change the way Gradle works and force explicit declaration of all
> >>> environment variables a user script can use. Then, we would only spawn
> a
> >>> new VM if the current daemon environment variables do not match those
> >>> required found by the client.
> >
> > This describes a more appropriate behavior.
> >
> > Kind regards,
> > Kirk Pepperdine
>

From Roger.Riggs at Oracle.com  Thu Oct 12 16:53:02 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Oct 2017 12:53:02 -0400
Subject: RFR 8080225: FileInputStream cleanup should be improved
In-Reply-To: <e8edb14b-4ea1-10ca-5e12-92cde3cbe514@oracle.com>
References: <abbc6122-e6fa-71eb-fa85-01a419cfbfd1@Oracle.com>
 <410d0712-5ff6-5821-482a-389d6a6ac69b@oracle.com>
 <c31522d5-60ff-0a69-88f5-01a68049bd32@Oracle.com>
 <e8edb14b-4ea1-10ca-5e12-92cde3cbe514@oracle.com>
Message-ID: <245bad5b-e004-f7eb-ce0a-90ead85b2896@Oracle.com>

Hi Alan,

On 10/12/2017 8:35 AM, Alan Bateman wrote:
> On 04/10/2017 15:35, Roger Riggs wrote:
>> Hi Mandy,
>>
>> Updated the webrev in place:
>> http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/
> I skimmed the latest webrev.
>
> The @apiNote in FIS is copied from FOS so it needs 
> s/FileOutputStream/FileInputStream/.
fixed
>
> I assume in FIS that we should skip registerCleanup when the fd is 
> FileDescriptor.in, ditto in FOS and RAF where we shouldn't register 
> for cleanup when the fd is one of the standard streams. Alternatively 
> handle this in FileDescriptor.
The FileDescriptors for in, out, err are held in static fields and 
should never be only phantom reachable.
The registration of cleanup handlers only occurs when opening files, not 
for constructors that accept a FileDescriptor.? So there will be no 
cleanup registrations for fd 0,1,2. (unless I'm missing a case)

>
> I'm curious why registerCleaner invoke clears and create a new 
> cleanup. There are cases where we create a FileDescriptor and set the 
> fd or handle lazily but these won't be registered until set.
Just an abundance of caution, currently there are no calls with set(-1) 
but if there were the
cleaner should be reset to avoid closing a stale fd at some future time.

Thanks, Roger
>
> Otherwise I think this looks quite good.
>
> -Alan
>


From Roger.Riggs at Oracle.com  Thu Oct 12 17:06:28 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Oct 2017 13:06:28 -0400
Subject: [10] RFR of JDK-8173411: Some testng tests check nothing in java
 time
In-Reply-To: <ad99a750-1fb9-82b2-dce5-490b4ff9b856@oracle.com>
References: <ad99a750-1fb9-82b2-dce5-490b4ff9b856@oracle.com>
Message-ID: <4227998c-0522-4307-1b1c-7e52fae099c9@Oracle.com>

Hi Amy,

I'm not convinced this is the right move.? Moving parts of tests further 
from the test
is not helpful from a maintenance point of view.
I'm not concerned about compilation time.? Its not significant.

For example, AbstractDateTimeTest has @Test directives and is not just 
library code.

The files in the 'tck' hierarchy are intended to be self sufficient and 
a direct mirror
or the tests in the JCK.

Please provide a more compelling reason for the change.

Thanks, Roger



On 10/10/2017 11:30 PM, Amy Lu wrote:
> Please review the patch to change TestNG.dirs and lib.dirs (def and 
> file structure) for test/jdk/java/time.
>
> test/jdk/java/time contains three sets of tests:
> nontestng/
> tck/
> test/
>
> Tests from directory "tck" and "test" are testng tests with properties:
> TestNG.dirs = ..
> lib.dirs = ../../../lib/testlibrary
> lib.build = jdk.testlibrary.RandomFactory
>
> But not all files under "TestNG.dirs" are real tests, some of them are 
> "libraries" thus should not be put under "TestNG.dirs" (thus be run as 
> testng test). Moreover, due to this def, when one runs tests from 
> "test" directory, extra files (nontestng/* and tck/*) will also be 
> compiled (which are unnecessary compiling).
>
> In this patch:
> Non-test files ("libraries") are moved to "lib" directory;
> Real tests previously under "test" dir are moved to test/jdk/, and 
> tests under "tck" dir are moved to test/tck/;
> test/jdk/ and test/tck/ each has TEST.properties with def:
> ??? TestNG.dirs = .
> ??? lib.dirs = /java/time/lib /lib/testlibrary
> MockIOExceptionAppendable.java is not used anywhere, removed.
> MockSimplePeriod.java previously exist in both "tck" and "test", now 
> it is under "lib".
>
> With this change, non-test file then won't be run as testng test and 
> no unnecessary compiling.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8173411
> webrev: http://cr.openjdk.java.net/~amlu/8173411/webrev.00/
>
> Thanks,
> Amy
>


From mandy.chung at oracle.com  Thu Oct 12 18:00:14 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Thu, 12 Oct 2017 11:00:14 -0700
Subject: RFR 8080225: FileInputStream cleanup should be improved
In-Reply-To: <c31522d5-60ff-0a69-88f5-01a68049bd32@Oracle.com>
References: <abbc6122-e6fa-71eb-fa85-01a419cfbfd1@Oracle.com>
 <410d0712-5ff6-5821-482a-389d6a6ac69b@oracle.com>
 <c31522d5-60ff-0a69-88f5-01a68049bd32@Oracle.com>
Message-ID: <6d8cac1e-792e-cd25-28bc-a51370ccc8ef@oracle.com>



On 10/4/17 7:35 AM, Roger Riggs wrote:
>
> Updated the webrev in place:
> http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/

Looks good.? One minor comment:

251 private static native void cleanupClose0(int fd);
75 Java_java_io_FileDescriptor_cleanupClose0(JNIEnv *env, jclass 
fdClass, jint fd) {
76 if (close(fd) == -1) {
77 JNU_ThrowIOExceptionWithLastError(env, "close failed");
78 }
79 }

The native implementation throws IOException when there is any error.

Not directly related to this change: when there is any error in closing 
FIS/FOS,? the exception will be ignored by the cleaner. ? I wonder if we 
could enhance the Cleaner's diagnosability to log any exception thrown; 
of course this is a separate RFE that might have been considered.

Mandy

From huizhe.wang at oracle.com  Thu Oct 12 18:24:03 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 12 Oct 2017 11:24:03 -0700
Subject: RFR (JDK10/JAXP) 8181150: Fix lint warnings in JAXP repo: rawtypes
 and unchecked
Message-ID: <59DFB343.5080602@oracle.com>

Hi,

Please review a cleanup of rawtypes and unchecked warnings from JAXP 
sources.

The patch involved a good number of classes (278). However, the majority 
of the changes are straight-forward replacement, e.g. 
s/Vector/List[ArrayList] and their relevant methods e.g. s/elementAt/get 
and etc. In a few cases, ArrayIndexOutOfBoundsException was substituted 
with IndexOutOfBoundsException as they were caught.

A few cleanups unrelated to rawtypes and unchecked were made before 
Roger's suggestion to stay within the scope of the request, that is, a 
couple of StringBuffer substitution, other than that this changeset is 
almost rawtypes and unchecked cleanup only.

JBS: https://bugs.openjdk.java.net/browse/JDK-8181150
webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181150/webrev/

Thanks,
Joe


From dalibor.topic at oracle.com  Thu Oct 12 18:50:35 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Thu, 12 Oct 2017 20:50:35 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <8342ED1F-C4B6-4E66-BEE1-4F70CE69D4A7@gmail.com>
References: <CADQzvmmGEGDCOO1uTBF-RraMuNA9DU_3ZChFKQtBL+nebthuEA@mail.gmail.com>
 <CADQzvmnDBx_UF0J0=1NvxT6T+x3+x942aV0L9xJOZ_8gC04g_g@mail.gmail.com>
 <00f301d2ce6c$55611020$00233060$@apache.org>
 <CADQzvmnX8+jcjD4zCSHoXu4cbZMQJZ2JzuFY5hR2YCWb81vdKQ@mail.gmail.com>
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 <CADQzvm=yZD0QczjWv2O3sQb=syeT8ZsXHjD=U7mTA=3aQPaEvQ@mail.gmail.com>
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
 <CA+kOe0_3J-ebfojgbtdHp5UFmd0Qn9QyH_TFWUOuSxvU5U_K7Q@mail.gmail.com>
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
 <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>
 <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>
 <8A666ED1-DC0F-43AE-B451-1122A5C498D8@oracle.com>
 <CADQzvmmj2V3Crun+Vih4kQcZh_5givde1cuM1V89-pfSaWKMYA@mail.gmail.com>
 <CAGUMyaQCQXEqof74yOyqniBMCr6jJuPUnj+8QpEsY5SpJB+O0w@mail.gmail.com>
 <8342ED1F-C4B6-4E66-BEE1-4F70CE69D4A7@gmail.com>
Message-ID: <5a8e9af1-62f4-a381-26b4-d3eda070195d@oracle.com>



On 12.10.2017 16:23, Kirk Pepperdine wrote:
> Hi,
> 
>> On Oct 12, 2017, at 2:54 PM, Mario Torre <neugens.limasoftware at gmail.com> wrote:
>>
>> 2017-10-12 11:58 GMT+02:00 C?dric Champeau <cedric.champeau at gmail.com>:
>>
>>> 1. an API in 18.3 which would let us refresh the environment variables,
>>> even if inherently unsafe (we can take the risk, if the Javadocs explains
>>> that if you're really unlucky calling such a method could kill your VM).
>>
>> Being a public API we would expose everyone to this risk, and the API
>> should be supported on all platforms maybe forever. I know other
>> people have different opinion here, but this seems to be high risk,
>> high impact to be worth.
> 
> As I have stated in post postings, this is behavior is unexpected and IMHO shouldn?t be supported.

Yeah, it smells a bit like stopThread to me, which may have seemed like 
an interesting idea at the time, but created a lot of issues down the 
road, as discussed in 
https://docs.oracle.com/javase/9/docs/api/java/lang/doc-files/threadPrimitiveDeprecation.html

A 'setenv' might not be as simple as it sounds conceptually. For 
example, it might necessitate thinking through what kind of security 
permission would be required to govern its use.

In addition, having such functionality exposed by default could be a bit 
like a conveniently placed loaded gun for an attacker attempting to 
bring a system down - one man's 'unlucky call bringing down your VM' is 
another man's 'lucky shot'.

That's not necessarily a hypothetical concern, as similar designs have 
had their share of interesting issues in the past. For example:

"Cupsd invokes CGI applications for certain requests, and the 'SetEnv' 
directive allows us to set arbitrary environment variables for these CGI 
processes."

from 
https://googleprojectzero.blogspot.de/2015/06/owning-internet-printing-case-study-in.html

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From brent.christian at oracle.com  Thu Oct 12 18:52:16 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 12 Oct 2017 11:52:16 -0700
Subject: RFR 8187772 : JVM crash when currency set on MacOS 10.10 and earlier
Message-ID: <100b8914-a3f4-83b6-916b-91826467f7d9@oracle.com>

Hi,

Please review my change to prevent a startup crash on earlier versions 
of MacOS.

    Bug: https://bugs.openjdk.java.net/browse/JDK-8187772
Webrev: http://cr.openjdk.java.net/~bchristi/8187772/webrev.00/

When a non-default currency is set in the Language & Region control 
panel, it's reflected as a variant in the locale identifier string.  For 
example, "en_US at currency=RUB" for U.S. English using the Russian rubles 
currency.

convertToPOSIXLocale() is not expecting such variants, nor such a long 
string.  The result is a SEGV from memmove() on line 161.  (Additional 
details are in the bug report.)

The fix truncates the string passed to convertToPOSIXLocale() before any 
'@'-denoted variant tags.

FWIW, the crash only happens on MacOS 10.10 and earlier because later 
versions of MacOS always return a region along with the language (line 
65), so we don't need to query the locale identifier (line 84) to 
determine the region (hyphenPos is never NULL on line 82).

Thanks,
-Brent

From Roger.Riggs at Oracle.com  Thu Oct 12 19:13:01 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 12 Oct 2017 15:13:01 -0400
Subject: RFR 8080225: FileInputStream cleanup should be improved
In-Reply-To: <6d8cac1e-792e-cd25-28bc-a51370ccc8ef@oracle.com>
References: <abbc6122-e6fa-71eb-fa85-01a419cfbfd1@Oracle.com>
 <410d0712-5ff6-5821-482a-389d6a6ac69b@oracle.com>
 <c31522d5-60ff-0a69-88f5-01a68049bd32@Oracle.com>
 <6d8cac1e-792e-cd25-28bc-a51370ccc8ef@oracle.com>
Message-ID: <2d41865a-2727-3d6f-3ddb-30ad5b7ce437@Oracle.com>

Hi Mandy,

True in advertising, the FileDescriptor.close() method should be 
declared to throw IOException.

Cleanup via the Cleaner.clean() method can't throw a checked exception 
but the IOException can be
wrapped with UncheckedIOException that can be caught by Cleaner.clean() 
callers.
They can unwrap the exception as needed.

When invoked from the Cleaner thread,? all exceptions are ignored.
Perhaps that is a better place to log unexpected exceptions.

Roger

On 10/12/2017 2:00 PM, mandy chung wrote:
>
>
> On 10/4/17 7:35 AM, Roger Riggs wrote:
>>
>> Updated the webrev in place:
>> http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/
>
> Looks good.? One minor comment:
> 251 private static native void cleanupClose0(int fd);
> 75 Java_java_io_FileDescriptor_cleanupClose0(JNIEnv *env, jclass 
> fdClass, jint fd) {
> 76 if (close(fd) == -1) {
> 77 JNU_ThrowIOExceptionWithLastError(env, "close failed");
> 78 }
> 79 }
> The native implementation throws IOException when there is any error.
>
> Not directly related to this change: when there is any error in 
> closing FIS/FOS,? the exception will be ignored by the cleaner. I 
> wonder if we could enhance the Cleaner's diagnosability to log any 
> exception thrown; of course this is a separate RFE that might have 
> been considered.
>
> Mandy


From naoto.sato at oracle.com  Thu Oct 12 19:38:16 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 12 Oct 2017 12:38:16 -0700
Subject: RFR 8187772 : JVM crash when currency set on MacOS 10.10 and
 earlier
In-Reply-To: <100b8914-a3f4-83b6-916b-91826467f7d9@oracle.com>
References: <100b8914-a3f4-83b6-916b-91826467f7d9@oracle.com>
Message-ID: <2b3ea152-cc1f-0f06-e11d-c730e5420439@oracle.com>

Looks fine, Brent.

Naoto

On 10/12/17 11:52 AM, Brent Christian wrote:
> Hi,
> 
> Please review my change to prevent a startup crash on earlier versions 
> of MacOS.
> 
>  ?? Bug: https://bugs.openjdk.java.net/browse/JDK-8187772
> Webrev: http://cr.openjdk.java.net/~bchristi/8187772/webrev.00/
> 
> When a non-default currency is set in the Language & Region control 
> panel, it's reflected as a variant in the locale identifier string.? For 
> example, "en_US at currency=RUB" for U.S. English using the Russian rubles 
> currency.
> 
> convertToPOSIXLocale() is not expecting such variants, nor such a long 
> string.? The result is a SEGV from memmove() on line 161.? (Additional 
> details are in the bug report.)
> 
> The fix truncates the string passed to convertToPOSIXLocale() before any 
> '@'-denoted variant tags.
> 
> FWIW, the crash only happens on MacOS 10.10 and earlier because later 
> versions of MacOS always return a region along with the language (line 
> 65), so we don't need to query the locale identifier (line 84) to 
> determine the region (hyphenPos is never NULL on line 82).
> 
> Thanks,
> -Brent

From sean.mullan at oracle.com  Thu Oct 12 20:32:46 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 12 Oct 2017 16:32:46 -0400
Subject: Manifest Related Bugs JDK-6372077, JDK-6202130, JDK-8176843,
 JDK-4842483, JDK-6443578, JDK-6910466, JDK-4935610, and JDK-4271239
In-Reply-To: <9a4edee0-4edd-caaa-9970-61df083d39df@paratix.ch>
References: <9a4edee0-4edd-caaa-9970-61df083d39df@paratix.ch>
Message-ID: <02abcb68-2294-c733-5048-b1f81ee99435@oracle.com>

Hi Phillip,

All of these bugs are in the core-libs area, so I am copying the 
core-libs-dev list since that is where they should be discussed and 
reviewed. I have -bcc-ed security-dev (where this was originally posted).

--Sean

On 10/2/17 1:24 PM, Philipp Kunz wrote:
> Hi,
> 
> While fixing JDK-6695402 I came across other related bugs to manifests 
> such as JDK-6372077, JDK-6202130, JDK-8176843, JDK-4842483, and 
> JDK-6443578 which all relate to manifest reading and writing. Somewhere 
> bug 7071055 is mentioned but I cannot find anywhere. Another group of 
> bugs, JDK-6910466, JDK-4935610, and JDK-4271239 concern the mandatory 
> manifest main attributes Manifest-Version or Signature-Version and at 
> first glance are duplicates. If you know of more known bugs, not 
> necessarily present in jira, I'd be glad to get notified.
> 
> There are also some comments about utf handling and line breaking in the 
> code of Manifest:
> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l299
> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l327
> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l370
> 
> Furthermore, Attributes.map should declare appropriate type parameters:
> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l61
> The specification would also require that `header names must not start 
> with _, - or "From"` 
> (http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Section-Specification) 
> but I would opt not to add this as a hard restriction because I guess it 
> can be assumed that such names are in use now after having been working 
> for years. A warning to a logger might be conceivable such as in
> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Attributes.java#l424
> Attribute values are never checked at all and invalid characters such as 
> line breaks are never detected except that when reading the manifest 
> again the values are cut off.
> The tab character (U+0008) does not work in manifest values.
> I suspect that there are also issues regarding the iteration order but I 
> haven't got a prove yet unlike for the other points above:
> http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/share/classes/java/util/jar/Manifest.java#l54
> There is duplicated or very similar code in Attributes and Manifest: 
> Attributes.write-Manifest.write-Attributes.writeMain and 
> Attributes.read-Manifest.read.
> Resolving JDK-6202130 would have the additional benefit to be able to 
> view manifests with any utf-8 capable editor even if multi-byte 
> characters break across lines.
> 
> Fixing these issues individually looks like more complicated work than 
> fixing them all at once, I guess, also because of a very low current 
> test coverage. So I'd suggest to add some thorough tests along with 
> fixing these issues. But before I start I would like to get some 
> guidance, assistance or at least confirmation on how to proceed. I'm new 
> to open jdk and have submitted only one patch so far.
> 
> Is it ok to add tests for things that have worked before?
> Is it ok to refactor duplicated code just for the added value to reduce 
> effort for testing?
> I assume compatibility to and from existing manifests is the highest 
> priority, correct? This would also be the hard part in adding as 
> complete test coverage as possible. What would be acceptable criteria to 
> meet?
> Why does Attributes not extend LinkedHashMap and why does Manifest not 
> extend HashMap? Any objection?
> While I would not want to write code that looks slow or change more than 
> necessary one can never know before having performance actually 
> measured. Is there some way this is dealt with or should I wait for such 
> feedback until after patch submission?
> 
> Would someone sponsor?
> 
> Regards,
> Philipp
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> Paratix GmbH
> St Peterhofstatt 11
> 8001 Z?rich
> 
> +41 (0)76 397 79 35
> philipp.kunz at paratix.ch <mailto:philipp.kunz at paratix.ch>

From xueming.shen at oracle.com  Thu Oct 12 21:28:49 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 12 Oct 2017 14:28:49 -0700
Subject: RFR 8187772 : JVM crash when currency set on MacOS 10.10 and
 earlier
In-Reply-To: <100b8914-a3f4-83b6-916b-91826467f7d9@oracle.com>
References: <100b8914-a3f4-83b6-916b-91826467f7d9@oracle.com>
Message-ID: <59DFDE91.2030402@oracle.com>

Brent,

My mac build fails / crashes for a while at exactly the same location. 
The fix seems
have solved the problem. However my osx is 10.11.5/OSX El Capitan, and 
in my case
the locale variable looks like "en-US at calendar=iso8601". It's not the 
currency, but
the calendar is attached after "@"

Just FYI.

sherman

On 10/12/17, 11:52 AM, Brent Christian wrote:
> Hi,
>
> Please review my change to prevent a startup crash on earlier versions 
> of MacOS.
>
>    Bug: https://bugs.openjdk.java.net/browse/JDK-8187772
> Webrev: http://cr.openjdk.java.net/~bchristi/8187772/webrev.00/
>
> When a non-default currency is set in the Language & Region control 
> panel, it's reflected as a variant in the locale identifier string.  
> For example, "en_US at currency=RUB" for U.S. English using the Russian 
> rubles currency.
>
> convertToPOSIXLocale() is not expecting such variants, nor such a long 
> string.  The result is a SEGV from memmove() on line 161.  (Additional 
> details are in the bug report.)
>
> The fix truncates the string passed to convertToPOSIXLocale() before 
> any '@'-denoted variant tags.
>
> FWIW, the crash only happens on MacOS 10.10 and earlier because later 
> versions of MacOS always return a region along with the language (line 
> 65), so we don't need to query the locale identifier (line 84) to 
> determine the region (hyphenPos is never NULL on line 82).
>
> Thanks,
> -Brent


From brent.christian at oracle.com  Thu Oct 12 23:41:27 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 12 Oct 2017 16:41:27 -0700
Subject: RFR 8187772 : JVM crash when currency set on MacOS 10.10 and
 earlier
In-Reply-To: <59DFDE91.2030402@oracle.com>
References: <100b8914-a3f4-83b6-916b-91826467f7d9@oracle.com>
 <59DFDE91.2030402@oracle.com>
Message-ID: <233dece8-ef38-3725-f5f1-61b00e0ed423@oracle.com>

That is interesting, thanks.  I'll add the info to the bug report.

I can reproduce the crash on 10.9 when setting a non-default calendar 
instead of a currency.  But I still cannot reproduce it on 10.12.

-Brent

On 10/12/17 2:28 PM, Xueming Shen wrote:
> Brent,
> 
> My mac build fails / crashes for a while at exactly the same location. 
> The fix seems
> have solved the problem. However my osx is 10.11.5/OSX El Capitan, and 
> in my case
> the locale variable looks like "en-US at calendar=iso8601". It's not the 
> currency, but
> the calendar is attached after "@"
> 
> Just FYI.
> 
> sherman
> 
> On 10/12/17, 11:52 AM, Brent Christian wrote:
>> Hi,
>>
>> Please review my change to prevent a startup crash on earlier versions 
>> of MacOS.
>>
>> ?? Bug: https://bugs.openjdk.java.net/browse/JDK-8187772
>> Webrev: http://cr.openjdk.java.net/~bchristi/8187772/webrev.00/
>>
>> When a non-default currency is set in the Language & Region control 
>> panel, it's reflected as a variant in the locale identifier string. 
>> For example, "en_US at currency=RUB" for U.S. English using the Russian 
>> rubles currency.
>>
>> convertToPOSIXLocale() is not expecting such variants, nor such a long 
>> string.? The result is a SEGV from memmove() on line 161.? (Additional 
>> details are in the bug report.)
>>
>> The fix truncates the string passed to convertToPOSIXLocale() before 
>> any '@'-denoted variant tags.
>>
>> FWIW, the crash only happens on MacOS 10.10 and earlier because later 
>> versions of MacOS always return a region along with the language (line 
>> 65), so we don't need to query the locale identifier (line 84) to 
>> determine the region (hyphenPos is never NULL on line 82).
>>
>> Thanks,
>> -Brent
> 

From paul.sandoz at oracle.com  Fri Oct 13 00:32:14 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 12 Oct 2017 17:32:14 -0700
Subject: RFR: jsr166 jdk10 integration wave 4
In-Reply-To: <CA+kOe0-ApLWMdA-6rAwTEysN8P7Q4Dmp9==H=t10BF8FTX9nSg@mail.gmail.com>
References: <CA+kOe0-ApLWMdA-6rAwTEysN8P7Q4Dmp9==H=t10BF8FTX9nSg@mail.gmail.com>
Message-ID: <723DBFD4-6B0C-4567-BA9B-6F64E8654B1E@oracle.com>

Looks good, one minor comment below.

> On 11 Oct 2017, at 14:42, Martin Buchholz <martinrb at google.com> wrote:
> 
> This wave introduces a more clickable overview Home Page:
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/overview.html
> 
> 8188900: ConcurrentLinkedDeque linearizability
> 8188853: java/util/concurrent/ExecutorService/Invoke.java Assertion failure
> 8188047: Add SplittableRandom.nextBytes


SplittableRandomTest.java
?

 592         int n = sr.nextInt(20);

nextInt(1, 20) ? so you get a byte array of 1 or more in length.

Paul.


> 8187941: Add StampedLock stamp inspection methods
> 8188575: Miscellaneous changes imported from jsr166 CVS 2017-10


From martinrb at google.com  Fri Oct 13 02:35:14 2017
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 12 Oct 2017 19:35:14 -0700
Subject: RFR: jsr166 jdk10 integration wave 4
In-Reply-To: <723DBFD4-6B0C-4567-BA9B-6F64E8654B1E@oracle.com>
References: <CA+kOe0-ApLWMdA-6rAwTEysN8P7Q4Dmp9==H=t10BF8FTX9nSg@mail.gmail.com>
 <723DBFD4-6B0C-4567-BA9B-6F64E8654B1E@oracle.com>
Message-ID: <CA+kOe09H-DWpV31CaaT95cZ7vO0bdt22GkN+UO4CbA8nyGRQZA@mail.gmail.com>

On Thu, Oct 12, 2017 at 5:32 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> SplittableRandomTest.java
> ?
>
>  592         int n = sr.nextInt(20);
>
> nextInt(1, 20) ? so you get a byte array of 1 or more in length.
>

Yes, I see now there is no testing at all when n == 0.  Empty array and
null array are both worth testing, so:

 Index: SplittableRandomTest.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/test/tck/SplittableRandomTest.java,v
retrieving revision 1.22
diff -u -r1.22 SplittableRandomTest.java
--- SplittableRandomTest.java 3 Oct 2017 22:27:04 -0000 1.22
+++ SplittableRandomTest.java 13 Oct 2017 02:31:20 -0000
@@ -562,7 +562,7 @@
      */
     public void testNextBytes() {
         SplittableRandom sr = new SplittableRandom();
-        int n = sr.nextInt(20);
+        int n = sr.nextInt(1, 20);
         byte[] bytes = new byte[n];
         outer:
         for (int i = 0; i < n; i++) {
@@ -577,4 +577,18 @@
         }
     }

+    /**
+     * Filling an empty array with random bytes succeeds without effect.
+     */
+    public void testNextBytes_emptyArray() {
+        new SplittableRandom().nextBytes(new byte[0]);
+    }
+
+    public void testNextBytes_nullArray() {
+        try {
+            new SplittableRandom().nextBytes(null);
+            shouldThrow();
+        } catch (NullPointerException success) {}
+    }
+
 }

From amy.lu at oracle.com  Fri Oct 13 05:39:46 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Fri, 13 Oct 2017 13:39:46 +0800
Subject: [10] RFR of JDK-8173411: Some testng tests check nothing in java
 time
In-Reply-To: <4227998c-0522-4307-1b1c-7e52fae099c9@Oracle.com>
References: <ad99a750-1fb9-82b2-dce5-490b4ff9b856@oracle.com>
 <4227998c-0522-4307-1b1c-7e52fae099c9@Oracle.com>
Message-ID: <f3d2413e-4c3c-2e1d-b668-c9a955eefcbf@oracle.com>

non-test be run as a test, the result may lead to confusion.

For example, if look at MockSimplePeriod.java test result, it shows:
===============================================
java/time/test/java/time/MockSimplePeriod.java
Total tests run: 0, Failures: 0, Skips: 0
===============================================

Without looking into the detail of the test code, one may raise question 
why this test has 0 testcase.

If this is not a concern, I can withdraw this change request.

Thanks,
Amy

On 10/13/17 1:06 AM, Roger Riggs wrote:
> Hi Amy,
>
> I'm not convinced this is the right move.? Moving parts of tests 
> further from the test
> is not helpful from a maintenance point of view.
> I'm not concerned about compilation time.? Its not significant.
>
> For example, AbstractDateTimeTest has @Test directives and is not just 
> library code.
>
> The files in the 'tck' hierarchy are intended to be self sufficient 
> and a direct mirror
> or the tests in the JCK.
>
> Please provide a more compelling reason for the change.
>
> Thanks, Roger
>
>
>
> On 10/10/2017 11:30 PM, Amy Lu wrote:
>> Please review the patch to change TestNG.dirs and lib.dirs (def and 
>> file structure) for test/jdk/java/time.
>>
>> test/jdk/java/time contains three sets of tests:
>> nontestng/
>> tck/
>> test/
>>
>> Tests from directory "tck" and "test" are testng tests with properties:
>> TestNG.dirs = ..
>> lib.dirs = ../../../lib/testlibrary
>> lib.build = jdk.testlibrary.RandomFactory
>>
>> But not all files under "TestNG.dirs" are real tests, some of them 
>> are "libraries" thus should not be put under "TestNG.dirs" (thus be 
>> run as testng test). Moreover, due to this def, when one runs tests 
>> from "test" directory, extra files (nontestng/* and tck/*) will also 
>> be compiled (which are unnecessary compiling).
>>
>> In this patch:
>> Non-test files ("libraries") are moved to "lib" directory;
>> Real tests previously under "test" dir are moved to test/jdk/, and 
>> tests under "tck" dir are moved to test/tck/;
>> test/jdk/ and test/tck/ each has TEST.properties with def:
>> ??? TestNG.dirs = .
>> ??? lib.dirs = /java/time/lib /lib/testlibrary
>> MockIOExceptionAppendable.java is not used anywhere, removed.
>> MockSimplePeriod.java previously exist in both "tck" and "test", now 
>> it is under "lib".
>>
>> With this change, non-test file then won't be run as testng test and 
>> no unnecessary compiling.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8173411
>> webrev: http://cr.openjdk.java.net/~amlu/8173411/webrev.00/
>>
>> Thanks,
>> Amy
>>
>


From christoph.dreis at freenet.de  Fri Oct 13 06:33:59 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Fri, 13 Oct 2017 08:33:59 +0200
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
 reflection
In-Reply-To: <b6524f36-29f0-452e-bf34-b4d463d3fe1d@oracle.com>
References: <000001d341f1$82764870$8762d950$@freenet.de>
 <b6524f36-29f0-452e-bf34-b4d463d3fe1d@oracle.com>
Message-ID: <000001d343ed$41a37d60$c4ea7820$@freenet.de>

Hi Claes,

> Let's file a separate RFE and push this.  I assume you need a sponsor to do
> both?
> 
> Thanks!
> 
> /Claes

Indeed, I would need a sponsor. Thank you!

Cheers,
Christoph


From christoph.dreis at freenet.de  Fri Oct 13 06:55:03 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Fri, 13 Oct 2017 08:55:03 +0200
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
 reflection
In-Reply-To: <58df9bf3-fb5d-958e-b4fb-1baf3d86248b@gmail.com>
References: <000001d341f1$82764870$8762d950$@freenet.de>
 <58df9bf3-fb5d-958e-b4fb-1baf3d86248b@gmail.com>
Message-ID: <000101d343f0$32b7ba70$98272f50$@freenet.de>

Hi Peter,

Thanks for your feedback!

> Method.getName() returns an interned String and String literals are interned strings. Reference comparison is therefore possible
Good point. 

> The pair (declaringClass, methodName) uniquely identifies the method for a bunch of interesting methods when declaringClass is either java.lang.Object or java.lang.annotation.Annotation, so we don't need to obtain method's parameterTypes even for equals().
Forgive me the maybe stupid question, but isn't your proposed code changing semantics because it doesn't check for the first parameter in equals() to be of type java.lang.Object anymore? E.g. like "method.getParameterTypes()[0] == Object.class". Am I missing something? Personally, I find this a bit too "magic" overall. I don't know what Claes thinks about that. 

I would settle on this, if I include the reference comparison change of yours. 

For example:

   public Object invoke(Object proxy, Method method, Object[] args) {
        String memberName = method.getName(); // guaranteed interned String
        int parameterCount = method.getParameterCount();

        // Handle Object and Annotation methods
        if (parameterCount == 1 && memberName == "equals" &&
            method.getParameterTypes()[0] == Object.class)
            return equalsImpl(proxy, args[0]);
        if (parameterCount != 0)
            throw new AssertionError("Too many parameters for an annotation method");

        if (memberName == "hashCode") return hashCodeImpl();
        if (memberName == "annotationType") return type;
        if (memberName == "toString") return toStringImpl();

        // Handle annotation member accessors
        Object result = memberValues.get(memberName);

        if (result == null)
            throw new IncompleteAnnotationException(type, memberName);

        if (result instanceof ExceptionProxy)
            throw ((ExceptionProxy) result).generateException();

        if (result.getClass().isArray() && Array.getLength(result) != 0)
            result = cloneArray(result);

        return result;
    }

What do you think?

Cheers,
Christoph


From dawid.weiss at gmail.com  Fri Oct 13 07:53:01 2017
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Fri, 13 Oct 2017 09:53:01 +0200
Subject: AssertionError in WildcardTypeImpl.getUpperBoundASTs
Message-ID: <CAM21Rt8uPUk5NE6RSP6Gej9uejsmAz8HNLj3nXon0sK1K0=sUg@mail.gmail.com>

Hi all,

We are observing very infrequent assertion errors originating in
getUpperBoundASTs, mostly during concurrent builds on our build
machine, when it's under a heavy load. This has been happening from
time to time with various Java versions; most recently with 1.8.0_131.

I don't see anything in Jira about it, but even a quick Google search
yields some hits [1].

The stack trace starts with (I include the jackson stack frame which calls it):

java.lang.AssertionError: null
at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBoundASTs(WildcardTypeImpl.java:86)
~[?:1.8.0_131]
at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBounds(WildcardTypeImpl.java:122)
~[?:1.8.0_131]
at com.fasterxml.jackson.databind.type.TypeFactory._fromWildcard(TypeFactory.java:1424)
~[jackson-databind-2.8.2.jar:2.8.2]

The problem cannot be easily reproduced, but I see a comment mentioned
on the core-libs-dev a while ago [2] by Joel Borggr?n-Franck, so
perhaps his question is a valid one and worth investigating:

> Btw, has anyone seen the assert for upper/lower bounds == null fail in the wild?

Dawid

[1] https://www.google.com/search?q=getUpperBoundASTs+AssertionError&filter=0&biw=1279&bih=863
(note the "[JENKINS] Lucene-olr-master-Linux" hit).

[2] http://markmail.org/message/4phfnh7dj3qdlo6b

From peter.levart at gmail.com  Fri Oct 13 10:05:54 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 13 Oct 2017 12:05:54 +0200
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
 reflection
In-Reply-To: <000101d343f0$32b7ba70$98272f50$@freenet.de>
References: <000001d341f1$82764870$8762d950$@freenet.de>
 <58df9bf3-fb5d-958e-b4fb-1baf3d86248b@gmail.com>
 <000101d343f0$32b7ba70$98272f50$@freenet.de>
Message-ID: <34043e48-45ec-2e2f-97cb-81b110575864@gmail.com>



On 10/13/2017 08:55 AM, Christoph Dreis wrote:
> Hi Peter,
>
> Thanks for your feedback!
>
>> Method.getName() returns an interned String and String literals are interned strings. Reference comparison is therefore possible
> Good point.
>
>> The pair (declaringClass, methodName) uniquely identifies the method for a bunch of interesting methods when declaringClass is either java.lang.Object or java.lang.annotation.Annotation, so we don't need to obtain method's parameterTypes even for equals().
> Forgive me the maybe stupid question, but isn't your proposed code changing semantics because it doesn't check for the first parameter in equals() to be of type java.lang.Object anymore? E.g. like "method.getParameterTypes()[0] == Object.class". Am I missing something? Personally, I find this a bit too "magic" overall. I don't know what Claes thinks about that.

There's only one method named "equals" declared in either Object or 
Annotation (currently :-). So it's enough to check for declaringClass 
and name to identify the correct method.

Regards, Peter

>
> I would settle on this, if I include the reference comparison change of yours.
>
> For example:
>
>     public Object invoke(Object proxy, Method method, Object[] args) {
>          String memberName = method.getName(); // guaranteed interned String
>          int parameterCount = method.getParameterCount();
>
>          // Handle Object and Annotation methods
>          if (parameterCount == 1 && memberName == "equals" &&
>              method.getParameterTypes()[0] == Object.class)
>              return equalsImpl(proxy, args[0]);
>          if (parameterCount != 0)
>              throw new AssertionError("Too many parameters for an annotation method");
>
>          if (memberName == "hashCode") return hashCodeImpl();
>          if (memberName == "annotationType") return type;
>          if (memberName == "toString") return toStringImpl();
>
>          // Handle annotation member accessors
>          Object result = memberValues.get(memberName);
>
>          if (result == null)
>              throw new IncompleteAnnotationException(type, memberName);
>
>          if (result instanceof ExceptionProxy)
>              throw ((ExceptionProxy) result).generateException();
>
>          if (result.getClass().isArray() && Array.getLength(result) != 0)
>              result = cloneArray(result);
>
>          return result;
>      }
>
> What do you think?
>
> Cheers,
> Christoph
>


From adam.farley at uk.ibm.com  Fri Oct 13 12:16:41 2017
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Fri, 13 Oct 2017 12:16:41 +0000
Subject: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be
 exited by java
Message-ID: <OFFB8A8A7A.5AE2F216-ON002581B8.003FC147-802581B8.00437393@notes.na.collabserv.com>

Hi All,

Here's a summary of the email below (which is intended, partly, as a 
summary of the emails before it).

Let me know if you agree/disagree with any of these points.

1) Exit(#) during vm startup is a bug because it should return a code 
regardless of the state of the VM.
2) Exit(0) is an *especially* big bug because it imitates successful 
completion of external cpp code accessing JNI methods.
3) One solution is to specify a new return code for JNI.
4) The supplied code (diff) generates, facilitates, and handles that 
return code for the exit(0) scenario: -agentlib:jdwp=help
5) The supplied test confirms that the supplied code works (run via unzip, 
and then bash TestStart.sh <path to jdk home dir that contains bin dir>).
6) To implement this new return code, plus the code that handles it, we 
would need to follow the CSR process.
7) To implement the fix for the scenario used as an example of the new 
return code's use, we would need to modify the JVM TI spec.
8) To address all of the worst instances of exit(#), we would need to 
search for exit(#) and raise a bug for each significant one (or group).
9) To solve (8) in one bug would be a lot of work, arguably too much work 
for a single bug.
10) If the new return code is chosen as the appropriate solution to this 
problem, we may need to choose a better name for the return code.

Is this a fair assessment of the current state of the debate?

I'm on IRC every weekday from 9am-5pm (4pm fridays) BST (GMT+1) if anyone 
wants to discuss this in real-time on the openjdk channel. 

Best Regards

Adam Farley



-- Previous Email --

Hi David, Alan,

You are right in that the changes to HotSpot would be nontrivial. 
I see a number of places in (e.g.) arguments.cpp that seem to 
exit in the same manner as Xlog (such as -Xinternalversion).

I would advise ploughing through the CSR process to alter the 
JNI spec, and simultaneously identify some key paths that can 
be raised as bugs. That way, when people have time to address 
these issues, the mechanism to handle a silent exit is already 
in place. 

The JDWP fix can be raised separately as one of these bugs, if 
it would make things simpler. 

As for the name, JNI_SILENT_EXIT is a placeholder, and can be 
readily changed. Do you have any suggestions?

Lastly, in an ideal world, the VM initialisation should never exit(#). It
should return a return code that tells the caller something, pass or 
fail, messy or tidy. That way, if someone is using the JNI as part of 
something bigger (like a database or a web server), one of these 
scenarios is just a bug, rather than a world-ender like exit(#).

And now for the individual messages. :)

David: Having help data returned by the launcher seems like a
good way to avoid exit(0) calls, but I'm not sure how we'd prevent 
a JNI-caller using those options. Ultimately, to be sure, we'd have
to remove the logic for those options, centralise the data to better
enable launcher access, and add some logic in there so it can find 
any other help data (e.g. from the jdwp agent library). I feel this would 
be a bigger task than adding the new return code and changing the
vm, plus it wouldn't provide for any non-help scenarios where the
vm wants to shut down without error during initialisation.

Alan: I should mention that the silent exit solution is already in
use in the OpenJ9 VM. Not all of the exit paths have been 
resolved, but many have.

The code is open and can be found here: 
https://github.com/eclipse/openj9

And though the silent exit code is disabled for the time being, it
can be re-enabled by entering this class:

runtime/vm/jvminit.c

and altering line 2343 ( ctrl-f for exit(1) if it's not there).

I won't paste the full code here in case people are concerned
about contamination, but I would assert that this code (and the
associated vm files) prove that the concept is possible.

Note that that code should not be enabled until after we've 
integrated the code that can handle a silent exit.

Best Regards

Adam Farley

P.S. Thank you both for your efforts on this. :)



From:   David Holmes <david.holmes at oracle.com>
To:     Alan Bateman <Alan.Bateman at oracle.com>, Adam Farley8 
<adam.farley at uk.ibm.com>, core-libs-dev at openjdk.java.net, 
hotspot-runtime-dev at openjdk.java.net, thomas.stuefe at gmail.com
Date:   15/09/2017 12:03
Subject:        Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM 
can be exited by java





On 15/09/2017 8:17 PM, Alan Bateman wrote:
> On 15/09/2017 02:47, David Holmes wrote:
>> Hi Adam,
>>
>> I am still very much torn over this one. I think the idea of 
>> print-and-exit flags for a potentially hosted library like the JVM is 
>> just wrong - we should never have done that, but we did. Fixing that 
>> by moving the flags to the launcher is far from trivial**. Endorsing 
>> and encouraging these sorts of flag by adding JNI support seems to be 
>> sending the wrong message.
>>
>> ** I can envisage a "help xxx" Dcmd that can read back the info from 
>> the VM. The launcher can send the Dcmd, print the output and exit. The 
>> launcher would not need to know what the xxx values mean, but would 
>> have to intercept the existing ones.
>>
>> Another option is just to be aware of these flags (are there more than 
>> jdwp and Xlog?) and deal with them specially in your custom launcher - 
>> either filter them out and ignore them, or else launch the VM in its 
>> own process to respond to them.
>>
>> Any changes to the JNI specification need to go through the CSR 
process.
> Yes, it would require an update to the JNI spec, also a change to the 
> JVM TI spec where Agent_OnLoad returning a non-0 value is specified to 
> terminates the VM. The name and value needs discussion too, esp. as the 
> JNI spec uses negative values for failure.
> 
> In any case, I'm also torn over this one as it's a corner case that is 
> only interesting for custom launchers that load agents with options that 

> print usage messages. It wouldn't be hard to have the Agent_OnLoad 
> specify a printf hook that the agent could use for output although there 

> are complications with agents such as JDWP that also announce their 
> transport end point. Beyond that there is still the issue of the custom 
> launcher that would need to know to destroy the VM without reporting an 
> error.
> 
> So what happened to the more meaty part to this which is fixing the 
> various cases in HotSpot that terminate the process during 
> initialization? I would expect some progress could be made on those 
> cases while trying to decide whether to rev the JNI and JVM TI specs to 
> cover the help case.

Trying to eliminate the vm_exit_during_initialization paths in hotspot 
is a huge undertaking IMHO.

David

> 
> -Alan

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From OGATAK at jp.ibm.com  Fri Oct 13 12:36:55 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Fri, 13 Oct 2017 21:36:55 +0900
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
 <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
Message-ID: <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>

Hi Alan,

Alan Bateman <Alan.Bateman at oracle.com> wrote on 2017/10/12 22:17:48:

> This is better but it still not safe. You'll have to atomically set/get 
> the cachedLoader or put it into a thread local to ensure that 
> resolveClass picks up the loader cached by the current thread. A thread 
> local could work too although (needs study) it might need a reference to 

> the OIS to guard against nested deserialization with a different stream.

Thank you for your review. I fixed the code that does not read the 
cachedLoader atomically when the code tries to update it.

Updated webrev: http://cr.openjdk.java.net/~horii/8188858/webrev.02/


The updated code does not use atomic CAS or ThreadLocal.  This code can 
race when the cachedLoader is null, but I think it works correctly because 
a pair of a thread and a class loader (stored in a CachedLoader) is always 
correct regardless of the value of the cachedLoader field, and the thread 
that writes the cachedLoader last resets it to null.  The thread that 
failed to cache a loader simply calls latestUserDefinedLoader(), which is 
the same behavior as the original code.

Considering that multi-thread use of an OIS is rare, I don't want to add 
an overhead of CAS to update the cachedLoader, especially on the POWER 
platform because CAS has high overhead.  Caching loaders in a ThreadLocal 
in each OIS can be more thread safe, but I'm not sure if its memory 
overhead is worth doing so for the rare (and correctly working) case.


Regards,
Ogata


From Alan.Bateman at oracle.com  Fri Oct 13 12:58:17 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 13 Oct 2017 13:58:17 +0100
Subject: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be
 exited by java
In-Reply-To: <OFFB8A8A7A.5AE2F216-ON002581B8.003FC147-802581B8.00437393@notes.na.collabserv.com>
References: <OFFB8A8A7A.5AE2F216-ON002581B8.003FC147-802581B8.00437393@notes.na.collabserv.com>
Message-ID: <d5c5ed8b-5350-2a8e-6e24-9956e7c361a3@oracle.com>

On 13/10/2017 13:16, Adam Farley8 wrote:
> Hi All,
>
> Here's a summary of the email below (which is intended, partly, as a 
> summary of the emails before it).
>
> Let me know if you agree/disagree with any of these points.
>
> :
> 3) One solution is to specify a new return code for JNI.
Yes, hence the need to update the JNI spec. A discussion point to add to 
your point #10 is the return code value as the JNI spec uses negative 
values for errors.

>
> 6) To implement this new return code, plus the code that handles it, 
> we would need to follow the CSR process.
Yes, a CSR will be needed if this goes ahead as it will need changes to 
both the JNI and JVM TI specs.

>
> 7) To implement the fix for the scenario used as an example of the new 
> return code's use, we would need to modify the JVM TI spec.
Yes, because the JVM TI spec is very clear that the Agent_OnLoad 
returning a non-0 value is an error that terminates the VM.


>
> 8) To address all of the worst instances of exit(#), we would need to 
> search for exit(#) and raise a bug for each significant one (or group).

In the discussion to date then I think there is an acknowledgement that 
there are issues in hotspot for several error or resource exhaustion 
cases that would need a lot of work to recover from. I don't think there 
was any suggestion that they would need to be addressed or even 
identified as part of deciding if the agent "-help" scenario is worth 
trying to support.

-Alan

From david.holmes at oracle.com  Fri Oct 13 13:29:52 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 13 Oct 2017 23:29:52 +1000
Subject: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be
 exited by java
In-Reply-To: <OFFB8A8A7A.5AE2F216-ON002581B8.003FC147-802581B8.00437393@notes.na.collabserv.com>
References: <OFFB8A8A7A.5AE2F216-ON002581B8.003FC147-802581B8.00437393@notes.na.collabserv.com>
Message-ID: <1c824799-e58c-1ff8-bc0a-d13be651a3ec@oracle.com>

Hi Adam,

On 13/10/2017 10:16 PM, Adam Farley8 wrote:
> Hi All,
> 
> Here's a summary of the email below (which is intended, partly, as a 
> summary of the emails before it).
> 
> Let me know if you agree/disagree with any of these points.
> 
> 1) Exit(#) during vm startup is a bug because it should return a code 
> regardless of the state of the VM.

Yes it's a bug but not one that is likely to be addressed in any 
foreseeable timeframe. There are simply too many "exit on error" paths. 
If we were to start using C++ exceptions within the VM that might 
provide a way to quickly get back to the CreateJavaVM routine where we 
could return an error code - but that is itself a major project that has 
barely even been discussed AFAIK. (Compiler folk have talked about it 
because compiler paths are fairly self-contained - though that was 
before Graal and AOT.)

> 2) Exit(0) is an *especially* big bug because it imitates successful 
> completion of external cpp code accessing JNI methods.
> 3) One solution is to specify a new return code for JNI.

A solution for 2) yes.

> 4) The supplied code (diff) generates, facilitates, and handles that 
> return code for the exit(0) scenario: -agentlib:jdwp=help
> 5) The supplied test confirms that the supplied code works (run via 
> unzip, and then bash TestStart.sh <path to jdk home dir that contains 
> bin dir>).
> 6) To implement this new return code, plus the code that handles it, we 
> would need to follow the CSR process.
> 7) To implement the fix for the scenario used as an example of the new 
> return code's use, we would need to modify the JVM TI spec.

Yes you have demonstrated a potential solution for the agent case. The 
question is, is it the right solution? Is it a worthwhile solution? (As 
I've said I'd prefer not to have any "do something then exit" VM 
arguments.) And can we make it fit into the existing specs without 
contorting things too much.

I still think it easier/preferable for whatever loads the VM to filter 
out the VM args that trigger this behaviour. I mean if you pass 
-Xshare:dump you don't have any right to expect a functioning VM after 
JNI_CreateJavaVM returns - at least I don't think so. Just don't do it. 
Yes it is an imperfection in the invocation API, but life isn't perfect.

> 8) To address all of the worst instances of exit(#), we would need to 
> search for exit(#) and raise a bug for each significant one (or group).
> 9) To solve (8) in one bug would be a lot of work, arguably too much 
> work for a single bug.

This is simply impractical. You may be able to pick off a few 
low-hanging cases, but that won't really make any practical difference.

> 10) If the new return code is chosen as the appropriate solution to this 
> problem, we may need to choose a better name for the return code.
> 
> Is this a fair assessment of the current state of the debate?

It's a fair summary of your position and proposal.

Cheers,
David

> I'm on IRC every weekday from 9am-5pm (4pm fridays) BST (GMT+1) if 
> anyone wants to discuss this in real-time on the openjdk channel.
> 
> Best Regards
> 
> Adam Farley
> 
> 
> 
> -- Previous Email --
> 
> Hi David, Alan,
> 
> You are right in that the changes to HotSpot would be nontrivial.
> I see a number of places in (e.g.) arguments.cpp that seem to
> exit in the same manner as Xlog (such as -Xinternalversion).
> 
> I would advise ploughing through the CSR process to alter the
> JNI spec, and simultaneously identify some key paths that can
> be raised as bugs. That way, when people have time to address
> these issues, the mechanism to handle a silent exit is already
> in place.
> 
> The JDWP fix can be raised separately as one of these bugs, if
> it would make things simpler.
> 
> As for the name, JNI_SILENT_EXIT is a placeholder, and can be
> readily changed. Do you have any suggestions?
> 
> Lastly, in an ideal world, the VM initialisation should never exit(#). It
> should return a return code that tells the caller something, pass or
> fail, messy or tidy. That way, if someone is using the JNI as part of
> something bigger (like a database or a web server), one of these
> scenarios is just a bug, rather than a world-ender like exit(#).
> 
> And now for the individual messages. :)
> 
> David: Having help data returned by the launcher seems like a
> good way to avoid exit(0) calls, but I'm not sure how we'd prevent
> a JNI-caller using those options. Ultimately, to be sure, we'd have
> to remove the logic for those options, centralise the data to better
> enable launcher access, and add some logic in there so it can find
> any other help data (e.g. from the jdwp agent library). I feel this would
> be a bigger task than adding the new return code and changing the
> vm, plus it wouldn't provide for any non-help scenarios where the
> vm wants to shut down without error during initialisation.
> 
> Alan: I should mention that the silent exit solution is already in
> use in the OpenJ9 VM. Not all of the exit paths have been
> resolved, but many have.
> 
> The code is open and can be found here: <https://github.com/eclipse/openj9>
> https://github.com/eclipse/openj9
> 
> And though the silent exit code is disabled for the time being, it
> can be re-enabled by entering this class:
> 
> runtime/vm/jvminit.c
> 
> and altering line 2343 ( ctrl-f for exit(1) if it's not there).
> 
> I won't paste the full code here in case people are concerned
> about contamination, but I would assert that this code (and the
> associated vm files) prove that the concept is possible.
> 
> Note that that code should not be enabled until after we've
> integrated the code that can handle a silent exit.
> 
> Best Regards
> 
> Adam Farley
> 
> P.S. Thank you both for your efforts on this. :)
> 
> 
> 
> From: David Holmes <david.holmes at oracle.com>
> To: Alan Bateman <Alan.Bateman at oracle.com>, Adam Farley8 
> <adam.farley at uk.ibm.com>, core-libs-dev at openjdk.java.net, 
> hotspot-runtime-dev at openjdk.java.net, thomas.stuefe at gmail.com
> Date: 15/09/2017 12:03
> Subject: Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be 
> exited by java
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> On 15/09/2017 8:17 PM, Alan Bateman wrote:
>  > On 15/09/2017 02:47, David Holmes wrote:
>  >> Hi Adam,
>  >>
>  >> I am still very much torn over this one. I think the idea of
>  >> print-and-exit flags for a potentially hosted library like the JVM is
>  >> just wrong - we should never have done that, but we did. Fixing that
>  >> by moving the flags to the launcher is far from trivial**. Endorsing
>  >> and encouraging these sorts of flag by adding JNI support seems to be
>  >> sending the wrong message.
>  >>
>  >> ** I can envisage a "help xxx" Dcmd that can read back the info from
>  >> the VM. The launcher can send the Dcmd, print the output and exit. The
>  >> launcher would not need to know what the xxx values mean, but would
>  >> have to intercept the existing ones.
>  >>
>  >> Another option is just to be aware of these flags (are there more than
>  >> jdwp and Xlog?) and deal with them specially in your custom launcher -
>  >> either filter them out and ignore them, or else launch the VM in its
>  >> own process to respond to them.
>  >>
>  >> Any changes to the JNI specification need to go through the CSR process.
>  > Yes, it would require an update to the JNI spec, also a change to the
>  > JVM TI spec where Agent_OnLoad returning a non-0 value is specified to
>  > terminates the VM. The name and value needs discussion too, esp. as the
>  > JNI spec uses negative values for failure.
>  >
>  > In any case, I'm also torn over this one as it's a corner case that is
>  > only interesting for custom launchers that load agents with options that
>  > print usage messages. It wouldn't be hard to have the Agent_OnLoad
>  > specify a printf hook that the agent could use for output although there
>  > are complications with agents such as JDWP that also announce their
>  > transport end point. Beyond that there is still the issue of the custom
>  > launcher that would need to know to destroy the VM without reporting an
>  > error.
>  >
>  > So what happened to the more meaty part to this which is fixing the
>  > various cases in HotSpot that terminate the process during
>  > initialization? I would expect some progress could be made on those
>  > cases while trying to decide whether to rev the JNI and JVM TI specs to
>  > cover the help case.
> 
> Trying to eliminate the vm_exit_during_initialization paths in hotspot
> is a huge undertaking IMHO.
> 
> David
> 
>  >
>  > -Alan
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From mandy.chung at oracle.com  Fri Oct 13 15:40:11 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 13 Oct 2017 08:40:11 -0700
Subject: Review Request JDK-8189202: (jdeps) Need jdeps output format easy for
 jlink --add-modules to use
Message-ID: <0f5f93dc-5e4f-421a-7ff2-12f1f8939373@oracle.com>

http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8189202/webrev.00/

This proposes to add a new jdeps --print-module-deps option to print a 
comma-separated list of modules that the analyzed classes depend on and 
such output can be taken by jlink --add-modules option.? This will make 
it easy for users to run jlink to create a custom image. As Paul and 
Mikael suggest one use is doing something like:
 ?? $ jlink --module-path jmods --add-modules $(jdeps 
--print-module-deps myapp.jar) --output image

jdeps emits warnings if myapp.jar has split packages with JDK modules 
and you can use -q to suppress the warnings.

jdeps --list-deps and --list-reduced-deps provide similiar information 
but it also lists dependences to? JDK internal APIs. It is intended to 
print the dependences to make it easy to convert to @modules in jtreg 
tests and also can be used to set up --add-exports option if needed.?? 
This patch also changes these options not to show "not found" and 
"unnamed module" which are not specific for module dependencies.

thanks
Mandy


From jonathan.gibbons at oracle.com  Fri Oct 13 15:56:34 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 13 Oct 2017 08:56:34 -0700
Subject: [10] RFR of JDK-8173411: Some testng tests check nothing in java
 time
In-Reply-To: <f3d2413e-4c3c-2e1d-b668-c9a955eefcbf@oracle.com>
References: <ad99a750-1fb9-82b2-dce5-490b4ff9b856@oracle.com>
 <4227998c-0522-4307-1b1c-7e52fae099c9@Oracle.com>
 <f3d2413e-4c3c-2e1d-b668-c9a955eefcbf@oracle.com>
Message-ID: <c02b1ffe-75ef-e426-ba47-a41e7f45b251@oracle.com>

FWIW, this is a side-effect of taking jtreg having to take some corner 
cases into account when determining what are "jtreg" tests in a 
hierarchy of TestNG tests.

The underlying problem is that there is no easy reliable way to 
determine if a source file contains test cases or if it is just a 
library file. It is not enough to use simple heuristics like scanning 
the source for @Test annotations, because of the variety of dynamic ways 
that tests can be found when precompiling all the files and then running 
them all together with TestNG itself.

If we accepted some restrictions, or some guidelines, on marking tests 
as "jtreg-tests", then we could avoid issues like this, but there was 
resistance to such a proposal when TestNG support was added to jtreg.

-- Jon


On 10/12/17 10:39 PM, Amy Lu wrote:
> non-test be run as a test, the result may lead to confusion.
>
> For example, if look at MockSimplePeriod.java test result, it shows:
> ===============================================
> java/time/test/java/time/MockSimplePeriod.java
> Total tests run: 0, Failures: 0, Skips: 0
> ===============================================
>
> Without looking into the detail of the test code, one may raise 
> question why this test has 0 testcase.
>
> If this is not a concern, I can withdraw this change request.
>
> Thanks,
> Amy
>
> On 10/13/17 1:06 AM, Roger Riggs wrote:
>> Hi Amy,
>>
>> I'm not convinced this is the right move.  Moving parts of tests 
>> further from the test
>> is not helpful from a maintenance point of view.
>> I'm not concerned about compilation time.  Its not significant.
>>
>> For example, AbstractDateTimeTest has @Test directives and is not 
>> just library code.
>>
>> The files in the 'tck' hierarchy are intended to be self sufficient 
>> and a direct mirror
>> or the tests in the JCK.
>>
>> Please provide a more compelling reason for the change.
>>
>> Thanks, Roger
>>
>>
>>
>> On 10/10/2017 11:30 PM, Amy Lu wrote:
>>> Please review the patch to change TestNG.dirs and lib.dirs (def and 
>>> file structure) for test/jdk/java/time.
>>>
>>> test/jdk/java/time contains three sets of tests:
>>> nontestng/
>>> tck/
>>> test/
>>>
>>> Tests from directory "tck" and "test" are testng tests with properties:
>>> TestNG.dirs = ..
>>> lib.dirs = ../../../lib/testlibrary
>>> lib.build = jdk.testlibrary.RandomFactory
>>>
>>> But not all files under "TestNG.dirs" are real tests, some of them 
>>> are "libraries" thus should not be put under "TestNG.dirs" (thus be 
>>> run as testng test). Moreover, due to this def, when one runs tests 
>>> from "test" directory, extra files (nontestng/* and tck/*) will also 
>>> be compiled (which are unnecessary compiling).
>>>
>>> In this patch:
>>> Non-test files ("libraries") are moved to "lib" directory;
>>> Real tests previously under "test" dir are moved to test/jdk/, and 
>>> tests under "tck" dir are moved to test/tck/;
>>> test/jdk/ and test/tck/ each has TEST.properties with def:
>>>     TestNG.dirs = .
>>>     lib.dirs = /java/time/lib /lib/testlibrary
>>> MockIOExceptionAppendable.java is not used anywhere, removed.
>>> MockSimplePeriod.java previously exist in both "tck" and "test", now 
>>> it is under "lib".
>>>
>>> With this change, non-test file then won't be run as testng test and 
>>> no unnecessary compiling.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8173411
>>> webrev: http://cr.openjdk.java.net/~amlu/8173411/webrev.00/
>>>
>>> Thanks,
>>> Amy
>>>
>>
>


From martinrb at google.com  Fri Oct 13 18:21:06 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 13 Oct 2017 11:21:06 -0700
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <5a8e9af1-62f4-a381-26b4-d3eda070195d@oracle.com>
References: <CADQzvmmGEGDCOO1uTBF-RraMuNA9DU_3ZChFKQtBL+nebthuEA@mail.gmail.com>
 <CADQzvmnDBx_UF0J0=1NvxT6T+x3+x942aV0L9xJOZ_8gC04g_g@mail.gmail.com>
 <00f301d2ce6c$55611020$00233060$@apache.org>
 <CADQzvmnX8+jcjD4zCSHoXu4cbZMQJZ2JzuFY5hR2YCWb81vdKQ@mail.gmail.com>
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 <CADQzvm=yZD0QczjWv2O3sQb=syeT8ZsXHjD=U7mTA=3aQPaEvQ@mail.gmail.com>
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
 <CA+kOe0_3J-ebfojgbtdHp5UFmd0Qn9QyH_TFWUOuSxvU5U_K7Q@mail.gmail.com>
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
 <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>
 <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>
 <8A666ED1-DC0F-43AE-B451-1122A5C498D8@oracle.com>
 <CADQzvmmj2V3Crun+Vih4kQcZh_5givde1cuM1V89-pfSaWKMYA@mail.gmail.com>
 <CAGUMyaQCQXEqof74yOyqniBMCr6jJuPUnj+8QpEsY5SpJB+O0w@mail.gmail.com>
 <8342ED1F-C4B6-4E66-BEE1-4F70CE69D4A7@gmail.com>
 <5a8e9af1-62f4-a381-26b4-d3eda070195d@oracle.com>
Message-ID: <CA+kOe09uzcmw5REN1AKQZNJnU9f-68zEQ3hcT5vAJZq-DM=J2w@mail.gmail.com>

Actual mutability of the Unix process environment is something we have to
give up when moving to multi-threaded processes.  The only time you get to
change the environment is when running single-threaded, typically around
fork/exec.  Learn to live with it.

The Java System.getenv() is initialized from the Unix environment and is
also immutable.  One could imagine making that mutable in the style of
ConcurrentHashMap and having subprocesses inherit it, but it would open up
a divergence between Java and native.  It's easier for an environment like
gradle to do the same sort of thing, but then there's the same problem -
all the users would need to use exclusively gradle APIs to access the
environment and spawn subprocesses, else the mismatch will cause trouble.

From Roger.Riggs at Oracle.com  Fri Oct 13 19:04:14 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 13 Oct 2017 15:04:14 -0400
Subject: [10] RFR of JDK-8173411: Some testng tests check nothing in java
 time
In-Reply-To: <f3d2413e-4c3c-2e1d-b668-c9a955eefcbf@oracle.com>
References: <ad99a750-1fb9-82b2-dce5-490b4ff9b856@oracle.com>
 <4227998c-0522-4307-1b1c-7e52fae099c9@Oracle.com>
 <f3d2413e-4c3c-2e1d-b668-c9a955eefcbf@oracle.com>
Message-ID: <bf2ef545-607b-ee8d-c17d-1189b50cbb1b@Oracle.com>

Hi Amy,

I don't see a problem with the cases of 'Total tests run: 0'.? It is 
very explicit, no tests were selected.
Testng has a number of dynamic mechanisms for test selection such that
even files in the test directories might not have any tests to run. As 
Jon pointed out that's just part of TestNG.

Does this throw off the jtreg reports of tests run vs failures?? I 
haven't seen that.

I'd leave well enough alone.

Thanks, Roger




On 10/13/2017 1:39 AM, Amy Lu wrote:
> non-test be run as a test, the result may lead to confusion.
>
> For example, if look at MockSimplePeriod.java test result, it shows:
> ===============================================
> java/time/test/java/time/MockSimplePeriod.java
> Total tests run: 0, Failures: 0, Skips: 0
> ===============================================
>
> Without looking into the detail of the test code, one may raise 
> question why this test has 0 testcase.
>
> If this is not a concern, I can withdraw this change request.
>
> Thanks,
> Amy
>
> On 10/13/17 1:06 AM, Roger Riggs wrote:
>> Hi Amy,
>>
>> I'm not convinced this is the right move.? Moving parts of tests 
>> further from the test
>> is not helpful from a maintenance point of view.
>> I'm not concerned about compilation time.? Its not significant.
>>
>> For example, AbstractDateTimeTest has @Test directives and is not 
>> just library code.
>>
>> The files in the 'tck' hierarchy are intended to be self sufficient 
>> and a direct mirror
>> or the tests in the JCK.
>>
>> Please provide a more compelling reason for the change.
>>
>> Thanks, Roger
>>
>>
>>
>> On 10/10/2017 11:30 PM, Amy Lu wrote:
>>> Please review the patch to change TestNG.dirs and lib.dirs (def and 
>>> file structure) for test/jdk/java/time.
>>>
>>> test/jdk/java/time contains three sets of tests:
>>> nontestng/
>>> tck/
>>> test/
>>>
>>> Tests from directory "tck" and "test" are testng tests with properties:
>>> TestNG.dirs = ..
>>> lib.dirs = ../../../lib/testlibrary
>>> lib.build = jdk.testlibrary.RandomFactory
>>>
>>> But not all files under "TestNG.dirs" are real tests, some of them 
>>> are "libraries" thus should not be put under "TestNG.dirs" (thus be 
>>> run as testng test). Moreover, due to this def, when one runs tests 
>>> from "test" directory, extra files (nontestng/* and tck/*) will also 
>>> be compiled (which are unnecessary compiling).
>>>
>>> In this patch:
>>> Non-test files ("libraries") are moved to "lib" directory;
>>> Real tests previously under "test" dir are moved to test/jdk/, and 
>>> tests under "tck" dir are moved to test/tck/;
>>> test/jdk/ and test/tck/ each has TEST.properties with def:
>>> ??? TestNG.dirs = .
>>> ??? lib.dirs = /java/time/lib /lib/testlibrary
>>> MockIOExceptionAppendable.java is not used anywhere, removed.
>>> MockSimplePeriod.java previously exist in both "tck" and "test", now 
>>> it is under "lib".
>>>
>>> With this change, non-test file then won't be run as testng test and 
>>> no unnecessary compiling.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8173411
>>> webrev: http://cr.openjdk.java.net/~amlu/8173411/webrev.00/
>>>
>>> Thanks,
>>> Amy
>>>
>>
>


From amy.lu at oracle.com  Sat Oct 14 04:37:38 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Sat, 14 Oct 2017 12:37:38 +0800
Subject: [10] RFR of JDK-8173411: Some testng tests check nothing in java
 time
In-Reply-To: <bf2ef545-607b-ee8d-c17d-1189b50cbb1b@Oracle.com>
References: <ad99a750-1fb9-82b2-dce5-490b4ff9b856@oracle.com>
 <4227998c-0522-4307-1b1c-7e52fae099c9@Oracle.com>
 <f3d2413e-4c3c-2e1d-b668-c9a955eefcbf@oracle.com>
 <bf2ef545-607b-ee8d-c17d-1189b50cbb1b@Oracle.com>
Message-ID: <0b05c042-0608-7ebe-72ee-33308845c0e0@oracle.com>

Thank you Roger and Jon for the comments!

Change request withdrawn :-)

Thanks,
Amy

On 10/14/17 3:04 AM, Roger Riggs wrote:
> Hi Amy,
>
> I don't see a problem with the cases of 'Total tests run: 0'.? It is 
> very explicit, no tests were selected.
> Testng has a number of dynamic mechanisms for test selection such that
> even files in the test directories might not have any tests to run. As 
> Jon pointed out that's just part of TestNG.
>
> Does this throw off the jtreg reports of tests run vs failures?? I 
> haven't seen that.
>
> I'd leave well enough alone.
>
> Thanks, Roger
>
>
>
>
> On 10/13/2017 1:39 AM, Amy Lu wrote:
>> non-test be run as a test, the result may lead to confusion.
>>
>> For example, if look at MockSimplePeriod.java test result, it shows:
>> ===============================================
>> java/time/test/java/time/MockSimplePeriod.java
>> Total tests run: 0, Failures: 0, Skips: 0
>> ===============================================
>>
>> Without looking into the detail of the test code, one may raise 
>> question why this test has 0 testcase.
>>
>> If this is not a concern, I can withdraw this change request.
>>
>> Thanks,
>> Amy
>>
>> On 10/13/17 1:06 AM, Roger Riggs wrote:
>>> Hi Amy,
>>>
>>> I'm not convinced this is the right move.? Moving parts of tests 
>>> further from the test
>>> is not helpful from a maintenance point of view.
>>> I'm not concerned about compilation time.? Its not significant.
>>>
>>> For example, AbstractDateTimeTest has @Test directives and is not 
>>> just library code.
>>>
>>> The files in the 'tck' hierarchy are intended to be self sufficient 
>>> and a direct mirror
>>> or the tests in the JCK.
>>>
>>> Please provide a more compelling reason for the change.
>>>
>>> Thanks, Roger
>>>
>>>
>>>
>>> On 10/10/2017 11:30 PM, Amy Lu wrote:
>>>> Please review the patch to change TestNG.dirs and lib.dirs (def and 
>>>> file structure) for test/jdk/java/time.
>>>>
>>>> test/jdk/java/time contains three sets of tests:
>>>> nontestng/
>>>> tck/
>>>> test/
>>>>
>>>> Tests from directory "tck" and "test" are testng tests with 
>>>> properties:
>>>> TestNG.dirs = ..
>>>> lib.dirs = ../../../lib/testlibrary
>>>> lib.build = jdk.testlibrary.RandomFactory
>>>>
>>>> But not all files under "TestNG.dirs" are real tests, some of them 
>>>> are "libraries" thus should not be put under "TestNG.dirs" (thus be 
>>>> run as testng test). Moreover, due to this def, when one runs tests 
>>>> from "test" directory, extra files (nontestng/* and tck/*) will 
>>>> also be compiled (which are unnecessary compiling).
>>>>
>>>> In this patch:
>>>> Non-test files ("libraries") are moved to "lib" directory;
>>>> Real tests previously under "test" dir are moved to test/jdk/, and 
>>>> tests under "tck" dir are moved to test/tck/;
>>>> test/jdk/ and test/tck/ each has TEST.properties with def:
>>>> ??? TestNG.dirs = .
>>>> ??? lib.dirs = /java/time/lib /lib/testlibrary
>>>> MockIOExceptionAppendable.java is not used anywhere, removed.
>>>> MockSimplePeriod.java previously exist in both "tck" and "test", 
>>>> now it is under "lib".
>>>>
>>>> With this change, non-test file then won't be run as testng test 
>>>> and no unnecessary compiling.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8173411
>>>> webrev: http://cr.openjdk.java.net/~amlu/8173411/webrev.00/
>>>>
>>>> Thanks,
>>>> Amy
>>>>
>>>
>>
>


From peter.levart at gmail.com  Sat Oct 14 08:51:34 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 14 Oct 2017 10:51:34 +0200
Subject: RFR 8080225: FileInputStream cleanup should be improved
In-Reply-To: <c31522d5-60ff-0a69-88f5-01a68049bd32@Oracle.com>
References: <abbc6122-e6fa-71eb-fa85-01a419cfbfd1@Oracle.com>
 <410d0712-5ff6-5821-482a-389d6a6ac69b@oracle.com>
 <c31522d5-60ff-0a69-88f5-01a68049bd32@Oracle.com>
Message-ID: <f642863c-94a4-153b-65e2-a0b8a74e736a@gmail.com>

Hi Roger,

I know I'm late for the comments on this one, but anyway...

I'm looking at JNI part of FileDescriptor. There are now two native 
"close" methods for each FileDescriptor variant (unix/windows). One is 
instance method (close0) and the other is static (cleanupClose0), which 
takes an int fd / long handle argument. close0 delegates to C method 
"fileDescriptorClose", which could be implemented entirely in Java with 
a little help from static cleanupClose0, don't you think? This could be 
a follow-up cleanup effort.

Regards, Peter

On 10/04/17 16:35, Roger Riggs wrote:
> Hi Mandy,
>
> Updated the webrev in place:
> ?? http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/
>
>
> On 10/3/2017 7:17 PM, mandy chung wrote:
>> Hi Roger,
>>
>> This looks good overall.
>>
>> 53 * unreachable should explicitly override {@link #finalize} and 
>> call {@code close}.
>>
>> Since finalize is deprecated, I would not recommend to have the 
>> subclass adding the finalize method.? I suggest to take that phrase 
>> out (I gave a similar comment to JDK-8185582 [1]). Users should use 
>> try-with-resource or register the instances in a cleaner.
> ok, but neither t-w-r or cleaner can completely replace the behavior 
> of finalize.
> In some cases, significant refactoring of the application class may be 
> needed.
>>
>> As for the tests, FinalizeShdCallClose.java implements finalize.? I 
>> think it'd be good to convert them to try-with-resource.
> The new tests Unreferenced*ClosesFd incorporate the original 
> FinalizeShdCallClose tests cases
> except the case where the subclass does override finalize to call 
> closed; behavior that is deprecated
> but still supported.
> I refactored the Unreferenced*ClosesFd tests to make the 
> FinalizeShdCallClose tests unnecessary and
> will remove them. [If the CSR requires greater behavioral 
> compatibility, the tests may be needed again].
>
>>
>> I'm not close to java.io implementation.? Would registerCleanup be 
>> called more than once? line 220 in the registerCleanup will create a 
>> new cleanup if it's invoked the second time - is it intentional?
>> 216 synchronized void registerCleanup() {
>> 217 if (cleanup != null) {
>> 218 cleanup.clear();
>> 219 }
>> 220 cleanup = FDCleanup.create(this);
>> 221 }
> Re-registering *clears* not cleans the previous cleanup and then 
> creates a new one.
> If the native fd has changed a new cleanup is needed.
> There no cases currently where registerCleanup is called twice on the 
> same FileDescriptor.
>
> Thanks, Roger
>
>> thanks Mandy
>> [1] 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049362.html
>>
>> On 9/29/17 10:17 AM, Roger Riggs wrote:
>>> Replacing finalizers in FileInputStream, FileOutputStream, and 
>>> adding cleanup to RandomAccessFile
>>> and NIO File Channels with Cleaner based implementations required 
>>> changes to FileDescriptor.
>>>
>>> The specification of FileInputStream and FileOutputStream is changed 
>>> to remove the finalizer
>>> behavior that required their respective close methods to be called.
>>> This change to the behavior is tracked with CSR 8187325 [3].
>>>
>>> The FileDescriptor implementations (Unix and Windows) provide a 
>>> cleanup function that is now used by
>>> FIS, FOS, RAF, and async and normal FileChannels.? Each requests 
>>> FileDescriptor to register a cleanup function
>>> when the fd or handle is assigned and delegates to 
>>> FileDescriptor.close.? If the respective
>>> FileDescriptor.close method is not called, the fd or handle will be 
>>> closed when the FileDescriptor
>>> is determined to be phantom reachable.
>>>
>>> The other uses of FileDescriptor are not intended to be changed, for 
>>> example in sockets and datagrams.
>>>
>>> Some tests were modified to not rely on finalization; new tests are 
>>> provided.
>>>
>>> Comments are appreciated on both the CSR [3] and the implementation 
>>> [1].
>>>
>>> [1] webrev: 
>>> http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/
>>>
>>> [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8080225
>>>
>>> [3] CSR:? 8187325? FileInputStream/FileOutputStream should use the 
>>> Cleaner instead of finalize
>>> https://bugs.openjdk.java.net/browse/JDK-8187325
>>>
>>> Thanks, Roger
>>>
>>>
>>
>


From peter.levart at gmail.com  Sat Oct 14 09:00:25 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 14 Oct 2017 11:00:25 +0200
Subject: RFR 8080225: FileInputStream cleanup should be improved
In-Reply-To: <f642863c-94a4-153b-65e2-a0b8a74e736a@gmail.com>
References: <abbc6122-e6fa-71eb-fa85-01a419cfbfd1@Oracle.com>
 <410d0712-5ff6-5821-482a-389d6a6ac69b@oracle.com>
 <c31522d5-60ff-0a69-88f5-01a68049bd32@Oracle.com>
 <f642863c-94a4-153b-65e2-a0b8a74e736a@gmail.com>
Message-ID: <bfc6864b-3e9e-a630-0079-76177b7eade3@gmail.com>


On 10/14/17 10:51, Peter Levart wrote:
> Hi Roger,
>
> I know I'm late for the comments on this one, but anyway...
>
> I'm looking at JNI part of FileDescriptor. There are now two native 
> "close" methods for each FileDescriptor variant (unix/windows). One is 
> instance method (close0) and the other is static (cleanupClose0), 
> which takes an int fd / long handle argument. close0 delegates to C 
> method "fileDescriptorClose", which could be implemented entirely in 
> Java with a little help from static cleanupClose0, don't you think? 

Well, there is this complication in UNIX variant about closing 0,1 or 2 
descriptors. Perhaps the static cleanupClose0 method could encapsulate 
this logic and have the following signature:

private static native int cleanupClose0(int fd);

The all-Java close0() would then use the returned value and replace it 
in FileDescriptor.fd.

What do you think?

Regards, Peter

> This could be a follow-up cleanup effort.
>
> Regards, Peter
>
> On 10/04/17 16:35, Roger Riggs wrote:
>> Hi Mandy,
>>
>> Updated the webrev in place:
>> http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/
>>
>>
>> On 10/3/2017 7:17 PM, mandy chung wrote:
>>> Hi Roger,
>>>
>>> This looks good overall.
>>>
>>> 53 * unreachable should explicitly override {@link #finalize} and 
>>> call {@code close}.
>>>
>>> Since finalize is deprecated, I would not recommend to have the 
>>> subclass adding the finalize method.? I suggest to take that phrase 
>>> out (I gave a similar comment to JDK-8185582 [1]). Users should use 
>>> try-with-resource or register the instances in a cleaner.
>> ok, but neither t-w-r or cleaner can completely replace the behavior 
>> of finalize.
>> In some cases, significant refactoring of the application class may 
>> be needed.
>>>
>>> As for the tests, FinalizeShdCallClose.java implements finalize.? I 
>>> think it'd be good to convert them to try-with-resource.
>> The new tests Unreferenced*ClosesFd incorporate the original 
>> FinalizeShdCallClose tests cases
>> except the case where the subclass does override finalize to call 
>> closed; behavior that is deprecated
>> but still supported.
>> I refactored the Unreferenced*ClosesFd tests to make the 
>> FinalizeShdCallClose tests unnecessary and
>> will remove them. [If the CSR requires greater behavioral 
>> compatibility, the tests may be needed again].
>>
>>>
>>> I'm not close to java.io implementation.? Would registerCleanup be 
>>> called more than once? line 220 in the registerCleanup will create a 
>>> new cleanup if it's invoked the second time - is it intentional?
>>> 216 synchronized void registerCleanup() {
>>> 217 if (cleanup != null) {
>>> 218 cleanup.clear();
>>> 219 }
>>> 220 cleanup = FDCleanup.create(this);
>>> 221 }
>> Re-registering *clears* not cleans the previous cleanup and then 
>> creates a new one.
>> If the native fd has changed a new cleanup is needed.
>> There no cases currently where registerCleanup is called twice on the 
>> same FileDescriptor.
>>
>> Thanks, Roger
>>
>>> thanks Mandy
>>> [1] 
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049362.html
>>>
>>> On 9/29/17 10:17 AM, Roger Riggs wrote:
>>>> Replacing finalizers in FileInputStream, FileOutputStream, and 
>>>> adding cleanup to RandomAccessFile
>>>> and NIO File Channels with Cleaner based implementations required 
>>>> changes to FileDescriptor.
>>>>
>>>> The specification of FileInputStream and FileOutputStream is 
>>>> changed to remove the finalizer
>>>> behavior that required their respective close methods to be called.
>>>> This change to the behavior is tracked with CSR 8187325 [3].
>>>>
>>>> The FileDescriptor implementations (Unix and Windows) provide a 
>>>> cleanup function that is now used by
>>>> FIS, FOS, RAF, and async and normal FileChannels.? Each requests 
>>>> FileDescriptor to register a cleanup function
>>>> when the fd or handle is assigned and delegates to 
>>>> FileDescriptor.close.? If the respective
>>>> FileDescriptor.close method is not called, the fd or handle will be 
>>>> closed when the FileDescriptor
>>>> is determined to be phantom reachable.
>>>>
>>>> The other uses of FileDescriptor are not intended to be changed, 
>>>> for example in sockets and datagrams.
>>>>
>>>> Some tests were modified to not rely on finalization; new tests are 
>>>> provided.
>>>>
>>>> Comments are appreciated on both the CSR [3] and the implementation 
>>>> [1].
>>>>
>>>> [1] webrev: 
>>>> http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/
>>>>
>>>> [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8080225
>>>>
>>>> [3] CSR:? 8187325? FileInputStream/FileOutputStream should use the 
>>>> Cleaner instead of finalize
>>>> https://bugs.openjdk.java.net/browse/JDK-8187325
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>
>>
>


From Roger.Riggs at Oracle.com  Sat Oct 14 16:25:46 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Sat, 14 Oct 2017 12:25:46 -0400
Subject: RFR 8080225: FileInputStream cleanup should be improved
In-Reply-To: <bfc6864b-3e9e-a630-0079-76177b7eade3@gmail.com>
References: <abbc6122-e6fa-71eb-fa85-01a419cfbfd1@Oracle.com>
 <410d0712-5ff6-5821-482a-389d6a6ac69b@oracle.com>
 <c31522d5-60ff-0a69-88f5-01a68049bd32@Oracle.com>
 <f642863c-94a4-153b-65e2-a0b8a74e736a@gmail.com>
 <bfc6864b-3e9e-a630-0079-76177b7eade3@gmail.com>
Message-ID: <87ba874d-4d56-79c8-4ab5-82b489b82fc1@Oracle.com>

Hi Peter,

On 10/14/2017 5:00 AM, Peter Levart wrote:
>
> On 10/14/17 10:51, Peter Levart wrote:
>> Hi Roger,
>>
>> I know I'm late for the comments on this one, but anyway...
>>
>> I'm looking at JNI part of FileDescriptor. There are now two native 
>> "close" methods for each FileDescriptor variant (unix/windows). One 
>> is instance method (close0) and the other is static (cleanupClose0), 
>> which takes an int fd / long handle argument. close0 delegates to C 
>> method "fileDescriptorClose", which could be implemented entirely in 
>> Java with a little help from static cleanupClose0, don't you think? 
>
> Well, there is this complication in UNIX variant about closing 0,1 or 
> 2 descriptors. Perhaps the static cleanupClose0 method could 
> encapsulate this logic and have the following signature:
>
> private static native int cleanupClose0(int fd);
>
> The all-Java close0() would then use the returned value and replace it 
> in FileDescriptor.fd.
>
> What do you think?

The native handling of the file descriptor and setting the field to -1 
in native code was,
I think, trying to avoid races in the closing of the fd.? The functions 
in io_util_md.c
are also used for sockets and datagrams in addition to files.? It has 
always been sensitive code.
The new CleanupClose0 was intended only for the case where a FD was 
unreferenced.
The System.in/out/err FileDescriptors should never become unreferenced 
so the redirection
to /dev/null is not needed in that case.

I filed a cleanup bug: https://bugs.openjdk.java.net/browse/JDK-8189330
to take another look later.

Thanks, Roger

>
> Regards, Peter
>
>> This could be a follow-up cleanup effort.
>>
>> Regards, Peter
>>
>> On 10/04/17 16:35, Roger Riggs wrote:
>>> Hi Mandy,
>>>
>>> Updated the webrev in place:
>>> http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/
>>>
>>>
>>> On 10/3/2017 7:17 PM, mandy chung wrote:
>>>> Hi Roger,
>>>>
>>>> This looks good overall.
>>>>
>>>> 53 * unreachable should explicitly override {@link #finalize} and 
>>>> call {@code close}.
>>>>
>>>> Since finalize is deprecated, I would not recommend to have the 
>>>> subclass adding the finalize method.? I suggest to take that phrase 
>>>> out (I gave a similar comment to JDK-8185582 [1]). Users should use 
>>>> try-with-resource or register the instances in a cleaner.
>>> ok, but neither t-w-r or cleaner can completely replace the behavior 
>>> of finalize.
>>> In some cases, significant refactoring of the application class may 
>>> be needed.
>>>>
>>>> As for the tests, FinalizeShdCallClose.java implements finalize.? I 
>>>> think it'd be good to convert them to try-with-resource.
>>> The new tests Unreferenced*ClosesFd incorporate the original 
>>> FinalizeShdCallClose tests cases
>>> except the case where the subclass does override finalize to call 
>>> closed; behavior that is deprecated
>>> but still supported.
>>> I refactored the Unreferenced*ClosesFd tests to make the 
>>> FinalizeShdCallClose tests unnecessary and
>>> will remove them. [If the CSR requires greater behavioral 
>>> compatibility, the tests may be needed again].
>>>
>>>>
>>>> I'm not close to java.io implementation.? Would registerCleanup be 
>>>> called more than once? line 220 in the registerCleanup will create 
>>>> a new cleanup if it's invoked the second time - is it intentional?
>>>> 216 synchronized void registerCleanup() {
>>>> 217 if (cleanup != null) {
>>>> 218 cleanup.clear();
>>>> 219 }
>>>> 220 cleanup = FDCleanup.create(this);
>>>> 221 }
>>> Re-registering *clears* not cleans the previous cleanup and then 
>>> creates a new one.
>>> If the native fd has changed a new cleanup is needed.
>>> There no cases currently where registerCleanup is called twice on 
>>> the same FileDescriptor.
>>>
>>> Thanks, Roger
>>>
>>>> thanks Mandy
>>>> [1] 
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049362.html
>>>>
>>>> On 9/29/17 10:17 AM, Roger Riggs wrote:
>>>>> Replacing finalizers in FileInputStream, FileOutputStream, and 
>>>>> adding cleanup to RandomAccessFile
>>>>> and NIO File Channels with Cleaner based implementations required 
>>>>> changes to FileDescriptor.
>>>>>
>>>>> The specification of FileInputStream and FileOutputStream is 
>>>>> changed to remove the finalizer
>>>>> behavior that required their respective close methods to be called.
>>>>> This change to the behavior is tracked with CSR 8187325 [3].
>>>>>
>>>>> The FileDescriptor implementations (Unix and Windows) provide a 
>>>>> cleanup function that is now used by
>>>>> FIS, FOS, RAF, and async and normal FileChannels.? Each requests 
>>>>> FileDescriptor to register a cleanup function
>>>>> when the fd or handle is assigned and delegates to 
>>>>> FileDescriptor.close.? If the respective
>>>>> FileDescriptor.close method is not called, the fd or handle will 
>>>>> be closed when the FileDescriptor
>>>>> is determined to be phantom reachable.
>>>>>
>>>>> The other uses of FileDescriptor are not intended to be changed, 
>>>>> for example in sockets and datagrams.
>>>>>
>>>>> Some tests were modified to not rely on finalization; new tests 
>>>>> are provided.
>>>>>
>>>>> Comments are appreciated on both the CSR [3] and the 
>>>>> implementation [1].
>>>>>
>>>>> [1] webrev: 
>>>>> http://cr.openjdk.java.net/~rriggs/webrev-fis-cleanup-8080225/
>>>>>
>>>>> [2] Issue: https://bugs.openjdk.java.net/browse/JDK-8080225
>>>>>
>>>>> [3] CSR:? 8187325? FileInputStream/FileOutputStream should use the 
>>>>> Cleaner instead of finalize
>>>>> https://bugs.openjdk.java.net/browse/JDK-8187325
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>
>>>
>>
>


From sundararajan.athijegannathan at oracle.com  Mon Oct 16 02:12:43 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 16 Oct 2017 07:42:43 +0530
Subject: Review Request JDK-8189202: (jdeps) Need jdeps output format
 easy for jlink --add-modules to use
In-Reply-To: <0f5f93dc-5e4f-421a-7ff2-12f1f8939373@oracle.com>
References: <0f5f93dc-5e4f-421a-7ff2-12f1f8939373@oracle.com>
Message-ID: <59E4159B.50503@oracle.com>

Looks good.

-Sundar

On 13/10/17, 9:10 PM, mandy chung wrote:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8189202/webrev.00/
>
> This proposes to add a new jdeps --print-module-deps option to print a 
> comma-separated list of modules that the analyzed classes depend on 
> and such output can be taken by jlink --add-modules option.  This will 
> make it easy for users to run jlink to create a custom image. As Paul 
> and Mikael suggest one use is doing something like:
>    $ jlink --module-path jmods --add-modules $(jdeps 
> --print-module-deps myapp.jar) --output image
>
> jdeps emits warnings if myapp.jar has split packages with JDK modules 
> and you can use -q to suppress the warnings.
>
> jdeps --list-deps and --list-reduced-deps provide similiar information 
> but it also lists dependences to  JDK internal APIs. It is intended to 
> print the dependences to make it easy to convert to @modules in jtreg 
> tests and also can be used to set up --add-exports option if needed.   
> This patch also changes these options not to show "not found" and 
> "unnamed module" which are not specific for module dependencies.
>
> thanks
> Mandy
>

From peter.levart at gmail.com  Mon Oct 16 09:02:05 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 16 Oct 2017 11:02:05 +0200
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
 <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
Message-ID: <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>

Hi Ogata,

I think that webrev.02 is safe as you describe. But there's one case 
which now has some overhead. It's a common practice to subclass 
ObjectInputStream and override resloveClass() method and implement 
custom resolving (without calling super.resolveClass()). In such case, 
the cached loader is unnecessarily set-up and then not used. So I'm 
thinking about lazy caching.

For example:
- let public readObject() / readUnshared() entry and exit points just 
clear the cached loader (set it to null).
- let resloveClass() do something like the following at entry:

 ????????? CachedLoader cl = cachedLoader;
 ????????? Thread curThread = Thread.currentThread();
 ??? ????? ClassLoader loader;
 ??? ??? ? if (cl == null) {
 ??? ????? ??? loader = latestUserDefinedLoader();
 ????????????? cl = new CachedLoader(loader, curThread);
 ??? ??? ? } else if (cl.thread == curThread) {
 ??? ????? ??? loader = cl.loader;
 ????????? } else {
 ????????????? // multi threaded use
 ??? ??? ????? loader = latestUserDefinedLoader();
 ????????? }

 ????????? // and then...
 ??? ????? return Class.forName(name, false, loader);

What do you think?

Regards, Peter


On 10/13/2017 02:36 PM, Kazunori Ogata wrote:
> Hi Alan,
>
> Alan Bateman <Alan.Bateman at oracle.com> wrote on 2017/10/12 22:17:48:
>
>> This is better but it still not safe. You'll have to atomically set/get
>> the cachedLoader or put it into a thread local to ensure that
>> resolveClass picks up the loader cached by the current thread. A thread
>> local could work too although (needs study) it might need a reference to
>> the OIS to guard against nested deserialization with a different stream.
> Thank you for your review. I fixed the code that does not read the
> cachedLoader atomically when the code tries to update it.
>
> Updated webrev: http://cr.openjdk.java.net/~horii/8188858/webrev.02/
>
>
> The updated code does not use atomic CAS or ThreadLocal.  This code can
> race when the cachedLoader is null, but I think it works correctly because
> a pair of a thread and a class loader (stored in a CachedLoader) is always
> correct regardless of the value of the cachedLoader field, and the thread
> that writes the cachedLoader last resets it to null.  The thread that
> failed to cache a loader simply calls latestUserDefinedLoader(), which is
> the same behavior as the original code.
>
> Considering that multi-thread use of an OIS is rare, I don't want to add
> an overhead of CAS to update the cachedLoader, especially on the POWER
> platform because CAS has high overhead.  Caching loaders in a ThreadLocal
> in each OIS can be more thread safe, but I'm not sure if its memory
> overhead is worth doing so for the rare (and correctly working) case.
>
>
> Regards,
> Ogata
>


From peter.levart at gmail.com  Mon Oct 16 09:36:49 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 16 Oct 2017 11:36:49 +0200
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
 <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
 <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
Message-ID: <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>



On 10/16/2017 11:02 AM, Peter Levart wrote:
> For example:
> - let public readObject() / readUnshared() entry and exit points just 
> clear the cached loader (set it to null).

An alternative would be for entry point to save and clear the cached 
loader while exit point would restore / clear it if it is from correct 
thread / when the call was not nested. Like the following:

public Object readObject() {
 ??? CachedLoader outerCL = cachedLoader;
 ??? cachedLoader = null;
 ??? try {
 ??? ??? ...
 ??? } finally {
 ??? ??? if (outerCL == null || outerCL.thread == Thread.currentThread()) {
 ??? ??? ??? // restore/clear cached loader when nested/outer call ends
 ??? ??? ??? cachedLoader = outerCL;
 ??? ??? }
 ??? }
}

with resolveClass() fragment repeated here for comparison:

 ????????? CachedLoader cl = cachedLoader;
 ????????? Thread curThread = Thread.currentThread();
 ????????? ClassLoader loader;
 ????????? if (cl == null) {
 ????????????? loader = latestUserDefinedLoader();
 ????????????? cachedLoader = new CachedLoader(loader, curThread);
 ????????? } else if (cl.thread == curThread) {
 ????????????? loader = cl.loader;
 ????????? } else {
 ????????????? // multi threaded use
 ????????????? loader = latestUserDefinedLoader();
 ????????? }

 ????????? // and then...
 ????????? return Class.forName(name, false, loader);


There are all sorts of races possible when called concurrently from 
multiple threads, but the worst consequence is that the loader is not 
cached. I also think that even in the presence of races, the 
cachedLoader is eventually cleared when all calls to OIS complete. I 
couldn't think of a situation where such cached loader would remain 
hanging off the completed OIS because of races.

Well, there is one such situation but for a different reason. For 
example, if an OIS subclass is constructed solely to override 
resolveClass method to make it accessible to custom code (for example, 
make it public and call super.resolveClass()) in order to provide a 
utility for resolving classes with the default OIS semantics, but such 
OIS instance is never used for deserialization itself 
(readObject()/readUnshared() is never called).

To solve this problem, resolveClass() logic, including lazy caching, 
should be moved to a private method (resolveClass0()) with protected 
resolveClass() treated like public readObject()/readUnshared() with 
before/after treatment of cached loader around delegation to 
resolveClass0(). All OIS internal uses of resolveClass() should then be 
redirected to resolveClass0().

Regards, Peter


From peter.levart at gmail.com  Mon Oct 16 10:57:50 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 16 Oct 2017 12:57:50 +0200
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
 <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
 <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
 <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>
Message-ID: <1238393b-0d7f-9fea-eb75-3fd816c951a5@gmail.com>

Hi Ogata,

I found a problem in my last suggestion. See below...

On 10/16/2017 11:36 AM, Peter Levart wrote:
>
>
> On 10/16/2017 11:02 AM, Peter Levart wrote:
>> For example:
>> - let public readObject() / readUnshared() entry and exit points just 
>> clear the cached loader (set it to null).
>
> An alternative would be for entry point to save and clear the cached 
> loader while exit point would restore / clear it if it is from correct 
> thread / when the call was not nested. Like the following:
>
> public Object readObject() {
> ??? CachedLoader outerCL = cachedLoader;
> ??? cachedLoader = null;
> ??? try {
> ??? ??? ...
> ??? } finally {
> ??? ??? if (outerCL == null || outerCL.thread == 
> Thread.currentThread()) {
> ??? ??? ??? // restore/clear cached loader when nested/outer call ends
> ??? ??? ??? cachedLoader = outerCL;
> ??? ??? }
> ??? }
> }
>
> with resolveClass() fragment repeated here for comparison:
>
> ????????? CachedLoader cl = cachedLoader;
> ????????? Thread curThread = Thread.currentThread();
> ????????? ClassLoader loader;
> ????????? if (cl == null) {
> ????????????? loader = latestUserDefinedLoader();
> ????????????? cachedLoader = new CachedLoader(loader, curThread);
> ????????? } else if (cl.thread == curThread) {
> ????????????? loader = cl.loader;
> ????????? } else {
> ????????????? // multi threaded use
> ????????????? loader = latestUserDefinedLoader();
> ????????? }
>
> ????????? // and then...
> ????????? return Class.forName(name, false, loader);
>
>
> There are all sorts of races possible when called concurrently from 
> multiple threads, but the worst consequence is that the loader is not 
> cached. I also think that even in the presence of races, the 
> cachedLoader is eventually cleared when all calls to OIS complete. I 
> couldn't think of a situation where such cached loader would remain 
> hanging off the completed OIS because of races.
>
> Well, there is one such situation but for a different reason. For 
> example, if an OIS subclass is constructed solely to override 
> resolveClass method to make it accessible to custom code (for example, 
> make it public and call super.resolveClass()) in order to provide a 
> utility for resolving classes with the default OIS semantics, but such 
> OIS instance is never used for deserialization itself 
> (readObject()/readUnshared() is never called).
>
> To solve this problem, resolveClass() logic, including lazy caching, 
> should be moved to a private method (resolveClass0()) with protected 
> resolveClass() treated like public readObject()/readUnshared() with 
> before/after treatment of cached loader around delegation to 
> resolveClass0(). All OIS internal uses of resolveClass() should then 
> be redirected to resolveClass0().

Oops, this would not work for subclasses that override resolveClass() 
with custom logic. Hm...

The correct and optimal solution is a little bit more involved, I think. 
Here's what I think should work (did not run any tests yet):

http://cr.openjdk.java.net/~plevart/jdk10-dev/8188858_OIS.latestUserDefinedLoader.caching/webrev.01/


Regards, Peter


From sundararajan.athijegannathan at oracle.com  Mon Oct 16 12:22:28 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 16 Oct 2017 17:52:28 +0530
Subject: RFR 8189262: jdk.jlink module-info.java javadoc comment refers to
 the non-existent jmage tool doc
Message-ID: <59E4A484.2060608@oracle.com>

Please review:

Webrev: http://cr.openjdk.java.net/~sundar/8189262/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8189262

Thanks,
-Sundar

From Alan.Bateman at oracle.com  Mon Oct 16 12:20:18 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 16 Oct 2017 13:20:18 +0100
Subject: RFR 8189262: jdk.jlink module-info.java javadoc comment refers to
 the non-existent jmage tool doc
In-Reply-To: <59E4A484.2060608@oracle.com>
References: <59E4A484.2060608@oracle.com>
Message-ID: <18d7c45d-4766-236f-541a-7c4ca8051b94@oracle.com>



On 16/10/2017 13:22, Sundararajan Athijegannathan wrote:
> Please review:
>
> Webrev: http://cr.openjdk.java.net/~sundar/8189262/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189262
Looks fine.

From david.holmes at oracle.com  Mon Oct 16 12:33:20 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Oct 2017 22:33:20 +1000
Subject: RFR 8189262: jdk.jlink module-info.java javadoc comment refers to
 the non-existent jmage tool doc
In-Reply-To: <59E4A484.2060608@oracle.com>
References: <59E4A484.2060608@oracle.com>
Message-ID: <ffdd4e3b-4e49-3113-15e0-d74e40b68219@oracle.com>

Hi Sundar,

Please fix the typo in the bug synopsis:  jmage

Thanks,
David

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

From sundararajan.athijegannathan at oracle.com  Mon Oct 16 12:42:17 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 16 Oct 2017 18:12:17 +0530
Subject: RFR 8189262: jdk.jlink module-info.java javadoc comment refers
 to the non-existent jmage tool doc
In-Reply-To: <ffdd4e3b-4e49-3113-15e0-d74e40b68219@oracle.com>
References: <59E4A484.2060608@oracle.com>
 <ffdd4e3b-4e49-3113-15e0-d74e40b68219@oracle.com>
Message-ID: <59E4A929.4090701@oracle.com>

Thanks! Fixed in JIRA.

-Sundar

On 16/10/17, 6:03 PM, David Holmes wrote:
> Hi Sundar,
>
> Please fix the typo in the bug synopsis:  jmage
>
> Thanks,
> David
>
> On 16/10/2017 10:22 PM, Sundararajan Athijegannathan wrote:
>> Please review:
>>
>> Webrev: http://cr.openjdk.java.net/~sundar/8189262/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189262
>>
>> Thanks,
>> -Sundar

From clement at guillaume.bzh  Thu Oct 12 00:04:56 2017
From: clement at guillaume.bzh (=?UTF-8?Q?Cl=C3=A9ment_Guillaume?=)
Date: Thu, 12 Oct 2017 00:04:56 +0000
Subject: java 9 AKST timezone parsing
In-Reply-To: <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>
References: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
 <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>
Message-ID: <CABYWF2o=cfs3-xmzR4dnVC_jHyWXHm+y6DnDQjcKLoqQvfCsGw@mail.gmail.com>

Hi,

I verified that using java.locale.providers=COMPAT with java 9 makes the
AKST to be parsed as America/Juneau

Is http://bugreport.java.com/ the correct way to file a jira?

Le mer. 11 oct. 2017 ? 10:50, Naoto Sato <naoto.sato at oracle.com> a ?crit :

> (replying to appropriate aliases, instead of generic jdk9-dev alias)
>
> Hi Cl?ment,
>
> The locale data, where those time zone names are derived from, have been
> switched to use Unicode Consortium's CLDR, instead of the ones that are
> previously used prior to JDK9. So there will be some differences you may
> encounter. However it seems not right to parse "AKST" to SystemV time
> zone. I'd appreciate it if you file a JIRA issue for this.
>
> In the mean time, you can revert to the JDK8 behavior by setting the
> system property "-Djava.locale.providers=COMPAT" to the command line.
>
> HTH,
> Naoto
>
> On 10/10/17 7:37 PM, Cl?ment Guillaume wrote:
> > Hello,
> >
> > When parsing a date time string that contains a time zone like AKST,
> AKDT,
> > HST or AST with a DateTimeFormatter built from a pattern containing 'z',
> > java 9 returns the SystemV variant of those timezone, which then behave
> > differently as the "modern" ones. Looks like it's also an issue with long
> > time zone ("Alaska Standard Time")
> >
> >  From my digging I noticed that the PrefixTree generated
> > by ZoneTextPrinterParser.getTree is different in java 8 and java 9, and
> > this may be caused by a different order in the content returned
> > by TimeZoneNameUtility.getZoneStrings(Locale.getDefault())
> >
> > Is this an expected behavior of java 9? (other american time zones are
> > parsed to the modern version: PST -> America/Los_Angeles)
> >
> > I tested it with java 9 build 9+181 and java 8 build 1.8.0_131-b11 (both
> > linux 64 with en_US as local) on this code:
> >
> > import java.time.ZoneOffset;
> > import java.time.format.DateTimeFormatter;
> > import java.time.temporal.TemporalAccessor;
> >
> > public class Main{
> >
> > public static void main(String[] args){
> > DateTimeFormatter timezoneFormatter = DateTimeFormatter.ofPattern("z");
> > TemporalAccessor temporalAccessor = timezoneFormatter.parse("AKST");
> > System.out.println(temporalAccessor);
> > temporalAccessor = timezoneFormatter.parse("AKDT");
> > System.out.println(temporalAccessor);
> > temporalAccessor = timezoneFormatter.parse("HST");
> > System.out.println(temporalAccessor);
> > temporalAccessor = timezoneFormatter.parse("AST");
> > System.out.println(temporalAccessor);
> >
> > DateTimeFormatter isoFormatter =
> >
> DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mmX").withZone(ZoneOffset.UTC);
> > temporalAccessor =
> >
> DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSz").parse("2017-09-13T06:30:33.123AKST");
> > System.out.println(temporalAccessor);
> > System.out.println(isoFormatter.format(temporalAccessor));
> > temporalAccessor =
> >
> DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSVV").parse("2017-09-13T06:30:33.123America/Anchorage");
> > System.out.println(temporalAccessor);
> > System.out.println(isoFormatter.format(temporalAccessor));
> > }
> >
> > }
> >
>

From brent.christian at oracle.com  Mon Oct 16 18:23:22 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 16 Oct 2017 11:23:22 -0700
Subject: RFR 8187772 : JVM crash when currency set on MacOS 10.10 and
 earlier
In-Reply-To: <2b3ea152-cc1f-0f06-e11d-c730e5420439@oracle.com>
References: <100b8914-a3f4-83b6-916b-91826467f7d9@oracle.com>
 <2b3ea152-cc1f-0f06-e11d-c730e5420439@oracle.com>
Message-ID: <c9bad825-cb9d-c905-043e-dbb27f127efa@oracle.com>

Thanks, Naoto.  An automated test run looked fine, so I've pushed this 
change.

-Brent

On 10/12/17 12:38 PM, Naoto Sato wrote:
> Looks fine, Brent.
> 
> Naoto
> 
> On 10/12/17 11:52 AM, Brent Christian wrote:
>> Hi,
>>
>> Please review my change to prevent a startup crash on earlier versions 
>> of MacOS.
>>
>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8187772
>> Webrev: http://cr.openjdk.java.net/~bchristi/8187772/webrev.00/
>>
>> When a non-default currency is set in the Language & Region control 
>> panel, it's reflected as a variant in the locale identifier string.  
>> For example, "en_US at currency=RUB" for U.S. English using the Russian 
>> rubles currency.
>>
>> convertToPOSIXLocale() is not expecting such variants, nor such a long 
>> string.? The result is a SEGV from memmove() on line 161.? (Additional 
>> details are in the bug report.)
>>
>> The fix truncates the string passed to convertToPOSIXLocale() before 
>> any '@'-denoted variant tags.
>>
>> FWIW, the crash only happens on MacOS 10.10 and earlier because later 
>> versions of MacOS always return a region along with the language (line 
>> 65), so we don't need to query the locale identifier (line 84) to 
>> determine the region (hyphenPos is never NULL on line 82).
>>
>> Thanks,
>> -Brent

From claes.redestad at oracle.com  Mon Oct 16 18:26:48 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 16 Oct 2017 20:26:48 +0200
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
 reflection
In-Reply-To: <34043e48-45ec-2e2f-97cb-81b110575864@gmail.com>
References: <000001d341f1$82764870$8762d950$@freenet.de>
 <58df9bf3-fb5d-958e-b4fb-1baf3d86248b@gmail.com>
 <000101d343f0$32b7ba70$98272f50$@freenet.de>
 <34043e48-45ec-2e2f-97cb-81b110575864@gmail.com>
Message-ID: <007dcb59-5759-eb03-0fad-14c301e5dc56@oracle.com>

Hi Peter,

On 2017-10-13 12:05, Peter Levart wrote:
>> Forgive me the maybe stupid question, but isn't your proposed code 
>> changing semantics because it doesn't check for the first parameter 
>> in equals() to be of type java.lang.Object anymore? E.g. like 
>> "method.getParameterTypes()[0] == Object.class". Am I missing 
>> something? Personally, I find this a bit too "magic" overall. I don't 
>> know what Claes thinks about that.
>
> There's only one method named "equals" declared in either Object or 
> Annotation (currently :-). So it's enough to check for declaringClass 
> and name to identify the correct method.

I'm somewhat strapped for cycles right now, so do you mind if I move 
ahead with the simpler patch Christoph proposed initially (and which 
Joel has already reviewed)?

I filed https://bugs.openjdk.java.net/browse/JDK-8189266 for this 
purpose, but feel free to assign this task to yourself if you want to 
work with Christoph to sponsor an improved version.

Looking back at the history of JDK-8029019 I personally prefer adding a 
way to get non-copying access to the Method parameter array rather than 
the declaringClass origin checking.

Thanks!

/Claes


From peter.levart at gmail.com  Tue Oct 17 10:13:28 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 17 Oct 2017 12:13:28 +0200
Subject: AssertionError in WildcardTypeImpl.getUpperBoundASTs
In-Reply-To: <CAM21Rt8uPUk5NE6RSP6Gej9uejsmAz8HNLj3nXon0sK1K0=sUg@mail.gmail.com>
References: <CAM21Rt8uPUk5NE6RSP6Gej9uejsmAz8HNLj3nXon0sK1K0=sUg@mail.gmail.com>
Message-ID: <c011bed4-e776-0ae0-f556-973896841980@gmail.com>

Hi Dawid,

The [2] mentions a thread which resulted in a patch by Martin Bucholtz 
for JDK 9:

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

...but it seems this has not been backported to 8u (yet). The question 
is, will there be any more 8u releases? Would you like this to be 
backported to 8u?

Regards, Peter

On 10/13/2017 09:53 AM, Dawid Weiss wrote:
> Hi all,
>
> We are observing very infrequent assertion errors originating in
> getUpperBoundASTs, mostly during concurrent builds on our build
> machine, when it's under a heavy load. This has been happening from
> time to time with various Java versions; most recently with 1.8.0_131.
>
> I don't see anything in Jira about it, but even a quick Google search
> yields some hits [1].
>
> The stack trace starts with (I include the jackson stack frame which calls it):
>
> java.lang.AssertionError: null
> at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBoundASTs(WildcardTypeImpl.java:86)
> ~[?:1.8.0_131]
> at sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBounds(WildcardTypeImpl.java:122)
> ~[?:1.8.0_131]
> at com.fasterxml.jackson.databind.type.TypeFactory._fromWildcard(TypeFactory.java:1424)
> ~[jackson-databind-2.8.2.jar:2.8.2]
>
> The problem cannot be easily reproduced, but I see a comment mentioned
> on the core-libs-dev a while ago [2] by Joel Borggr?n-Franck, so
> perhaps his question is a valid one and worth investigating:
>
>> Btw, has anyone seen the assert for upper/lower bounds == null fail in the wild?
> Dawid
>
> [1] https://www.google.com/search?q=getUpperBoundASTs+AssertionError&filter=0&biw=1279&bih=863
> (note the "[JENKINS] Lucene-olr-master-Linux" hit).
>
> [2] http://markmail.org/message/4phfnh7dj3qdlo6b


From dawid.weiss at gmail.com  Tue Oct 17 10:41:59 2017
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Tue, 17 Oct 2017 12:41:59 +0200
Subject: AssertionError in WildcardTypeImpl.getUpperBoundASTs
In-Reply-To: <c011bed4-e776-0ae0-f556-973896841980@gmail.com>
References: <CAM21Rt8uPUk5NE6RSP6Gej9uejsmAz8HNLj3nXon0sK1K0=sUg@mail.gmail.com>
 <c011bed4-e776-0ae0-f556-973896841980@gmail.com>
Message-ID: <CAM21Rt8X7uTOEzSJJKWyyPK+d+DhLXf3RzN=B+w=6FGFjROCxw@mail.gmail.com>

Hi Peter,

Thanks for the pointer. Whether or not this fix should be backported
to 8u is probably not for me to decide... but if I can provide some
rationale then I think it'd be better to backport for the following
reasons:

- This assertion isn't frequent, but it does happen from time to time.
Robert Muir also let me know in a private conversation that the
assertion was triggered from time to time in Lucene tests; the test
that mostly caused it to happen has been since disabled (for unrelated
reasons).

- I quickly grepped the most recent Solr/Lucene logs and I see that
the assertion can be buried deep (in the suppressed exceptions chain),
which may be easily overlooked or raise false other concerns. Look at
the stack trace [1] below, for example.

- We run tests on multiple different JVMs/ systems and I'm 99%
confident I've seen errors with this assertion on IBM's J9 too, so it
affects the whole Java ecosystem, not just OpenJDK?

Dawid

[1] Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20468/

5 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.analytics.facet.QueryFacetCloudTest

Error Message:
Error starting up MiniSolrCloudCluster

java.lang.Exception: Error starting up MiniSolrCloudCluster
        at __randomizedtesting.SeedInfo.seed([954FE60C5C176808]:0)
        at org.apache.solr.cloud.MiniSolrCloudCluster.checkForExceptions(MiniSolrCloudCluster.java:507)
        at org.apache.solr.cloud.MiniSolrCloudCluster.<init>(MiniSolrCloudCluster.java:251)
        at org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:190)
        at org.apache.solr.analytics.facet.AbstractAnalyticsFacetCloudTest.setupCluster(AbstractAnalyticsFacetCloudTest.java:56)
        at org.apache.solr.analytics.facet.QueryFacetCloudTest.beforeClass(QueryFacetCloudTest.java:44)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
        at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
        at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
        at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
        at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
        at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
        at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
        at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
        at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
        at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
        at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
        at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
        at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
        at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
        at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
        at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
        at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
        at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
        at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
        at java.lang.Thread.run(Thread.java:748)
        Suppressed: java.lang.AssertionError
                at
sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBoundASTs(WildcardTypeImpl.java:86)
                at
sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBounds(WildcardTypeImpl.java:122)
                at
sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.toString(WildcardTypeImpl.java:190)
                at java.lang.reflect.Type.getTypeName(Type.java:46)
                at
sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.toString(ParameterizedTypeImpl.java:234)
                at java.lang.reflect.Type.getTypeName(Type.java:46)
                at
java.lang.reflect.Method.specificToGenericStringHeader(Method.java:421)
                at
java.lang.reflect.Executable.sharedToGenericString(Executable.java:163)
                at java.lang.reflect.Method.toGenericString(Method.java:415)
                at java.beans.MethodRef.set(MethodRef.java:46)
                at
java.beans.MethodDescriptor.setMethod(MethodDescriptor.java:117)
                at java.beans.MethodDescriptor.<init>(MethodDescriptor.java:72)
                at java.beans.MethodDescriptor.<init>(MethodDescriptor.java:56)
                at
java.beans.Introspector.getTargetMethodInfo(Introspector.java:1205)
                at java.beans.Introspector.getBeanInfo(Introspector.java:426)
                at java.beans.Introspector.getBeanInfo(Introspector.java:173)
                at java.beans.Introspector.getBeanInfo(Introspector.java:260)
                at java.beans.Introspector.<init>(Introspector.java:407)
                at java.beans.Introspector.getBeanInfo(Introspector.java:173)
                at java.beans.Introspector.getBeanInfo(Introspector.java:260)
                at java.beans.Introspector.<init>(Introspector.java:407)
                at java.beans.Introspector.getBeanInfo(Introspector.java:173)
                at java.beans.Introspector.getBeanInfo(Introspector.java:260)
                at java.beans.Introspector.<init>(Introspector.java:407)
                at java.beans.Introspector.getBeanInfo(Introspector.java:173)
                at
org.apache.solr.util.SolrPluginUtils.findSetter(SolrPluginUtils.java:1027)
                at
org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1011)
                at
org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1000)

On Tue, Oct 17, 2017 at 12:13 PM, Peter Levart <peter.levart at gmail.com> wrote:
> Hi Dawid,
>
> The [2] mentions a thread which resulted in a patch by Martin Bucholtz for
> JDK 9:
>
> https://bugs.openjdk.java.net/browse/JDK-8065172
>
> ...but it seems this has not been backported to 8u (yet). The question is,
> will there be any more 8u releases? Would you like this to be backported to
> 8u?
>
> Regards, Peter
>
>
> On 10/13/2017 09:53 AM, Dawid Weiss wrote:
>>
>> Hi all,
>>
>> We are observing very infrequent assertion errors originating in
>> getUpperBoundASTs, mostly during concurrent builds on our build
>> machine, when it's under a heavy load. This has been happening from
>> time to time with various Java versions; most recently with 1.8.0_131.
>>
>> I don't see anything in Jira about it, but even a quick Google search
>> yields some hits [1].
>>
>> The stack trace starts with (I include the jackson stack frame which calls
>> it):
>>
>> java.lang.AssertionError: null
>> at
>> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBoundASTs(WildcardTypeImpl.java:86)
>> ~[?:1.8.0_131]
>> at
>> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBounds(WildcardTypeImpl.java:122)
>> ~[?:1.8.0_131]
>> at
>> com.fasterxml.jackson.databind.type.TypeFactory._fromWildcard(TypeFactory.java:1424)
>> ~[jackson-databind-2.8.2.jar:2.8.2]
>>
>> The problem cannot be easily reproduced, but I see a comment mentioned
>> on the core-libs-dev a while ago [2] by Joel Borggr?n-Franck, so
>> perhaps his question is a valid one and worth investigating:
>>
>>> Btw, has anyone seen the assert for upper/lower bounds == null fail in
>>> the wild?
>>
>> Dawid
>>
>> [1]
>> https://www.google.com/search?q=getUpperBoundASTs+AssertionError&filter=0&biw=1279&bih=863
>> (note the "[JENKINS] Lucene-olr-master-Linux" hit).
>>
>> [2] http://markmail.org/message/4phfnh7dj3qdlo6b
>
>

From OGATAK at jp.ibm.com  Tue Oct 17 11:48:49 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Tue, 17 Oct 2017 20:48:49 +0900
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <1238393b-0d7f-9fea-eb75-3fd816c951a5@gmail.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
 <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
 <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
 <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>
 <1238393b-0d7f-9fea-eb75-3fd816c951a5@gmail.com>
Message-ID: <OFA0D9E522.56232230-ON492581BC.003EF1D9-492581BC.0040E6BF@notes.na.collabserv.com>

Hi Peter,

Thank you for your comments and the fix.  It's a good idea to mark 
cachedLoader with the Thread object.


I think we need to check the marking thread of cachedLoader before 
updating it.  Otherwise, there is a scenario that can leak a CachedLoader 
object:

//1. Thread-A enters readObject() and then call resolveClass()
outerCL-A <- null
cachedLoader <- Thread-A
cachedLoader <- CachedLoader-A

//2. Thread-B enters readObject() and then call resolveClass()
outerCL-B <- CachedLoader-A
cachedLoader <- Thread-B
cachedLoader <- CachedLoader-B1

//3. Thread-B returns from readObject()
cachedLoader is unchanged because outerCL.thread == Thread-A

//4. Thread-B enters readObject() again and then call resolveClass()
outerCL-B <- CachedLoader-B1
cachedLoader <- Thread-B
cachedLoader <- CachedLoader-B2

//5. Thread-A returns from readObject()
cachedLoader <- null

//6. Thread-B returns from readObject()
cachedLoader <- CachedLoader-B1  // Because outerCL-B.thread is Thread-B


By adding checking before updating the mark, Thread-B won't update 
cachedLoader, or it only saves null when race occurs (and always restores 
to null on exit).


Here is the updated webrev: 
http://cr.openjdk.java.net/~horii/8188858/webrev.03/

I also made minor changes to reduce the number of invocation of the JNI 
method Thread.currentThread().


Regards,
Ogata



From:   Peter Levart <peter.levart at gmail.com>
To:     Kazunori Ogata <OGATAK at jp.ibm.com>, Alan Bateman 
<Alan.Bateman at oracle.com>
Cc:     core-libs-dev at openjdk.java.net
Date:   2017/10/16 19:58
Subject:        Re: RFR: 8188858: Caching latestUserDefinedLoader() 
results in ObjectInputStream.readObject()



Hi Ogata,

I found a problem in my last suggestion. See below...

On 10/16/2017 11:36 AM, Peter Levart wrote:
>
>
> On 10/16/2017 11:02 AM, Peter Levart wrote:
>> For example:
>> - let public readObject() / readUnshared() entry and exit points just 
>> clear the cached loader (set it to null).
>
> An alternative would be for entry point to save and clear the cached 
> loader while exit point would restore / clear it if it is from correct 
> thread / when the call was not nested. Like the following:
>
> public Object readObject() {
>     CachedLoader outerCL = cachedLoader;
>     cachedLoader = null;
>     try {
>         ...
>     } finally {
>         if (outerCL == null || outerCL.thread == 
> Thread.currentThread()) {
>             // restore/clear cached loader when nested/outer call ends
>             cachedLoader = outerCL;
>         }
>     }
> }
>
> with resolveClass() fragment repeated here for comparison:
>
>           CachedLoader cl = cachedLoader;
>           Thread curThread = Thread.currentThread();
>           ClassLoader loader;
>           if (cl == null) {
>               loader = latestUserDefinedLoader();
>               cachedLoader = new CachedLoader(loader, curThread);
>           } else if (cl.thread == curThread) {
>               loader = cl.loader;
>           } else {
>               // multi threaded use
>               loader = latestUserDefinedLoader();
>           }
>
>           // and then...
>           return Class.forName(name, false, loader);
>
>
> There are all sorts of races possible when called concurrently from 
> multiple threads, but the worst consequence is that the loader is not 
> cached. I also think that even in the presence of races, the 
> cachedLoader is eventually cleared when all calls to OIS complete. I 
> couldn't think of a situation where such cached loader would remain 
> hanging off the completed OIS because of races.
>
> Well, there is one such situation but for a different reason. For 
> example, if an OIS subclass is constructed solely to override 
> resolveClass method to make it accessible to custom code (for example, 
> make it public and call super.resolveClass()) in order to provide a 
> utility for resolving classes with the default OIS semantics, but such 
> OIS instance is never used for deserialization itself 
> (readObject()/readUnshared() is never called).
>
> To solve this problem, resolveClass() logic, including lazy caching, 
> should be moved to a private method (resolveClass0()) with protected 
> resolveClass() treated like public readObject()/readUnshared() with 
> before/after treatment of cached loader around delegation to 
> resolveClass0(). All OIS internal uses of resolveClass() should then 
> be redirected to resolveClass0().

Oops, this would not work for subclasses that override resolveClass() 
with custom logic. Hm...

The correct and optimal solution is a little bit more involved, I think. 
Here's what I think should work (did not run any tests yet):

https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Eplevart_jdk10-2Ddev_8188858-5FOIS.latestUserDefinedLoader.caching_webrev.01_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=PbaGqOdJOR6jMQkXDVYmjn6832m7o0LU2bzwt2awUgQ&s=gKz_rwcTcGIw8JvmRqlg1-OtjqFNXmIs4oQmIXlF3Wc&e=



Regards, Peter





From peter.levart at gmail.com  Wed Oct 18 06:55:05 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 18 Oct 2017 08:55:05 +0200
Subject: AssertionError in WildcardTypeImpl.getUpperBoundASTs
In-Reply-To: <CAM21Rt8X7uTOEzSJJKWyyPK+d+DhLXf3RzN=B+w=6FGFjROCxw@mail.gmail.com>
References: <CAM21Rt8uPUk5NE6RSP6Gej9uejsmAz8HNLj3nXon0sK1K0=sUg@mail.gmail.com>
 <c011bed4-e776-0ae0-f556-973896841980@gmail.com>
 <CAM21Rt8X7uTOEzSJJKWyyPK+d+DhLXf3RzN=B+w=6FGFjROCxw@mail.gmail.com>
Message-ID: <1fee1e49-12b5-c8b1-60cb-e9fdc921b688@gmail.com>

Hi Dawid,

So if we want this to be included in 8u162 [1] (to be released on 
January 2018), we better hurry up and submit a backported patch before 
end of October...

I can sponsor the patch. Will you be willing to prepare it or do you 
need some help?

I think it should be a straightforward backport of JDK-8065172 [2].

Regards, Peter

[1] http://openjdk.java.net/projects/jdk8u/releases/8u162.html
[2] https://bugs.openjdk.java.net/browse/JDK-8065172

On 10/17/17 12:41, Dawid Weiss wrote:
> Hi Peter,
>
> Thanks for the pointer. Whether or not this fix should be backported
> to 8u is probably not for me to decide... but if I can provide some
> rationale then I think it'd be better to backport for the following
> reasons:
>
> - This assertion isn't frequent, but it does happen from time to time.
> Robert Muir also let me know in a private conversation that the
> assertion was triggered from time to time in Lucene tests; the test
> that mostly caused it to happen has been since disabled (for unrelated
> reasons).
>
> - I quickly grepped the most recent Solr/Lucene logs and I see that
> the assertion can be buried deep (in the suppressed exceptions chain),
> which may be easily overlooked or raise false other concerns. Look at
> the stack trace [1] below, for example.
>
> - We run tests on multiple different JVMs/ systems and I'm 99%
> confident I've seen errors with this assertion on IBM's J9 too, so it
> affects the whole Java ecosystem, not just OpenJDK?
>
> Dawid
>
> [1] Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20468/
>
> 5 tests failed.
> FAILED:  junit.framework.TestSuite.org.apache.solr.analytics.facet.QueryFacetCloudTest
>
> Error Message:
> Error starting up MiniSolrCloudCluster
>
> java.lang.Exception: Error starting up MiniSolrCloudCluster
>          at __randomizedtesting.SeedInfo.seed([954FE60C5C176808]:0)
>          at org.apache.solr.cloud.MiniSolrCloudCluster.checkForExceptions(MiniSolrCloudCluster.java:507)
>          at org.apache.solr.cloud.MiniSolrCloudCluster.<init>(MiniSolrCloudCluster.java:251)
>          at org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:190)
>          at org.apache.solr.analytics.facet.AbstractAnalyticsFacetCloudTest.setupCluster(AbstractAnalyticsFacetCloudTest.java:56)
>          at org.apache.solr.analytics.facet.QueryFacetCloudTest.beforeClass(QueryFacetCloudTest.java:44)
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>          at java.lang.reflect.Method.invoke(Method.java:498)
>          at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>          at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
>          at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
>          at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>          at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>          at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>          at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>          at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
>          at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>          at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>          at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>          at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>          at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>          at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
>          at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>          at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>          at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
>          at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>          at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
>          at java.lang.Thread.run(Thread.java:748)
>          Suppressed: java.lang.AssertionError
>                  at
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBoundASTs(WildcardTypeImpl.java:86)
>                  at
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBounds(WildcardTypeImpl.java:122)
>                  at
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.toString(WildcardTypeImpl.java:190)
>                  at java.lang.reflect.Type.getTypeName(Type.java:46)
>                  at
> sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.toString(ParameterizedTypeImpl.java:234)
>                  at java.lang.reflect.Type.getTypeName(Type.java:46)
>                  at
> java.lang.reflect.Method.specificToGenericStringHeader(Method.java:421)
>                  at
> java.lang.reflect.Executable.sharedToGenericString(Executable.java:163)
>                  at java.lang.reflect.Method.toGenericString(Method.java:415)
>                  at java.beans.MethodRef.set(MethodRef.java:46)
>                  at
> java.beans.MethodDescriptor.setMethod(MethodDescriptor.java:117)
>                  at java.beans.MethodDescriptor.<init>(MethodDescriptor.java:72)
>                  at java.beans.MethodDescriptor.<init>(MethodDescriptor.java:56)
>                  at
> java.beans.Introspector.getTargetMethodInfo(Introspector.java:1205)
>                  at java.beans.Introspector.getBeanInfo(Introspector.java:426)
>                  at java.beans.Introspector.getBeanInfo(Introspector.java:173)
>                  at java.beans.Introspector.getBeanInfo(Introspector.java:260)
>                  at java.beans.Introspector.<init>(Introspector.java:407)
>                  at java.beans.Introspector.getBeanInfo(Introspector.java:173)
>                  at java.beans.Introspector.getBeanInfo(Introspector.java:260)
>                  at java.beans.Introspector.<init>(Introspector.java:407)
>                  at java.beans.Introspector.getBeanInfo(Introspector.java:173)
>                  at java.beans.Introspector.getBeanInfo(Introspector.java:260)
>                  at java.beans.Introspector.<init>(Introspector.java:407)
>                  at java.beans.Introspector.getBeanInfo(Introspector.java:173)
>                  at
> org.apache.solr.util.SolrPluginUtils.findSetter(SolrPluginUtils.java:1027)
>                  at
> org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1011)
>                  at
> org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1000)
>
> On Tue, Oct 17, 2017 at 12:13 PM, Peter Levart <peter.levart at gmail.com> wrote:
>> Hi Dawid,
>>
>> The [2] mentions a thread which resulted in a patch by Martin Bucholtz for
>> JDK 9:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8065172
>>
>> ...but it seems this has not been backported to 8u (yet). The question is,
>> will there be any more 8u releases? Would you like this to be backported to
>> 8u?
>>
>> Regards, Peter
>>
>>
>> On 10/13/2017 09:53 AM, Dawid Weiss wrote:
>>> Hi all,
>>>
>>> We are observing very infrequent assertion errors originating in
>>> getUpperBoundASTs, mostly during concurrent builds on our build
>>> machine, when it's under a heavy load. This has been happening from
>>> time to time with various Java versions; most recently with 1.8.0_131.
>>>
>>> I don't see anything in Jira about it, but even a quick Google search
>>> yields some hits [1].
>>>
>>> The stack trace starts with (I include the jackson stack frame which calls
>>> it):
>>>
>>> java.lang.AssertionError: null
>>> at
>>> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBoundASTs(WildcardTypeImpl.java:86)
>>> ~[?:1.8.0_131]
>>> at
>>> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBounds(WildcardTypeImpl.java:122)
>>> ~[?:1.8.0_131]
>>> at
>>> com.fasterxml.jackson.databind.type.TypeFactory._fromWildcard(TypeFactory.java:1424)
>>> ~[jackson-databind-2.8.2.jar:2.8.2]
>>>
>>> The problem cannot be easily reproduced, but I see a comment mentioned
>>> on the core-libs-dev a while ago [2] by Joel Borggr?n-Franck, so
>>> perhaps his question is a valid one and worth investigating:
>>>
>>>> Btw, has anyone seen the assert for upper/lower bounds == null fail in
>>>> the wild?
>>> Dawid
>>>
>>> [1]
>>> https://www.google.com/search?q=getUpperBoundASTs+AssertionError&filter=0&biw=1279&bih=863
>>> (note the "[JENKINS] Lucene-olr-master-Linux" hit).
>>>
>>> [2] http://markmail.org/message/4phfnh7dj3qdlo6b


From thomas.stuefe at gmail.com  Wed Oct 18 07:44:54 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 18 Oct 2017 09:44:54 +0200
Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer
 overflow in Java_java_nio_MappedByteBuffer_isLoaded0
In-Reply-To: <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com>
References: <CAA-vtUzU5zvZLuUe6kHOfTkijLk7ydrr3C4wsSoaQRhCYdV51g@mail.gmail.com>
 <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com>
 <CAA-vtUztOsSQoYuTmexqDTdhY=bGiYqdqMYdNh=MpmmQ7CveTg@mail.gmail.com>
 <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com>
Message-ID: <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>

Hi all,

I am wrapping up fixes which did not make it into the repo before the
consolidation. Alan already reviewed the last webrev, but I need a second
reviewer.


Issue: https://bugs.openjdk.java.net/browse/JDK-8186665
Last Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-ov
erflow-in-mincore/webrev.01/webrev

Issue text for your convenience:

--
In Java_java_nio_MappedByteBuffer_isLoaded0, we call mincore(2) to retrieve
the paging status of an address range.

The size of the output buffer for mincore(2) depends on the number of pages
in *system page size* in the given memory range (this is spelled out more
or less explicitly on AIX and Linux, nothing is said on BSD/OSX, but I
assume the same). The number of pages in the memory range is calculated by
MappedByteBuffer.isLoaded() and handed down to
Java_java_nio_MappedByteBuffer_isLoaded0() together with the memory range
to test.

MappedByteBuffer.isLoaded() calculates this number of pages based on
jjdk.internal.misc.Unsafe.pagesize(), which ultimately comes down to
os::vm_page_size().

For AIX, os::vm_page_size() may return a page size larger than the system
page size of 4K. The reason for this is that on AIX, memory can be backed
by different page sizes, usually either 4K or 64K - e.g. posix thread
stacks may have 4K pages, java heap (system V shared memory) with 64K
pages, but mmap memory is always 4K page backed...

But as the OpenJDK code base generally assumes one homogeneous page size
for everything - which is usually synonymous with os::vm_page_size() - a
decision had to be made which page size to assume as a global system page
size, and this may be a larger page size than the 4K system page size
mincore(2) assumes.

This usually is no problem, but with mincore(2) it is: as the size of the
output buffer depends on the number of pages, calculating with a too-large
page size causes the output buffer to be too small and hence the buffer
overflows. The solution must be to base the size of the mincore output
buffer on the system page size.

--

Thanks and Kind Regards, Thomas


On Thu, Aug 31, 2017 at 9:39 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 31/08/2017 19:01, Thomas St?fe wrote:
>
>> Hi Alan,
>>
>> thank you for your review!
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-ov
>> erflow-in-mincore/webrev.01/webrev/ <http://cr.openjdk.java.net/%7
>> Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/>
>>
>> I fixed the indention and embellished the comments around the sentinel at
>> the end of the buffer somewhat.
>>
>> This looks okay to me.
>
> -Alan
>

From peter.levart at gmail.com  Wed Oct 18 08:14:40 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 18 Oct 2017 10:14:40 +0200
Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer
 overflow in Java_java_nio_MappedByteBuffer_isLoaded0
In-Reply-To: <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>
References: <CAA-vtUzU5zvZLuUe6kHOfTkijLk7ydrr3C4wsSoaQRhCYdV51g@mail.gmail.com>
 <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com>
 <CAA-vtUztOsSQoYuTmexqDTdhY=bGiYqdqMYdNh=MpmmQ7CveTg@mail.gmail.com>
 <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com>
 <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>
Message-ID: <bf5f0990-41e4-763e-e0b2-b184ccaac340@gmail.com>

Hi Thomas,

Shouldn't the following line:

 ? 47???? return len2 + pagesize - 1 / pagesize;

..be written as:

 ??? ??? ?? return (len2 + pagesize - 1) / pagesize;


Regards, Peter

On 10/18/2017 09:44 AM, Thomas St?fe wrote:
> Hi all,
>
> I am wrapping up fixes which did not make it into the repo before the 
> consolidation. Alan already reviewed the last webrev, but I need a 
> second reviewer.
>
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8186665 
> <https://bugs.openjdk.java.net/browse/JDK-8186665>
> Last Webrev: 
> http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev 
> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/>
>
> Issue text for your convenience:
>
> --
> In Java_java_nio_MappedByteBuffer_isLoaded0, we call mincore(2) to 
> retrieve the paging status of an address range.
>
> The size of the output buffer for mincore(2) depends on the number of 
> pages in *system page size* in the given memory range (this is spelled 
> out more or less explicitly on AIX and Linux, nothing is said on 
> BSD/OSX, but I assume the same). The number of pages in the memory 
> range is calculated by MappedByteBuffer.isLoaded() and handed down to 
> Java_java_nio_MappedByteBuffer_isLoaded0() together with the memory 
> range to test.
>
> MappedByteBuffer.isLoaded() calculates this number of pages based on 
> jjdk.internal.misc.Unsafe.pagesize(), which ultimately comes down to 
> os::vm_page_size().
>
> For AIX, os::vm_page_size() may return a page size larger than the 
> system page size of 4K. The reason for this is that on AIX, memory can 
> be backed by different page sizes, usually either 4K or 64K - e.g. 
> posix thread stacks may have 4K pages, java heap (system V shared 
> memory) with 64K pages, but mmap memory is always 4K page backed...
>
> But as the OpenJDK code base generally assumes one homogeneous page 
> size for everything - which is usually synonymous with 
> os::vm_page_size() - a decision had to be made which page size to 
> assume as a global system page size, and this may be a larger page 
> size than the 4K system page size mincore(2) assumes.
>
> This usually is no problem, but with mincore(2) it is: as the size of 
> the output buffer depends on the number of pages, calculating with a 
> too-large page size causes the output buffer to be too small and hence 
> the buffer overflows. The solution must be to base the size of the 
> mincore output buffer on the system page size.
>
> --
>
> Thanks and Kind Regards, Thomas
>
>
> On Thu, Aug 31, 2017 at 9:39 PM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>     On 31/08/2017 19:01, Thomas St?fe wrote:
>
>         Hi Alan,
>
>         thank you for your review!
>
>         Updated webrev:
>         http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/
>         <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/>
>         <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/
>         <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/>>
>
>         I fixed the indention and embellished the comments around the
>         sentinel at the end of the buffer somewhat.
>
>     This looks okay to me.
>
>     -Alan
>
>


From peter.levart at gmail.com  Wed Oct 18 08:17:29 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 18 Oct 2017 10:17:29 +0200
Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer
 overflow in Java_java_nio_MappedByteBuffer_isLoaded0
In-Reply-To: <bf5f0990-41e4-763e-e0b2-b184ccaac340@gmail.com>
References: <CAA-vtUzU5zvZLuUe6kHOfTkijLk7ydrr3C4wsSoaQRhCYdV51g@mail.gmail.com>
 <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com>
 <CAA-vtUztOsSQoYuTmexqDTdhY=bGiYqdqMYdNh=MpmmQ7CveTg@mail.gmail.com>
 <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com>
 <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>
 <bf5f0990-41e4-763e-e0b2-b184ccaac340@gmail.com>
Message-ID: <b14ad6c7-5ee8-c8a9-d0d2-c805e2f48a8f@gmail.com>



On 10/18/2017 10:14 AM, Peter Levart wrote:
> Hi Thomas,
>
> Shouldn't the following line:
>
> ? 47???? return len2 + pagesize - 1 / pagesize;
>
> ..be written as:
>
> ??? ??? ?? return (len2 + pagesize - 1) / pagesize;

...or better yet, as:

 ??? ??? ?????? return numPages;


(you already calculate it correctly in previous line, but then return an 
expression, which is wrong).

Regards, Peter

>
>
> Regards, Peter
>
> On 10/18/2017 09:44 AM, Thomas St?fe wrote:
>> Hi all,
>>
>> I am wrapping up fixes which did not make it into the repo before the 
>> consolidation. Alan already reviewed the last webrev, but I need a 
>> second reviewer.
>>
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8186665 
>> <https://bugs.openjdk.java.net/browse/JDK-8186665>
>> Last Webrev: 
>> http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev 
>> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/>
>>
>> Issue text for your convenience:
>>
>> --
>> In Java_java_nio_MappedByteBuffer_isLoaded0, we call mincore(2) to 
>> retrieve the paging status of an address range.
>>
>> The size of the output buffer for mincore(2) depends on the number of 
>> pages in *system page size* in the given memory range (this is 
>> spelled out more or less explicitly on AIX and Linux, nothing is said 
>> on BSD/OSX, but I assume the same). The number of pages in the memory 
>> range is calculated by MappedByteBuffer.isLoaded() and handed down to 
>> Java_java_nio_MappedByteBuffer_isLoaded0() together with the memory 
>> range to test.
>>
>> MappedByteBuffer.isLoaded() calculates this number of pages based on 
>> jjdk.internal.misc.Unsafe.pagesize(), which ultimately comes down to 
>> os::vm_page_size().
>>
>> For AIX, os::vm_page_size() may return a page size larger than the 
>> system page size of 4K. The reason for this is that on AIX, memory 
>> can be backed by different page sizes, usually either 4K or 64K - 
>> e.g. posix thread stacks may have 4K pages, java heap (system V 
>> shared memory) with 64K pages, but mmap memory is always 4K page 
>> backed...
>>
>> But as the OpenJDK code base generally assumes one homogeneous page 
>> size for everything - which is usually synonymous with 
>> os::vm_page_size() - a decision had to be made which page size to 
>> assume as a global system page size, and this may be a larger page 
>> size than the 4K system page size mincore(2) assumes.
>>
>> This usually is no problem, but with mincore(2) it is: as the size of 
>> the output buffer depends on the number of pages, calculating with a 
>> too-large page size causes the output buffer to be too small and 
>> hence the buffer overflows. The solution must be to base the size of 
>> the mincore output buffer on the system page size.
>>
>> --
>>
>> Thanks and Kind Regards, Thomas
>>
>>
>> On Thu, Aug 31, 2017 at 9:39 PM, Alan Bateman 
>> <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>>     On 31/08/2017 19:01, Thomas St?fe wrote:
>>
>>         Hi Alan,
>>
>>         thank you for your review!
>>
>>         Updated webrev:
>>         http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/
>>         <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/>
>>         <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/
>>         <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/>>
>>
>>         I fixed the indention and embellished the comments around the
>>         sentinel at the end of the buffer somewhat.
>>
>>     This looks okay to me.
>>
>>     -Alan
>>
>>
>


From christoph.langer at sap.com  Wed Oct 18 08:23:42 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 18 Oct 2017 08:23:42 +0000
Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer
 overflow in Java_java_nio_MappedByteBuffer_isLoaded0
In-Reply-To: <b14ad6c7-5ee8-c8a9-d0d2-c805e2f48a8f@gmail.com>
References: <CAA-vtUzU5zvZLuUe6kHOfTkijLk7ydrr3C4wsSoaQRhCYdV51g@mail.gmail.com>
 <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com>
 <CAA-vtUztOsSQoYuTmexqDTdhY=bGiYqdqMYdNh=MpmmQ7CveTg@mail.gmail.com>
 <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com>
 <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>
 <bf5f0990-41e4-763e-e0b2-b184ccaac340@gmail.com>
 <b14ad6c7-5ee8-c8a9-d0d2-c805e2f48a8f@gmail.com>
Message-ID: <a19f863fca694434b7e79335888c807a@sap.com>

Hi Thomas,

apart from the point that Peter found, I?d also think it would look better if the typedef section (line 51-56) would be placed before the AIX only function (line 41-49).

Other than that, it looks good to me.

Best regards
Christoph

From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Peter Levart
Sent: Mittwoch, 18. Oktober 2017 10:17
To: Thomas St?fe <thomas.stuefe at gmail.com>; Alan Bateman <Alan.Bateman at oracle.com>
Cc: nio-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Java Core Libs <core-libs-dev at openjdk.java.net>
Subject: Re: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0


On 10/18/2017 10:14 AM, Peter Levart wrote:
Hi Thomas,

Shouldn't the following line:

  47     return len2 + pagesize - 1 / pagesize;

..be written as:

           return (len2 + pagesize - 1) / pagesize;

...or better yet, as:

               return numPages;


(you already calculate it correctly in previous line, but then return an expression, which is wrong).

Regards, Peter




Regards, Peter
On 10/18/2017 09:44 AM, Thomas St?fe wrote:
Hi all,

I am wrapping up fixes which did not make it into the repo before the consolidation. Alan already reviewed the last webrev, but I need a second reviewer.


Issue: https://bugs.openjdk.java.net/browse/JDK-8186665
Last Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev<http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/>

Issue text for your convenience:

--
In Java_java_nio_MappedByteBuffer_isLoaded0, we call mincore(2) to retrieve the paging status of an address range.

The size of the output buffer for mincore(2) depends on the number of pages in *system page size* in the given memory range (this is spelled out more or less explicitly on AIX and Linux, nothing is said on BSD/OSX, but I assume the same). The number of pages in the memory range is calculated by MappedByteBuffer.isLoaded() and handed down to Java_java_nio_MappedByteBuffer_isLoaded0() together with the memory range to test.

MappedByteBuffer.isLoaded() calculates this number of pages based on jjdk.internal.misc.Unsafe.pagesize(), which ultimately comes down to os::vm_page_size().

For AIX, os::vm_page_size() may return a page size larger than the system page size of 4K. The reason for this is that on AIX, memory can be backed by different page sizes, usually either 4K or 64K - e.g. posix thread stacks may have 4K pages, java heap (system V shared memory) with 64K pages, but mmap memory is always 4K page backed...

But as the OpenJDK code base generally assumes one homogeneous page size for everything - which is usually synonymous with os::vm_page_size() - a decision had to be made which page size to assume as a global system page size, and this may be a larger page size than the 4K system page size mincore(2) assumes.

This usually is no problem, but with mincore(2) it is: as the size of the output buffer depends on the number of pages, calculating with a too-large page size causes the output buffer to be too small and hence the buffer overflows. The solution must be to base the size of the mincore output buffer on the system page size.

--

Thanks and Kind Regards, Thomas


On Thu, Aug 31, 2017 at 9:39 PM, Alan Bateman <Alan.Bateman at oracle.com<mailto:Alan.Bateman at oracle.com>> wrote:
On 31/08/2017 19:01, Thomas St?fe wrote:
Hi Alan,

thank you for your review!

Updated webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/<http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/>

I fixed the indention and embellished the comments around the sentinel at the end of the buffer somewhat.
This looks okay to me.

-Alan




From peter.levart at gmail.com  Wed Oct 18 08:32:39 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 18 Oct 2017 10:32:39 +0200
Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer
 overflow in Java_java_nio_MappedByteBuffer_isLoaded0
In-Reply-To: <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>
References: <CAA-vtUzU5zvZLuUe6kHOfTkijLk7ydrr3C4wsSoaQRhCYdV51g@mail.gmail.com>
 <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com>
 <CAA-vtUztOsSQoYuTmexqDTdhY=bGiYqdqMYdNh=MpmmQ7CveTg@mail.gmail.com>
 <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com>
 <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>
Message-ID: <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com>

Hi Thomas,

Just one more concern...

On 10/18/2017 09:44 AM, Thomas St?fe wrote:
> Hi all,
>
> I am wrapping up fixes which did not make it into the repo before the 
> consolidation. Alan already reviewed the last webrev, but I need a 
> second reviewer.
>
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8186665 
> <https://bugs.openjdk.java.net/browse/JDK-8186665>
> Last Webrev: 
> http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev 
> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/>
>
> Issue text for your convenience:
>
> --
> In Java_java_nio_MappedByteBuffer_isLoaded0, we call mincore(2) to 
> retrieve the paging status of an address range.
>
> The size of the output buffer for mincore(2) depends on the number of 
> pages in *system page size* in the given memory range (this is spelled 
> out more or less explicitly on AIX and Linux, nothing is said on 
> BSD/OSX, but I assume the same). The number of pages in the memory 
> range is calculated by MappedByteBuffer.isLoaded() and handed down to 
> Java_java_nio_MappedByteBuffer_isLoaded0() together with the memory 
> range to test.
>
> MappedByteBuffer.isLoaded() calculates this number of pages based on 
> jjdk.internal.misc.Unsafe.pagesize(), which ultimately comes down to 
> os::vm_page_size().
>
> For AIX, os::vm_page_size() may return a page size larger than the 
> system page size of 4K. The reason for this is that on AIX, memory can 
> be backed by different page sizes, usually either 4K or 64K - e.g. 
> posix thread stacks may have 4K pages, java heap (system V shared 
> memory) with 64K pages, but mmap memory is always 4K page backed...

If this is true and Unsafe.pagesize() returns a value > 4K, then perhaps 
also the MappedByteBuffer.load() method is wrong for AIX?

 ??? public final MappedByteBuffer load() {
 ??????? checkMapped();
 ??????? if ((address == 0) || (capacity() == 0))
 ??????????? return this;
 ??????? long offset = mappingOffset();
 ??????? long length = mappingLength(offset);
 ??????? load0(mappingAddress(offset), length);

 ??????? // Read a byte from each page to bring it into memory. A checksum
 ??????? // is computed as we go along to prevent the compiler from 
otherwise
 ??????? // considering the loop as dead code.
 ??????? Unsafe unsafe = Unsafe.getUnsafe();
 ??????? int ps = Bits.pageSize(); // << LOOK HERE
 ??????? int count = Bits.pageCount(length);
 ??????? long a = mappingAddress(offset);
 ??????? byte x = 0;
 ??????? for (int i=0; i<count; i++) {
 ??????????? x ^= unsafe.getByte(a);
 ??????????? a += ps; // << AND HERE
 ??????? }
 ??????? if (unused != 0)
 ??????????? unused = x;

 ??????? return this;
 ??? }

...this loop reads a byte from the start of each block in lumps of 
Bits.pageSize(). Should it always read in lumps of 4K for AIX? Do we 
rather need a special Unsafe.mmappedPageSize() method instead of just a 
hack in isLoaded0 ?

Regards, Peter

>
> But as the OpenJDK code base generally assumes one homogeneous page 
> size for everything - which is usually synonymous with 
> os::vm_page_size() - a decision had to be made which page size to 
> assume as a global system page size, and this may be a larger page 
> size than the 4K system page size mincore(2) assumes.
>
> This usually is no problem, but with mincore(2) it is: as the size of 
> the output buffer depends on the number of pages, calculating with a 
> too-large page size causes the output buffer to be too small and hence 
> the buffer overflows. The solution must be to base the size of the 
> mincore output buffer on the system page size.
>
> --
>
> Thanks and Kind Regards, Thomas
>
>
> On Thu, Aug 31, 2017 at 9:39 PM, Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>> wrote:
>
>     On 31/08/2017 19:01, Thomas St?fe wrote:
>
>         Hi Alan,
>
>         thank you for your review!
>
>         Updated webrev:
>         http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/
>         <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/>
>         <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/
>         <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.01/webrev/>>
>
>         I fixed the indention and embellished the comments around the
>         sentinel at the end of the buffer somewhat.
>
>     This looks okay to me.
>
>     -Alan
>
>


From thomas.stuefe at gmail.com  Wed Oct 18 10:24:11 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 18 Oct 2017 12:24:11 +0200
Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer
 overflow in Java_java_nio_MappedByteBuffer_isLoaded0
In-Reply-To: <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com>
References: <CAA-vtUzU5zvZLuUe6kHOfTkijLk7ydrr3C4wsSoaQRhCYdV51g@mail.gmail.com>
 <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com>
 <CAA-vtUztOsSQoYuTmexqDTdhY=bGiYqdqMYdNh=MpmmQ7CveTg@mail.gmail.com>
 <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com>
 <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>
 <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com>
Message-ID: <CAA-vtUzG1kvdG+S2JfBSW_JkYvSSOBkFArbgu4HQ0hgG9jFCKg@mail.gmail.com>

Hi Peter, Christoph,

Thank you both for reviewing.

New webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/

@Peter:

>Shouldn't the following line:
>
>  47     return len2 + pagesize - 1 / pagesize;
>
>..be written as:
>
>           return (len2 + pagesize - 1) / pagesize;

You are right. Did not cause the mincore output buffer to be unnecessarily
large. Thanks for catching this.

As for your other concern:


On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart <peter.levart at gmail.com>
wrote:

> --
> In Java_java_nio_MappedByteBuffer_isLoaded0, we call mincore(2) to
> retrieve the paging status of an address range.
>
> The size of the output buffer for mincore(2) depends on the number of
> pages in *system page size* in the given memory range (this is spelled out
> more or less explicitly on AIX and Linux, nothing is said on BSD/OSX, but I
> assume the same). The number of pages in the memory range is calculated by
> MappedByteBuffer.isLoaded() and handed down to Java_java_nio_MappedByteBuffer_isLoaded0()
> together with the memory range to test.
>
> MappedByteBuffer.isLoaded() calculates this number of pages based on
> jjdk.internal.misc.Unsafe.pagesize(), which ultimately comes down to
> os::vm_page_size().
>
> For AIX, os::vm_page_size() may return a page size larger than the system
> page size of 4K. The reason for this is that on AIX, memory can be backed
> by different page sizes, usually either 4K or 64K - e.g. posix thread
> stacks may have 4K pages, java heap (system V shared memory) with 64K
> pages, but mmap memory is always 4K page backed...
>
>
> If this is true and Unsafe.pagesize() returns a value > 4K, then perhaps
> also the MappedByteBuffer.load() method is wrong for AIX?
>
>     public final MappedByteBuffer load() {
>         checkMapped();
>         if ((address == 0) || (capacity() == 0))
>             return this;
>         long offset = mappingOffset();
>         long length = mappingLength(offset);
>         load0(mappingAddress(offset), length);
>
>         // Read a byte from each page to bring it into memory. A checksum
>         // is computed as we go along to prevent the compiler from
> otherwise
>         // considering the loop as dead code.
>         Unsafe unsafe = Unsafe.getUnsafe();
>         int ps = Bits.pageSize(); // << LOOK HERE
>         int count = Bits.pageCount(length);
>         long a = mappingAddress(offset);
>         byte x = 0;
>         for (int i=0; i<count; i++) {
>             x ^= unsafe.getByte(a);
>             a += ps; // << AND HERE
>         }
>         if (unused != 0)
>             unused = x;
>
>         return this;
>     }
>
> ...this loop reads a byte from the start of each block in lumps of
> Bits.pageSize(). Should it always read in lumps of 4K for AIX? Do we rather
> need a special Unsafe.mmappedPageSize() method instead of just a hack in
> isLoaded0 ?
>
>
Yes, I considered this too. In effect, on AIX, we only touch every 16th
page, thereby reducing MappedByteBuffer::load() to something like
load_every_16th_page... However, this bug is very old (even our 1.4 VM
already does this when the touching was still implemented in
MappedByteBuffer.c) and did not cause any problems AFAIK.

The story behind this is long and quite boring :) basically, 64k pages are
used for the java heap and give a large performance bonus over 4K paged
java heap. But we cannot switch all memory regions to 64K pages, so we live
with multiple page sizes and above us we have a ton of code which assumes
one consistent page size for everything. So we lie about the page size to
everyone - claiming system page size to be 64k - and except for very rare
cases like this one get away with this.

I would like to keep lying consistently. There is not a hard reason for it,
just that I am afraid that starting to publish a different page size to
parts of the VM will confuse things and may introduce errors further down
the line.

I think a proper solution would be to keep page size on a per-ByteBuffer
base, because ByteBuffers may be allocated in different memory regions -
they are now allocated with mmap() in system page size, but that may change
in the future. That is assuming that one byte buffer cannot span areas of
multiple page sizes, which would complicate matters further.

Btw, I also wondered whether other platforms could have a clash between the
real memory page size and MappedByteBuffer's notion of that size - e.g.
whether it is possible to have MappedByteBuffers with huge pages on Linux.
But all cases I could think of are cases where the page size the JDK would
assume is smaller than the actual page size, which would not be a problem
for both mincore and load/touch. In the above example (huge pages on
Linux), pages would be pinned anyway, so load() and isLoaded() would be
noops.


@Christoph:

> apart from the point that Peter found, I?d also think it would look
better if the typedef section (line 51-56) would be placed before the AIX
only function (line 41-49).


Sure. I moved the section up, below the includes.

Kind Regards, Thomas

From ben_walsh at uk.ibm.com  Wed Oct 18 10:35:39 2017
From: ben_walsh at uk.ibm.com (Ben Walsh)
Date: Wed, 18 Oct 2017 11:35:39 +0100
Subject: [PATCH] Unnecessary Amount Of Internal Class Conversion
Message-ID: <OF4944AD2F.D1994796-ON802581BD.0038567D-802581BD.003A31F9@notes.na.collabserv.com>

I have observed a problem where an unnecessary amount of internal class 
conversion is occurring.

I have a patch which I would like to contribute which represents a 
performance optimisation for this problem in the java.instrument module 
implementation.

It avoids having to convert all classes from a JVM's internal class format 
to the .class file format, in order to call the ClassFileLoadHook, when no 
java transformer installed.

I would like to pair with a sponsor to contribute this patch.


Regards,
Ben Walsh


Hursley Labs
IBM United Kingdom Limited
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From Alan.Bateman at oracle.com  Wed Oct 18 11:00:46 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 18 Oct 2017 12:00:46 +0100
Subject: [PATCH] Unnecessary Amount Of Internal Class Conversion
In-Reply-To: <OF4944AD2F.D1994796-ON802581BD.0038567D-802581BD.003A31F9@notes.na.collabserv.com>
References: <OF4944AD2F.D1994796-ON802581BD.0038567D-802581BD.003A31F9@notes.na.collabserv.com>
Message-ID: <5f2f7139-69c6-5120-a2fc-ea97f018ba75@oracle.com>

On 18/10/2017 11:35, Ben Walsh wrote:
> I have observed a problem where an unnecessary amount of internal class
> conversion is occurring.
>
> I have a patch which I would like to contribute which represents a
> performance optimisation for this problem in the java.instrument module
> implementation.
>
> It avoids having to convert all classes from a JVM's internal class format
> to the .class file format, in order to call the ClassFileLoadHook, when no
> java transformer installed.
>
> I would like to pair with a sponsor to contribute this patch.
>
The java.lang.instrument API is maintained by serviceability-dev so that 
would be the best place to bring that specific issue.

-Alan

From adam.farley at uk.ibm.com  Wed Oct 18 11:17:53 2017
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Wed, 18 Oct 2017 12:17:53 +0100
Subject: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be
 exited by java
In-Reply-To: <OFE060B054.F433A001-ON002581B8.004A4A39@LocalDomain>
References: <OFFB8A8A7A.5AE2F216-ON002581B8.003FC147-802581B8.00437393@notes.na.collabserv.com>
 <OFE060B054.F433A001-ON002581B8.004A4A39@LocalDomain>
Message-ID: <OFF7A3AF0A.6966753E-ON002581BB.00565D42-802581BD.003E10E1@notes.na.collabserv.com>

Hi All,

Updated summary, based on the responses:

1) Exit(0) (during VM startup) is a big bug because it imitates successful 
completion of external cpp code accessing JNI methods.
2) One solution for (1) is to specify a new return code for JNI.
3) The supplied code (diff) generates, facilitates, and handles that 
return code for the exit(0) scenario: -agentlib:jdwp=help
4) The exit(0) problem (in general) is worth fixing, however we may choose 
not to support the use of this new code in the jdwp example case.
5) The supplied test confirms that the supplied code works (run via unzip, 
and then bash TestStart.sh <path to jdk home dir that contains bin dir>).
6) To implement this new return code, plus the code that handles it, we 
would need to follow the CSR process to modify the JNI spec.
7) To implement the jdwp scenario fix, if we choose to support it at all, 
we would also need to use the CSR process the JVM TI spec.
8) To address all of the worst instances of exit(0), we would need to 
search for exit(0) and raise a bug for each significant one (or group).
9) To solve (8) in one bug would be a lot of work, arguably too much work 
for a single bug.
10) If the new return code is identified as the appropriate solution to 
this problem, we will need to agree on the right name and return code 
value.

Also, here's a shortlist of the main questions I recall being raised here, 
plus answers people have given.

A) What are the potential solutions for the exit(0) problem?
    i) New JNI Return Code.
    ii) Remove the info-only options, at least via the JNI, and return a 
standard error code if they are used.
    iii) Remove the info-only options, at least via the JNI, and filter 
them out if they are used.
    iv) Retain existing behaviour, and document a need for the user to 
filter out help options before starting the VM via the JNI.

B) What are the criteria for the "Best" solution?
    i) It must prevent "exit(0)" calls.
    ii) It must be proven to work.
    iii) It should require minimal (none, ideally) behaviour change from 
the java.exe user.
    iv) It should allow the external cpp code accessing the JNI to 
complete normally, without being prematurely terminated.

C) Which solutions meet the (B) criteria?
    i) Both the "new return code" and the "remove info-only options" 
solutions meet the (B) criteria.

D) Is it right to have any "Do X and then exit." arguments at all, and (if 
no) what would be the alternatives?
    i) ?

Best Regards

Adam Farley

P.S. As per Alan and David's emails, the exit(#) references have been 
removed entirely, as discussing them alongside the original exit(0) 
problem risks scope creep.

This bug, if raised, should only cover the exit(0) cases. I believe we 
have consensus here.



From:   David Holmes <david.holmes at oracle.com>
To:     Adam Farley8 <adam.farley at uk.ibm.com>, Alan Bateman 
<Alan.Bateman at oracle.com>, core-libs-dev at openjdk.java.net, 
hotspot-runtime-dev at openjdk.java.net, thomas.stuefe at gmail.com
Date:   13/10/2017 14:31
Subject:        Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM 
can be exited by java



Hi Adam,

On 13/10/2017 10:16 PM, Adam Farley8 wrote:
> Hi All,
> 
> Here's a summary of the email below (which is intended, partly, as a 
> summary of the emails before it).
> 
> Let me know if you agree/disagree with any of these points.
> 
> 1) Exit(#) during vm startup is a bug because it should return a code 
> regardless of the state of the VM.

Yes it's a bug but not one that is likely to be addressed in any 
foreseeable timeframe. There are simply too many "exit on error" paths. 
If we were to start using C++ exceptions within the VM that might 
provide a way to quickly get back to the CreateJavaVM routine where we 
could return an error code - but that is itself a major project that has 
barely even been discussed AFAIK. (Compiler folk have talked about it 
because compiler paths are fairly self-contained - though that was 
before Graal and AOT.)

> 2) Exit(0) is an *especially* big bug because it imitates successful 
> completion of external cpp code accessing JNI methods.
> 3) One solution is to specify a new return code for JNI.

A solution for 2) yes.

> 4) The supplied code (diff) generates, facilitates, and handles that 
> return code for the exit(0) scenario: -agentlib:jdwp=help
> 5) The supplied test confirms that the supplied code works (run via 
> unzip, and then bash TestStart.sh <path to jdk home dir that contains 
> bin dir>).
> 6) To implement this new return code, plus the code that handles it, we 
> would need to follow the CSR process.
> 7) To implement the fix for the scenario used as an example of the new 
> return code's use, we would need to modify the JVM TI spec.

Yes you have demonstrated a potential solution for the agent case. The 
question is, is it the right solution? Is it a worthwhile solution? (As 
I've said I'd prefer not to have any "do something then exit" VM 
arguments.) And can we make it fit into the existing specs without 
contorting things too much.

I still think it easier/preferable for whatever loads the VM to filter 
out the VM args that trigger this behaviour. I mean if you pass 
-Xshare:dump you don't have any right to expect a functioning VM after 
JNI_CreateJavaVM returns - at least I don't think so. Just don't do it. 
Yes it is an imperfection in the invocation API, but life isn't perfect.

> 8) To address all of the worst instances of exit(#), we would need to 
> search for exit(#) and raise a bug for each significant one (or group).
> 9) To solve (8) in one bug would be a lot of work, arguably too much 
> work for a single bug.

This is simply impractical. You may be able to pick off a few 
low-hanging cases, but that won't really make any practical difference.

> 10) If the new return code is chosen as the appropriate solution to this 

> problem, we may need to choose a better name for the return code.
> 
> Is this a fair assessment of the current state of the debate?

It's a fair summary of your position and proposal.

Cheers,
David

> I'm on IRC every weekday from 9am-5pm (4pm fridays) BST (GMT+1) if 
> anyone wants to discuss this in real-time on the openjdk channel.
> 
> Best Regards
> 
> Adam Farley
> 
> 
> 
> -- Previous Email --
> 
> Hi David, Alan,
> 
> You are right in that the changes to HotSpot would be nontrivial.
> I see a number of places in (e.g.) arguments.cpp that seem to
> exit in the same manner as Xlog (such as -Xinternalversion).
> 
> I would advise ploughing through the CSR process to alter the
> JNI spec, and simultaneously identify some key paths that can
> be raised as bugs. That way, when people have time to address
> these issues, the mechanism to handle a silent exit is already
> in place.
> 
> The JDWP fix can be raised separately as one of these bugs, if
> it would make things simpler.
> 
> As for the name, JNI_SILENT_EXIT is a placeholder, and can be
> readily changed. Do you have any suggestions?
> 
> Lastly, in an ideal world, the VM initialisation should never exit(#). 
It
> should return a return code that tells the caller something, pass or
> fail, messy or tidy. That way, if someone is using the JNI as part of
> something bigger (like a database or a web server), one of these
> scenarios is just a bug, rather than a world-ender like exit(#).
> 
> And now for the individual messages. :)
> 
> David: Having help data returned by the launcher seems like a
> good way to avoid exit(0) calls, but I'm not sure how we'd prevent
> a JNI-caller using those options. Ultimately, to be sure, we'd have
> to remove the logic for those options, centralise the data to better
> enable launcher access, and add some logic in there so it can find
> any other help data (e.g. from the jdwp agent library). I feel this 
would
> be a bigger task than adding the new return code and changing the
> vm, plus it wouldn't provide for any non-help scenarios where the
> vm wants to shut down without error during initialisation.
> 
> Alan: I should mention that the silent exit solution is already in
> use in the OpenJ9 VM. Not all of the exit paths have been
> resolved, but many have.
> 
> The code is open and can be found here: <
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_openj9&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=c_McLiDSKtlzF_gNlWcAvBTNbDqyGHyW325GY3_3QkU&s=0QVowxRejNRAXI0Vv5whKQFWGTO36XVICmPYCG8EqIU&e=
>
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_openj9&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=c_McLiDSKtlzF_gNlWcAvBTNbDqyGHyW325GY3_3QkU&s=0QVowxRejNRAXI0Vv5whKQFWGTO36XVICmPYCG8EqIU&e=

> 
> And though the silent exit code is disabled for the time being, it
> can be re-enabled by entering this class:
> 
> runtime/vm/jvminit.c
> 
> and altering line 2343 ( ctrl-f for exit(1) if it's not there).
> 
> I won't paste the full code here in case people are concerned
> about contamination, but I would assert that this code (and the
> associated vm files) prove that the concept is possible.
> 
> Note that that code should not be enabled until after we've
> integrated the code that can handle a silent exit.
> 
> Best Regards
> 
> Adam Farley
> 
> P.S. Thank you both for your efforts on this. :)
> 
> 
> 
> From: David Holmes <david.holmes at oracle.com>
> To: Alan Bateman <Alan.Bateman at oracle.com>, Adam Farley8 
> <adam.farley at uk.ibm.com>, core-libs-dev at openjdk.java.net, 
> hotspot-runtime-dev at openjdk.java.net, thomas.stuefe at gmail.com
> Date: 15/09/2017 12:03
> Subject: Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be 

> exited by java
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> On 15/09/2017 8:17 PM, Alan Bateman wrote:
>  > On 15/09/2017 02:47, David Holmes wrote:
>  >> Hi Adam,
>  >>
>  >> I am still very much torn over this one. I think the idea of
>  >> print-and-exit flags for a potentially hosted library like the JVM 
is
>  >> just wrong - we should never have done that, but we did. Fixing that
>  >> by moving the flags to the launcher is far from trivial**. Endorsing
>  >> and encouraging these sorts of flag by adding JNI support seems to 
be
>  >> sending the wrong message.
>  >>
>  >> ** I can envisage a "help xxx" Dcmd that can read back the info from
>  >> the VM. The launcher can send the Dcmd, print the output and exit. 
The
>  >> launcher would not need to know what the xxx values mean, but would
>  >> have to intercept the existing ones.
>  >>
>  >> Another option is just to be aware of these flags (are there more 
than
>  >> jdwp and Xlog?) and deal with them specially in your custom launcher 
-
>  >> either filter them out and ignore them, or else launch the VM in its
>  >> own process to respond to them.
>  >>
>  >> Any changes to the JNI specification need to go through the CSR 
process.
>  > Yes, it would require an update to the JNI spec, also a change to the
>  > JVM TI spec where Agent_OnLoad returning a non-0 value is specified 
to
>  > terminates the VM. The name and value needs discussion too, esp. as 
the
>  > JNI spec uses negative values for failure.
>  >
>  > In any case, I'm also torn over this one as it's a corner case that 
is
>  > only interesting for custom launchers that load agents with options 
that
>  > print usage messages. It wouldn't be hard to have the Agent_OnLoad
>  > specify a printf hook that the agent could use for output although 
there
>  > are complications with agents such as JDWP that also announce their
>  > transport end point. Beyond that there is still the issue of the 
custom
>  > launcher that would need to know to destroy the VM without reporting 
an
>  > error.
>  >
>  > So what happened to the more meaty part to this which is fixing the
>  > various cases in HotSpot that terminate the process during
>  > initialization? I would expect some progress could be made on those
>  > cases while trying to decide whether to rev the JNI and JVM TI specs 
to
>  > cover the help case.
> 
> Trying to eliminate the vm_exit_during_initialization paths in hotspot
> is a huge undertaking IMHO.
> 
> David
> 
>  >
>  > -Alan
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 

> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From ben_walsh at uk.ibm.com  Wed Oct 18 12:46:49 2017
From: ben_walsh at uk.ibm.com (Ben Walsh)
Date: Wed, 18 Oct 2017 13:46:49 +0100
Subject: [PATCH] Unnecessary Amount Of Internal Class Conversion
In-Reply-To: <OF8D9C8FCE.3209B573-ON002581BD.003C718D@LocalDomain>
References: <OF4944AD2F.D1994796-ON802581BD.0038567D-802581BD.003A31F9@notes.na.collabserv.com>
 <OF8D9C8FCE.3209B573-ON002581BD.003C718D@LocalDomain>
Message-ID: <OF0BFE9173.B8581843-ON802581BD.00452144-802581BD.00463463@notes.na.collabserv.com>

Thank you for the suggestion Alan. I'll continue further discussion on 
that mailing list.

Regards,
Ben


Ben Walsh




From:   Alan Bateman <Alan.Bateman at oracle.com>
To:     Ben Walsh <ben_walsh at uk.ibm.com>, core-libs-dev at openjdk.java.net
Date:   18/10/2017 12:00
Subject:        Re: [PATCH] Unnecessary Amount Of Internal Class 
Conversion



On 18/10/2017 11:35, Ben Walsh wrote:
> I have observed a problem where an unnecessary amount of internal class
> conversion is occurring.
>
> I have a patch which I would like to contribute which represents a
> performance optimisation for this problem in the java.instrument module
> implementation.
>
> It avoids having to convert all classes from a JVM's internal class 
format
> to the .class file format, in order to call the ClassFileLoadHook, when 
no
> java transformer installed.
>
> I would like to pair with a sponsor to contribute this patch.
>
The java.lang.instrument API is maintained by serviceability-dev so that 
would be the best place to bring that specific issue.

-Alan



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


From roger.riggs at oracle.com  Wed Oct 18 17:57:24 2017
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 18 Oct 2017 10:57:24 -0700
Subject: RFR (JDK10/JAXP) 8181150: Fix lint warnings in JAXP repo:
 rawtypes and unchecked
In-Reply-To: <59DFB343.5080602@oracle.com>
References: <59DFB343.5080602@oracle.com>
Message-ID: <24b463cb-8956-765d-d5b2-4f0a6edb1174@oracle.com>

Hi Joe,

The changes look fine.

Maybe do them in smaller batches next time with a consistent kind of 
change. Just thought.

Thanks, Roger


On 10/12/17 11:24 AM, Joe Wang wrote:
> Hi,
>
> Please review a cleanup of rawtypes and unchecked warnings from JAXP 
> sources.
>
> The patch involved a good number of classes (278). However, the 
> majority of the changes are straight-forward replacement, e.g. 
> s/Vector/List[ArrayList] and their relevant methods e.g. 
> s/elementAt/get and etc. In a few cases, 
> ArrayIndexOutOfBoundsException was substituted with 
> IndexOutOfBoundsException as they were caught.
>
> A few cleanups unrelated to rawtypes and unchecked were made before 
> Roger's suggestion to stay within the scope of the request, that is, a 
> couple of StringBuffer substitution, other than that this changeset is 
> almost rawtypes and unchecked cleanup only.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8181150
> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181150/webrev/
>
> Thanks,
> Joe
>


From lance.andersen at oracle.com  Wed Oct 18 19:18:58 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 18 Oct 2017 15:18:58 -0400
Subject: RFR (JDK10/JAXP) 8181150: Fix lint warnings in JAXP repo:
 rawtypes and unchecked
In-Reply-To: <59DFB343.5080602@oracle.com>
References: <59DFB343.5080602@oracle.com>
Message-ID: <E08A5461-4934-4829-B090-25E81EEB6E66@oracle.com>

Hi Joe,

Overall looks good.

As we discussed, I would add a comment to NameNodeMapImpl.java read/writeObject describing the use of Vector for backward compatibility.  No need for another webrev :-)

Best
Lance
> On Oct 12, 2017, at 2:24 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Hi,
> 
> Please review a cleanup of rawtypes and unchecked warnings from JAXP sources.
> 
> The patch involved a good number of classes (278). However, the majority of the changes are straight-forward replacement, e.g. s/Vector/List[ArrayList] and their relevant methods e.g. s/elementAt/get and etc. In a few cases, ArrayIndexOutOfBoundsException was substituted with IndexOutOfBoundsException as they were caught.
> 
> A few cleanups unrelated to rawtypes and unchecked were made before Roger's suggestion to stay within the scope of the request, that is, a couple of StringBuffer substitution, other than that this changeset is almost rawtypes and unchecked cleanup only.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8181150
> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181150/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 huizhe.wang at oracle.com  Wed Oct 18 20:15:41 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 18 Oct 2017 13:15:41 -0700
Subject: RFR (JDK10/JAXP) 8181150: Fix lint warnings in JAXP repo: rawtypes
 and unchecked
In-Reply-To: <24b463cb-8956-765d-d5b2-4f0a6edb1174@oracle.com>
References: <59DFB343.5080602@oracle.com>
 <24b463cb-8956-765d-d5b2-4f0a6edb1174@oracle.com>
Message-ID: <59E7B66D.9030101@oracle.com>

Thanks Roger!

We'll go through a bunch of much smaller patches once this one is out of 
the way. After BCEL update and this, we'll go from over 5000 warnings 
down to 365 that will be fixed in three separate categories.

-Joe

On 10/18/17, 10:57 AM, Roger Riggs wrote:
> Hi Joe,
>
> The changes look fine.
>
> Maybe do them in smaller batches next time with a consistent kind of 
> change. Just thought.
>
> Thanks, Roger
>
>
> On 10/12/17 11:24 AM, Joe Wang wrote:
>> Hi,
>>
>> Please review a cleanup of rawtypes and unchecked warnings from JAXP 
>> sources.
>>
>> The patch involved a good number of classes (278). However, the 
>> majority of the changes are straight-forward replacement, e.g. 
>> s/Vector/List[ArrayList] and their relevant methods e.g. 
>> s/elementAt/get and etc. In a few cases, 
>> ArrayIndexOutOfBoundsException was substituted with 
>> IndexOutOfBoundsException as they were caught.
>>
>> A few cleanups unrelated to rawtypes and unchecked were made before 
>> Roger's suggestion to stay within the scope of the request, that is, 
>> a couple of StringBuffer substitution, other than that this changeset 
>> is almost rawtypes and unchecked cleanup only.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181150
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181150/webrev/
>>
>> Thanks,
>> Joe
>>
>

From huizhe.wang at oracle.com  Wed Oct 18 20:21:39 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 18 Oct 2017 13:21:39 -0700
Subject: RFR (JDK10/JAXP) 8181150: Fix lint warnings in JAXP repo: rawtypes
 and unchecked
In-Reply-To: <E08A5461-4934-4829-B090-25E81EEB6E66@oracle.com>
References: <59DFB343.5080602@oracle.com>
 <E08A5461-4934-4829-B090-25E81EEB6E66@oracle.com>
Message-ID: <59E7B7D3.4040709@oracle.com>

Thanks Lance!

Yes, comments are added to NameNodeMapImpl. Those are among a few cases 
where Vector is still used for compatibility.

By the way, Sean also okay-ed the change to FuncHere.java in the 
java.xml.crypto module.

Best,
Joe

On 10/18/17, 12:18 PM, Lance Andersen wrote:
> Hi Joe,
>
> Overall looks good.
>
> As we discussed, I would add a comment to NameNodeMapImpl.java 
> read/writeObject describing the use of Vector for backward 
> compatibility.  No need for another webrev :-)
>
> Best
> Lance
>> On Oct 12, 2017, at 2:24 PM, Joe Wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please review a cleanup of rawtypes and unchecked warnings from JAXP 
>> sources.
>>
>> The patch involved a good number of classes (278). However, the 
>> majority of the changes are straight-forward replacement, e.g. 
>> s/Vector/List[ArrayList] and their relevant methods e.g. 
>> s/elementAt/get and etc. In a few cases, 
>> ArrayIndexOutOfBoundsException was substituted with 
>> IndexOutOfBoundsException as they were caught.
>>
>> A few cleanups unrelated to rawtypes and unchecked were made before 
>> Roger's suggestion to stay within the scope of the request, that is, 
>> a couple of StringBuffer substitution, other than that this changeset 
>> is almost rawtypes and unchecked cleanup only.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181150
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181150/webrev/ 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk10/8181150/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 stevenschlansker at gmail.com  Wed Oct 18 21:54:12 2017
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Wed, 18 Oct 2017 14:54:12 -0700
Subject: Random.nextLong(long bound)?
Message-ID: <457D1030-57E4-4597-826E-8F940B9E1075@gmail.com>

My coworker is implementing an algorithm for which he needs a bounded random long.
He needs to be in full control of the seed and not share the instance (i.e. not use ThreadLocalRandom).

Random helpfully provides a nextInt(int bound) but nextLong has no such overload.

The code to do so is not super involved, but you only have to briefly peruse
the wasteland of StackOverflow answers to see what happens when you get developers
to solve this problem themselves:

https://stackoverflow.com/questions/2546078/java-random-long-number-in-0-x-n-range

Seems like a nextLong(bound) would be a trivial addition with outsize benefits.
Any reason not to add it?

PS --
nextLong says
"Returns the next pseudorandom, uniformly distributed {@code long} value from this random number generator's sequence."
and
"Because class {@code Random} uses a seed with only 48 bits, this algorithm will not return all possible {@code long} values."

How can this be true?  Given a long L1 which can be generated and L2 which cannot, it seems trivial that P(L1) != P(L2)
and therefore it is not a uniformly distributed long value.  Am I misunderstanding this concept?

Thanks!
Steven


From vitalyd at gmail.com  Wed Oct 18 22:11:03 2017
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Wed, 18 Oct 2017 22:11:03 +0000
Subject: Random.nextLong(long bound)?
In-Reply-To: <457D1030-57E4-4597-826E-8F940B9E1075@gmail.com>
References: <457D1030-57E4-4597-826E-8F940B9E1075@gmail.com>
Message-ID: <CAHjP37HLgWLTQ4KRe-y_OiQ=z7mBenD29A5v-rCPUt2vc0MoNg@mail.gmail.com>

On Wed, Oct 18, 2017 at 5:54 PM Steven Schlansker <
stevenschlansker at gmail.com> wrote:

> My coworker is implementing an algorithm for which he needs a bounded
> random long.
> He needs to be in full control of the seed and not share the instance
> (i.e. not use ThreadLocalRandom).
>
> Random helpfully provides a nextInt(int bound) but nextLong has no such
> overload.
>
> The code to do so is not super involved, but you only have to briefly
> peruse
> the wasteland of StackOverflow answers to see what happens when you get
> developers
> to solve this problem themselves:
>
>
> https://stackoverflow.com/questions/2546078/java-random-long-number-in-0-x-n-range
>
> Seems like a nextLong(bound) would be a trivial addition with outsize
> benefits.
> Any reason not to add it?
>
> PS --
> nextLong says
> "Returns the next pseudorandom, uniformly distributed {@code long} value
> from this random number generator's sequence."
> and
> "Because class {@code Random} uses a seed with only 48 bits, this
> algorithm will not return all possible {@code long} values."
>
> How can this be true?  Given a long L1 which can be generated and L2 which
> cannot, it seems trivial that P(L1) != P(L2)
> and therefore it is not a uniformly distributed long value.  Am I
> misunderstanding this concept?

It?s uniformly distributed over the *sequence* that the PRNG produces -
it?s just that the sequence doesn?t produce all long values.

>
>
> Thanks!
> Steven
>
> --
Sent from my phone

From martinrb at google.com  Wed Oct 18 22:15:43 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 18 Oct 2017 15:15:43 -0700
Subject: Random.nextLong(long bound)?
In-Reply-To: <457D1030-57E4-4597-826E-8F940B9E1075@gmail.com>
References: <457D1030-57E4-4597-826E-8F940B9E1075@gmail.com>
Message-ID: <CA+kOe08R1z3aSb3-8-GzgXzcvys1Bom5HDfYsx0Op8a44-+u0w@mail.gmail.com>

Why not SplittableRandom?
https://docs.oracle.com/javase/9/docs/api/java/util/SplittableRandom.html#nextLong-long-

On Wed, Oct 18, 2017 at 2:54 PM, Steven Schlansker <
stevenschlansker at gmail.com> wrote:

> My coworker is implementing an algorithm for which he needs a bounded
> random long.
> He needs to be in full control of the seed and not share the instance
> (i.e. not use ThreadLocalRandom).
>

From stevenschlansker at gmail.com  Wed Oct 18 22:25:54 2017
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Wed, 18 Oct 2017 15:25:54 -0700
Subject: Random.nextLong(long bound)?
In-Reply-To: <CA+kOe08R1z3aSb3-8-GzgXzcvys1Bom5HDfYsx0Op8a44-+u0w@mail.gmail.com>
References: <457D1030-57E4-4597-826E-8F940B9E1075@gmail.com>
 <CA+kOe08R1z3aSb3-8-GzgXzcvys1Bom5HDfYsx0Op8a44-+u0w@mail.gmail.com>
Message-ID: <F5B47E1D-91D4-4276-9EE4-582376B581FE@gmail.com>


> On Oct 18, 2017, at 3:15 PM, Martin Buchholz <martinrb at google.com> wrote:
> 
> Why not SplittableRandom?
> https://docs.oracle.com/javase/9/docs/api/java/util/SplittableRandom.html#nextLong-long-

In this particular case, an algorithm written by a library vendor takes a parameter of type Random.
SplittableRandom is not a Random.  I'm guessing this is because it is not thread-safe like the Random
contract promises.

We were hoping to have a single sequence shared between the library that takes Random and our
own code that hopes to generate bounded longs.  We want such tight control because we are writing
a repeatable tester and want to use the seed to be able to replay sequences that cause our
system to fail.

We are looking into somehow retrofitting our code to use SplittableRandom but it's likely less
complex for us to just implement the na?ve re-roll algorithm [ while(sample >= bound) sample = nextLong(); ]

I don't think this will turn into a total blocker for us, you're correct -- we'll find a path forward.
But I do think it highlights missing functionality, and the SO post highlights that this is a problem 'in the wild'.
It feels like an obvious omission!


From dmcmanam at gmail.com  Wed Oct 18 22:35:07 2017
From: dmcmanam at gmail.com (David McManamon)
Date: Wed, 18 Oct 2017 18:35:07 -0400
Subject: AVL tree implemented in the style of TreeMap for better performance
Message-ID: <CAN-rbk0M0Y=c_qm_2f-ffbjaKrr80G85E5-HPn0V9T-oxkVp7g@mail.gmail.com>

If the BBST performance numbers from Ben Pfaff's c language research in 2004
https://benpfaff.org/papers/libavl.pdf
are correct then it seems the red-black tree implementations that are so
popular in the JDK might be worth another look.  However, when I surveyed
the AVL implementations in the Java world I didn't find the variety I was
looking for - specifically an implementation similar to that of the
red-black TreeMap (parent pointers, no recursion), so I wrote insert &
delete in TreeMapAVL here:

https://github.com/dmcmanam/bbst-showdown

Although an old topic, it may be worth another look in Java since AVL trees
do much better in some circumstances.

Next week I'll write a WAVL implementation and expand the performance
testing comparison which so far looks like this:

Results for inserting 262143 random integers (height 18 for a complete BST)
-

  Mean insertion time: 171ms and 169ms, runs to converge:2. AVL tree of
size: 262126, height: 21, rotations 183194

  Mean insertion time: 165ms and 169ms, runs to converge:2. Red-black tree
of size: 262126, height: 22, rotations 152622

  Mean insertion time: 170ms and 167ms, runs to converge:1. BST          of
size: 262126, height: 46, rotations 0

  Time to copy a red-black tree (sorted insertion via recursion): 44ms.
Red-black tree of size: 262126, height: 18, rotations 0

Results for inserting integer clusters in sequences of 12 and total size:
262143 -

  Mean insertion time: 63ms and 62ms, runs to converge:3. AVL tree of size:
262125, height: 21, rotations 325176

  Mean insertion time: 70ms and 72ms, runs to converge:2. Red-black tree of
size: 262125, height: 24, rotations 320990

--David

From mandy.chung at oracle.com  Wed Oct 18 23:32:15 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 18 Oct 2017 16:32:15 -0700
Subject: Review Request JDK-8187089: StringConcatFactory.makeConcat &
 makeConcatWithConstants should throw StringConcatException if parameter slot
 count is over 200
Message-ID: <1f2107e3-e639-b575-4f2c-731cd39984c8@oracle.com>

StringConcatFactory::makeConcat and makeConcatWithConstants APIs are
specified to accept concatType to have a maximum of 200 parameter slots.
If violated, it should throw StringConcatException.? The implementation
mistakenly checks the parameter count.? The javadoc of these methods
states "parameter count" rather than "parameter slots" whereas
@apiNote in the class spec correctly says "parameter slots".

Webrev:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8187089/webrev.00/

CSR:
 ?? https://bugs.openjdk.java.net/browse/JDK-8189634

Thanks
Mandy

From roger.riggs at oracle.com  Thu Oct 19 00:18:22 2017
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 18 Oct 2017 17:18:22 -0700
Subject: Review Request JDK-8187089: StringConcatFactory.makeConcat &
 makeConcatWithConstants should throw StringConcatException if parameter slot
 count is over 200
In-Reply-To: <1f2107e3-e639-b575-4f2c-731cd39984c8@oracle.com>
References: <1f2107e3-e639-b575-4f2c-731cd39984c8@oracle.com>
Message-ID: <85c4d35e-4c5d-566f-71a7-5e8d6d98f865@oracle.com>

Hi Mandy,

typo in BasicTest: line 50: "200 the parameter" - "200 parameter"

I think I would have had the tests exactly fit the slots of 200 and 201.
The test exceeds the limit by 2 possibly hiding an off by 1 error.

Arrays.fill(types, 100, 102, int.class);


Roger


On 10/18/17 4:32 PM, mandy chung wrote:
> StringConcatFactory::makeConcat and makeConcatWithConstants APIs are
> specified to accept concatType to have a maximum of 200 parameter slots.
> If violated, it should throw StringConcatException.? The implementation
> mistakenly checks the parameter count.? The javadoc of these methods
> states "parameter count" rather than "parameter slots" whereas
> @apiNote in the class spec correctly says "parameter slots".
>
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8187089/webrev.00/
>
> CSR:
> ?? https://bugs.openjdk.java.net/browse/JDK-8189634
>
> Thanks
> Mandy


From mandy.chung at oracle.com  Thu Oct 19 01:11:19 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Wed, 18 Oct 2017 18:11:19 -0700
Subject: Review Request JDK-8187089: StringConcatFactory.makeConcat &
 makeConcatWithConstants should throw StringConcatException if parameter slot
 count is over 200
In-Reply-To: <85c4d35e-4c5d-566f-71a7-5e8d6d98f865@oracle.com>
References: <1f2107e3-e639-b575-4f2c-731cd39984c8@oracle.com>
 <85c4d35e-4c5d-566f-71a7-5e8d6d98f865@oracle.com>
Message-ID: <f1cde7bd-4cb3-7a6c-f629-ee6b0c13ba31@oracle.com>



On 10/18/17 5:18 PM, Roger Riggs wrote:
> Hi Mandy,
>
> typo in BasicTest: line 50: "200 the parameter" - "200 parameter"
>

Fixed.

> I think I would have had the tests exactly fit the slots of 200 and 201.
> The test exceeds the limit by 2 possibly hiding an off by 1 error.
> Arrays.fill(types, 100, 102, int.class);
>

Thanks.? I caught that later myself.

Updated:
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8187089/webrev.01/

Mandy

>
> Roger
>
>
> On 10/18/17 4:32 PM, mandy chung wrote:
>> StringConcatFactory::makeConcat and makeConcatWithConstants APIs are
>> specified to accept concatType to have a maximum of 200 parameter slots.
>> If violated, it should throw StringConcatException.? The implementation
>> mistakenly checks the parameter count.? The javadoc of these methods
>> states "parameter count" rather than "parameter slots" whereas
>> @apiNote in the class spec correctly says "parameter slots".
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8187089/webrev.00/
>>
>> CSR:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8189634
>>
>> Thanks
>> Mandy
>


From roger.riggs at oracle.com  Thu Oct 19 01:28:28 2017
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 18 Oct 2017 18:28:28 -0700
Subject: Review Request JDK-8187089: StringConcatFactory.makeConcat &
 makeConcatWithConstants should throw StringConcatException if parameter slot
 count is over 200
In-Reply-To: <f1cde7bd-4cb3-7a6c-f629-ee6b0c13ba31@oracle.com>
References: <1f2107e3-e639-b575-4f2c-731cd39984c8@oracle.com>
 <85c4d35e-4c5d-566f-71a7-5e8d6d98f865@oracle.com>
 <f1cde7bd-4cb3-7a6c-f629-ee6b0c13ba31@oracle.com>
Message-ID: <9239bd29-c4c4-27eb-3bf3-443623e1f526@oracle.com>

Looks good.

Thanks, Roger

On 10/18/17 6:11 PM, mandy chung wrote:
>
>
> On 10/18/17 5:18 PM, Roger Riggs wrote:
>> Hi Mandy,
>>
>> typo in BasicTest: line 50: "200 the parameter" - "200 parameter"
>>
>
> Fixed.
>
>> I think I would have had the tests exactly fit the slots of 200 and 201.
>> The test exceeds the limit by 2 possibly hiding an off by 1 error.
>> Arrays.fill(types, 100, 102, int.class);
>>
>
> Thanks.? I caught that later myself.
>
> Updated:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8187089/webrev.01/
>
> Mandy
>
>>
>> Roger
>>
>>
>> On 10/18/17 4:32 PM, mandy chung wrote:
>>> StringConcatFactory::makeConcat and makeConcatWithConstants APIs are
>>> specified to accept concatType to have a maximum of 200 parameter 
>>> slots.
>>> If violated, it should throw StringConcatException.? The implementation
>>> mistakenly checks the parameter count.? The javadoc of these methods
>>> states "parameter count" rather than "parameter slots" whereas
>>> @apiNote in the class spec correctly says "parameter slots".
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8187089/webrev.00/
>>>
>>> CSR:
>>> ?? https://bugs.openjdk.java.net/browse/JDK-8189634
>>>
>>> Thanks
>>> Mandy
>>
>


From dawid.weiss at gmail.com  Thu Oct 19 06:44:38 2017
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Thu, 19 Oct 2017 08:44:38 +0200
Subject: Random.nextLong(long bound)?
In-Reply-To: <F5B47E1D-91D4-4276-9EE4-582376B581FE@gmail.com>
References: <457D1030-57E4-4597-826E-8F940B9E1075@gmail.com>
 <CA+kOe08R1z3aSb3-8-GzgXzcvys1Bom5HDfYsx0Op8a44-+u0w@mail.gmail.com>
 <F5B47E1D-91D4-4276-9EE4-582376B581FE@gmail.com>
Message-ID: <CAM21Rt_+d_i8gd3Abd_atVn8mX5pjbQ2+MYtRxfAJNMOj1iqEg@mail.gmail.com>

Hi Steven,

> We were hoping to have a single sequence shared between the library that takes Random and our
> own code that hopes to generate bounded longs.  We want such tight control because we are writing
> a repeatable tester and want to use the seed to be able to replay sequences that cause our
> system to fail.

A repeatable randomized tester is a noble idea; have you perhaps tried
the randomized
testing package (full disclosure -- I'm the author) [1]?

This is used in Solr/Lucene and other projects for running JUnit tests
with predictable
randomness (where it's possible to assert it, of course [4]). The
Random instance you get from the test's context should be
predictable and has an implementation of nextLong() with a long cycle
(as pointed out, it's not the long range,
it's the rnd generator's cycle that is a problem here).

> complex for us to just implement the na?ve re-roll algorithm [ while(sample >= bound) sample = nextLong(); ]

There are some utilities that should be helpful here [2], but
Sebastiano Vigna (dsiutil package [3]) has Random
implementations with very long cycles too.

Dawid

[1] https://github.com/randomizedtesting/randomizedtesting

[2] https://github.com/randomizedtesting/randomizedtesting/blob/aeebebef5e8961205c60c2f4d5f4bf82b68cf0a8/randomized-runner/src/main/java/com/carrotsearch/randomizedtesting/generators/RandomNumbers.java

[3] http://dsiutils.di.unimi.it/

[4] https://berlinbuzzwords.de/sites/berlinbuzzwords.de/files/media/documents/dawidweiss-randomizedtesting-pub.pdf

From dawid.weiss at gmail.com  Thu Oct 19 07:20:26 2017
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Thu, 19 Oct 2017 09:20:26 +0200
Subject: AssertionError in WildcardTypeImpl.getUpperBoundASTs
In-Reply-To: <1fee1e49-12b5-c8b1-60cb-e9fdc921b688@gmail.com>
References: <CAM21Rt8uPUk5NE6RSP6Gej9uejsmAz8HNLj3nXon0sK1K0=sUg@mail.gmail.com>
 <c011bed4-e776-0ae0-f556-973896841980@gmail.com>
 <CAM21Rt8X7uTOEzSJJKWyyPK+d+DhLXf3RzN=B+w=6FGFjROCxw@mail.gmail.com>
 <1fee1e49-12b5-c8b1-60cb-e9fdc921b688@gmail.com>
Message-ID: <CAM21Rt8CMGKiAYYJDQGqqwGR9OJ_KRMNkBoVchr_p+vixFWwjA@mail.gmail.com>

Hi Peter,

> Will you be willing to prepare it or do you need some help?

I was afraid you'd say that... ;) I'm vaguely familiar with the
process, so I could try to provide a patch, but end of October seems
very tight given my current schedule. I'll see what I can do though.

Also, I did grep the build logs that I have available and I can
confirm the problem to occur on Java 1.8 (various minors) and on IBM's
Java 1.8, regardless of the target platform (Windows, Linux).

./L4G-SOFTWARE1-JDK18LINUX/download-data/build_logs/L4G-SOFTWARE1-JDK18LINUX-1052.log
./L4G-JDKS-J1IW/download-data/build_logs/L4G-JDKS-J1IW-167.log
./L4G-JDKS-J1IW/download-data/build_logs/L4G-JDKS-J1IW-174.log
./L4G-JDKS-J1IW/download-data/build_logs/L4G-JDKS-J1IW-172.log
./L4G-JDKS-J1IW/download-data/build_logs/L4G-JDKS-J1IW-155.log
./L4G-SOFTWARE-JDK18LINUX/download-data/build_logs/L4G-SOFTWARE-JDK18LINUX-1219.log
./L4G-SOFTWARE1-JDK18WINDOWS/download-data/build_logs/L4G-SOFTWARE1-JDK18WINDOWS-1088.log

Dawid

On Wed, Oct 18, 2017 at 8:55 AM, Peter Levart <peter.levart at gmail.com> wrote:
> Hi Dawid,
>
> So if we want this to be included in 8u162 [1] (to be released on January
> 2018), we better hurry up and submit a backported patch before end of
> October...
>
> I can sponsor the patch. Will you be willing to prepare it or do you need
> some help?
>
> I think it should be a straightforward backport of JDK-8065172 [2].
>
> Regards, Peter
>
> [1] http://openjdk.java.net/projects/jdk8u/releases/8u162.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8065172
>
>
> On 10/17/17 12:41, Dawid Weiss wrote:
>
> Hi Peter,
>
> Thanks for the pointer. Whether or not this fix should be backported
> to 8u is probably not for me to decide... but if I can provide some
> rationale then I think it'd be better to backport for the following
> reasons:
>
> - This assertion isn't frequent, but it does happen from time to time.
> Robert Muir also let me know in a private conversation that the
> assertion was triggered from time to time in Lucene tests; the test
> that mostly caused it to happen has been since disabled (for unrelated
> reasons).
>
> - I quickly grepped the most recent Solr/Lucene logs and I see that
> the assertion can be buried deep (in the suppressed exceptions chain),
> which may be easily overlooked or raise false other concerns. Look at
> the stack trace [1] below, for example.
>
> - We run tests on multiple different JVMs/ systems and I'm 99%
> confident I've seen errors with this assertion on IBM's J9 too, so it
> affects the whole Java ecosystem, not just OpenJDK?
>
> Dawid
>
> [1] Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20468/
>
> 5 tests failed.
> FAILED:
> junit.framework.TestSuite.org.apache.solr.analytics.facet.QueryFacetCloudTest
>
> Error Message:
> Error starting up MiniSolrCloudCluster
>
> java.lang.Exception: Error starting up MiniSolrCloudCluster
>         at __randomizedtesting.SeedInfo.seed([954FE60C5C176808]:0)
>         at
> org.apache.solr.cloud.MiniSolrCloudCluster.checkForExceptions(MiniSolrCloudCluster.java:507)
>         at
> org.apache.solr.cloud.MiniSolrCloudCluster.<init>(MiniSolrCloudCluster.java:251)
>         at
> org.apache.solr.cloud.SolrCloudTestCase$Builder.configure(SolrCloudTestCase.java:190)
>         at
> org.apache.solr.analytics.facet.AbstractAnalyticsFacetCloudTest.setupCluster(AbstractAnalyticsFacetCloudTest.java:56)
>         at
> org.apache.solr.analytics.facet.QueryFacetCloudTest.beforeClass(QueryFacetCloudTest.java:44)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:498)
>         at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
>         at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:874)
>         at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
>         at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>         at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>         at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
>         at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>         at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
>         at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>         at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
>         at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>         at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>         at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>         at
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
>         at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
>         at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
>         at
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
>         at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>         at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
>         at java.lang.Thread.run(Thread.java:748)
>         Suppressed: java.lang.AssertionError
>                 at
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBoundASTs(WildcardTypeImpl.java:86)
>                 at
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBounds(WildcardTypeImpl.java:122)
>                 at
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.toString(WildcardTypeImpl.java:190)
>                 at java.lang.reflect.Type.getTypeName(Type.java:46)
>                 at
> sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.toString(ParameterizedTypeImpl.java:234)
>                 at java.lang.reflect.Type.getTypeName(Type.java:46)
>                 at
> java.lang.reflect.Method.specificToGenericStringHeader(Method.java:421)
>                 at
> java.lang.reflect.Executable.sharedToGenericString(Executable.java:163)
>                 at java.lang.reflect.Method.toGenericString(Method.java:415)
>                 at java.beans.MethodRef.set(MethodRef.java:46)
>                 at
> java.beans.MethodDescriptor.setMethod(MethodDescriptor.java:117)
>                 at
> java.beans.MethodDescriptor.<init>(MethodDescriptor.java:72)
>                 at
> java.beans.MethodDescriptor.<init>(MethodDescriptor.java:56)
>                 at
> java.beans.Introspector.getTargetMethodInfo(Introspector.java:1205)
>                 at
> java.beans.Introspector.getBeanInfo(Introspector.java:426)
>                 at
> java.beans.Introspector.getBeanInfo(Introspector.java:173)
>                 at
> java.beans.Introspector.getBeanInfo(Introspector.java:260)
>                 at java.beans.Introspector.<init>(Introspector.java:407)
>                 at
> java.beans.Introspector.getBeanInfo(Introspector.java:173)
>                 at
> java.beans.Introspector.getBeanInfo(Introspector.java:260)
>                 at java.beans.Introspector.<init>(Introspector.java:407)
>                 at
> java.beans.Introspector.getBeanInfo(Introspector.java:173)
>                 at
> java.beans.Introspector.getBeanInfo(Introspector.java:260)
>                 at java.beans.Introspector.<init>(Introspector.java:407)
>                 at
> java.beans.Introspector.getBeanInfo(Introspector.java:173)
>                 at
> org.apache.solr.util.SolrPluginUtils.findSetter(SolrPluginUtils.java:1027)
>                 at
> org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1011)
>                 at
> org.apache.solr.util.SolrPluginUtils.invokeSetters(SolrPluginUtils.java:1000)
>
> On Tue, Oct 17, 2017 at 12:13 PM, Peter Levart <peter.levart at gmail.com>
> wrote:
>
> Hi Dawid,
>
> The [2] mentions a thread which resulted in a patch by Martin Bucholtz for
> JDK 9:
>
> https://bugs.openjdk.java.net/browse/JDK-8065172
>
> ...but it seems this has not been backported to 8u (yet). The question is,
> will there be any more 8u releases? Would you like this to be backported to
> 8u?
>
> Regards, Peter
>
>
> On 10/13/2017 09:53 AM, Dawid Weiss wrote:
>
> Hi all,
>
> We are observing very infrequent assertion errors originating in
> getUpperBoundASTs, mostly during concurrent builds on our build
> machine, when it's under a heavy load. This has been happening from
> time to time with various Java versions; most recently with 1.8.0_131.
>
> I don't see anything in Jira about it, but even a quick Google search
> yields some hits [1].
>
> The stack trace starts with (I include the jackson stack frame which calls
> it):
>
> java.lang.AssertionError: null
> at
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBoundASTs(WildcardTypeImpl.java:86)
> ~[?:1.8.0_131]
> at
> sun.reflect.generics.reflectiveObjects.WildcardTypeImpl.getUpperBounds(WildcardTypeImpl.java:122)
> ~[?:1.8.0_131]
> at
> com.fasterxml.jackson.databind.type.TypeFactory._fromWildcard(TypeFactory.java:1424)
> ~[jackson-databind-2.8.2.jar:2.8.2]
>
> The problem cannot be easily reproduced, but I see a comment mentioned
> on the core-libs-dev a while ago [2] by Joel Borggr?n-Franck, so
> perhaps his question is a valid one and worth investigating:
>
> Btw, has anyone seen the assert for upper/lower bounds == null fail in
> the wild?
>
> Dawid
>
> [1]
> https://www.google.com/search?q=getUpperBoundASTs+AssertionError&filter=0&biw=1279&bih=863
> (note the "[JENKINS] Lucene-olr-master-Linux" hit).
>
> [2] http://markmail.org/message/4phfnh7dj3qdlo6b
>
>

From shade at redhat.com  Thu Oct 19 08:55:56 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 19 Oct 2017 10:55:56 +0200
Subject: Review Request JDK-8187089: StringConcatFactory.makeConcat &
 makeConcatWithConstants should throw StringConcatException if parameter slot
 count is over 200
In-Reply-To: <1f2107e3-e639-b575-4f2c-731cd39984c8@oracle.com>
References: <1f2107e3-e639-b575-4f2c-731cd39984c8@oracle.com>
Message-ID: <1c0f7713-a995-d194-20eb-f1e3ddaa9f92@redhat.com>

On 10/19/2017 01:32 AM, mandy chung wrote:
> StringConcatFactory::makeConcat and makeConcatWithConstants APIs are
> specified to accept concatType to have a maximum of 200 parameter slots.
> If violated, it should throw StringConcatException.? The implementation
> mistakenly checks the parameter count.? The javadoc of these methods
> states "parameter count" rather than "parameter slots" whereas
> @apiNote in the class spec correctly says "parameter slots".
> 
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8187089/webrev.00/

Looks good, thanks for taking care of this!

-Aleksey


From aph at redhat.com  Thu Oct 19 12:01:02 2017
From: aph at redhat.com (Andrew Haley)
Date: Thu, 19 Oct 2017 13:01:02 +0100
Subject: Random.nextLong(long bound)?
In-Reply-To: <457D1030-57E4-4597-826E-8F940B9E1075@gmail.com>
References: <457D1030-57E4-4597-826E-8F940B9E1075@gmail.com>
Message-ID: <de211b9e-77e0-3b88-4529-6efb649073e7@redhat.com>

On 18/10/17 22:54, Steven Schlansker wrote:

> Given a long L1 which can be generated and L2 which cannot, it seems
> trivial that P(L1) != P(L2) and therefore it is not a uniformly
> distributed long value.  Am I misunderstanding this concept?

I think it's OK.

The result of nextLong() is uniformly distributed over all 64 bits of
a long because nextLong() returns:

    ((long)(next(32)) << 32) + next(32)

To get your bounded long, you can use

    Math.multiplyHigh(r.nextLong(), bound)

Bear in mind that if you want a result bounded below at zero you'll
have to correct the sign.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From thomas.stuefe at gmail.com  Thu Oct 19 13:21:58 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 19 Oct 2017 15:21:58 +0200
Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer
 overflow in Java_java_nio_MappedByteBuffer_isLoaded0
In-Reply-To: <CAA-vtUzG1kvdG+S2JfBSW_JkYvSSOBkFArbgu4HQ0hgG9jFCKg@mail.gmail.com>
References: <CAA-vtUzU5zvZLuUe6kHOfTkijLk7ydrr3C4wsSoaQRhCYdV51g@mail.gmail.com>
 <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com>
 <CAA-vtUztOsSQoYuTmexqDTdhY=bGiYqdqMYdNh=MpmmQ7CveTg@mail.gmail.com>
 <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com>
 <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>
 <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com>
 <CAA-vtUzG1kvdG+S2JfBSW_JkYvSSOBkFArbgu4HQ0hgG9jFCKg@mail.gmail.com>
Message-ID: <CAA-vtUxMy8Lvmtf4ZhuU9-7km9MXmC4BmhuoiQ8XSwmpKR6f4g@mail.gmail.com>

Hi Peter, Christoph,

if you have no objections, I'd like to push this change. As I explained in
my earlier mail, I'd prefer not to change MappedByteBuffer::load(), and if
you are fine with the change in its current form (http://cr.openjdk.
java.net/~stuefe/webrevs/8186665-buffer-overflow-in-
mincore/webrev.02/webrev/), I'd like to push it.

Thanks, Thomas


On Wed, Oct 18, 2017 at 12:24 PM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi Peter, Christoph,
>
> Thank you both for reviewing.
>
> New webrev: http://cr.openjdk.java.net/~stuefe/webrevs/
> 8186665-buffer-overflow-in-mincore/webrev.02/webrev/
>
> @Peter:
>
> >Shouldn't the following line:
> >
> >  47     return len2 + pagesize - 1 / pagesize;
> >
> >..be written as:
> >
> >           return (len2 + pagesize - 1) / pagesize;
>
> You are right. Did not cause the mincore output buffer to be unnecessarily
> large. Thanks for catching this.
>
> As for your other concern:
>
>
> On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart <peter.levart at gmail.com>
> wrote:
>
>> --
>> In Java_java_nio_MappedByteBuffer_isLoaded0, we call mincore(2) to
>> retrieve the paging status of an address range.
>>
>> The size of the output buffer for mincore(2) depends on the number of
>> pages in *system page size* in the given memory range (this is spelled out
>> more or less explicitly on AIX and Linux, nothing is said on BSD/OSX, but I
>> assume the same). The number of pages in the memory range is calculated by
>> MappedByteBuffer.isLoaded() and handed down to
>> Java_java_nio_MappedByteBuffer_isLoaded0() together with the memory
>> range to test.
>>
>> MappedByteBuffer.isLoaded() calculates this number of pages based on
>> jjdk.internal.misc.Unsafe.pagesize(), which ultimately comes down to
>> os::vm_page_size().
>>
>> For AIX, os::vm_page_size() may return a page size larger than the system
>> page size of 4K. The reason for this is that on AIX, memory can be backed
>> by different page sizes, usually either 4K or 64K - e.g. posix thread
>> stacks may have 4K pages, java heap (system V shared memory) with 64K
>> pages, but mmap memory is always 4K page backed...
>>
>>
>> If this is true and Unsafe.pagesize() returns a value > 4K, then perhaps
>> also the MappedByteBuffer.load() method is wrong for AIX?
>>
>>     public final MappedByteBuffer load() {
>>         checkMapped();
>>         if ((address == 0) || (capacity() == 0))
>>             return this;
>>         long offset = mappingOffset();
>>         long length = mappingLength(offset);
>>         load0(mappingAddress(offset), length);
>>
>>         // Read a byte from each page to bring it into memory. A checksum
>>         // is computed as we go along to prevent the compiler from
>> otherwise
>>         // considering the loop as dead code.
>>         Unsafe unsafe = Unsafe.getUnsafe();
>>         int ps = Bits.pageSize(); // << LOOK HERE
>>         int count = Bits.pageCount(length);
>>         long a = mappingAddress(offset);
>>         byte x = 0;
>>         for (int i=0; i<count; i++) {
>>             x ^= unsafe.getByte(a);
>>             a += ps; // << AND HERE
>>         }
>>         if (unused != 0)
>>             unused = x;
>>
>>         return this;
>>     }
>>
>> ...this loop reads a byte from the start of each block in lumps of
>> Bits.pageSize(). Should it always read in lumps of 4K for AIX? Do we rather
>> need a special Unsafe.mmappedPageSize() method instead of just a hack in
>> isLoaded0 ?
>>
>>
> Yes, I considered this too. In effect, on AIX, we only touch every 16th
> page, thereby reducing MappedByteBuffer::load() to something like
> load_every_16th_page... However, this bug is very old (even our 1.4 VM
> already does this when the touching was still implemented in
> MappedByteBuffer.c) and did not cause any problems AFAIK.
>
> The story behind this is long and quite boring :) basically, 64k pages are
> used for the java heap and give a large performance bonus over 4K paged
> java heap. But we cannot switch all memory regions to 64K pages, so we live
> with multiple page sizes and above us we have a ton of code which assumes
> one consistent page size for everything. So we lie about the page size to
> everyone - claiming system page size to be 64k - and except for very rare
> cases like this one get away with this.
>
> I would like to keep lying consistently. There is not a hard reason for
> it, just that I am afraid that starting to publish a different page size to
> parts of the VM will confuse things and may introduce errors further down
> the line.
>
> I think a proper solution would be to keep page size on a per-ByteBuffer
> base, because ByteBuffers may be allocated in different memory regions -
> they are now allocated with mmap() in system page size, but that may change
> in the future. That is assuming that one byte buffer cannot span areas of
> multiple page sizes, which would complicate matters further.
>
> Btw, I also wondered whether other platforms could have a clash between
> the real memory page size and MappedByteBuffer's notion of that size - e.g.
> whether it is possible to have MappedByteBuffers with huge pages on Linux.
> But all cases I could think of are cases where the page size the JDK would
> assume is smaller than the actual page size, which would not be a problem
> for both mincore and load/touch. In the above example (huge pages on
> Linux), pages would be pinned anyway, so load() and isLoaded() would be
> noops.
>
>
> @Christoph:
>
> > apart from the point that Peter found, I?d also think it would look
> better if the typedef section (line 51-56) would be placed before the AIX
> only function (line 41-49).
>
>
> Sure. I moved the section up, below the includes.
>
> Kind Regards, Thomas
>
>

From christoph.langer at sap.com  Thu Oct 19 13:22:45 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 19 Oct 2017 13:22:45 +0000
Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer
 overflow in Java_java_nio_MappedByteBuffer_isLoaded0
In-Reply-To: <CAA-vtUxMy8Lvmtf4ZhuU9-7km9MXmC4BmhuoiQ8XSwmpKR6f4g@mail.gmail.com>
References: <CAA-vtUzU5zvZLuUe6kHOfTkijLk7ydrr3C4wsSoaQRhCYdV51g@mail.gmail.com>
 <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com>
 <CAA-vtUztOsSQoYuTmexqDTdhY=bGiYqdqMYdNh=MpmmQ7CveTg@mail.gmail.com>
 <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com>
 <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>
 <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com>
 <CAA-vtUzG1kvdG+S2JfBSW_JkYvSSOBkFArbgu4HQ0hgG9jFCKg@mail.gmail.com>
 <CAA-vtUxMy8Lvmtf4ZhuU9-7km9MXmC4BmhuoiQ8XSwmpKR6f4g@mail.gmail.com>
Message-ID: <99e9d160c1df4129969421931f08ff24@sap.com>

Hi Thomas,

ok from my end.

Best regards
Christoph

From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
Sent: Donnerstag, 19. Oktober 2017 15:22
To: Peter Levart <peter.levart at gmail.com>; Langer, Christoph <christoph.langer at sap.com>
Cc: Alan Bateman <Alan.Bateman at oracle.com>; nio-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Java Core Libs <core-libs-dev at openjdk.java.net>
Subject: Re: RFR(xs): (aix but affects shared code too) 8186665: buffer overflow in Java_java_nio_MappedByteBuffer_isLoaded0

Hi Peter, Christoph,

if you have no objections, I'd like to push this change. As I explained in my earlier mail, I'd prefer not to change MappedByteBuffer::load(), and if you are fine with the change in its current form (http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/), I'd like to push it.

Thanks, Thomas


On Wed, Oct 18, 2017 at 12:24 PM, Thomas St?fe <thomas.stuefe at gmail.com<mailto:thomas.stuefe at gmail.com>> wrote:
Hi Peter, Christoph,

Thank you both for reviewing.

New webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/

@Peter:

>Shouldn't the following line:
>
>  47     return len2 + pagesize - 1 / pagesize;
>
>..be written as:
>
>           return (len2 + pagesize - 1) / pagesize;

You are right. Did not cause the mincore output buffer to be unnecessarily large. Thanks for catching this.

As for your other concern:


On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart <peter.levart at gmail.com<mailto:peter.levart at gmail.com>> wrote:
--
In Java_java_nio_MappedByteBuffer_isLoaded0, we call mincore(2) to retrieve the paging status of an address range.

The size of the output buffer for mincore(2) depends on the number of pages in *system page size* in the given memory range (this is spelled out more or less explicitly on AIX and Linux, nothing is said on BSD/OSX, but I assume the same). The number of pages in the memory range is calculated by MappedByteBuffer.isLoaded() and handed down to Java_java_nio_MappedByteBuffer_isLoaded0() together with the memory range to test.

MappedByteBuffer.isLoaded() calculates this number of pages based on jjdk.internal.misc.Unsafe.pagesize(), which ultimately comes down to os::vm_page_size().

For AIX, os::vm_page_size() may return a page size larger than the system page size of 4K. The reason for this is that on AIX, memory can be backed by different page sizes, usually either 4K or 64K - e.g. posix thread stacks may have 4K pages, java heap (system V shared memory) with 64K pages, but mmap memory is always 4K page backed...

If this is true and Unsafe.pagesize() returns a value > 4K, then perhaps also the MappedByteBuffer.load() method is wrong for AIX?

    public final MappedByteBuffer load() {
        checkMapped();
        if ((address == 0) || (capacity() == 0))
            return this;
        long offset = mappingOffset();
        long length = mappingLength(offset);
        load0(mappingAddress(offset), length);

        // Read a byte from each page to bring it into memory. A checksum
        // is computed as we go along to prevent the compiler from otherwise
        // considering the loop as dead code.
        Unsafe unsafe = Unsafe.getUnsafe();
        int ps = Bits.pageSize(); // << LOOK HERE
        int count = Bits.pageCount(length);
        long a = mappingAddress(offset);
        byte x = 0;
        for (int i=0; i<count; i++) {
            x ^= unsafe.getByte(a);
            a += ps; // << AND HERE
        }
        if (unused != 0)
            unused = x;

        return this;
    }

...this loop reads a byte from the start of each block in lumps of Bits.pageSize(). Should it always read in lumps of 4K for AIX? Do we rather need a special Unsafe.mmappedPageSize() method instead of just a hack in isLoaded0 ?

Yes, I considered this too. In effect, on AIX, we only touch every 16th page, thereby reducing MappedByteBuffer::load() to something like load_every_16th_page... However, this bug is very old (even our 1.4 VM already does this when the touching was still implemented in MappedByteBuffer.c) and did not cause any problems AFAIK.

The story behind this is long and quite boring :) basically, 64k pages are used for the java heap and give a large performance bonus over 4K paged java heap. But we cannot switch all memory regions to 64K pages, so we live with multiple page sizes and above us we have a ton of code which assumes one consistent page size for everything. So we lie about the page size to everyone - claiming system page size to be 64k - and except for very rare cases like this one get away with this.

I would like to keep lying consistently. There is not a hard reason for it, just that I am afraid that starting to publish a different page size to parts of the VM will confuse things and may introduce errors further down the line.

I think a proper solution would be to keep page size on a per-ByteBuffer base, because ByteBuffers may be allocated in different memory regions - they are now allocated with mmap() in system page size, but that may change in the future. That is assuming that one byte buffer cannot span areas of multiple page sizes, which would complicate matters further.

Btw, I also wondered whether other platforms could have a clash between the real memory page size and MappedByteBuffer's notion of that size - e.g. whether it is possible to have MappedByteBuffers with huge pages on Linux. But all cases I could think of are cases where the page size the JDK would assume is smaller than the actual page size, which would not be a problem for both mincore and load/touch. In the above example (huge pages on Linux), pages would be pinned anyway, so load() and isLoaded() would be noops.


@Christoph:

> apart from the point that Peter found, I?d also think it would look better if the typedef section (line 51-56) would be placed before the AIX only function (line 41-49).

Sure. I moved the section up, below the includes.

Kind Regards, Thomas



From thomas.stuefe at gmail.com  Thu Oct 19 13:29:03 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 19 Oct 2017 15:29:03 +0200
Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer
 overflow in Java_java_nio_MappedByteBuffer_isLoaded0
In-Reply-To: <99e9d160c1df4129969421931f08ff24@sap.com>
References: <CAA-vtUzU5zvZLuUe6kHOfTkijLk7ydrr3C4wsSoaQRhCYdV51g@mail.gmail.com>
 <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com>
 <CAA-vtUztOsSQoYuTmexqDTdhY=bGiYqdqMYdNh=MpmmQ7CveTg@mail.gmail.com>
 <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com>
 <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>
 <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com>
 <CAA-vtUzG1kvdG+S2JfBSW_JkYvSSOBkFArbgu4HQ0hgG9jFCKg@mail.gmail.com>
 <CAA-vtUxMy8Lvmtf4ZhuU9-7km9MXmC4BmhuoiQ8XSwmpKR6f4g@mail.gmail.com>
 <99e9d160c1df4129969421931f08ff24@sap.com>
Message-ID: <CAA-vtUyzVYjhzfEcrRpFW3-GqNc3fDWha_QjdedMiq+weUAGTw@mail.gmail.com>

Thanks Christoph!

On Thu, Oct 19, 2017 at 3:22 PM, Langer, Christoph <christoph.langer at sap.com
> wrote:

> Hi Thomas,
>
>
>
> ok from my end.
>
>
>
> Best regards
>
> Christoph
>
>
>
> *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> *Sent:* Donnerstag, 19. Oktober 2017 15:22
> *To:* Peter Levart <peter.levart at gmail.com>; Langer, Christoph <
> christoph.langer at sap.com>
> *Cc:* Alan Bateman <Alan.Bateman at oracle.com>; nio-dev at openjdk.java.net;
> ppc-aix-port-dev at openjdk.java.net; Java Core Libs <
> core-libs-dev at openjdk.java.net>
> *Subject:* Re: RFR(xs): (aix but affects shared code too) 8186665: buffer
> overflow in Java_java_nio_MappedByteBuffer_isLoaded0
>
>
>
> Hi Peter, Christoph,
>
>
>
> if you have no objections, I'd like to push this change. As I explained in
> my earlier mail, I'd prefer not to change MappedByteBuffer::load(), and if
> you are fine with the change in its current form (
> http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-
> overflow-in-mincore/webrev.02/webrev/), I'd like to push it.
>
>
>
> Thanks, Thomas
>
>
>
>
>
> On Wed, Oct 18, 2017 at 12:24 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
> Hi Peter, Christoph,
>
>
>
> Thank you both for reviewing.
>
>
>
> New webrev: http://cr.openjdk.java.net/~stuefe/webrevs/
> 8186665-buffer-overflow-in-mincore/webrev.02/webrev/
>
>
>
> @Peter:
>
>
>
> >Shouldn't the following line:
> >
> >  47     return len2 + pagesize - 1 / pagesize;
> >
> >..be written as:
> >
> >           return (len2 + pagesize - 1) / pagesize;
>
>
>
> You are right. Did not cause the mincore output buffer to be unnecessarily
> large. Thanks for catching this.
>
>
>
> As for your other concern:
>
>
>
>
>
> On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart <peter.levart at gmail.com>
> wrote:
>
> --
> In Java_java_nio_MappedByteBuffer_isLoaded0, we call mincore(2) to
> retrieve the paging status of an address range.
>
> The size of the output buffer for mincore(2) depends on the number of
> pages in *system page size* in the given memory range (this is spelled out
> more or less explicitly on AIX and Linux, nothing is said on BSD/OSX, but I
> assume the same). The number of pages in the memory range is calculated by
> MappedByteBuffer.isLoaded() and handed down to Java_java_nio_MappedByteBuffer_isLoaded0()
> together with the memory range to test.
>
> MappedByteBuffer.isLoaded() calculates this number of pages based on
> jjdk.internal.misc.Unsafe.pagesize(), which ultimately comes down to
> os::vm_page_size().
>
> For AIX, os::vm_page_size() may return a page size larger than the system
> page size of 4K. The reason for this is that on AIX, memory can be backed
> by different page sizes, usually either 4K or 64K - e.g. posix thread
> stacks may have 4K pages, java heap (system V shared memory) with 64K
> pages, but mmap memory is always 4K page backed...
>
>
> If this is true and Unsafe.pagesize() returns a value > 4K, then perhaps
> also the MappedByteBuffer.load() method is wrong for AIX?
>
>     public final MappedByteBuffer load() {
>         checkMapped();
>         if ((address == 0) || (capacity() == 0))
>             return this;
>         long offset = mappingOffset();
>         long length = mappingLength(offset);
>         load0(mappingAddress(offset), length);
>
>         // Read a byte from each page to bring it into memory. A checksum
>         // is computed as we go along to prevent the compiler from
> otherwise
>         // considering the loop as dead code.
>         Unsafe unsafe = Unsafe.getUnsafe();
>         int ps = Bits.pageSize(); // << LOOK HERE
>         int count = Bits.pageCount(length);
>         long a = mappingAddress(offset);
>         byte x = 0;
>         for (int i=0; i<count; i++) {
>             x ^= unsafe.getByte(a);
>             a += ps; // << AND HERE
>         }
>         if (unused != 0)
>             unused = x;
>
>         return this;
>     }
>
> ...this loop reads a byte from the start of each block in lumps of
> Bits.pageSize(). Should it always read in lumps of 4K for AIX? Do we rather
> need a special Unsafe.mmappedPageSize() method instead of just a hack in
> isLoaded0 ?
>
>
>
> Yes, I considered this too. In effect, on AIX, we only touch every 16th
> page, thereby reducing MappedByteBuffer::load() to something like
> load_every_16th_page... However, this bug is very old (even our 1.4 VM
> already does this when the touching was still implemented in
> MappedByteBuffer.c) and did not cause any problems AFAIK.
>
>
>
> The story behind this is long and quite boring :) basically, 64k pages are
> used for the java heap and give a large performance bonus over 4K paged
> java heap. But we cannot switch all memory regions to 64K pages, so we live
> with multiple page sizes and above us we have a ton of code which assumes
> one consistent page size for everything. So we lie about the page size to
> everyone - claiming system page size to be 64k - and except for very rare
> cases like this one get away with this.
>
>
>
> I would like to keep lying consistently. There is not a hard reason for
> it, just that I am afraid that starting to publish a different page size to
> parts of the VM will confuse things and may introduce errors further down
> the line.
>
>
>
> I think a proper solution would be to keep page size on a per-ByteBuffer
> base, because ByteBuffers may be allocated in different memory regions -
> they are now allocated with mmap() in system page size, but that may change
> in the future. That is assuming that one byte buffer cannot span areas of
> multiple page sizes, which would complicate matters further.
>
>
>
> Btw, I also wondered whether other platforms could have a clash between
> the real memory page size and MappedByteBuffer's notion of that size - e.g.
> whether it is possible to have MappedByteBuffers with huge pages on Linux.
> But all cases I could think of are cases where the page size the JDK would
> assume is smaller than the actual page size, which would not be a problem
> for both mincore and load/touch. In the above example (huge pages on
> Linux), pages would be pinned anyway, so load() and isLoaded() would be
> noops.
>
>
>
>
>
> @Christoph:
>
>
>
> > apart from the point that Peter found, I?d also think it would look
> better if the typedef section (line 51-56) would be placed before the AIX
> only function (line 41-49).
>
>
>
> Sure. I moved the section up, below the includes.
>
>
>
> Kind Regards, Thomas
>
>
>
>
>

From peter.levart at gmail.com  Thu Oct 19 20:42:19 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 19 Oct 2017 22:42:19 +0200
Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer
 overflow in Java_java_nio_MappedByteBuffer_isLoaded0
In-Reply-To: <CAA-vtUxMy8Lvmtf4ZhuU9-7km9MXmC4BmhuoiQ8XSwmpKR6f4g@mail.gmail.com>
References: <CAA-vtUzU5zvZLuUe6kHOfTkijLk7ydrr3C4wsSoaQRhCYdV51g@mail.gmail.com>
 <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com>
 <CAA-vtUztOsSQoYuTmexqDTdhY=bGiYqdqMYdNh=MpmmQ7CveTg@mail.gmail.com>
 <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com>
 <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>
 <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com>
 <CAA-vtUzG1kvdG+S2JfBSW_JkYvSSOBkFArbgu4HQ0hgG9jFCKg@mail.gmail.com>
 <CAA-vtUxMy8Lvmtf4ZhuU9-7km9MXmC4BmhuoiQ8XSwmpKR6f4g@mail.gmail.com>
Message-ID: <746b8bb2-0203-f50c-c7bd-77e5a0e434f7@gmail.com>

Hi Thomas,

Right. I can understand the situation and potential problems of 
introducing API for mmappedPageSize. So let's keep pretending that page 
size is uniform for all memory regions used by VM and see where this 
brings us. The change fixes the problem, although in a hack-ish way. It 
will be good for now.

Regards, Peter


On 10/19/17 15:21, Thomas St?fe wrote:
> Hi Peter, Christoph,
>
> if you have no objections, I'd like to push this change. As I 
> explained in my earlier mail, I'd prefer not to change 
> MappedByteBuffer::load(), and if you are fine with the change in its 
> current form 
> (http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/ 
> <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/>), 
> I'd like to push it.
>
> Thanks, Thomas
>
>
> On Wed, Oct 18, 2017 at 12:24 PM, Thomas St?fe 
> <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>> wrote:
>
>     Hi Peter, Christoph,
>
>     Thank you both for reviewing.
>
>     New webrev:
>     http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/
>     <http://cr.openjdk.java.net/%7Estuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/>
>
>     @Peter:
>
>     >Shouldn't the following line:
>     >
>     >? 47???? return len2 + pagesize - 1 / pagesize;
>     >
>     >..be written as:
>     >
>     >? ? ? ? ? ?return (len2 + pagesize - 1) / pagesize;
>
>     You are right. Did not cause the mincore output buffer to be
>     unnecessarily large. Thanks for catching this.
>
>     As for your other concern:
>
>
>     On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart
>     <peter.levart at gmail.com <mailto:peter.levart at gmail.com>> wrote:
>
>>         --
>>         In Java_java_nio_MappedByteBuffer_isLoaded0, we call
>>         mincore(2) to retrieve the paging status of an address range.
>>
>>         The size of the output buffer for mincore(2) depends on the
>>         number of pages in *system page size* in the given memory
>>         range (this is spelled out more or less explicitly on AIX and
>>         Linux, nothing is said on BSD/OSX, but I assume the same).
>>         The number of pages in the memory range is calculated by
>>         MappedByteBuffer.isLoaded() and handed down to
>>         Java_java_nio_MappedByteBuffer_isLoaded0() together with the
>>         memory range to test.
>>
>>         MappedByteBuffer.isLoaded() calculates this number of pages
>>         based on jjdk.internal.misc.Unsafe.pagesize(), which
>>         ultimately comes down to os::vm_page_size().
>>
>>         For AIX, os::vm_page_size() may return a page size larger
>>         than the system page size of 4K. The reason for this is that
>>         on AIX, memory can be backed by different page sizes, usually
>>         either 4K or 64K - e.g. posix thread stacks may have 4K
>>         pages, java heap (system V shared memory) with 64K pages, but
>>         mmap memory is always 4K page backed...
>
>         If this is true and Unsafe.pagesize() returns a value > 4K,
>         then perhaps also the MappedByteBuffer.load() method is wrong
>         for AIX?
>
>         ??? public final MappedByteBuffer load() {
>         ??????? checkMapped();
>         ??????? if ((address == 0) || (capacity() == 0))
>         ??????????? return this;
>         ??????? long offset = mappingOffset();
>         ??????? long length = mappingLength(offset);
>         ??????? load0(mappingAddress(offset), length);
>
>         ??????? // Read a byte from each page to bring it into memory.
>         A checksum
>         ??????? // is computed as we go along to prevent the compiler
>         from otherwise
>         ??????? // considering the loop as dead code.
>         ??????? Unsafe unsafe = Unsafe.getUnsafe();
>         ??????? int ps = Bits.pageSize(); // << LOOK HERE
>         ??????? int count = Bits.pageCount(length);
>         ??????? long a = mappingAddress(offset);
>         ??????? byte x = 0;
>         ??????? for (int i=0; i<count; i++) {
>         ??????????? x ^= unsafe.getByte(a);
>         ??????????? a += ps; // << AND HERE
>         ??????? }
>         ??????? if (unused != 0)
>         ??????????? unused = x;
>
>         ??????? return this;
>         ??? }
>
>         ...this loop reads a byte from the start of each block in
>         lumps of Bits.pageSize(). Should it always read in lumps of 4K
>         for AIX? Do we rather need a special Unsafe.mmappedPageSize()
>         method instead of just a hack in isLoaded0 ?
>
>
>     Yes, I considered this too. In effect, on AIX, we only touch every
>     16th page, thereby reducing MappedByteBuffer::load() to something
>     like load_every_16th_page... However, this bug is very old (even
>     our 1.4 VM already does this when the touching was still
>     implemented in MappedByteBuffer.c) and did not cause any problems
>     AFAIK.
>
>     The story behind this is long and quite boring :) basically, 64k
>     pages are used for the java heap and give a large performance
>     bonus over 4K paged java heap. But we cannot switch all memory
>     regions to 64K pages, so we live with multiple page sizes and
>     above us we have a ton of code which assumes one consistent page
>     size for everything. So we lie about the page size to everyone -
>     claiming system page size to be 64k - and except for very rare
>     cases like this one get away with this.
>
>     I would like to keep lying consistently. There is not a hard
>     reason for it, just that I am afraid that starting to publish a
>     different page size to parts of the VM will confuse things and may
>     introduce errors further down the line.
>
>     I think a proper solution would be to keep page size on a
>     per-ByteBuffer base, because ByteBuffers may be allocated in
>     different memory regions - they are now allocated with mmap() in
>     system page size, but that may change in the future. That is
>     assuming that one byte buffer cannot span areas of multiple page
>     sizes, which would complicate matters further.
>
>     Btw, I also wondered whether other platforms could have a clash
>     between the real memory page size and MappedByteBuffer's notion of
>     that size - e.g. whether it is possible to have MappedByteBuffers
>     with huge pages on Linux. But all cases I could think of?are cases
>     where the page size the JDK would assume is smaller than the
>     actual page size, which would not be a problem for both mincore
>     and load/touch. In the above example (huge pages on Linux), pages
>     would be pinned anyway, so load() and isLoaded() would be noops.
>
>
>     @Christoph:
>
>     > apart from the point that Peter found, I?d also think it would
>     look better if the typedef section (line 51-56) would be placed
>     before the AIX only function (line 41-49).
>
>
>     Sure. I moved the section up, below the includes.
>
>     Kind Regards, Thomas
>
>


From thomas.stuefe at gmail.com  Thu Oct 19 20:43:24 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 19 Oct 2017 20:43:24 +0000
Subject: RFR(xs): (aix but affects shared code too) 8186665: buffer
 overflow in Java_java_nio_MappedByteBuffer_isLoaded0
In-Reply-To: <746b8bb2-0203-f50c-c7bd-77e5a0e434f7@gmail.com>
References: <CAA-vtUzU5zvZLuUe6kHOfTkijLk7ydrr3C4wsSoaQRhCYdV51g@mail.gmail.com>
 <0557a2d5-5a5d-9218-7551-121a95fb4f6c@oracle.com>
 <CAA-vtUztOsSQoYuTmexqDTdhY=bGiYqdqMYdNh=MpmmQ7CveTg@mail.gmail.com>
 <0c1e56e1-e802-260d-3224-5eebd7f1e569@oracle.com>
 <CAA-vtUxGm2Wdk79jz8x7rSjHJzy5trdMQDAL=_h8M1Om_FGFHQ@mail.gmail.com>
 <2888a60f-1c15-eaed-d47c-58e389f7762a@gmail.com>
 <CAA-vtUzG1kvdG+S2JfBSW_JkYvSSOBkFArbgu4HQ0hgG9jFCKg@mail.gmail.com>
 <CAA-vtUxMy8Lvmtf4ZhuU9-7km9MXmC4BmhuoiQ8XSwmpKR6f4g@mail.gmail.com>
 <746b8bb2-0203-f50c-c7bd-77e5a0e434f7@gmail.com>
Message-ID: <CAA-vtUyMdCz9xABS759A5gNM-Po0iOve-X-iC-1ZiRJbkCsV8w@mail.gmail.com>

Thank you, Peter.

..Thomas

On Thu 19. Oct 2017 at 22:42, Peter Levart <peter.levart at gmail.com> wrote:

> Hi Thomas,
>
> Right. I can understand the situation and potential problems of
> introducing API for mmappedPageSize. So let's keep pretending that page
> size is uniform for all memory regions used by VM and see where this brings
> us. The change fixes the problem, although in a hack-ish way. It will be
> good for now.
>
> Regards, Peter
>
>
>
> On 10/19/17 15:21, Thomas St?fe wrote:
>
> Hi Peter, Christoph,
>
> if you have no objections, I'd like to push this change. As I explained in
> my earlier mail, I'd prefer not to change MappedByteBuffer::load(), and if
> you are fine with the change in its current form (
> http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/),
> I'd like to push it.
>
> Thanks, Thomas
>
>
> On Wed, Oct 18, 2017 at 12:24 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
>> Hi Peter, Christoph,
>>
>> Thank you both for reviewing.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8186665-buffer-overflow-in-mincore/webrev.02/webrev/
>>
>> @Peter:
>>
>> >Shouldn't the following line:
>> >
>> >  47     return len2 + pagesize - 1 / pagesize;
>> >
>> >..be written as:
>> >
>> >           return (len2 + pagesize - 1) / pagesize;
>>
>> You are right. Did not cause the mincore output buffer to be
>> unnecessarily large. Thanks for catching this.
>>
>> As for your other concern:
>>
>>
>> On Wed, Oct 18, 2017 at 10:32 AM, Peter Levart <peter.levart at gmail.com>
>> wrote:
>>
>>> --
>>> In Java_java_nio_MappedByteBuffer_isLoaded0, we call mincore(2) to
>>> retrieve the paging status of an address range.
>>>
>>> The size of the output buffer for mincore(2) depends on the number of
>>> pages in *system page size* in the given memory range (this is spelled out
>>> more or less explicitly on AIX and Linux, nothing is said on BSD/OSX, but I
>>> assume the same). The number of pages in the memory range is calculated by
>>> MappedByteBuffer.isLoaded() and handed down to
>>> Java_java_nio_MappedByteBuffer_isLoaded0() together with the memory range
>>> to test.
>>>
>>> MappedByteBuffer.isLoaded() calculates this number of pages based on
>>> jjdk.internal.misc.Unsafe.pagesize(), which ultimately comes down to
>>> os::vm_page_size().
>>>
>>> For AIX, os::vm_page_size() may return a page size larger than the
>>> system page size of 4K. The reason for this is that on AIX, memory can be
>>> backed by different page sizes, usually either 4K or 64K - e.g. posix
>>> thread stacks may have 4K pages, java heap (system V shared memory) with
>>> 64K pages, but mmap memory is always 4K page backed...
>>>
>>>
>>> If this is true and Unsafe.pagesize() returns a value > 4K, then perhaps
>>> also the MappedByteBuffer.load() method is wrong for AIX?
>>>
>>>     public final MappedByteBuffer load() {
>>>         checkMapped();
>>>         if ((address == 0) || (capacity() == 0))
>>>             return this;
>>>         long offset = mappingOffset();
>>>         long length = mappingLength(offset);
>>>         load0(mappingAddress(offset), length);
>>>
>>>         // Read a byte from each page to bring it into memory. A checksum
>>>         // is computed as we go along to prevent the compiler from
>>> otherwise
>>>         // considering the loop as dead code.
>>>         Unsafe unsafe = Unsafe.getUnsafe();
>>>         int ps = Bits.pageSize(); // << LOOK HERE
>>>         int count = Bits.pageCount(length);
>>>         long a = mappingAddress(offset);
>>>         byte x = 0;
>>>         for (int i=0; i<count; i++) {
>>>             x ^= unsafe.getByte(a);
>>>             a += ps; // << AND HERE
>>>         }
>>>         if (unused != 0)
>>>             unused = x;
>>>
>>>         return this;
>>>     }
>>>
>>> ...this loop reads a byte from the start of each block in lumps of
>>> Bits.pageSize(). Should it always read in lumps of 4K for AIX? Do we rather
>>> need a special Unsafe.mmappedPageSize() method instead of just a hack in
>>> isLoaded0 ?
>>>
>>>
>> Yes, I considered this too. In effect, on AIX, we only touch every 16th
>> page, thereby reducing MappedByteBuffer::load() to something like
>> load_every_16th_page... However, this bug is very old (even our 1.4 VM
>> already does this when the touching was still implemented in
>> MappedByteBuffer.c) and did not cause any problems AFAIK.
>>
>> The story behind this is long and quite boring :) basically, 64k pages
>> are used for the java heap and give a large performance bonus over 4K paged
>> java heap. But we cannot switch all memory regions to 64K pages, so we live
>> with multiple page sizes and above us we have a ton of code which assumes
>> one consistent page size for everything. So we lie about the page size to
>> everyone - claiming system page size to be 64k - and except for very rare
>> cases like this one get away with this.
>>
>> I would like to keep lying consistently. There is not a hard reason for
>> it, just that I am afraid that starting to publish a different page size to
>> parts of the VM will confuse things and may introduce errors further down
>> the line.
>>
>> I think a proper solution would be to keep page size on a per-ByteBuffer
>> base, because ByteBuffers may be allocated in different memory regions -
>> they are now allocated with mmap() in system page size, but that may change
>> in the future. That is assuming that one byte buffer cannot span areas of
>> multiple page sizes, which would complicate matters further.
>>
>> Btw, I also wondered whether other platforms could have a clash between
>> the real memory page size and MappedByteBuffer's notion of that size - e.g.
>> whether it is possible to have MappedByteBuffers with huge pages on Linux.
>> But all cases I could think of are cases where the page size the JDK would
>> assume is smaller than the actual page size, which would not be a problem
>> for both mincore and load/touch. In the above example (huge pages on
>> Linux), pages would be pinned anyway, so load() and isLoaded() would be
>> noops.
>>
>>
>> @Christoph:
>>
>> > apart from the point that Peter found, I?d also think it would look
>> better if the typedef section (line 51-56) would be placed before the AIX
>> only function (line 41-49).
>>
>>
>> Sure. I moved the section up, below the includes.
>>
>> Kind Regards, Thomas
>>
>>
>
>

From christoph.dreis at freenet.de  Fri Oct 20 11:04:52 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Fri, 20 Oct 2017 13:04:52 +0200
Subject: RFR: 8029019: (ann) Optimize annotation handling in core
 reflection
In-Reply-To: <007dcb59-5759-eb03-0fad-14c301e5dc56@oracle.com>
References: <000001d341f1$82764870$8762d950$@freenet.de>
 <58df9bf3-fb5d-958e-b4fb-1baf3d86248b@gmail.com>
 <000101d343f0$32b7ba70$98272f50$@freenet.de>
 <34043e48-45ec-2e2f-97cb-81b110575864@gmail.com>
 <007dcb59-5759-eb03-0fad-14c301e5dc56@oracle.com>
Message-ID: <003a01d34993$42185f30$c6491d90$@freenet.de>

Hey Claes and Peter,

> I'm somewhat strapped for cycles right now, so do you mind if I move ahead
> with the simpler patch Christoph proposed initially (and which Joel has
> already reviewed)?

unsurprisingly I'd go for the simple patch. It's even small enough to have it backported in my opinion.

> Looking back at the history of JDK-8029019 I personally prefer adding a way to
> get non-copying access to the Method parameter array rather than the
> declaringClass origin checking.

I like that idea - I could at least think of several places in open source libs that could benefit from something like that.

Cheers,
Christoph


From christoph.dreis at freenet.de  Fri Oct 20 11:45:50 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Fri, 20 Oct 2017 13:45:50 +0200
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
Message-ID: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>

Hey,

while discussing JDK-8029019 & JDK-8189266 Claes came up with the idea to
introduce non-copying access to the underlying parameter types of an
Executable [1]. While there is a (for a good reason?) package-private
Method.getSharedParameterTypes() already I thought of an alternative that
doesn't open up the parameterTypes array to the outside world and actually
solves the use-case where we wanted an allocation-free alternative for
Method.getParameterTypes()[index].

Here is a draft of what I'm thinking of:

Executable:
    /**
     * Returns the {@code Class} object that represents the formal
     * parameter type, at the given index, of the executable
     * represented by this object. The given index starts at 0 and
     * represents the declaration order of the parameters.
     *
     *
     * @param index index to look for the parameter type
     * @return the parameter type at the given index for the executable this
object
     * represents
     * @throws IndexOutOfBoundsException if the parameter type
     *      at the given index of the underlying executable could not be
found
     */
    public abstract Class<?> getParameterType(int index);

Method & Constructor:
   /**
     * {@inheritDoc}
     * @throws IndexOutOfBoundsException {@inheritDoc}
     * @since 18.3
     */
    public Class<?> getParameterType(int index) {
        if (index < 0 || index > getParameterCount()) {
            throw new IndexOutOfBoundsException("No parameter found on index
" + index);
        }
        return parameterTypes[index];
    }

As I don't know what the official @since should look like in the future, do
not pay too much attention on that. I'm not happy with the documentation
wording though.

What do you think about that? Is someone willing to sponsor this given it's
considered worthwhile.

Cheers,
Christoph

[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049520.htm
l


From claes.redestad at oracle.com  Fri Oct 20 12:27:33 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 20 Oct 2017 14:27:33 +0200
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
Message-ID: <b8a2aa2e-2965-961d-887a-88775e4f6454@oracle.com>

Hi Christoph,


On 2017-10-20 13:45, Christoph Dreis wrote:
> Hey,
>
> while discussing JDK-8029019 & JDK-8189266 Claes came up with the idea to
> introduce non-copying access to the underlying parameter types of an
> Executable [1].

I only recalled Peter had a version of his patch for 8029019 that
included making a shared secret out of
Method.getSharedParameterTypes(), which is kept package-private
for good reason (giving anyone outside the module direct access
to shared arrays is never safe - clone defensively!).

A non-intrusive public API to get at the parameter types safely might
be better overall, though, so if you want to give me some credit for
this then I don't mind... :-)

> While there is a (for a good reason?) package-private
> Method.getSharedParameterTypes() already I thought of an alternative that
> doesn't open up the parameterTypes array to the outside world and actually
> solves the use-case where we wanted an allocation-free alternative for
> Method.getParameterTypes()[index].
>
> Here is a draft of what I'm thinking of:
>
> Executable:
>      /**
>       * Returns the {@code Class} object that represents the formal
>       * parameter type, at the given index, of the executable
>       * represented by this object. The given index starts at 0 and
>       * represents the declaration order of the parameters.
>       *
>       *
>       * @param index index to look for the parameter type
>       * @return the parameter type at the given index for the executable this
> object
>       * represents
>       * @throws IndexOutOfBoundsException if the parameter type
>       *      at the given index of the underlying executable could not be
> found
>       */
>      public abstract Class<?> getParameterType(int index);
>
> Method & Constructor:
>     /**
>       * {@inheritDoc}
>       * @throws IndexOutOfBoundsException {@inheritDoc}
>       * @since 18.3
>       */
>      public Class<?> getParameterType(int index) {
>          if (index < 0 || index > getParameterCount()) {
>              throw new IndexOutOfBoundsException("No parameter found on index
> " + index);
>          }

I don't think we need the explicit range check here.

>          return parameterTypes[index];
>      }
>
> As I don't know what the official @since should look like in the future, do
> not pay too much attention on that. I'm not happy with the documentation
> wording though.

I'm sure there are some who can comment on the wording around
here... :-)

>
> What do you think about that? Is someone willing to sponsor this given it's
> considered worthwhile.

Overall this design captures the desire to allow performant access to
parameter types, and experience and experiments show that the JIT fails
to eliminate the cloning more often than not.

This means there may be both internal[1] and possibly external use cases
where using this API is an optimization, and a simple getter like this can
also make some code cleaner. It does this without introducing another
shared secret in the meantime, which would only have limited applicability.

All in all I think it can pull its weight by allowing us to reduce JDK 
internal
use of getParameterTypes() alone, thus I'm in favor and can volunteer
to sponsor (this will need a CSR etc..)

Thanks!

/Claes

[1] 30+ uses of {Method|Constructor}.getParameterTypes() in java.base
alone, many of which could be improved with this.? Admittedly a few of
them are getParameterTypes().length != 0 that should be replaced with
getParameterCount() != 0 regardless..

>
> Cheers,
> Christoph
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049520.html
>


From rafael.wth at gmail.com  Fri Oct 20 13:32:33 2017
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 20 Oct 2017 15:32:33 +0200
Subject: Decreased latency performance with Stack Walker API compared to
 sun.misc.JavaLangAccess
Message-ID: <CA+DM0Am_PpFqhEXme+7MeXrnpiEnFiQmy7Opd7LptBtBc476+g@mail.gmail.com>

Hello,

a typical patern when reading the stack of the current thread in tooling
like performance monitoring used to imply the creation of an instance of
Throwable and to process this instance's attached stack in another thread.
The performance cost is shared about 10/90 for creating a new throwable
compared to reading its frames, so this is really a worthy optimization.

It is also common to use the JavaLangAccess API which offers selective
access of single frames.

This API does no longer exist as it was superseeded by the Stack Walker API
which is of course much safer and even a more performant alternative when
looking at the total performance. However, using a stack walker, it is no
longer possible to move the stack processing out of the user thread but it
must be done at the moment the snapshot of the stack is taken. It turns out
that this increases latency dramatically when processing stacks compared to
the asyncronous alternative.

In a quick benchmark, it seems like walking 35 frames of a 100 frames stack
allows me 70k operations per second whereas creating a new throwable yields
about 200k operations per second. Also, within a less isolated test, I can
infer this additional overhead from the actual latency numbers of a web
service when using the stack walker API to extract the top 35 frames
compared to the "old" solution using JavaLangAccess.

For this reason, it seems to be the best solution to avoid the stack walker
when aiming for latency at the moment if the stack is not required
immediately and if access resources are available in other threads.

I would therefore like to propose to extend the stack walker API to allow
walking the stack of an existing throwable to allow for similar performance
as with JavaLangAccess. I understand that the VM must do more work
altogether. When receving the full stack from a throwable, this takes about
three times as long. In practice, for a product I am involved in, this
casues a noticable overhead when running a Java 9 VM compared to Java 8.

Alternatively, it would of course even be better if one could take a
snapshot of only the top x frames to walk on this object rather then a
throwable.

I have added my benchmarks (snapshot for the current user thread operation,
complete for the entire processing) into this Gist:
https://gist.github.com/raphw/96e7c81d7c719cf7991b361bb7266c70

Thank you for any feedback on my finding!

Best regards, Rafael

From forax at univ-mlv.fr  Fri Oct 20 13:54:57 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 20 Oct 2017 15:54:57 +0200 (CEST)
Subject: Decreased latency performance with Stack Walker API compared to
 sun.misc.JavaLangAccess
In-Reply-To: <CA+DM0Am_PpFqhEXme+7MeXrnpiEnFiQmy7Opd7LptBtBc476+g@mail.gmail.com>
References: <CA+DM0Am_PpFqhEXme+7MeXrnpiEnFiQmy7Opd7LptBtBc476+g@mail.gmail.com>
Message-ID: <655276083.2146830.1508507697910.JavaMail.zimbra@u-pem.fr>

Hi Rafael,
stream.iterator() is usually super slow*, did you try with toArray() or forEach() instead ?

R?mi
* you want to see a push based API (Stream) as a pull based API (Iterator)

----- Mail original -----
> De: "Rafael Winterhalter" <rafael.wth at gmail.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 20 Octobre 2017 15:32:33
> Objet: Decreased latency performance with Stack Walker API compared to sun.misc.JavaLangAccess

> Hello,
> 
> a typical patern when reading the stack of the current thread in tooling
> like performance monitoring used to imply the creation of an instance of
> Throwable and to process this instance's attached stack in another thread.
> The performance cost is shared about 10/90 for creating a new throwable
> compared to reading its frames, so this is really a worthy optimization.
> 
> It is also common to use the JavaLangAccess API which offers selective
> access of single frames.
> 
> This API does no longer exist as it was superseeded by the Stack Walker API
> which is of course much safer and even a more performant alternative when
> looking at the total performance. However, using a stack walker, it is no
> longer possible to move the stack processing out of the user thread but it
> must be done at the moment the snapshot of the stack is taken. It turns out
> that this increases latency dramatically when processing stacks compared to
> the asyncronous alternative.
> 
> In a quick benchmark, it seems like walking 35 frames of a 100 frames stack
> allows me 70k operations per second whereas creating a new throwable yields
> about 200k operations per second. Also, within a less isolated test, I can
> infer this additional overhead from the actual latency numbers of a web
> service when using the stack walker API to extract the top 35 frames
> compared to the "old" solution using JavaLangAccess.
> 
> For this reason, it seems to be the best solution to avoid the stack walker
> when aiming for latency at the moment if the stack is not required
> immediately and if access resources are available in other threads.
> 
> I would therefore like to propose to extend the stack walker API to allow
> walking the stack of an existing throwable to allow for similar performance
> as with JavaLangAccess. I understand that the VM must do more work
> altogether. When receving the full stack from a throwable, this takes about
> three times as long. In practice, for a product I am involved in, this
> casues a noticable overhead when running a Java 9 VM compared to Java 8.
> 
> Alternatively, it would of course even be better if one could take a
> snapshot of only the top x frames to walk on this object rather then a
> throwable.
> 
> I have added my benchmarks (snapshot for the current user thread operation,
> complete for the entire processing) into this Gist:
> https://gist.github.com/raphw/96e7c81d7c719cf7991b361bb7266c70
> 
> Thank you for any feedback on my finding!
> 
> Best regards, Rafael

From rafael.wth at gmail.com  Fri Oct 20 14:03:35 2017
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 20 Oct 2017 16:03:35 +0200
Subject: Decreased latency performance with Stack Walker API compared to
 sun.misc.JavaLangAccess
In-Reply-To: <655276083.2146830.1508507697910.JavaMail.zimbra@u-pem.fr>
References: <CA+DM0Am_PpFqhEXme+7MeXrnpiEnFiQmy7Opd7LptBtBc476+g@mail.gmail.com>
 <655276083.2146830.1508507697910.JavaMail.zimbra@u-pem.fr>
Message-ID: <CA+DM0AkHKFTSevf0R=SkRnDVOKa-QiAhBtCPBeo1nwUEQcDiJg@mail.gmail.com>

Hi Remi,
thank you for your quick reply! I just changed the benchmark to use:

stackFrameStream.skip(startFrame).limit(stackDepth).collect(Collectors.toList());

and it yields a small improvement.
Best regards, Rafael

2017-10-20 15:54 GMT+02:00 Remi Forax <forax at univ-mlv.fr>:

> Hi Rafael,
> stream.iterator() is usually super slow*, did you try with toArray() or
> forEach() instead ?
>
> R?mi
> * you want to see a push based API (Stream) as a pull based API (Iterator)
>
> ----- Mail original -----
> > De: "Rafael Winterhalter" <rafael.wth at gmail.com>
> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoy?: Vendredi 20 Octobre 2017 15:32:33
> > Objet: Decreased latency performance with Stack Walker API compared to
> sun.misc.JavaLangAccess
>
> > Hello,
> >
> > a typical patern when reading the stack of the current thread in tooling
> > like performance monitoring used to imply the creation of an instance of
> > Throwable and to process this instance's attached stack in another
> thread.
> > The performance cost is shared about 10/90 for creating a new throwable
> > compared to reading its frames, so this is really a worthy optimization.
> >
> > It is also common to use the JavaLangAccess API which offers selective
> > access of single frames.
> >
> > This API does no longer exist as it was superseeded by the Stack Walker
> API
> > which is of course much safer and even a more performant alternative when
> > looking at the total performance. However, using a stack walker, it is no
> > longer possible to move the stack processing out of the user thread but
> it
> > must be done at the moment the snapshot of the stack is taken. It turns
> out
> > that this increases latency dramatically when processing stacks compared
> to
> > the asyncronous alternative.
> >
> > In a quick benchmark, it seems like walking 35 frames of a 100 frames
> stack
> > allows me 70k operations per second whereas creating a new throwable
> yields
> > about 200k operations per second. Also, within a less isolated test, I
> can
> > infer this additional overhead from the actual latency numbers of a web
> > service when using the stack walker API to extract the top 35 frames
> > compared to the "old" solution using JavaLangAccess.
> >
> > For this reason, it seems to be the best solution to avoid the stack
> walker
> > when aiming for latency at the moment if the stack is not required
> > immediately and if access resources are available in other threads.
> >
> > I would therefore like to propose to extend the stack walker API to allow
> > walking the stack of an existing throwable to allow for similar
> performance
> > as with JavaLangAccess. I understand that the VM must do more work
> > altogether. When receving the full stack from a throwable, this takes
> about
> > three times as long. In practice, for a product I am involved in, this
> > casues a noticable overhead when running a Java 9 VM compared to Java 8.
> >
> > Alternatively, it would of course even be better if one could take a
> > snapshot of only the top x frames to walk on this object rather then a
> > throwable.
> >
> > I have added my benchmarks (snapshot for the current user thread
> operation,
> > complete for the entire processing) into this Gist:
> > https://gist.github.com/raphw/96e7c81d7c719cf7991b361bb7266c70
> >
> > Thank you for any feedback on my finding!
> >
> > Best regards, Rafael
>

From claes.redestad at oracle.com  Fri Oct 20 14:10:31 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 20 Oct 2017 16:10:31 +0200
Subject: RFR: 8189266: (ann) Optimize AnnotationInvocationHandler.invoke
Message-ID: <b2bafb68-b94f-53a9-9445-1646515ba9b9@oracle.com>

Hi,

please review this patch, contributed by Christoph Dreis, to speed up 
AnnotationInvocationHandler.invoke, primarily by avoiding cloning the 
Method parameterTypes array unnecessarily.

Webrev: http://cr.openjdk.java.net/~redestad/8189266/jdk.00/

Bug: https://bugs.openjdk.java.net/browse/JDK-8189266

Thanks!

/Claes


From peter.levart at gmail.com  Fri Oct 20 15:47:51 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 20 Oct 2017 17:47:51 +0200
Subject: RFR: 8189266: (ann) Optimize AnnotationInvocationHandler.invoke
In-Reply-To: <b2bafb68-b94f-53a9-9445-1646515ba9b9@oracle.com>
References: <b2bafb68-b94f-53a9-9445-1646515ba9b9@oracle.com>
Message-ID: <9c9e728b-80de-6f6d-0133-27025b07ae61@gmail.com>

Hi Claes,

This looks good. And can even be backported if desired. If/When 
Christoph's proposal to add Executable.getParameterType(index) gets 
accepted, all getParameterTypes() usages will be fixed at once, 
including this one...

Regards, Peter

On 10/20/2017 04:10 PM, Claes Redestad wrote:
> Hi,
>
> please review this patch, contributed by Christoph Dreis, to speed up 
> AnnotationInvocationHandler.invoke, primarily by avoiding cloning the 
> Method parameterTypes array unnecessarily.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8189266/jdk.00/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189266
>
> Thanks!
>
> /Claes
>


From clement at guillaume.bzh  Thu Oct 19 18:57:12 2017
From: clement at guillaume.bzh (=?UTF-8?Q?Cl=C3=A9ment_Guillaume?=)
Date: Thu, 19 Oct 2017 11:57:12 -0700
Subject: java 9 AKST timezone parsing
In-Reply-To: <b3771125-0d5a-aca1-47e8-7f163c4565f0@oracle.com>
References: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
 <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>
 <CABYWF2o=cfs3-xmzR4dnVC_jHyWXHm+y6DnDQjcKLoqQvfCsGw@mail.gmail.com>
 <b3771125-0d5a-aca1-47e8-7f163c4565f0@oracle.com>
Message-ID: <CABYWF2q5Ho9HiBhGWv_99xH0vPVsxWfOVZps4yccxZ2u-yXKwQ@mail.gmail.com>

I posted it few days ago (and got the id 9051213). I think it's still being
reviewed.

2017-10-11 17:11 GMT-07:00 Naoto Sato <naoto.sato at oracle.com>:

> Yes. Please go ahead and file a bug report. Thanks.
>
> Naoto
>
> On 10/11/17 5:04 PM, Cl?ment Guillaume wrote:
>
>> Hi,
>>
>> I verified that using java.locale.providers=COMPAT with java 9 makes the
>> AKST to be parsed as America/Juneau
>>
>> Is http://bugreport.java.com/ the correct way to file a jira?
>>
>> Le mer. 11 oct. 2017 ? 10:50, Naoto Sato <naoto.sato at oracle.com <mailto:
>> naoto.sato at oracle.com>> a ?crit :
>>
>>     (replying to appropriate aliases, instead of generic jdk9-dev alias)
>>
>>     Hi Cl?ment,
>>
>>     The locale data, where those time zone names are derived from, have
>> been
>>     switched to use Unicode Consortium's CLDR, instead of the ones that
>> are
>>     previously used prior to JDK9. So there will be some differences you
>> may
>>     encounter. However it seems not right to parse "AKST" to SystemV time
>>     zone. I'd appreciate it if you file a JIRA issue for this.
>>
>>     In the mean time, you can revert to the JDK8 behavior by setting the
>>     system property "-Djava.locale.providers=COMPAT" to the command line.
>>
>>     HTH,
>>     Naoto
>>
>>     On 10/10/17 7:37 PM, Cl?ment Guillaume wrote:
>>      > Hello,
>>      >
>>      > When parsing a date time string that contains a time zone like
>>     AKST, AKDT,
>>      > HST or AST with a DateTimeFormatter built from a pattern
>>     containing 'z',
>>      > java 9 returns the SystemV variant of those timezone, which then
>>     behave
>>      > differently as the "modern" ones. Looks like it's also an issue
>>     with long
>>      > time zone ("Alaska Standard Time")
>>      >
>>      >  From my digging I noticed that the PrefixTree generated
>>      > by ZoneTextPrinterParser.getTree is different in java 8 and java
>>     9, and
>>      > this may be caused by a different order in the content returned
>>      > by TimeZoneNameUtility.getZoneStrings(Locale.getDefault())
>>      >
>>      > Is this an expected behavior of java 9? (other american time
>>     zones are
>>      > parsed to the modern version: PST -> America/Los_Angeles)
>>      >
>>      > I tested it with java 9 build 9+181 and java 8 build
>>     1.8.0_131-b11 (both
>>      > linux 64 with en_US as local) on this code:
>>      >
>>      > import java.time.ZoneOffset;
>>      > import java.time.format.DateTimeFormatter;
>>      > import java.time.temporal.TemporalAccessor;
>>      >
>>      > public class Main{
>>      >
>>      > public static void main(String[] args){
>>      > DateTimeFormatter timezoneFormatter =
>>     DateTimeFormatter.ofPattern("z");
>>      > TemporalAccessor temporalAccessor = timezoneFormatter.parse("AKST"
>> );
>>      > System.out.println(temporalAccessor);
>>      > temporalAccessor = timezoneFormatter.parse("AKDT");
>>      > System.out.println(temporalAccessor);
>>      > temporalAccessor = timezoneFormatter.parse("HST");
>>      > System.out.println(temporalAccessor);
>>      > temporalAccessor = timezoneFormatter.parse("AST");
>>      > System.out.println(temporalAccessor);
>>      >
>>      > DateTimeFormatter isoFormatter =
>>      >
>>     DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mmX").withZone(
>> ZoneOffset.UTC);
>>      > temporalAccessor =
>>      >
>>     DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSz").pa
>> rse("2017-09-13T06:30:33.123AKST");
>>      > System.out.println(temporalAccessor);
>>      > System.out.println(isoFormatter.format(temporalAccessor));
>>      > temporalAccessor =
>>      >
>>     DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSVV").p
>> arse("2017-09-13T06:30:33.123America/Anchorage");
>>      > System.out.println(temporalAccessor);
>>      > System.out.println(isoFormatter.format(temporalAccessor));
>>      > }
>>      >
>>      > }
>>      >
>>
>>

From mandy.chung at oracle.com  Fri Oct 20 16:11:20 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 20 Oct 2017 09:11:20 -0700
Subject: Decreased latency performance with Stack Walker API compared to
 sun.misc.JavaLangAccess
In-Reply-To: <CA+DM0Am_PpFqhEXme+7MeXrnpiEnFiQmy7Opd7LptBtBc476+g@mail.gmail.com>
References: <CA+DM0Am_PpFqhEXme+7MeXrnpiEnFiQmy7Opd7LptBtBc476+g@mail.gmail.com>
Message-ID: <dc388d06-732a-4986-42d4-e519c24cc4b5@oracle.com>

Hi Rafael,

Thanks for the feedback.? We did some investigation in understanding the 
overhead of Throwable if it used StackWalker API [1].? It did come to 
mind whether the StackWalker API should provide a way to walk the 
backtrace which we should do the investigation with JDK-8141239.

The benchmark compares capturing 35 StackTraceElements for 
apple-to-apple comparison which is fair.? I am curious on the perf 
difference when you capture only StackFrame objects?? This would save 
the overhead to construct StackTraceElement objects (and its associated 
string objects).

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

On 10/20/17 6:32 AM, Rafael Winterhalter wrote:
> Hello,
>
> a typical patern when reading the stack of the current thread in tooling
> like performance monitoring used to imply the creation of an instance of
> Throwable and to process this instance's attached stack in another thread.
> The performance cost is shared about 10/90 for creating a new throwable
> compared to reading its frames, so this is really a worthy optimization.
>
> It is also common to use the JavaLangAccess API which offers selective
> access of single frames.
>
> This API does no longer exist as it was superseeded by the Stack Walker API
> which is of course much safer and even a more performant alternative when
> looking at the total performance. However, using a stack walker, it is no
> longer possible to move the stack processing out of the user thread but it
> must be done at the moment the snapshot of the stack is taken. It turns out
> that this increases latency dramatically when processing stacks compared to
> the asyncronous alternative.
>
> In a quick benchmark, it seems like walking 35 frames of a 100 frames stack
> allows me 70k operations per second whereas creating a new throwable yields
> about 200k operations per second. Also, within a less isolated test, I can
> infer this additional overhead from the actual latency numbers of a web
> service when using the stack walker API to extract the top 35 frames
> compared to the "old" solution using JavaLangAccess.
>
> For this reason, it seems to be the best solution to avoid the stack walker
> when aiming for latency at the moment if the stack is not required
> immediately and if access resources are available in other threads.
>
> I would therefore like to propose to extend the stack walker API to allow
> walking the stack of an existing throwable to allow for similar performance
> as with JavaLangAccess. I understand that the VM must do more work
> altogether. When receving the full stack from a throwable, this takes about
> three times as long. In practice, for a product I am involved in, this
> casues a noticable overhead when running a Java 9 VM compared to Java 8.
>
> Alternatively, it would of course even be better if one could take a
> snapshot of only the top x frames to walk on this object rather then a
> throwable.
>
> I have added my benchmarks (snapshot for the current user thread operation,
> complete for the entire processing) into this Gist:
> https://gist.github.com/raphw/96e7c81d7c719cf7991b361bb7266c70
>
> Thank you for any feedback on my finding!
>
> Best regards, Rafael


From rafael.wth at gmail.com  Fri Oct 20 17:35:06 2017
From: rafael.wth at gmail.com (Rafael Winterhalter)
Date: Fri, 20 Oct 2017 19:35:06 +0200
Subject: Decreased latency performance with Stack Walker API compared to
 sun.misc.JavaLangAccess
In-Reply-To: <dc388d06-732a-4986-42d4-e519c24cc4b5@oracle.com>
References: <CA+DM0Am_PpFqhEXme+7MeXrnpiEnFiQmy7Opd7LptBtBc476+g@mail.gmail.com>
 <dc388d06-732a-4986-42d4-e519c24cc4b5@oracle.com>
Message-ID: <CA+DM0Am-Vn6o9Exso2vg7FwL6CxDTsOQkNX6A1gF1Ux1FNXs0Q@mail.gmail.com>

Hei Mandy,
thank you for your quick reply.

The benchmark is already only capturing the stack frame object. I ran the
benchmark with the transformation as a comparison and it is indeed slower
due to extra work. The JIT code suggests the native method plus monitor to
be the major cost here but it is of course necessary to have it there to
fetch the stack information.

Without this transformation in the user  thread, capturing stack frame
objects of 100 frames is however still about 2.5 times as expensive as
constructing a throwable as a snapshot.

Just to not be misunderstood: the total cost is reduced by using the stack
walker, even compared to using java lang secrets under Java 8 but the
inability to process the stack outside of a worker thread makes it
inapplicable for my purposes due to latency requirements.

Thank you for considering this use case and all your great work!

Cheers, Rafael


Am 20.10.2017 18:11 schrieb "mandy chung" <mandy.chung at oracle.com>:

Hi Rafael,

Thanks for the feedback.  We did some investigation in understanding the
overhead of Throwable if it used StackWalker API [1].  It did come to mind
whether the StackWalker API should provide a way to walk the backtrace
which we should do the investigation with JDK-8141239.

The benchmark compares capturing 35 StackTraceElements for apple-to-apple
comparison which is fair.  I am curious on the perf difference when you
capture only StackFrame objects?  This would save the overhead to construct
StackTraceElement objects (and its associated string objects).

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


On 10/20/17 6:32 AM, Rafael Winterhalter wrote:

> Hello,
>
> a typical patern when reading the stack of the current thread in tooling
> like performance monitoring used to imply the creation of an instance of
> Throwable and to process this instance's attached stack in another thread.
> The performance cost is shared about 10/90 for creating a new throwable
> compared to reading its frames, so this is really a worthy optimization.
>
> It is also common to use the JavaLangAccess API which offers selective
> access of single frames.
>
> This API does no longer exist as it was superseeded by the Stack Walker API
> which is of course much safer and even a more performant alternative when
> looking at the total performance. However, using a stack walker, it is no
> longer possible to move the stack processing out of the user thread but it
> must be done at the moment the snapshot of the stack is taken. It turns out
> that this increases latency dramatically when processing stacks compared to
> the asyncronous alternative.
>
> In a quick benchmark, it seems like walking 35 frames of a 100 frames stack
> allows me 70k operations per second whereas creating a new throwable yields
> about 200k operations per second. Also, within a less isolated test, I can
> infer this additional overhead from the actual latency numbers of a web
> service when using the stack walker API to extract the top 35 frames
> compared to the "old" solution using JavaLangAccess.
>
> For this reason, it seems to be the best solution to avoid the stack walker
> when aiming for latency at the moment if the stack is not required
> immediately and if access resources are available in other threads.
>
> I would therefore like to propose to extend the stack walker API to allow
> walking the stack of an existing throwable to allow for similar performance
> as with JavaLangAccess. I understand that the VM must do more work
> altogether. When receving the full stack from a throwable, this takes about
> three times as long. In practice, for a product I am involved in, this
> casues a noticable overhead when running a Java 9 VM compared to Java 8.
>
> Alternatively, it would of course even be better if one could take a
> snapshot of only the top x frames to walk on this object rather then a
> throwable.
>
> I have added my benchmarks (snapshot for the current user thread operation,
> complete for the entire processing) into this Gist:
> https://gist.github.com/raphw/96e7c81d7c719cf7991b361bb7266c70
>
> Thank you for any feedback on my finding!
>
> Best regards, Rafael
>

From ralph.goers at dslextreme.com  Fri Oct 20 19:53:04 2017
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Fri, 20 Oct 2017 12:53:04 -0700
Subject: Decreased latency performance with Stack Walker API compared to
 sun.misc.JavaLangAccess
In-Reply-To: <CA+DM0Am-Vn6o9Exso2vg7FwL6CxDTsOQkNX6A1gF1Ux1FNXs0Q@mail.gmail.com>
References: <CA+DM0Am_PpFqhEXme+7MeXrnpiEnFiQmy7Opd7LptBtBc476+g@mail.gmail.com>
 <dc388d06-732a-4986-42d4-e519c24cc4b5@oracle.com>
 <CA+DM0Am-Vn6o9Exso2vg7FwL6CxDTsOQkNX6A1gF1Ux1FNXs0Q@mail.gmail.com>
Message-ID: <E452380E-CEB4-4AB5-A14A-650EFE3D1AFB@dslextreme.com>

This would could also make sense for asynchronous logging with Log4j 2. We currently disabled capturing location information for asynchronous logging as capturing the information before passing the information to the thread doing the logging is fairly expensive. Being able to capture the stack trace and then use StackWalker to walk it in another thread would be very useful.

Ralph

> On Oct 20, 2017, at 10:35 AM, Rafael Winterhalter <rafael.wth at gmail.com> wrote:
> 
> Hei Mandy,
> thank you for your quick reply.
> 
> The benchmark is already only capturing the stack frame object. I ran the
> benchmark with the transformation as a comparison and it is indeed slower
> due to extra work. The JIT code suggests the native method plus monitor to
> be the major cost here but it is of course necessary to have it there to
> fetch the stack information.
> 
> Without this transformation in the user  thread, capturing stack frame
> objects of 100 frames is however still about 2.5 times as expensive as
> constructing a throwable as a snapshot.
> 
> Just to not be misunderstood: the total cost is reduced by using the stack
> walker, even compared to using java lang secrets under Java 8 but the
> inability to process the stack outside of a worker thread makes it
> inapplicable for my purposes due to latency requirements.
> 
> Thank you for considering this use case and all your great work!
> 
> Cheers, Rafael
> 
> 
> Am 20.10.2017 18:11 schrieb "mandy chung" <mandy.chung at oracle.com>:
> 
> Hi Rafael,
> 
> Thanks for the feedback.  We did some investigation in understanding the
> overhead of Throwable if it used StackWalker API [1].  It did come to mind
> whether the StackWalker API should provide a way to walk the backtrace
> which we should do the investigation with JDK-8141239.
> 
> The benchmark compares capturing 35 StackTraceElements for apple-to-apple
> comparison which is fair.  I am curious on the perf difference when you
> capture only StackFrame objects?  This would save the overhead to construct
> StackTraceElement objects (and its associated string objects).
> 
> Mandy
> [1] https://bugs.openjdk.java.net/browse/JDK-8141239
> 
> 
> On 10/20/17 6:32 AM, Rafael Winterhalter wrote:
> 
>> Hello,
>> 
>> a typical patern when reading the stack of the current thread in tooling
>> like performance monitoring used to imply the creation of an instance of
>> Throwable and to process this instance's attached stack in another thread.
>> The performance cost is shared about 10/90 for creating a new throwable
>> compared to reading its frames, so this is really a worthy optimization.
>> 
>> It is also common to use the JavaLangAccess API which offers selective
>> access of single frames.
>> 
>> This API does no longer exist as it was superseeded by the Stack Walker API
>> which is of course much safer and even a more performant alternative when
>> looking at the total performance. However, using a stack walker, it is no
>> longer possible to move the stack processing out of the user thread but it
>> must be done at the moment the snapshot of the stack is taken. It turns out
>> that this increases latency dramatically when processing stacks compared to
>> the asyncronous alternative.
>> 
>> In a quick benchmark, it seems like walking 35 frames of a 100 frames stack
>> allows me 70k operations per second whereas creating a new throwable yields
>> about 200k operations per second. Also, within a less isolated test, I can
>> infer this additional overhead from the actual latency numbers of a web
>> service when using the stack walker API to extract the top 35 frames
>> compared to the "old" solution using JavaLangAccess.
>> 
>> For this reason, it seems to be the best solution to avoid the stack walker
>> when aiming for latency at the moment if the stack is not required
>> immediately and if access resources are available in other threads.
>> 
>> I would therefore like to propose to extend the stack walker API to allow
>> walking the stack of an existing throwable to allow for similar performance
>> as with JavaLangAccess. I understand that the VM must do more work
>> altogether. When receving the full stack from a throwable, this takes about
>> three times as long. In practice, for a product I am involved in, this
>> casues a noticable overhead when running a Java 9 VM compared to Java 8.
>> 
>> Alternatively, it would of course even be better if one could take a
>> snapshot of only the top x frames to walk on this object rather then a
>> throwable.
>> 
>> I have added my benchmarks (snapshot for the current user thread operation,
>> complete for the entire processing) into this Gist:
>> https://gist.github.com/raphw/96e7c81d7c719cf7991b361bb7266c70
>> 
>> Thank you for any feedback on my finding!
>> 
>> Best regards, Rafael
>> 
> 



From mandy.chung at oracle.com  Fri Oct 20 20:18:34 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 20 Oct 2017 13:18:34 -0700
Subject: Decreased latency performance with Stack Walker API compared to
 sun.misc.JavaLangAccess
In-Reply-To: <CA+DM0Am-Vn6o9Exso2vg7FwL6CxDTsOQkNX6A1gF1Ux1FNXs0Q@mail.gmail.com>
References: <CA+DM0Am_PpFqhEXme+7MeXrnpiEnFiQmy7Opd7LptBtBc476+g@mail.gmail.com>
 <dc388d06-732a-4986-42d4-e519c24cc4b5@oracle.com>
 <CA+DM0Am-Vn6o9Exso2vg7FwL6CxDTsOQkNX6A1gF1Ux1FNXs0Q@mail.gmail.com>
Message-ID: <288f2163-15c6-ebe6-52cd-642ab2ae20cb@oracle.com>

I created https://bugs.openjdk.java.net/browse/JDK-8189752 to track this.

Mandy

On 10/20/17 10:35 AM, Rafael Winterhalter wrote:
> Hei Mandy,
> thank you for your quick reply.
>
> The benchmark is already only capturing the stack frame object. I ran 
> the benchmark with the transformation as a comparison and it is indeed 
> slower due to extra work. The JIT code suggests the native method plus 
> monitor to be the major cost here but it is of course necessary to 
> have it there to fetch the stack information.
>
> Without this transformation in the user? thread, capturing stack frame 
> objects of 100 frames is however still about 2.5 times as expensive as 
> constructing a throwable as a snapshot.
>
> Just to not be misunderstood: the total cost is reduced by using the 
> stack walker, even compared to using java lang secrets under Java 8 
> but the inability to process the stack outside of a worker thread 
> makes it inapplicable for my purposes due to latency requirements.
>
> Thank you for considering this use case and all your great work!
>
> Cheers, Rafael
>
>
> Am 20.10.2017 18:11 schrieb "mandy chung" <mandy.chung at oracle.com 
> <mailto:mandy.chung at oracle.com>>:
>
>     Hi Rafael,
>
>     Thanks for the feedback.? We did some investigation in
>     understanding the overhead of Throwable if it used StackWalker API
>     [1].? It did come to mind whether the StackWalker API should
>     provide a way to walk the backtrace which we should do the
>     investigation with JDK-8141239.
>
>     The benchmark compares capturing 35 StackTraceElements for
>     apple-to-apple comparison which is fair.? I am curious on the perf
>     difference when you capture only StackFrame objects?? This would
>     save the overhead to construct StackTraceElement objects (and its
>     associated string objects).
>
>     Mandy
>     [1] https://bugs.openjdk.java.net/browse/JDK-8141239
>     <https://bugs.openjdk.java.net/browse/JDK-8141239>
>
>
>     On 10/20/17 6:32 AM, Rafael Winterhalter wrote:
>
>         Hello,
>
>         a typical patern when reading the stack of the current thread
>         in tooling
>         like performance monitoring used to imply the creation of an
>         instance of
>         Throwable and to process this instance's attached stack in
>         another thread.
>         The performance cost is shared about 10/90 for creating a new
>         throwable
>         compared to reading its frames, so this is really a worthy
>         optimization.
>
>         It is also common to use the JavaLangAccess API which offers
>         selective
>         access of single frames.
>
>         This API does no longer exist as it was superseeded by the
>         Stack Walker API
>         which is of course much safer and even a more performant
>         alternative when
>         looking at the total performance. However, using a stack
>         walker, it is no
>         longer possible to move the stack processing out of the user
>         thread but it
>         must be done at the moment the snapshot of the stack is taken.
>         It turns out
>         that this increases latency dramatically when processing
>         stacks compared to
>         the asyncronous alternative.
>
>         In a quick benchmark, it seems like walking 35 frames of a 100
>         frames stack
>         allows me 70k operations per second whereas creating a new
>         throwable yields
>         about 200k operations per second. Also, within a less isolated
>         test, I can
>         infer this additional overhead from the actual latency numbers
>         of a web
>         service when using the stack walker API to extract the top 35
>         frames
>         compared to the "old" solution using JavaLangAccess.
>
>         For this reason, it seems to be the best solution to avoid the
>         stack walker
>         when aiming for latency at the moment if the stack is not required
>         immediately and if access resources are available in other
>         threads.
>
>         I would therefore like to propose to extend the stack walker
>         API to allow
>         walking the stack of an existing throwable to allow for
>         similar performance
>         as with JavaLangAccess. I understand that the VM must do more work
>         altogether. When receving the full stack from a throwable,
>         this takes about
>         three times as long. In practice, for a product I am involved
>         in, this
>         casues a noticable overhead when running a Java 9 VM compared
>         to Java 8.
>
>         Alternatively, it would of course even be better if one could
>         take a
>         snapshot of only the top x frames to walk on this object
>         rather then a
>         throwable.
>
>         I have added my benchmarks (snapshot for the current user
>         thread operation,
>         complete for the entire processing) into this Gist:
>         https://gist.github.com/raphw/96e7c81d7c719cf7991b361bb7266c70
>         <https://gist.github.com/raphw/96e7c81d7c719cf7991b361bb7266c70>
>
>         Thank you for any feedback on my finding!
>
>         Best regards, Rafael
>
>
>


From naoto.sato at oracle.com  Fri Oct 20 21:20:57 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 20 Oct 2017 14:20:57 -0700
Subject: [10] RFR: 8189272 & 8189291
Message-ID: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>

Hello,

Please review the changes for the following two issues:

8189272: CLDR and JRE LocaleProviderAdapters silently swallow exceptions [1]
8189291: Test policy should extend the default system policy [2]

The proposed fixes for the above issues are located below, respectively:

http://cr.openjdk.java.net/~naoto/8189272/webrev.00/
http://cr.openjdk.java.net/~naoto/8189291/webrev.00/

The fix to 8189272 will throw exceptions that were swallowed in those 
providers, which should not happen in proper environment. That fix makes 
test cases with security manager fail. The fix to 8189291 addresses it.

Naoto

[1] https://bugs.openjdk.java.net/browse/JDK-8189272
[2] https://bugs.openjdk.java.net/browse/JDK-8189291

From mandy.chung at oracle.com  Fri Oct 20 21:45:38 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 20 Oct 2017 14:45:38 -0700
Subject: [10] RFR: 8189272 & 8189291
In-Reply-To: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>
References: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>
Message-ID: <0a8bc81d-694e-aa8d-8530-e21f890b3507@oracle.com>



On 10/20/17 2:20 PM, Naoto Sato wrote:
> Hello,
>
> Please review the changes for the following two issues:
>
> 8189272: CLDR and JRE LocaleProviderAdapters silently swallow 
> exceptions [1]
> 8189291: Test policy should extend the default system policy [2]
>
> The proposed fixes for the above issues are located below, respectively:
>
> http://cr.openjdk.java.net/~naoto/8189272/webrev.00/

Looks fine.? The installed providers are our implementation and silently 
ignore any exception would make it really hard to diagnose problems.?? 
This change will help the diagnosability.

> http://cr.openjdk.java.net/~naoto/8189291/webrev.00/
>

If the default policy is not cached early before any test policy is 
constructed, the test might get the wrong Policy object set by the test 
previously (for example, if it runs in agentvm mode).?? It would be more 
reliable if this is cached as the static field in the test class (i.e. 
the enclosing class of the policy subclass) - like CallerSensitiveTest.

test/jdk/sun/util/locale/provider/Bug8038436.java
- I think the test fix should be part of JDK-8189272, right?

Mandy
> The fix to 8189272 will throw exceptions that were swallowed in those 
> providers, which should not happen in proper environment. That fix 
> makes test cases with security manager fail. The fix to 8189291 
> addresses it.
>
> Naoto
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8189272
> [2] https://bugs.openjdk.java.net/browse/JDK-8189291


From naoto.sato at oracle.com  Sat Oct 21 00:05:17 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 20 Oct 2017 17:05:17 -0700
Subject: [10] RFR: 8189272 & 8189291
In-Reply-To: <0a8bc81d-694e-aa8d-8530-e21f890b3507@oracle.com>
References: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>
 <0a8bc81d-694e-aa8d-8530-e21f890b3507@oracle.com>
Message-ID: <6d9c21d5-4baa-89b7-28be-519e70f88f10@oracle.com>

Hi Mandy,

Thanks for the review. Webrevs updated as suggested:

http://cr.openjdk.java.net/~naoto/8189272/webrev.01/
http://cr.openjdk.java.net/~naoto/8189291/webrev.01/

Naoto

On 10/20/17 2:45 PM, mandy chung wrote:
> 
> 
> On 10/20/17 2:20 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes for the following two issues:
>>
>> 8189272: CLDR and JRE LocaleProviderAdapters silently swallow 
>> exceptions [1]
>> 8189291: Test policy should extend the default system policy [2]
>>
>> The proposed fixes for the above issues are located below, respectively:
>>
>> http://cr.openjdk.java.net/~naoto/8189272/webrev.00/
> 
> Looks fine.? The installed providers are our implementation and silently 
> ignore any exception would make it really hard to diagnose problems. 
> This change will help the diagnosability.
> 
>> http://cr.openjdk.java.net/~naoto/8189291/webrev.00/
>>
> 
> If the default policy is not cached early before any test policy is 
> constructed, the test might get the wrong Policy object set by the test 
> previously (for example, if it runs in agentvm mode).?? It would be more 
> reliable if this is cached as the static field in the test class (i.e. 
> the enclosing class of the policy subclass) - like CallerSensitiveTest.
> 
> test/jdk/sun/util/locale/provider/Bug8038436.java
> - I think the test fix should be part of JDK-8189272, right?
> 
> Mandy
>> The fix to 8189272 will throw exceptions that were swallowed in those 
>> providers, which should not happen in proper environment. That fix 
>> makes test cases with security manager fail. The fix to 8189291 
>> addresses it.
>>
>> Naoto
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8189272
>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291
> 

From dl at cs.oswego.edu  Sun Oct 22 22:30:45 2017
From: dl at cs.oswego.edu (Doug Lea)
Date: Sun, 22 Oct 2017 18:30:45 -0400
Subject: AVL tree implemented in the style of TreeMap for better
 performance
In-Reply-To: <CAN-rbk0M0Y=c_qm_2f-ffbjaKrr80G85E5-HPn0V9T-oxkVp7g@mail.gmail.com>
References: <CAN-rbk0M0Y=c_qm_2f-ffbjaKrr80G85E5-HPn0V9T-oxkVp7g@mail.gmail.com>
Message-ID: <9db95425-4eb3-a28e-216b-64314e5621a1@cs.oswego.edu>

On 10/18/2017 06:35 PM, David McManamon wrote:
> 
> https://github.com/dmcmanam/bbst-showdown
> 
> Although an old topic, it may be worth another look in Java since AVL trees
> do much better in some circumstances.

(And possibly worse in others.) As you note on the above page,
it may be the case that circumstances favoring AVLs are more common
now than back when TreeMap was first introduced.
But it will take some effort to investigate this.
A few microbenchmarks are unlikely to be helpful for a class used in
so many ways across applications.

The best strategy would be to measure across one of the
performance-based program suite corpuses.
A new one (that I don't know much about) is Xcorpus
   https://bitbucket.org/jensdietrich/xcorpus
Others include DaCapo
  http://www.dacapobench.org/

-Doug



From martinrb at google.com  Mon Oct 23 00:38:14 2017
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 22 Oct 2017 17:38:14 -0700
Subject: AVL tree implemented in the style of TreeMap for better
 performance
In-Reply-To: <CAN-rbk0M0Y=c_qm_2f-ffbjaKrr80G85E5-HPn0V9T-oxkVp7g@mail.gmail.com>
References: <CAN-rbk0M0Y=c_qm_2f-ffbjaKrr80G85E5-HPn0V9T-oxkVp7g@mail.gmail.com>
Message-ID: <CA+kOe08kwLDjve0nxd5NNqpdWsd4RV1ae_zM9hWGowsU_wE=gA@mail.gmail.com>

Another thing to keep in mind is that someday Java might have value types,
which will make "inline objects" possible, which will make us reconsider
all the data structure implementations.

On Wed, Oct 18, 2017 at 3:35 PM, David McManamon <dmcmanam at gmail.com> wrote:

> If the BBST performance numbers from Ben Pfaff's c language research in
> 2004
> https://benpfaff.org/papers/libavl.pdf
> are correct then it seems the red-black tree implementations that are so
> popular in the JDK might be worth another look.  However, when I surveyed
> the AVL implementations in the Java world I didn't find the variety I was
> looking for - specifically an implementation similar to that of the
> red-black TreeMap (parent pointers, no recursion), so I wrote insert &
> delete in TreeMapAVL here:
>
> https://github.com/dmcmanam/bbst-showdown
>
> Although an old topic, it may be worth another look in Java since AVL trees
> do much better in some circumstances.
>
> Next week I'll write a WAVL implementation and expand the performance
> testing comparison which so far looks like this:
>
> Results for inserting 262143 random integers (height 18 for a complete BST)
> -
>
>   Mean insertion time: 171ms and 169ms, runs to converge:2. AVL tree of
> size: 262126, height: 21, rotations 183194
>
>   Mean insertion time: 165ms and 169ms, runs to converge:2. Red-black tree
> of size: 262126, height: 22, rotations 152622
>
>   Mean insertion time: 170ms and 167ms, runs to converge:1. BST          of
> size: 262126, height: 46, rotations 0
>
>   Time to copy a red-black tree (sorted insertion via recursion): 44ms.
> Red-black tree of size: 262126, height: 18, rotations 0
>
> Results for inserting integer clusters in sequences of 12 and total size:
> 262143 -
>
>   Mean insertion time: 63ms and 62ms, runs to converge:3. AVL tree of size:
> 262125, height: 21, rotations 325176
>
>   Mean insertion time: 70ms and 72ms, runs to converge:2. Red-black tree of
> size: 262125, height: 24, rotations 320990
>
> --David
>

From forax at univ-mlv.fr  Mon Oct 23 06:22:03 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 23 Oct 2017 08:22:03 +0200 (CEST)
Subject: AVL tree implemented in the style of TreeMap for better
 performance
In-Reply-To: <CA+kOe08kwLDjve0nxd5NNqpdWsd4RV1ae_zM9hWGowsU_wE=gA@mail.gmail.com>
References: <CAN-rbk0M0Y=c_qm_2f-ffbjaKrr80G85E5-HPn0V9T-oxkVp7g@mail.gmail.com>
 <CA+kOe08kwLDjve0nxd5NNqpdWsd4RV1ae_zM9hWGowsU_wE=gA@mail.gmail.com>
Message-ID: <741101564.27817.1508739723328.JavaMail.zimbra@u-pem.fr>

<shameless plug>

You can play with value types now !
in the valhalla repository, there is a mvt branch (for minimum value type) that add the support of value type in the VM
then you can use the valuetypifier [1] that takes a 1.8 compatible bytecode and transform every usages of the classes annotated with the annotation jdk.incubator.mvt.ValueCapableClass to make it act as a value type.

Here is an example of hastable using value types
  https://github.com/forax/valuetypify/blob/master/src/test/java/fr/umlv/valuetypify/test/Hash.java

R?mi  

[1] https://github.com/forax/valuetypify

----- Mail original -----
> De: "Martin Buchholz" <martinrb at google.com>
> ?: "David McManamon" <dmcmanam at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 23 Octobre 2017 02:38:14
> Objet: Re: AVL tree implemented in the style of TreeMap for better performance

> Another thing to keep in mind is that someday Java might have value types,
> which will make "inline objects" possible, which will make us reconsider
> all the data structure implementations.
> 
> On Wed, Oct 18, 2017 at 3:35 PM, David McManamon <dmcmanam at gmail.com> wrote:
> 
>> If the BBST performance numbers from Ben Pfaff's c language research in
>> 2004
>> https://benpfaff.org/papers/libavl.pdf
>> are correct then it seems the red-black tree implementations that are so
>> popular in the JDK might be worth another look.  However, when I surveyed
>> the AVL implementations in the Java world I didn't find the variety I was
>> looking for - specifically an implementation similar to that of the
>> red-black TreeMap (parent pointers, no recursion), so I wrote insert &
>> delete in TreeMapAVL here:
>>
>> https://github.com/dmcmanam/bbst-showdown
>>
>> Although an old topic, it may be worth another look in Java since AVL trees
>> do much better in some circumstances.
>>
>> Next week I'll write a WAVL implementation and expand the performance
>> testing comparison which so far looks like this:
>>
>> Results for inserting 262143 random integers (height 18 for a complete BST)
>> -
>>
>>   Mean insertion time: 171ms and 169ms, runs to converge:2. AVL tree of
>> size: 262126, height: 21, rotations 183194
>>
>>   Mean insertion time: 165ms and 169ms, runs to converge:2. Red-black tree
>> of size: 262126, height: 22, rotations 152622
>>
>>   Mean insertion time: 170ms and 167ms, runs to converge:1. BST          of
>> size: 262126, height: 46, rotations 0
>>
>>   Time to copy a red-black tree (sorted insertion via recursion): 44ms.
>> Red-black tree of size: 262126, height: 18, rotations 0
>>
>> Results for inserting integer clusters in sequences of 12 and total size:
>> 262143 -
>>
>>   Mean insertion time: 63ms and 62ms, runs to converge:3. AVL tree of size:
>> 262125, height: 21, rotations 325176
>>
>>   Mean insertion time: 70ms and 72ms, runs to converge:2. Red-black tree of
>> size: 262125, height: 24, rotations 320990
>>
>> --David

From christoph.dreis at freenet.de  Mon Oct 23 11:06:03 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Mon, 23 Oct 2017 13:06:03 +0200
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <b8a2aa2e-2965-961d-887a-88775e4f6454@oracle.com>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <b8a2aa2e-2965-961d-887a-88775e4f6454@oracle.com>
Message-ID: <005301d34bee$eb02df50$c1089df0$@freenet.de>

Hey Claes,

thank you for your comments on my proposal.

> >      public Class<?> getParameterType(int index) {
> >          if (index < 0 || index > getParameterCount()) {
> >              throw new IndexOutOfBoundsException("No parameter found
> > on index " + index);
> >          }
> 
> I don't think we need the explicit range check here.

I thought about that, but decided against the specific ArrayIndexOutOfBoundsException which would be thrown if we omit the explicit check. My reasoning behind that was that the API should not expose the fact that it's working with an array underneath. I have no strong feelings against your comment, though. I'd be fine with both solutions.

> All in all I think it can pull its weight by allowing us to reduce JDK internal use
> of getParameterTypes() alone, thus I'm in favor and can volunteer to sponsor
> (this will need a CSR etc..)

Anything I can do to help?

Cheers,
Christoph 


From christoph.dreis at freenet.de  Mon Oct 23 11:30:51 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Mon, 23 Oct 2017 13:30:51 +0200
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <005301d34bee$eb02df50$c1089df0$@freenet.de>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <b8a2aa2e-2965-961d-887a-88775e4f6454@oracle.com>
 <005301d34bee$eb02df50$c1089df0$@freenet.de>
Message-ID: <005401d34bf2$61c6be60$25543b20$@freenet.de>

Hey,

> > >      public Class<?> getParameterType(int index) {
> > >          if (index < 0 || index > getParameterCount()) {
> > >              throw new IndexOutOfBoundsException("No parameter found 
> > > on index " + index);
> > >          }

> > I don't think we need the explicit range check here.

> I thought about that, but decided against the specific
> ArrayIndexOutOfBoundsException which would be thrown if we omit the
> explicit check. My reasoning behind that was that the API should not expose
> the fact that it's working with an array underneath. I have no strong feelings
> against your comment, though. I'd be fine with both solutions.

On a second thought, people might expect the ArrayIndexOutOfBoundsException.

And it would behave the same way as getParameterTypes()[index] does currently. So I'd probably in favor of omitting it as you suggested.

Cheers,
Christoph 


From claes.redestad at oracle.com  Mon Oct 23 11:39:06 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Mon, 23 Oct 2017 13:39:06 +0200
Subject: [PROPOSAL][JDK10] Introduce Executable.getParameterType(index)
In-Reply-To: <005401d34bf2$61c6be60$25543b20$@freenet.de>
References: <003b01d34998$fafb5bb0$f0f21310$@freenet.de>
 <b8a2aa2e-2965-961d-887a-88775e4f6454@oracle.com>
 <005301d34bee$eb02df50$c1089df0$@freenet.de>
 <005401d34bf2$61c6be60$25543b20$@freenet.de>
Message-ID: <09018a81-a4ea-7c74-d1be-20de2482194b@oracle.com>


On 2017-10-23 13:30, Christoph Dreis wrote:
>>> I don't think we need the explicit range check here.
>> I thought about that, but decided against the specific
>> ArrayIndexOutOfBoundsException which would be thrown if we omit the
>> explicit check. My reasoning behind that was that the API should not expose
>> the fact that it's working with an array underneath. I have no strong feelings
>> against your comment, though. I'd be fine with both solutions.
> On a second thought, people might expect the ArrayIndexOutOfBoundsException.
>
> And it would behave the same way as getParameterTypes()[index] does currently. So I'd probably in favor of omitting it as you suggested.

Ok.? Specifying the thrown error as IOOBE and not AIOOBE may be fine, 
though.

/Claes


From naoto.sato at oracle.com  Mon Oct 23 17:56:07 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 23 Oct 2017 10:56:07 -0700
Subject: java 9 AKST timezone parsing
In-Reply-To: <CABYWF2q5Ho9HiBhGWv_99xH0vPVsxWfOVZps4yccxZ2u-yXKwQ@mail.gmail.com>
References: <CABYWF2o1a45GwuZOQr7CsXqLvT4fswmbAgvg0AZ_DnyP52dVqQ@mail.gmail.com>
 <79f380e2-d524-7288-dd8b-53e843abec9a@oracle.com>
 <CABYWF2o=cfs3-xmzR4dnVC_jHyWXHm+y6DnDQjcKLoqQvfCsGw@mail.gmail.com>
 <b3771125-0d5a-aca1-47e8-7f163c4565f0@oracle.com>
 <CABYWF2q5Ho9HiBhGWv_99xH0vPVsxWfOVZps4yccxZ2u-yXKwQ@mail.gmail.com>
Message-ID: <20a9edcc-11db-0111-cbab-f384b1ce98d4@oracle.com>

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

Naoto

On 10/19/17 11:57 AM, Cl?ment Guillaume wrote:
> I posted it few days ago (and got the id 9051213). I think it's still 
> being reviewed.
> 
> 2017-10-11 17:11 GMT-07:00 Naoto Sato <naoto.sato at oracle.com 
> <mailto:naoto.sato at oracle.com>>:
> 
>     Yes. Please go ahead and file a bug report. Thanks.
> 
>     Naoto
> 
>     On 10/11/17 5:04 PM, Cl?ment Guillaume wrote:
> 
>         Hi,
> 
>         I verified that using java.locale.providers=COMPAT with java 9
>         makes the AKST to be parsed as?America/Juneau
> 
>         Is http://bugreport.java.com/?the correct way to file a jira?
> 
>         Le?mer. 11 oct. 2017 ??10:50, Naoto Sato <naoto.sato at oracle.com
>         <mailto:naoto.sato at oracle.com> <mailto:naoto.sato at oracle.com
>         <mailto:naoto.sato at oracle.com>>> a ?crit?:
> 
>          ? ? (replying to appropriate aliases, instead of generic
>         jdk9-dev alias)
> 
>          ? ? Hi Cl?ment,
> 
>          ? ? The locale data, where those time zone names are derived
>         from, have been
>          ? ? switched to use Unicode Consortium's CLDR, instead of the
>         ones that are
>          ? ? previously used prior to JDK9. So there will be some
>         differences you may
>          ? ? encounter. However it seems not right to parse "AKST" to
>         SystemV time
>          ? ? zone. I'd appreciate it if you file a JIRA issue for this.
> 
>          ? ? In the mean time, you can revert to the JDK8 behavior by
>         setting the
>          ? ? system property "-Djava.locale.providers=COMPAT" to the
>         command line.
> 
>          ? ? HTH,
>          ? ? Naoto
> 
>          ? ? On 10/10/17 7:37 PM, Cl?ment Guillaume wrote:
>          ? ? ?> Hello,
>          ? ? ?>
>          ? ? ?> When parsing a date time string that contains a time
>         zone like
>          ? ? AKST, AKDT,
>          ? ? ?> HST or AST with a DateTimeFormatter built from a pattern
>          ? ? containing 'z',
>          ? ? ?> java 9 returns the SystemV variant of those timezone,
>         which then
>          ? ? behave
>          ? ? ?> differently as the "modern" ones. Looks like it's also
>         an issue
>          ? ? with long
>          ? ? ?> time zone ("Alaska Standard Time")
>          ? ? ?>
>          ? ? ?>? From my digging I noticed that the PrefixTree generated
>          ? ? ?> by ZoneTextPrinterParser.getTree is different in java 8
>         and java
>          ? ? 9, and
>          ? ? ?> this may be caused by a different order in the content
>         returned
>          ? ? ?> by TimeZoneNameUtility.getZoneStrings(Locale.getDefault())
>          ? ? ?>
>          ? ? ?> Is this an expected behavior of java 9? (other american time
>          ? ? zones are
>          ? ? ?> parsed to the modern version: PST -> America/Los_Angeles)
>          ? ? ?>
>          ? ? ?> I tested it with java 9 build 9+181 and java 8 build
>          ? ? 1.8.0_131-b11 (both
>          ? ? ?> linux 64 with en_US as local) on this code:
>          ? ? ?>
>          ? ? ?> import java.time.ZoneOffset;
>          ? ? ?> import java.time.format.DateTimeFormatter;
>          ? ? ?> import java.time.temporal.TemporalAccessor;
>          ? ? ?>
>          ? ? ?> public class Main{
>          ? ? ?>
>          ? ? ?> public static void main(String[] args){
>          ? ? ?> DateTimeFormatter timezoneFormatter =
>          ? ? DateTimeFormatter.ofPattern("z");
>          ? ? ?> TemporalAccessor temporalAccessor =
>         timezoneFormatter.parse("AKST");
>          ? ? ?> System.out.println(temporalAccessor);
>          ? ? ?> temporalAccessor = timezoneFormatter.parse("AKDT");
>          ? ? ?> System.out.println(temporalAccessor);
>          ? ? ?> temporalAccessor = timezoneFormatter.parse("HST");
>          ? ? ?> System.out.println(temporalAccessor);
>          ? ? ?> temporalAccessor = timezoneFormatter.parse("AST");
>          ? ? ?> System.out.println(temporalAccessor);
>          ? ? ?>
>          ? ? ?> DateTimeFormatter isoFormatter =
>          ? ? ?>
>             
>         DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mmX").withZone(ZoneOffset.UTC);
>          ? ? ?> temporalAccessor =
>          ? ? ?>
>             
>         DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSz").parse("2017-09-13T06:30:33.123AKST");
>          ? ? ?> System.out.println(temporalAccessor);
>          ? ? ?> System.out.println(isoFormatter.format(temporalAccessor));
>          ? ? ?> temporalAccessor =
>          ? ? ?>
>             
>         DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSVV").parse("2017-09-13T06:30:33.123America/Anchorage");
>          ? ? ?> System.out.println(temporalAccessor);
>          ? ? ?> System.out.println(isoFormatter.format(temporalAccessor));
>          ? ? ?> }
>          ? ? ?>
>          ? ? ?> }
>          ? ? ?>
> 
> 

From martinrb at google.com  Mon Oct 23 20:34:51 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 23 Oct 2017 13:34:51 -0700
Subject: tzdata2017c is out
Message-ID: <CA+kOe0_DybcdO4-LGmESMcYevNK8psBQZfAYiRoD3h_8hZ6sXg@mail.gmail.com>

tzdata2017c came out today, and the elves at Google are working hard to
incorporate changes in hours or days instead of weeks or quarters.  One
thing we noticed is that one of the java.time tck tests was broken by
tzdata rewrite of history.  Here's the fix we're applying (s/1879/1892/g):

@@ -941,21 +941,21 @@
     }

     public void
test_Apia_jumpForwardOverInternationalDateLine_P12_to_M12() {
-        // transition occurred at 1879-07-04T00:00+12:33:04
+        // transition occurred at 1892-07-04T00:00+12:33:04
         ZoneRules test = pacificApia();
-        Instant instantBefore = LocalDate.of(1879, 7,
2).atStartOfDay(ZoneOffset.UTC).toInstant();
+        Instant instantBefore = LocalDate.of(1892, 7,
2).atStartOfDay(ZoneOffset.UTC).toInstant();
         ZoneOffsetTransition trans = test.nextTransition(instantBefore);
-        assertEquals(trans.getDateTimeBefore(), LocalDateTime.of(1879, 7,
5, 0, 0));
-        assertEquals(trans.getDateTimeAfter(), LocalDateTime.of(1879, 7,
4, 0, 0));
+        assertEquals(trans.getDateTimeBefore(), LocalDateTime.of(1892, 7,
5, 0, 0));
+        assertEquals(trans.getDateTimeAfter(), LocalDateTime.of(1892, 7,
4, 0, 0));
         assertEquals(trans.isGap(), false);
         assertEquals(trans.isOverlap(), true);

 assertEquals(trans.isValidOffset(ZoneOffset.ofHoursMinutesSeconds(+12, 33,
4)), true);

 assertEquals(trans.isValidOffset(ZoneOffset.ofHoursMinutesSeconds(-11,
-26, -56)), true);
         assertEquals(trans.getDuration(), Duration.ofHours(-24));
-        assertEquals(trans.getInstant(), LocalDateTime.of(1879, 7, 4, 0,
0).toInstant(ZoneOffset.ofHoursMinutesSeconds(-11, -26, -56)));
+        assertEquals(trans.getInstant(), LocalDateTime.of(1892, 7, 4, 0,
0).toInstant(ZoneOffset.ofHoursMinutesSeconds(-11, -26, -56)));

-        ZonedDateTime zdt = ZonedDateTime.of(1879, 7, 4, 23, 0, 0, 0,
ZoneId.of("Pacific/Apia"));
-        assertEquals(zdt.plusHours(2).toLocalDateTime(),
LocalDateTime.of(1879, 7, 4, 1, 0, 0));
+        ZonedDateTime zdt = ZonedDateTime.of(1892, 7, 4, 23, 0, 0, 0,
ZoneId.of("Pacific/Apia"));
+        assertEquals(zdt.plusHours(2).toLocalDateTime(),
LocalDateTime.of(1892, 7, 4, 1, 0, 0));
     }


 //-------------------------------------------------------------------------

From peter.levart at gmail.com  Mon Oct 23 20:47:26 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 23 Oct 2017 22:47:26 +0200
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <OFA0D9E522.56232230-ON492581BC.003EF1D9-492581BC.0040E6BF@notes.na.collabserv.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
 <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
 <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
 <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>
 <1238393b-0d7f-9fea-eb75-3fd816c951a5@gmail.com>
 <OFA0D9E522.56232230-ON492581BC.003EF1D9-492581BC.0040E6BF@notes.na.collabserv.com>
Message-ID: <e2b5c5bf-1622-65bb-29d0-310f3b185529@gmail.com>

Hi Ogata,

Sorry for late reply. You are absolutely right. Good catch! I missed 
this scenario. The criteria for placing the mark (current Thread) on a 
cachedLoader must include the check that validates previous value for 
later restoration which uses the same criteria. Only in such case will 
one thread never restore something that has not been placed by it. And 
this guarantees that consumed OIS will never retain a reference to any 
ClassLoader or Thread. Your webrev.03 looks good to me.

Regards, Peter

On 10/17/17 13:48, Kazunori Ogata wrote:
> Hi Peter,
>
> Thank you for your comments and the fix.  It's a good idea to mark
> cachedLoader with the Thread object.
>
>
> I think we need to check the marking thread of cachedLoader before
> updating it.  Otherwise, there is a scenario that can leak a CachedLoader
> object:
>
> //1. Thread-A enters readObject() and then call resolveClass()
> outerCL-A <- null
> cachedLoader <- Thread-A
> cachedLoader <- CachedLoader-A
>
> //2. Thread-B enters readObject() and then call resolveClass()
> outerCL-B <- CachedLoader-A
> cachedLoader <- Thread-B
> cachedLoader <- CachedLoader-B1
>
> //3. Thread-B returns from readObject()
> cachedLoader is unchanged because outerCL.thread == Thread-A
>
> //4. Thread-B enters readObject() again and then call resolveClass()
> outerCL-B <- CachedLoader-B1
> cachedLoader <- Thread-B
> cachedLoader <- CachedLoader-B2
>
> //5. Thread-A returns from readObject()
> cachedLoader <- null
>
> //6. Thread-B returns from readObject()
> cachedLoader <- CachedLoader-B1  // Because outerCL-B.thread is Thread-B
>
>
> By adding checking before updating the mark, Thread-B won't update
> cachedLoader, or it only saves null when race occurs (and always restores
> to null on exit).
>
>
> Here is the updated webrev:
> http://cr.openjdk.java.net/~horii/8188858/webrev.03/
>
> I also made minor changes to reduce the number of invocation of the JNI
> method Thread.currentThread().
>
>
> Regards,
> Ogata
>
>
>
> From:   Peter Levart <peter.levart at gmail.com>
> To:     Kazunori Ogata <OGATAK at jp.ibm.com>, Alan Bateman
> <Alan.Bateman at oracle.com>
> Cc:     core-libs-dev at openjdk.java.net
> Date:   2017/10/16 19:58
> Subject:        Re: RFR: 8188858: Caching latestUserDefinedLoader()
> results in ObjectInputStream.readObject()
>
>
>
> Hi Ogata,
>
> I found a problem in my last suggestion. See below...
>
> On 10/16/2017 11:36 AM, Peter Levart wrote:
>> On 10/16/2017 11:02 AM, Peter Levart wrote:
>>> For example:
>>> - let public readObject() / readUnshared() entry and exit points just
>>> clear the cached loader (set it to null).
>> An alternative would be for entry point to save and clear the cached
>> loader while exit point would restore / clear it if it is from correct
>> thread / when the call was not nested. Like the following:
>>
>> public Object readObject() {
>>      CachedLoader outerCL = cachedLoader;
>>      cachedLoader = null;
>>      try {
>>          ...
>>      } finally {
>>          if (outerCL == null || outerCL.thread ==
>> Thread.currentThread()) {
>>              // restore/clear cached loader when nested/outer call ends
>>              cachedLoader = outerCL;
>>          }
>>      }
>> }
>>
>> with resolveClass() fragment repeated here for comparison:
>>
>>            CachedLoader cl = cachedLoader;
>>            Thread curThread = Thread.currentThread();
>>            ClassLoader loader;
>>            if (cl == null) {
>>                loader = latestUserDefinedLoader();
>>                cachedLoader = new CachedLoader(loader, curThread);
>>            } else if (cl.thread == curThread) {
>>                loader = cl.loader;
>>            } else {
>>                // multi threaded use
>>                loader = latestUserDefinedLoader();
>>            }
>>
>>            // and then...
>>            return Class.forName(name, false, loader);
>>
>>
>> There are all sorts of races possible when called concurrently from
>> multiple threads, but the worst consequence is that the loader is not
>> cached. I also think that even in the presence of races, the
>> cachedLoader is eventually cleared when all calls to OIS complete. I
>> couldn't think of a situation where such cached loader would remain
>> hanging off the completed OIS because of races.
>>
>> Well, there is one such situation but for a different reason. For
>> example, if an OIS subclass is constructed solely to override
>> resolveClass method to make it accessible to custom code (for example,
>> make it public and call super.resolveClass()) in order to provide a
>> utility for resolving classes with the default OIS semantics, but such
>> OIS instance is never used for deserialization itself
>> (readObject()/readUnshared() is never called).
>>
>> To solve this problem, resolveClass() logic, including lazy caching,
>> should be moved to a private method (resolveClass0()) with protected
>> resolveClass() treated like public readObject()/readUnshared() with
>> before/after treatment of cached loader around delegation to
>> resolveClass0(). All OIS internal uses of resolveClass() should then
>> be redirected to resolveClass0().
> Oops, this would not work for subclasses that override resolveClass()
> with custom logic. Hm...
>
> The correct and optimal solution is a little bit more involved, I think.
> Here's what I think should work (did not run any tests yet):
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Eplevart_jdk10-2Ddev_8188858-5FOIS.latestUserDefinedLoader.caching_webrev.01_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=PbaGqOdJOR6jMQkXDVYmjn6832m7o0LU2bzwt2awUgQ&s=gKz_rwcTcGIw8JvmRqlg1-OtjqFNXmIs4oQmIXlF3Wc&e=
>
>
>
> Regards, Peter
>
>
>
>


From huizhe.wang at oracle.com  Tue Oct 24 00:37:52 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 23 Oct 2017 17:37:52 -0700
Subject: RFR (JDK10/JAXP) 8176891: Fix lint warnings in JAXP repo: serial
Message-ID: <59EE8B60.7040800@oracle.com>

Hi,

Please review a fix that cleans up [serial] warnings by adding the 
serialVersionUID. The following tests showed that the serialVersionUID 
for the classes in this patch have not changed from JDK 1.4 to JDK 9:
      for each cls in classes that are missing serialVersionUID
           for jdk from 1.4 to 9
                run:
                $jdkversion/bin/serialver $jdkversion/jre/lib/rt.jar cls

One exception is javax.xml.namespace.QName. Its serialVersionUID was 
different in the standalone JAXP 1.3 before it was integrated into JDK 
1.5. Since JAXP 1.3 was EOLed in 2008 and the serialVersionUID has been 
consistent in the JDKs, it is now set with a static value from the JDK. 
The original workaround is discarded and the proprietary property 
(com.sun.xml.namespace.QName.useCompatibleSerialVersionUID) retired.

Another difference is between JDK 1.5 and 1.6 for class 
com.sun.org.apache.xml.internal.utils.URI. Since the UID was changed 
from 1.5 to 1.6 and then consistent through JDK 9, the incompatibility 
was already absorbed in JDK 1.6. This patch therefore simply adopts the 
later.

JBS: https://bugs.openjdk.java.net/browse/JDK-8176891
webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8176891/webrev/index.html

Thanks,
Joe

P.S.  Full test results:

JDK14
Class javax.xml.datatype.DatatypeConfigurationException not found.
JDK15
javax.xml.datatype.DatatypeConfigurationException:    static final long 
serialVersionUID = -1699373159027047238L;
JDK16
javax.xml.datatype.DatatypeConfigurationException:    static final long 
serialVersionUID = -1699373159027047238L;
JDK17
javax.xml.datatype.DatatypeConfigurationException:    static final long 
serialVersionUID = -1699373159027047238L;
JDK18
javax.xml.datatype.DatatypeConfigurationException:    private static 
final long serialVersionUID = -1699373159027047238L;
JDK19
javax.xml.datatype.DatatypeConfigurationException:    private static 
final long serialVersionUID = -1699373159027047238L;
JDK14
Class javax.xml.namespace.QName not found.
JDK15
javax.xml.namespace.QName:    static final long serialVersionUID = 
-9120448754896609940L;
JDK16
javax.xml.namespace.QName:    static final long serialVersionUID = 
-9120448754896609940L;
JDK17
javax.xml.namespace.QName:    static final long serialVersionUID = 
-9120448754896609940L;
JDK18
javax.xml.namespace.QName:    private static final long serialVersionUID 
= -9120448754896609940L;
JDK19
javax.xml.namespace.QName:    private static final long serialVersionUID 
= -9120448754896609940L;
JDK14
javax.xml.parsers.ParserConfigurationException:    static final long 
serialVersionUID = -3688849216575373917L;
JDK15
javax.xml.parsers.ParserConfigurationException:    static final long 
serialVersionUID = -3688849216575373917L;
JDK16
javax.xml.parsers.ParserConfigurationException:    static final long 
serialVersionUID = -3688849216575373917L;
JDK17
javax.xml.parsers.ParserConfigurationException:    static final long 
serialVersionUID = -3688849216575373917L;
JDK18
javax.xml.parsers.ParserConfigurationException:    private static final 
long serialVersionUID = -3688849216575373917L;
JDK19
javax.xml.parsers.ParserConfigurationException:    private static final 
long serialVersionUID = -3688849216575373917L;
JDK14
Class javax.xml.stream.XMLStreamException not found.
JDK15
Class javax.xml.stream.XMLStreamException not found.
JDK16
javax.xml.stream.XMLStreamException:    static final long 
serialVersionUID = 2018819321811497362L;
JDK17
javax.xml.stream.XMLStreamException:    static final long 
serialVersionUID = 2018819321811497362L;
JDK18
javax.xml.stream.XMLStreamException:    private static final long 
serialVersionUID = 2018819321811497362L;
JDK19
javax.xml.stream.XMLStreamException:    private static final long 
serialVersionUID = 2018819321811497362L;
JDK14
org.w3c.dom.events.EventException:    static final long serialVersionUID 
= 242753408332692061L;
JDK15
org.w3c.dom.events.EventException:    static final long serialVersionUID 
= 242753408332692061L;
JDK16
org.w3c.dom.events.EventException:    static final long serialVersionUID 
= 242753408332692061L;
JDK17
org.w3c.dom.events.EventException:    static final long serialVersionUID 
= 242753408332692061L;
JDK18
org.w3c.dom.events.EventException:    private static final long 
serialVersionUID = 242753408332692061L;
JDK19
org.w3c.dom.events.EventException:    private static final long 
serialVersionUID = 242753408332692061L;
JDK14
Class org.w3c.dom.ls.LSException not found.
JDK15
org.w3c.dom.ls.LSException:    static final long serialVersionUID = 
5371691160978884690L;
JDK16
org.w3c.dom.ls.LSException:    static final long serialVersionUID = 
5371691160978884690L;
JDK17
org.w3c.dom.ls.LSException:    static final long serialVersionUID = 
5371691160978884690L;
JDK18
org.w3c.dom.ls.LSException:    private static final long 
serialVersionUID = 5371691160978884690L;
JDK19
org.w3c.dom.ls.LSException:    private static final long 
serialVersionUID = 5371691160978884690L;
JDK14
Class org.w3c.dom.ranges.RangeException not found.
JDK15
org.w3c.dom.ranges.RangeException:    static final long serialVersionUID 
= 2427563372446661889L;
JDK16
org.w3c.dom.ranges.RangeException:    static final long serialVersionUID 
= 2427563372446661889L;
JDK17
org.w3c.dom.ranges.RangeException:    static final long serialVersionUID 
= 2427563372446661889L;
JDK18
org.w3c.dom.ranges.RangeException:    private static final long 
serialVersionUID = 2427563372446661889L;
JDK19
org.w3c.dom.ranges.RangeException:    private static final long 
serialVersionUID = 2427563372446661889L;
JDK14
Class com.sun.org.apache.xalan.internal.utils.ConfigurationError not found.
JDK15
com.sun.org.apache.xalan.internal.utils.ConfigurationError:    static 
final long serialVersionUID = 749136645488750664L;
JDK16
com.sun.org.apache.xalan.internal.utils.ConfigurationError:    static 
final long serialVersionUID = 749136645488750664L;
JDK17
com.sun.org.apache.xalan.internal.utils.ConfigurationError:    static 
final long serialVersionUID = 749136645488750664L;
JDK18
com.sun.org.apache.xalan.internal.utils.ConfigurationError:    private 
static final long serialVersionUID = 749136645488750664L;
JDK19
com.sun.org.apache.xalan.internal.utils.ConfigurationError:    private 
static final long serialVersionUID = 749136645488750664L;
JDK14
Class 
com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError not 
found.
JDK15
Class 
com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError not 
found.
JDK16
Class 
com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError not 
found.
JDK17
com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError:    
static final long serialVersionUID = -6690855975016554786L;
JDK18
com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError:    
private static final long serialVersionUID = -6690855975016554786L;
JDK19
com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError:    
private static final long serialVersionUID = -6690855975016554786L;
JDK14
Class 
com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError not 
found.
JDK15
Class 
com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError not 
found.
JDK16
Class 
com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError not 
found.
JDK17
com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError:    
static final long serialVersionUID = 2802784919179095307L;
JDK18
com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError:    
private static final long serialVersionUID = 2802784919179095307L;
JDK19
com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError:    
private static final long serialVersionUID = 2802784919179095307L;
JDK14
Class 
com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl not 
found.
JDK15
Class 
com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl not 
found.
JDK16
com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl:    
static final long serialVersionUID = 844792794952655204L;
JDK17
com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl:    
static final long serialVersionUID = 844792794952655204L;
JDK18
com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl:    
private static final long serialVersionUID = 844792794952655204L;
JDK19
com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl:    
private static final long serialVersionUID = 844792794952655204L;
JDK14
Class 
com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl 
not found.
JDK15
Class 
com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl 
not found.
JDK16
com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl:    
static final long serialVersionUID = -4430140662861507958L;
JDK17
com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl:    
static final long serialVersionUID = -4430140662861507958L;
JDK18
com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl:    
private static final long serialVersionUID = -4430140662861507958L;
JDK19
com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl:    
private static final long serialVersionUID = -4430140662861507958L;
JDK14
Class 
com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException 
not found.
JDK15
com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException:    
static final long serialVersionUID = -3201986204982729962L;
JDK16
com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException:    
static final long serialVersionUID = -3201986204982729962L;
JDK17
com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException:    
static final long serialVersionUID = -3201986204982729962L;
JDK18
com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException:    
private static final long serialVersionUID = -3201986204982729962L;
JDK19
com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException:    
private static final long serialVersionUID = -3201986204982729962L;
JDK14
Class com.sun.org.apache.xerces.internal.utils.ConfigurationError not 
found.
JDK15
com.sun.org.apache.xerces.internal.utils.ConfigurationError:    static 
final long serialVersionUID = 8095902236393167968L;
JDK16
com.sun.org.apache.xerces.internal.utils.ConfigurationError:    static 
final long serialVersionUID = 8095902236393167968L;
JDK17
com.sun.org.apache.xerces.internal.utils.ConfigurationError:    static 
final long serialVersionUID = 8095902236393167968L;
JDK18
com.sun.org.apache.xerces.internal.utils.ConfigurationError:    private 
static final long serialVersionUID = 8095902236393167968L;
JDK19
com.sun.org.apache.xerces.internal.utils.ConfigurationError:    private 
static final long serialVersionUID = 8095902236393167968L;
JDK14
Class 
com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException 
not found.
JDK15
Class 
com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException 
not found.
JDK16
com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException:    
static final long serialVersionUID = 4651455286983598951L;
JDK17
com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException:    
static final long serialVersionUID = 4651455286983598951L;
JDK18
com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException:    
private static final long serialVersionUID = 4651455286983598951L;
JDK19
com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException:    
private static final long serialVersionUID = 4651455286983598951L;
JDK14
Class com.sun.org.apache.xml.internal.utils.URI not found.
JDK15
com.sun.org.apache.xml.internal.utils.URI:    static final long 
serialVersionUID = -4864335621934089776L;
JDK16
com.sun.org.apache.xml.internal.utils.URI:    static final long 
serialVersionUID = 7096266377907081897L;
JDK17
com.sun.org.apache.xml.internal.utils.URI:    static final long 
serialVersionUID = 7096266377907081897L;
JDK18
com.sun.org.apache.xml.internal.utils.URI:    private static final long 
serialVersionUID = 7096266377907081897L;
JDK19
com.sun.org.apache.xml.internal.utils.URI:    private static final long 
serialVersionUID = 7096266377907081897L;
JDK14
Class com.sun.org.apache.xml.internal.utils.URI.MalformedURIException 
not found.
JDK15
com.sun.org.apache.xml.internal.utils.URI.MalformedURIException:    
static final long serialVersionUID = -8498313684991136829L;
JDK16
com.sun.org.apache.xml.internal.utils.URI.MalformedURIException:    
static final long serialVersionUID = -8498313684991136829L;
JDK17
com.sun.org.apache.xml.internal.utils.URI.MalformedURIException:    
static final long serialVersionUID = -8498313684991136829L;
JDK18
com.sun.org.apache.xml.internal.utils.URI.MalformedURIException:    
private static final long serialVersionUID = -8498313684991136829L;
JDK19
com.sun.org.apache.xml.internal.utils.URI.MalformedURIException:    
private static final long serialVersionUID = -8498313684991136829L;


From lance.andersen at oracle.com  Tue Oct 24 00:44:09 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 23 Oct 2017 20:44:09 -0400
Subject: RFR (JDK10/JAXP) 8176891: Fix lint warnings in JAXP repo: serial
In-Reply-To: <59EE8B60.7040800@oracle.com>
References: <59EE8B60.7040800@oracle.com>
Message-ID: <90576514-E31C-4455-8ABF-AFF4E121686E@oracle.com>

looks fine Joe
> On Oct 23, 2017, at 8:37 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Hi,
> 
> Please review a fix that cleans up [serial] warnings by adding the serialVersionUID. The following tests showed that the serialVersionUID for the classes in this patch have not changed from JDK 1.4 to JDK 9:
>     for each cls in classes that are missing serialVersionUID
>          for jdk from 1.4 to 9
>               run:
>               $jdkversion/bin/serialver $jdkversion/jre/lib/rt.jar cls
> 
> One exception is javax.xml.namespace.QName. Its serialVersionUID was different in the standalone JAXP 1.3 before it was integrated into JDK 1.5. Since JAXP 1.3 was EOLed in 2008 and the serialVersionUID has been consistent in the JDKs, it is now set with a static value from the JDK. The original workaround is discarded and the proprietary property (com.sun.xml.namespace.QName.useCompatibleSerialVersionUID) retired.
> 
> Another difference is between JDK 1.5 and 1.6 for class com.sun.org.apache.xml.internal.utils.URI. Since the UID was changed from 1.5 to 1.6 and then consistent through JDK 9, the incompatibility was already absorbed in JDK 1.6. This patch therefore simply adopts the later.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8176891
> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8176891/webrev/index.html
> 
> Thanks,
> Joe
> 
> P.S.  Full test results:
> 
> JDK14
> Class javax.xml.datatype.DatatypeConfigurationException not found.
> JDK15
> javax.xml.datatype.DatatypeConfigurationException:    static final long serialVersionUID = -1699373159027047238L;
> JDK16
> javax.xml.datatype.DatatypeConfigurationException:    static final long serialVersionUID = -1699373159027047238L;
> JDK17
> javax.xml.datatype.DatatypeConfigurationException:    static final long serialVersionUID = -1699373159027047238L;
> JDK18
> javax.xml.datatype.DatatypeConfigurationException:    private static final long serialVersionUID = -1699373159027047238L;
> JDK19
> javax.xml.datatype.DatatypeConfigurationException:    private static final long serialVersionUID = -1699373159027047238L;
> JDK14
> Class javax.xml.namespace.QName not found.
> JDK15
> javax.xml.namespace.QName:    static final long serialVersionUID = -9120448754896609940L;
> JDK16
> javax.xml.namespace.QName:    static final long serialVersionUID = -9120448754896609940L;
> JDK17
> javax.xml.namespace.QName:    static final long serialVersionUID = -9120448754896609940L;
> JDK18
> javax.xml.namespace.QName:    private static final long serialVersionUID = -9120448754896609940L;
> JDK19
> javax.xml.namespace.QName:    private static final long serialVersionUID = -9120448754896609940L;
> JDK14
> javax.xml.parsers.ParserConfigurationException:    static final long serialVersionUID = -3688849216575373917L;
> JDK15
> javax.xml.parsers.ParserConfigurationException:    static final long serialVersionUID = -3688849216575373917L;
> JDK16
> javax.xml.parsers.ParserConfigurationException:    static final long serialVersionUID = -3688849216575373917L;
> JDK17
> javax.xml.parsers.ParserConfigurationException:    static final long serialVersionUID = -3688849216575373917L;
> JDK18
> javax.xml.parsers.ParserConfigurationException:    private static final long serialVersionUID = -3688849216575373917L;
> JDK19
> javax.xml.parsers.ParserConfigurationException:    private static final long serialVersionUID = -3688849216575373917L;
> JDK14
> Class javax.xml.stream.XMLStreamException not found.
> JDK15
> Class javax.xml.stream.XMLStreamException not found.
> JDK16
> javax.xml.stream.XMLStreamException:    static final long serialVersionUID = 2018819321811497362L;
> JDK17
> javax.xml.stream.XMLStreamException:    static final long serialVersionUID = 2018819321811497362L;
> JDK18
> javax.xml.stream.XMLStreamException:    private static final long serialVersionUID = 2018819321811497362L;
> JDK19
> javax.xml.stream.XMLStreamException:    private static final long serialVersionUID = 2018819321811497362L;
> JDK14
> org.w3c.dom.events.EventException:    static final long serialVersionUID = 242753408332692061L;
> JDK15
> org.w3c.dom.events.EventException:    static final long serialVersionUID = 242753408332692061L;
> JDK16
> org.w3c.dom.events.EventException:    static final long serialVersionUID = 242753408332692061L;
> JDK17
> org.w3c.dom.events.EventException:    static final long serialVersionUID = 242753408332692061L;
> JDK18
> org.w3c.dom.events.EventException:    private static final long serialVersionUID = 242753408332692061L;
> JDK19
> org.w3c.dom.events.EventException:    private static final long serialVersionUID = 242753408332692061L;
> JDK14
> Class org.w3c.dom.ls.LSException not found.
> JDK15
> org.w3c.dom.ls.LSException:    static final long serialVersionUID = 5371691160978884690L;
> JDK16
> org.w3c.dom.ls.LSException:    static final long serialVersionUID = 5371691160978884690L;
> JDK17
> org.w3c.dom.ls.LSException:    static final long serialVersionUID = 5371691160978884690L;
> JDK18
> org.w3c.dom.ls.LSException:    private static final long serialVersionUID = 5371691160978884690L;
> JDK19
> org.w3c.dom.ls.LSException:    private static final long serialVersionUID = 5371691160978884690L;
> JDK14
> Class org.w3c.dom.ranges.RangeException not found.
> JDK15
> org.w3c.dom.ranges.RangeException:    static final long serialVersionUID = 2427563372446661889L;
> JDK16
> org.w3c.dom.ranges.RangeException:    static final long serialVersionUID = 2427563372446661889L;
> JDK17
> org.w3c.dom.ranges.RangeException:    static final long serialVersionUID = 2427563372446661889L;
> JDK18
> org.w3c.dom.ranges.RangeException:    private static final long serialVersionUID = 2427563372446661889L;
> JDK19
> org.w3c.dom.ranges.RangeException:    private static final long serialVersionUID = 2427563372446661889L;
> JDK14
> Class com.sun.org.apache.xalan.internal.utils.ConfigurationError not found.
> JDK15
> com.sun.org.apache.xalan.internal.utils.ConfigurationError:    static final long serialVersionUID = 749136645488750664L;
> JDK16
> com.sun.org.apache.xalan.internal.utils.ConfigurationError:    static final long serialVersionUID = 749136645488750664L;
> JDK17
> com.sun.org.apache.xalan.internal.utils.ConfigurationError:    static final long serialVersionUID = 749136645488750664L;
> JDK18
> com.sun.org.apache.xalan.internal.utils.ConfigurationError:    private static final long serialVersionUID = 749136645488750664L;
> JDK19
> com.sun.org.apache.xalan.internal.utils.ConfigurationError:    private static final long serialVersionUID = 749136645488750664L;
> JDK14
> Class com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError not found.
> JDK15
> Class com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError not found.
> JDK16
> Class com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError not found.
> JDK17
> com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError:    static final long serialVersionUID = -6690855975016554786L;
> JDK18
> com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError:    private static final long serialVersionUID = -6690855975016554786L;
> JDK19
> com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError:    private static final long serialVersionUID = -6690855975016554786L;
> JDK14
> Class com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError not found.
> JDK15
> Class com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError not found.
> JDK16
> Class com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError not found.
> JDK17
> com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError:    static final long serialVersionUID = 2802784919179095307L;
> JDK18
> com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError:    private static final long serialVersionUID = 2802784919179095307L;
> JDK19
> com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError:    private static final long serialVersionUID = 2802784919179095307L;
> JDK14
> Class com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl not found.
> JDK15
> Class com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl not found.
> JDK16
> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl:    static final long serialVersionUID = 844792794952655204L;
> JDK17
> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl:    static final long serialVersionUID = 844792794952655204L;
> JDK18
> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl:    private static final long serialVersionUID = 844792794952655204L;
> JDK19
> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl:    private static final long serialVersionUID = 844792794952655204L;
> JDK14
> Class com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl not found.
> JDK15
> Class com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl not found.
> JDK16
> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl:    static final long serialVersionUID = -4430140662861507958L;
> JDK17
> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl:    static final long serialVersionUID = -4430140662861507958L;
> JDK18
> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl:    private static final long serialVersionUID = -4430140662861507958L;
> JDK19
> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl:    private static final long serialVersionUID = -4430140662861507958L;
> JDK14
> Class com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException not found.
> JDK15
> com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException:    static final long serialVersionUID = -3201986204982729962L;
> JDK16
> com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException:    static final long serialVersionUID = -3201986204982729962L;
> JDK17
> com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException:    static final long serialVersionUID = -3201986204982729962L;
> JDK18
> com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException:    private static final long serialVersionUID = -3201986204982729962L;
> JDK19
> com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException:    private static final long serialVersionUID = -3201986204982729962L;
> JDK14
> Class com.sun.org.apache.xerces.internal.utils.ConfigurationError not found.
> JDK15
> com.sun.org.apache.xerces.internal.utils.ConfigurationError:    static final long serialVersionUID = 8095902236393167968L;
> JDK16
> com.sun.org.apache.xerces.internal.utils.ConfigurationError:    static final long serialVersionUID = 8095902236393167968L;
> JDK17
> com.sun.org.apache.xerces.internal.utils.ConfigurationError:    static final long serialVersionUID = 8095902236393167968L;
> JDK18
> com.sun.org.apache.xerces.internal.utils.ConfigurationError:    private static final long serialVersionUID = 8095902236393167968L;
> JDK19
> com.sun.org.apache.xerces.internal.utils.ConfigurationError:    private static final long serialVersionUID = 8095902236393167968L;
> JDK14
> Class com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException not found.
> JDK15
> Class com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException not found.
> JDK16
> com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException:    static final long serialVersionUID = 4651455286983598951L;
> JDK17
> com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException:    static final long serialVersionUID = 4651455286983598951L;
> JDK18
> com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException:    private static final long serialVersionUID = 4651455286983598951L;
> JDK19
> com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException:    private static final long serialVersionUID = 4651455286983598951L;
> JDK14
> Class com.sun.org.apache.xml.internal.utils.URI not found.
> JDK15
> com.sun.org.apache.xml.internal.utils.URI:    static final long serialVersionUID = -4864335621934089776L;
> JDK16
> com.sun.org.apache.xml.internal.utils.URI:    static final long serialVersionUID = 7096266377907081897L;
> JDK17
> com.sun.org.apache.xml.internal.utils.URI:    static final long serialVersionUID = 7096266377907081897L;
> JDK18
> com.sun.org.apache.xml.internal.utils.URI:    private static final long serialVersionUID = 7096266377907081897L;
> JDK19
> com.sun.org.apache.xml.internal.utils.URI:    private static final long serialVersionUID = 7096266377907081897L;
> JDK14
> Class com.sun.org.apache.xml.internal.utils.URI.MalformedURIException not found.
> JDK15
> com.sun.org.apache.xml.internal.utils.URI.MalformedURIException:    static final long serialVersionUID = -8498313684991136829L;
> JDK16
> com.sun.org.apache.xml.internal.utils.URI.MalformedURIException:    static final long serialVersionUID = -8498313684991136829L;
> JDK17
> com.sun.org.apache.xml.internal.utils.URI.MalformedURIException:    static final long serialVersionUID = -8498313684991136829L;
> JDK18
> com.sun.org.apache.xml.internal.utils.URI.MalformedURIException:    private static final long serialVersionUID = -8498313684991136829L;
> JDK19
> com.sun.org.apache.xml.internal.utils.URI.MalformedURIException:    private static final long serialVersionUID = -8498313684991136829L;
> 

 <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 mandy.chung at oracle.com  Tue Oct 24 00:48:02 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 23 Oct 2017 17:48:02 -0700
Subject: [10] RFR: 8189272 & 8189291
In-Reply-To: <6d9c21d5-4baa-89b7-28be-519e70f88f10@oracle.com>
References: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>
 <0a8bc81d-694e-aa8d-8530-e21f890b3507@oracle.com>
 <6d9c21d5-4baa-89b7-28be-519e70f88f10@oracle.com>
Message-ID: <3f337987-1628-62eb-1f6c-0aaa7e1ebc8e@oracle.com>



On 10/20/17 5:05 PM, Naoto Sato wrote:
> Hi Mandy,
>
> Thanks for the review. Webrevs updated as suggested:
>
> http://cr.openjdk.java.net/~naoto/8189272/webrev.01/
> http://cr.openjdk.java.net/~naoto/8189291/webrev.01/
>

DEFAULT_POLICY in test/jdk/java/util/logging/* tests can be moved to the 
enclosing class as suggested.

Other than that, the change looks good.

Mandy

> Naoto
>
> On 10/20/17 2:45 PM, mandy chung wrote:
>>
>>
>> On 10/20/17 2:20 PM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the changes for the following two issues:
>>>
>>> 8189272: CLDR and JRE LocaleProviderAdapters silently swallow 
>>> exceptions [1]
>>> 8189291: Test policy should extend the default system policy [2]
>>>
>>> The proposed fixes for the above issues are located below, 
>>> respectively:
>>>
>>> http://cr.openjdk.java.net/~naoto/8189272/webrev.00/
>>
>> Looks fine.? The installed providers are our implementation and 
>> silently ignore any exception would make it really hard to diagnose 
>> problems. This change will help the diagnosability.
>>
>>> http://cr.openjdk.java.net/~naoto/8189291/webrev.00/
>>>
>>
>> If the default policy is not cached early before any test policy is 
>> constructed, the test might get the wrong Policy object set by the 
>> test previously (for example, if it runs in agentvm mode).?? It would 
>> be more reliable if this is cached as the static field in the test 
>> class (i.e. the enclosing class of the policy subclass) - like 
>> CallerSensitiveTest.
>>
>> test/jdk/sun/util/locale/provider/Bug8038436.java
>> - I think the test fix should be part of JDK-8189272, right?
>>
>> Mandy
>>> The fix to 8189272 will throw exceptions that were swallowed in 
>>> those providers, which should not happen in proper environment. That 
>>> fix makes test cases with security manager fail. The fix to 8189291 
>>> addresses it.
>>>
>>> Naoto
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8189272
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291
>>


From huizhe.wang at oracle.com  Tue Oct 24 01:04:03 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 23 Oct 2017 18:04:03 -0700
Subject: RFR (JDK10/JAXP) 8176891: Fix lint warnings in JAXP repo: serial
In-Reply-To: <90576514-E31C-4455-8ABF-AFF4E121686E@oracle.com>
References: <59EE8B60.7040800@oracle.com>
 <90576514-E31C-4455-8ABF-AFF4E121686E@oracle.com>
Message-ID: <59EE9183.4040902@oracle.com>

Thanks Lance for the super fast review!!!  I haven't thought I'd check 
back today :-)

On 10/23/17, 5:44 PM, Lance Andersen wrote:
> looks fine Joe
>> On Oct 23, 2017, at 8:37 PM, Joe Wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please review a fix that cleans up [serial] warnings by adding the 
>> serialVersionUID. The following tests showed that the 
>> serialVersionUID for the classes in this patch have not changed from 
>> JDK 1.4 to JDK 9:
>>     for each cls in classes that are missing serialVersionUID
>>          for jdk from 1.4 to 9
>>               run:
>>               $jdkversion/bin/serialver $jdkversion/jre/lib/rt.jar cls
>>
>> One exception is javax.xml.namespace.QName. Its serialVersionUID was 
>> different in the standalone JAXP 1.3 before it was integrated into 
>> JDK 1.5. Since JAXP 1.3 was EOLed in 2008 and the serialVersionUID 
>> has been consistent in the JDKs, it is now set with a static value 
>> from the JDK. The original workaround is discarded and the 
>> proprietary property 
>> (com.sun.xml.namespace.QName.useCompatibleSerialVersionUID) retired.
>>
>> Another difference is between JDK 1.5 and 1.6 for class 
>> com.sun.org.apache.xml.internal.utils.URI. Since the UID was changed 
>> from 1.5 to 1.6 and then consistent through JDK 9, the 
>> incompatibility was already absorbed in JDK 1.6. This patch therefore 
>> simply adopts the later.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176891
>> webrevs: 
>> http://cr.openjdk.java.net/~joehw/jdk10/8176891/webrev/index.html 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk10/8176891/webrev/index.html>
>>
>> Thanks,
>> Joe
>>
>> P.S.  Full test results:
>>
>> JDK14
>> Class javax.xml.datatype.DatatypeConfigurationException not found.
>> JDK15
>> javax.xml.datatype.DatatypeConfigurationException:    static final 
>> long serialVersionUID = -1699373159027047238L;
>> JDK16
>> javax.xml.datatype.DatatypeConfigurationException:    static final 
>> long serialVersionUID = -1699373159027047238L;
>> JDK17
>> javax.xml.datatype.DatatypeConfigurationException:    static final 
>> long serialVersionUID = -1699373159027047238L;
>> JDK18
>> javax.xml.datatype.DatatypeConfigurationException:    private static 
>> final long serialVersionUID = -1699373159027047238L;
>> JDK19
>> javax.xml.datatype.DatatypeConfigurationException:    private static 
>> final long serialVersionUID = -1699373159027047238L;
>> JDK14
>> Class javax.xml.namespace.QName not found.
>> JDK15
>> javax.xml.namespace.QName:    static final long serialVersionUID = 
>> -9120448754896609940L;
>> JDK16
>> javax.xml.namespace.QName:    static final long serialVersionUID = 
>> -9120448754896609940L;
>> JDK17
>> javax.xml.namespace.QName:    static final long serialVersionUID = 
>> -9120448754896609940L;
>> JDK18
>> javax.xml.namespace.QName:    private static final long 
>> serialVersionUID = -9120448754896609940L;
>> JDK19
>> javax.xml.namespace.QName:    private static final long 
>> serialVersionUID = -9120448754896609940L;
>> JDK14
>> javax.xml.parsers.ParserConfigurationException:    static final long 
>> serialVersionUID = -3688849216575373917L;
>> JDK15
>> javax.xml.parsers.ParserConfigurationException:    static final long 
>> serialVersionUID = -3688849216575373917L;
>> JDK16
>> javax.xml.parsers.ParserConfigurationException:    static final long 
>> serialVersionUID = -3688849216575373917L;
>> JDK17
>> javax.xml.parsers.ParserConfigurationException:    static final long 
>> serialVersionUID = -3688849216575373917L;
>> JDK18
>> javax.xml.parsers.ParserConfigurationException:    private static 
>> final long serialVersionUID = -3688849216575373917L;
>> JDK19
>> javax.xml.parsers.ParserConfigurationException:    private static 
>> final long serialVersionUID = -3688849216575373917L;
>> JDK14
>> Class javax.xml.stream.XMLStreamException not found.
>> JDK15
>> Class javax.xml.stream.XMLStreamException not found.
>> JDK16
>> javax.xml.stream.XMLStreamException:    static final long 
>> serialVersionUID = 2018819321811497362L;
>> JDK17
>> javax.xml.stream.XMLStreamException:    static final long 
>> serialVersionUID = 2018819321811497362L;
>> JDK18
>> javax.xml.stream.XMLStreamException:    private static final long 
>> serialVersionUID = 2018819321811497362L;
>> JDK19
>> javax.xml.stream.XMLStreamException:    private static final long 
>> serialVersionUID = 2018819321811497362L;
>> JDK14
>> org.w3c.dom.events.EventException:    static final long 
>> serialVersionUID = 242753408332692061L;
>> JDK15
>> org.w3c.dom.events.EventException:    static final long 
>> serialVersionUID = 242753408332692061L;
>> JDK16
>> org.w3c.dom.events.EventException:    static final long 
>> serialVersionUID = 242753408332692061L;
>> JDK17
>> org.w3c.dom.events.EventException:    static final long 
>> serialVersionUID = 242753408332692061L;
>> JDK18
>> org.w3c.dom.events.EventException:    private static final long 
>> serialVersionUID = 242753408332692061L;
>> JDK19
>> org.w3c.dom.events.EventException:    private static final long 
>> serialVersionUID = 242753408332692061L;
>> JDK14
>> Class org.w3c.dom.ls.LSException not found.
>> JDK15
>> org.w3c.dom.ls.LSException:    static final long serialVersionUID = 
>> 5371691160978884690L;
>> JDK16
>> org.w3c.dom.ls.LSException:    static final long serialVersionUID = 
>> 5371691160978884690L;
>> JDK17
>> org.w3c.dom.ls.LSException:    static final long serialVersionUID = 
>> 5371691160978884690L;
>> JDK18
>> org.w3c.dom.ls.LSException:    private static final long 
>> serialVersionUID = 5371691160978884690L;
>> JDK19
>> org.w3c.dom.ls.LSException:    private static final long 
>> serialVersionUID = 5371691160978884690L;
>> JDK14
>> Class org.w3c.dom.ranges.RangeException not found.
>> JDK15
>> org.w3c.dom.ranges.RangeException:    static final long 
>> serialVersionUID = 2427563372446661889L;
>> JDK16
>> org.w3c.dom.ranges.RangeException:    static final long 
>> serialVersionUID = 2427563372446661889L;
>> JDK17
>> org.w3c.dom.ranges.RangeException:    static final long 
>> serialVersionUID = 2427563372446661889L;
>> JDK18
>> org.w3c.dom.ranges.RangeException:    private static final long 
>> serialVersionUID = 2427563372446661889L;
>> JDK19
>> org.w3c.dom.ranges.RangeException:    private static final long 
>> serialVersionUID = 2427563372446661889L;
>> JDK14
>> Class com.sun.org.apache.xalan.internal.utils.ConfigurationError not 
>> found.
>> JDK15
>> com.sun.org.apache.xalan.internal.utils.ConfigurationError:    static 
>> final long serialVersionUID = 749136645488750664L;
>> JDK16
>> com.sun.org.apache.xalan.internal.utils.ConfigurationError:    static 
>> final long serialVersionUID = 749136645488750664L;
>> JDK17
>> com.sun.org.apache.xalan.internal.utils.ConfigurationError:    static 
>> final long serialVersionUID = 749136645488750664L;
>> JDK18
>> com.sun.org.apache.xalan.internal.utils.ConfigurationError: 
>>    private static final long serialVersionUID = 749136645488750664L;
>> JDK19
>> com.sun.org.apache.xalan.internal.utils.ConfigurationError: 
>>    private static final long serialVersionUID = 749136645488750664L;
>> JDK14
>> Class 
>> com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError 
>> not found.
>> JDK15
>> Class 
>> com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError 
>> not found.
>> JDK16
>> Class 
>> com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError 
>> not found.
>> JDK17
>> com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError: 
>>    static final long serialVersionUID = -6690855975016554786L;
>> JDK18
>> com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError: 
>>    private static final long serialVersionUID = -6690855975016554786L;
>> JDK19
>> com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError: 
>>    private static final long serialVersionUID = -6690855975016554786L;
>> JDK14
>> Class 
>> com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError 
>> not found.
>> JDK15
>> Class 
>> com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError 
>> not found.
>> JDK16
>> Class 
>> com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError 
>> not found.
>> JDK17
>> com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError: 
>>    static final long serialVersionUID = 2802784919179095307L;
>> JDK18
>> com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError: 
>>    private static final long serialVersionUID = 2802784919179095307L;
>> JDK19
>> com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError: 
>>    private static final long serialVersionUID = 2802784919179095307L;
>> JDK14
>> Class 
>> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl 
>> not found.
>> JDK15
>> Class 
>> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl 
>> not found.
>> JDK16
>> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl: 
>>    static final long serialVersionUID = 844792794952655204L;
>> JDK17
>> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl: 
>>    static final long serialVersionUID = 844792794952655204L;
>> JDK18
>> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl: 
>>    private static final long serialVersionUID = 844792794952655204L;
>> JDK19
>> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl: 
>>    private static final long serialVersionUID = 844792794952655204L;
>> JDK14
>> Class 
>> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl not 
>> found.
>> JDK15
>> Class 
>> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl not 
>> found.
>> JDK16
>> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl: 
>>    static final long serialVersionUID = -4430140662861507958L;
>> JDK17
>> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl: 
>>    static final long serialVersionUID = -4430140662861507958L;
>> JDK18
>> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl: 
>>    private static final long serialVersionUID = -4430140662861507958L;
>> JDK19
>> com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl: 
>>    private static final long serialVersionUID = -4430140662861507958L;
>> JDK14
>> Class 
>> com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException not 
>> found.
>> JDK15
>> com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException: 
>>    static final long serialVersionUID = -3201986204982729962L;
>> JDK16
>> com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException: 
>>    static final long serialVersionUID = -3201986204982729962L;
>> JDK17
>> com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException: 
>>    static final long serialVersionUID = -3201986204982729962L;
>> JDK18
>> com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException: 
>>    private static final long serialVersionUID = -3201986204982729962L;
>> JDK19
>> com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException: 
>>    private static final long serialVersionUID = -3201986204982729962L;
>> JDK14
>> Class com.sun.org.apache.xerces.internal.utils.ConfigurationError not 
>> found.
>> JDK15
>> com.sun.org.apache.xerces.internal.utils.ConfigurationError: 
>>    static final long serialVersionUID = 8095902236393167968L;
>> JDK16
>> com.sun.org.apache.xerces.internal.utils.ConfigurationError: 
>>    static final long serialVersionUID = 8095902236393167968L;
>> JDK17
>> com.sun.org.apache.xerces.internal.utils.ConfigurationError: 
>>    static final long serialVersionUID = 8095902236393167968L;
>> JDK18
>> com.sun.org.apache.xerces.internal.utils.ConfigurationError: 
>>    private static final long serialVersionUID = 8095902236393167968L;
>> JDK19
>> com.sun.org.apache.xerces.internal.utils.ConfigurationError: 
>>    private static final long serialVersionUID = 8095902236393167968L;
>> JDK14
>> Class 
>> com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException 
>> not found.
>> JDK15
>> Class 
>> com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException 
>> not found.
>> JDK16
>> com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException: 
>>    static final long serialVersionUID = 4651455286983598951L;
>> JDK17
>> com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException: 
>>    static final long serialVersionUID = 4651455286983598951L;
>> JDK18
>> com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException: 
>>    private static final long serialVersionUID = 4651455286983598951L;
>> JDK19
>> com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException: 
>>    private static final long serialVersionUID = 4651455286983598951L;
>> JDK14
>> Class com.sun.org.apache.xml.internal.utils.URI not found.
>> JDK15
>> com.sun.org.apache.xml.internal.utils.URI:    static final long 
>> serialVersionUID = -4864335621934089776L;
>> JDK16
>> com.sun.org.apache.xml.internal.utils.URI:    static final long 
>> serialVersionUID = 7096266377907081897L;
>> JDK17
>> com.sun.org.apache.xml.internal.utils.URI:    static final long 
>> serialVersionUID = 7096266377907081897L;
>> JDK18
>> com.sun.org.apache.xml.internal.utils.URI:    private static final 
>> long serialVersionUID = 7096266377907081897L;
>> JDK19
>> com.sun.org.apache.xml.internal.utils.URI:    private static final 
>> long serialVersionUID = 7096266377907081897L;
>> JDK14
>> Class com.sun.org.apache.xml.internal.utils.URI.MalformedURIException 
>> not found.
>> JDK15
>> com.sun.org.apache.xml.internal.utils.URI.MalformedURIException: 
>>    static final long serialVersionUID = -8498313684991136829L;
>> JDK16
>> com.sun.org.apache.xml.internal.utils.URI.MalformedURIException: 
>>    static final long serialVersionUID = -8498313684991136829L;
>> JDK17
>> com.sun.org.apache.xml.internal.utils.URI.MalformedURIException: 
>>    static final long serialVersionUID = -8498313684991136829L;
>> JDK18
>> com.sun.org.apache.xml.internal.utils.URI.MalformedURIException: 
>>    private static final long serialVersionUID = -8498313684991136829L;
>> JDK19
>> com.sun.org.apache.xml.internal.utils.URI.MalformedURIException: 
>>    private static final long serialVersionUID = -8498313684991136829L;
>>
>
> <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 peter.levart at gmail.com  Tue Oct 24 05:11:01 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Oct 2017 07:11:01 +0200
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <e2b5c5bf-1622-65bb-29d0-310f3b185529@gmail.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
 <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
 <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
 <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>
 <1238393b-0d7f-9fea-eb75-3fd816c951a5@gmail.com>
 <OFA0D9E522.56232230-ON492581BC.003EF1D9-492581BC.0040E6BF@notes.na.collabserv.com>
 <e2b5c5bf-1622-65bb-29d0-310f3b185529@gmail.com>
Message-ID: <d27acb55-12fc-2a3d-1fa9-490a03831bce@gmail.com>

Hi,

I think that what Ogata has in webrev.03 is correct and the reasoning 
could be as follows:

- each thread writes to field 'cachedLoader' only from its own set of 
values that are distinct from the sets of values that may be written by 
any other thread, except null value.
- each thread reads field 'cachedLoader' and can verfy that it has read 
a value that belongs to the set of its own written values, or null value 
(in other words, a thread can verify that it has read a value that was 
written by self or null value).
- reads and writes of own set of non-null values always appear in 
program order since they are performed by same thread
- a sequence of writes of own set of non-null values performed by some 
thread begins after this thread 1st observes a null value read from the 
field and ends before this thread finally writes null value back to the 
field. The last write performed by some thread is therefore always a 
write of null value.

No matter how writes performed by a mixture of threads finally hit the 
actual field, since each thread that writes to it issues its final write 
of null value, the value that eventually ends in the field is null value.

Does this make sense?

Regards, Peter

On 10/23/17 22:47, Peter Levart wrote:
> Hi Ogata,
>
> Sorry for late reply. You are absolutely right. Good catch! I missed 
> this scenario. The criteria for placing the mark (current Thread) on a 
> cachedLoader must include the check that validates previous value for 
> later restoration which uses the same criteria. Only in such case will 
> one thread never restore something that has not been placed by it. And 
> this guarantees that consumed OIS will never retain a reference to any 
> ClassLoader or Thread. Your webrev.03 looks good to me.
>
> Regards, Peter
>
> On 10/17/17 13:48, Kazunori Ogata wrote:
>> Hi Peter,
>>
>> Thank you for your comments and the fix.  It's a good idea to mark
>> cachedLoader with the Thread object.
>>
>>
>> I think we need to check the marking thread of cachedLoader before
>> updating it.  Otherwise, there is a scenario that can leak a CachedLoader
>> object:
>>
>> //1. Thread-A enters readObject() and then call resolveClass()
>> outerCL-A <- null
>> cachedLoader <- Thread-A
>> cachedLoader <- CachedLoader-A
>>
>> //2. Thread-B enters readObject() and then call resolveClass()
>> outerCL-B <- CachedLoader-A
>> cachedLoader <- Thread-B
>> cachedLoader <- CachedLoader-B1
>>
>> //3. Thread-B returns from readObject()
>> cachedLoader is unchanged because outerCL.thread == Thread-A
>>
>> //4. Thread-B enters readObject() again and then call resolveClass()
>> outerCL-B <- CachedLoader-B1
>> cachedLoader <- Thread-B
>> cachedLoader <- CachedLoader-B2
>>
>> //5. Thread-A returns from readObject()
>> cachedLoader <- null
>>
>> //6. Thread-B returns from readObject()
>> cachedLoader <- CachedLoader-B1  // Because outerCL-B.thread is Thread-B
>>
>>
>> By adding checking before updating the mark, Thread-B won't update
>> cachedLoader, or it only saves null when race occurs (and always restores
>> to null on exit).
>>
>>
>> Here is the updated webrev:
>> http://cr.openjdk.java.net/~horii/8188858/webrev.03/
>>
>> I also made minor changes to reduce the number of invocation of the JNI
>> method Thread.currentThread().
>>
>>
>> Regards,
>> Ogata
>>
>>
>>
>> From:   Peter Levart<peter.levart at gmail.com>
>> To:     Kazunori Ogata<OGATAK at jp.ibm.com>, Alan Bateman
>> <Alan.Bateman at oracle.com>
>> Cc:core-libs-dev at openjdk.java.net
>> Date:   2017/10/16 19:58
>> Subject:        Re: RFR: 8188858: Caching latestUserDefinedLoader()
>> results in ObjectInputStream.readObject()
>>
>>
>>
>> Hi Ogata,
>>
>> I found a problem in my last suggestion. See below...
>>
>> On 10/16/2017 11:36 AM, Peter Levart wrote:
>>> On 10/16/2017 11:02 AM, Peter Levart wrote:
>>>> For example:
>>>> - let public readObject() / readUnshared() entry and exit points just
>>>> clear the cached loader (set it to null).
>>> An alternative would be for entry point to save and clear the cached
>>> loader while exit point would restore / clear it if it is from correct
>>> thread / when the call was not nested. Like the following:
>>>
>>> public Object readObject() {
>>>      CachedLoader outerCL = cachedLoader;
>>>      cachedLoader = null;
>>>      try {
>>>          ...
>>>      } finally {
>>>          if (outerCL == null || outerCL.thread ==
>>> Thread.currentThread()) {
>>>              // restore/clear cached loader when nested/outer call ends
>>>              cachedLoader = outerCL;
>>>          }
>>>      }
>>> }
>>>
>>> with resolveClass() fragment repeated here for comparison:
>>>
>>>            CachedLoader cl = cachedLoader;
>>>            Thread curThread = Thread.currentThread();
>>>            ClassLoader loader;
>>>            if (cl == null) {
>>>                loader = latestUserDefinedLoader();
>>>                cachedLoader = new CachedLoader(loader, curThread);
>>>            } else if (cl.thread == curThread) {
>>>                loader = cl.loader;
>>>            } else {
>>>                // multi threaded use
>>>                loader = latestUserDefinedLoader();
>>>            }
>>>
>>>            // and then...
>>>            return Class.forName(name, false, loader);
>>>
>>>
>>> There are all sorts of races possible when called concurrently from
>>> multiple threads, but the worst consequence is that the loader is not
>>> cached. I also think that even in the presence of races, the
>>> cachedLoader is eventually cleared when all calls to OIS complete. I
>>> couldn't think of a situation where such cached loader would remain
>>> hanging off the completed OIS because of races.
>>>
>>> Well, there is one such situation but for a different reason. For
>>> example, if an OIS subclass is constructed solely to override
>>> resolveClass method to make it accessible to custom code (for example,
>>> make it public and call super.resolveClass()) in order to provide a
>>> utility for resolving classes with the default OIS semantics, but such
>>> OIS instance is never used for deserialization itself
>>> (readObject()/readUnshared() is never called).
>>>
>>> To solve this problem, resolveClass() logic, including lazy caching,
>>> should be moved to a private method (resolveClass0()) with protected
>>> resolveClass() treated like public readObject()/readUnshared() with
>>> before/after treatment of cached loader around delegation to
>>> resolveClass0(). All OIS internal uses of resolveClass() should then
>>> be redirected to resolveClass0().
>> Oops, this would not work for subclasses that override resolveClass()
>> with custom logic. Hm...
>>
>> The correct and optimal solution is a little bit more involved, I think.
>> Here's what I think should work (did not run any tests yet):
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Eplevart_jdk10-2Ddev_8188858-5FOIS.latestUserDefinedLoader.caching_webrev.01_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=PbaGqOdJOR6jMQkXDVYmjn6832m7o0LU2bzwt2awUgQ&s=gKz_rwcTcGIw8JvmRqlg1-OtjqFNXmIs4oQmIXlF3Wc&e=
>>
>>
>>
>> Regards, Peter
>>
>>
>>
>>
>


From OGATAK at jp.ibm.com  Tue Oct 24 06:24:53 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Tue, 24 Oct 2017 15:24:53 +0900
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <OF1F44710D.C4E699CC-ON002581C3.001C7C1E@LocalDomain>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
 <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
 <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>
 <1238393b-0d7f-9fea-eb75-3fd816c951a5@gmail.com>
 <OFA0D9E522.56232230-ON492581BC.003EF1D9-492581BC.0040E6BF@notes.na.collabserv.com>
 <e2b5c5bf-1622-65bb-29d0-310f3b185529@gmail.com>
 <OF1F44710D.C4E699CC-ON002581C3.001C7C1E@LocalDomain>
Message-ID: <OF2B6D687C.C6B3B448-ON492581C3.00232994-492581C3.00233D7D@notes.na.collabserv.com>

Hi Peter,

Thank you for your review and summarizing the change.

Regards,
Ogata


Peter Levart <peter.levart at gmail.com> wrote on 2017/10/24 14:11:01:

> From: Peter Levart <peter.levart at gmail.com>
> To: Kazunori Ogata <OGATAK at jp.ibm.com>
> Cc: Alan Bateman <Alan.Bateman at oracle.com>, 
core-libs-dev at openjdk.java.net
> Date: 2017/10/24 14:11
> Subject: Re: RFR: 8188858: Caching latestUserDefinedLoader() results in 
> ObjectInputStream.readObject()
> 
> Hi,
> 
> I think that what Ogata has in webrev.03 is correct and the reasoning 
> could be as follows:
> 
> - each thread writes to field 'cachedLoader' only from its own set of 
> values that are distinct from the sets of values that may be written by 
> any other thread, except null value.
> - each thread reads field 'cachedLoader' and can verfy that it has read 
a 
> value that belongs to the set of its own written values, or null value 
(in
> other words, a thread can verify that it has read a value that was 
written
> by self or null value).
> - reads and writes of own set of non-null values always appear in 
program 
> order since they are performed by same thread
> - a sequence of writes of own set of non-null values performed by some 
> thread begins after this thread 1st observes a null value read from the 
> field and ends before this thread finally writes null value back to the 
> field. The last write performed by some thread is therefore always a 
write
> of null value.
> 
> No matter how writes performed by a mixture of threads finally hit the 
> actual field, since each thread that writes to it issues its final write 

> of null value, the value that eventually ends in the field is null 
value.
> 
> Does this make sense?
> 
> Regards, Peter

> On 10/23/17 22:47, Peter Levart wrote:
> Hi Ogata,
> 
> Sorry for late reply. You are absolutely right. Good catch! I missed 
this 
> scenario. The criteria for placing the mark (current Thread) on a 
> cachedLoader must include the check that validates previous value for 
> later restoration which uses the same criteria. Only in such case will 
one
> thread never restore something that has not been placed by it. And this 
> guarantees that consumed OIS will never retain a reference to any 
> ClassLoader or Thread. Your webrev.03 looks good to me.
> 
> Regards, Peter

> On 10/17/17 13:48, Kazunori Ogata wrote:
> Hi Peter,
> 
> Thank you for your comments and the fix.  It's a good idea to mark 
> cachedLoader with the Thread object.
> 
> 
> I think we need to check the marking thread of cachedLoader before 
> updating it.  Otherwise, there is a scenario that can leak a 
CachedLoader 
> object:
> 
> //1. Thread-A enters readObject() and then call resolveClass()
> outerCL-A <- null
> cachedLoader <- Thread-A
> cachedLoader <- CachedLoader-A
> 
> //2. Thread-B enters readObject() and then call resolveClass()
> outerCL-B <- CachedLoader-A
> cachedLoader <- Thread-B
> cachedLoader <- CachedLoader-B1
> 
> //3. Thread-B returns from readObject()
> cachedLoader is unchanged because outerCL.thread == Thread-A
> 
> //4. Thread-B enters readObject() again and then call resolveClass()
> outerCL-B <- CachedLoader-B1
> cachedLoader <- Thread-B
> cachedLoader <- CachedLoader-B2
> 
> //5. Thread-A returns from readObject()
> cachedLoader <- null
> 
> //6. Thread-B returns from readObject()
> cachedLoader <- CachedLoader-B1  // Because outerCL-B.thread is Thread-B
> 
> 
> By adding checking before updating the mark, Thread-B won't update 
> cachedLoader, or it only saves null when race occurs (and always 
restores 
> to null on exit).
> 
> 
> Here is the updated webrev: 
> http://cr.openjdk.java.net/~horii/8188858/webrev.03/
> 
> I also made minor changes to reduce the number of invocation of the JNI 
> method Thread.currentThread().
> 
> 
> Regards,
> Ogata
> 
> 
> 
> From:   Peter Levart <peter.levart at gmail.com>
> To:     Kazunori Ogata <OGATAK at jp.ibm.com>, Alan Bateman 
> <Alan.Bateman at oracle.com>
> Cc:     core-libs-dev at openjdk.java.net
> Date:   2017/10/16 19:58
> Subject:        Re: RFR: 8188858: Caching latestUserDefinedLoader() 
> results in ObjectInputStream.readObject()
> 
> 
> 
> Hi Ogata,
> 
> I found a problem in my last suggestion. See below...
> 
> On 10/16/2017 11:36 AM, Peter Levart wrote:

> On 10/16/2017 11:02 AM, Peter Levart wrote:

> For example:
> - let public readObject() / readUnshared() entry and exit points just 
> clear the cached loader (set it to null).

> An alternative would be for entry point to save and clear the cached 
> loader while exit point would restore / clear it if it is from correct 
> thread / when the call was not nested. Like the following:
> 
> public Object readObject() {
>     CachedLoader outerCL = cachedLoader;
>     cachedLoader = null;
>     try {
>         ...
>     } finally {
>         if (outerCL == null || outerCL.thread == 
> Thread.currentThread()) {
>             // restore/clear cached loader when nested/outer call ends
>             cachedLoader = outerCL;
>         }
>     }
> }
> 
> with resolveClass() fragment repeated here for comparison:
> 
>           CachedLoader cl = cachedLoader;
>           Thread curThread = Thread.currentThread();
>           ClassLoader loader;
>           if (cl == null) {
>               loader = latestUserDefinedLoader();
>               cachedLoader = new CachedLoader(loader, curThread);
>           } else if (cl.thread == curThread) {
>               loader = cl.loader;
>           } else {
>               // multi threaded use
>               loader = latestUserDefinedLoader();
>           }
> 
>           // and then...
>           return Class.forName(name, false, loader);
> 
> 
> There are all sorts of races possible when called concurrently from 
> multiple threads, but the worst consequence is that the loader is not 
> cached. I also think that even in the presence of races, the 
> cachedLoader is eventually cleared when all calls to OIS complete. I 
> couldn't think of a situation where such cached loader would remain 
> hanging off the completed OIS because of races.
> 
> Well, there is one such situation but for a different reason. For 
> example, if an OIS subclass is constructed solely to override 
> resolveClass method to make it accessible to custom code (for example, 
> make it public and call super.resolveClass()) in order to provide a 
> utility for resolving classes with the default OIS semantics, but such 
> OIS instance is never used for deserialization itself 
> (readObject()/readUnshared() is never called).
> 
> To solve this problem, resolveClass() logic, including lazy caching, 
> should be moved to a private method (resolveClass0()) with protected 
> resolveClass() treated like public readObject()/readUnshared() with 
> before/after treatment of cached loader around delegation to 
> resolveClass0(). All OIS internal uses of resolveClass() should then 
> be redirected to resolveClass0().

> Oops, this would not work for subclasses that override resolveClass() 
> with custom logic. Hm...
> 
> The correct and optimal solution is a little bit more involved, I think. 

> Here's what I think should work (did not run any tests yet):
> 
> https://urldefense.proofpoint.com/v2/url?
> 
u=http-3A__cr.openjdk.java.net_-7Eplevart_jdk10-2Ddev_8188858-5FOIS.latestUserDefinedLoader.caching_webrev.
> 01_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-
> 
FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=PbaGqOdJOR6jMQkXDVYmjn6832m7o0LU2bzwt2awUgQ&s=gKz_rwcTcGIw8JvmRqlg1-
> OtjqFNXmIs4oQmIXlF3Wc&e=
> 
> 
> 
> Regards, Peter
> 
> 
> 
> 



From david.holmes at oracle.com  Tue Oct 24 06:49:40 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Oct 2017 16:49:40 +1000
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <d27acb55-12fc-2a3d-1fa9-490a03831bce@gmail.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <493d0e55-77af-3987-d8a5-b208e1a88179@oracle.com>
 <OF33E5C5E6.14CDF254-ON492581B5.001732A7-492581B5.00361CEA@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
 <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
 <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>
 <1238393b-0d7f-9fea-eb75-3fd816c951a5@gmail.com>
 <OFA0D9E522.56232230-ON492581BC.003EF1D9-492581BC.0040E6BF@notes.na.collabserv.com>
 <e2b5c5bf-1622-65bb-29d0-310f3b185529@gmail.com>
 <d27acb55-12fc-2a3d-1fa9-490a03831bce@gmail.com>
Message-ID: <66683b87-044a-5ba5-9a65-5d36cf339037@oracle.com>

Hi Peter, Ogata,

Are you saying this is correct even if cachedLoader is not volatile? If 
so then that needs to be clearly documented.

Cheers,
David

On 24/10/2017 3:11 PM, Peter Levart wrote:
> Hi,
> 
> I think that what Ogata has in webrev.03 is correct and the reasoning 
> could be as follows:
> 
> - each thread writes to field 'cachedLoader' only from its own set of 
> values that are distinct from the sets of values that may be written by 
> any other thread, except null value.
> - each thread reads field 'cachedLoader' and can verfy that it has read 
> a value that belongs to the set of its own written values, or null value 
> (in other words, a thread can verify that it has read a value that was 
> written by self or null value).
> - reads and writes of own set of non-null values always appear in 
> program order since they are performed by same thread
> - a sequence of writes of own set of non-null values performed by some 
> thread begins after this thread 1st observes a null value read from the 
> field and ends before this thread finally writes null value back to the 
> field. The last write performed by some thread is therefore always a 
> write of null value.
> 
> No matter how writes performed by a mixture of threads finally hit the 
> actual field, since each thread that writes to it issues its final write 
> of null value, the value that eventually ends in the field is null value.
> 
> Does this make sense?
> 
> Regards, Peter
> 
> On 10/23/17 22:47, Peter Levart wrote:
>> Hi Ogata,
>>
>> Sorry for late reply. You are absolutely right. Good catch! I missed 
>> this scenario. The criteria for placing the mark (current Thread) on a 
>> cachedLoader must include the check that validates previous value for 
>> later restoration which uses the same criteria. Only in such case will 
>> one thread never restore something that has not been placed by it. And 
>> this guarantees that consumed OIS will never retain a reference to any 
>> ClassLoader or Thread. Your webrev.03 looks good to me.
>>
>> Regards, Peter
>>
>> On 10/17/17 13:48, Kazunori Ogata wrote:
>>> Hi Peter,
>>>
>>> Thank you for your comments and the fix.? It's a good idea to mark
>>> cachedLoader with the Thread object.
>>>
>>>
>>> I think we need to check the marking thread of cachedLoader before
>>> updating it.? Otherwise, there is a scenario that can leak a 
>>> CachedLoader
>>> object:
>>>
>>> //1. Thread-A enters readObject() and then call resolveClass()
>>> outerCL-A <- null
>>> cachedLoader <- Thread-A
>>> cachedLoader <- CachedLoader-A
>>>
>>> //2. Thread-B enters readObject() and then call resolveClass()
>>> outerCL-B <- CachedLoader-A
>>> cachedLoader <- Thread-B
>>> cachedLoader <- CachedLoader-B1
>>>
>>> //3. Thread-B returns from readObject()
>>> cachedLoader is unchanged because outerCL.thread == Thread-A
>>>
>>> //4. Thread-B enters readObject() again and then call resolveClass()
>>> outerCL-B <- CachedLoader-B1
>>> cachedLoader <- Thread-B
>>> cachedLoader <- CachedLoader-B2
>>>
>>> //5. Thread-A returns from readObject()
>>> cachedLoader <- null
>>>
>>> //6. Thread-B returns from readObject()
>>> cachedLoader <- CachedLoader-B1? // Because outerCL-B.thread is Thread-B
>>>
>>>
>>> By adding checking before updating the mark, Thread-B won't update
>>> cachedLoader, or it only saves null when race occurs (and always 
>>> restores
>>> to null on exit).
>>>
>>>
>>> Here is the updated webrev:
>>> http://cr.openjdk.java.net/~horii/8188858/webrev.03/
>>>
>>> I also made minor changes to reduce the number of invocation of the JNI
>>> method Thread.currentThread().
>>>
>>>
>>> Regards,
>>> Ogata
>>>
>>>
>>>
>>> From:?? Peter Levart<peter.levart at gmail.com>
>>> To:???? Kazunori Ogata<OGATAK at jp.ibm.com>, Alan Bateman
>>> <Alan.Bateman at oracle.com>
>>> Cc:core-libs-dev at openjdk.java.net
>>> Date:?? 2017/10/16 19:58
>>> Subject:??????? Re: RFR: 8188858: Caching latestUserDefinedLoader()
>>> results in ObjectInputStream.readObject()
>>>
>>>
>>>
>>> Hi Ogata,
>>>
>>> I found a problem in my last suggestion. See below...
>>>
>>> On 10/16/2017 11:36 AM, Peter Levart wrote:
>>>> On 10/16/2017 11:02 AM, Peter Levart wrote:
>>>>> For example:
>>>>> - let public readObject() / readUnshared() entry and exit points just
>>>>> clear the cached loader (set it to null).
>>>> An alternative would be for entry point to save and clear the cached
>>>> loader while exit point would restore / clear it if it is from correct
>>>> thread / when the call was not nested. Like the following:
>>>>
>>>> public Object readObject() {
>>>> ???? CachedLoader outerCL = cachedLoader;
>>>> ???? cachedLoader = null;
>>>> ???? try {
>>>> ???????? ...
>>>> ???? } finally {
>>>> ???????? if (outerCL == null || outerCL.thread ==
>>>> Thread.currentThread()) {
>>>> ???????????? // restore/clear cached loader when nested/outer call ends
>>>> ???????????? cachedLoader = outerCL;
>>>> ???????? }
>>>> ???? }
>>>> }
>>>>
>>>> with resolveClass() fragment repeated here for comparison:
>>>>
>>>> ?????????? CachedLoader cl = cachedLoader;
>>>> ?????????? Thread curThread = Thread.currentThread();
>>>> ?????????? ClassLoader loader;
>>>> ?????????? if (cl == null) {
>>>> ?????????????? loader = latestUserDefinedLoader();
>>>> ?????????????? cachedLoader = new CachedLoader(loader, curThread);
>>>> ?????????? } else if (cl.thread == curThread) {
>>>> ?????????????? loader = cl.loader;
>>>> ?????????? } else {
>>>> ?????????????? // multi threaded use
>>>> ?????????????? loader = latestUserDefinedLoader();
>>>> ?????????? }
>>>>
>>>> ?????????? // and then...
>>>> ?????????? return Class.forName(name, false, loader);
>>>>
>>>>
>>>> There are all sorts of races possible when called concurrently from
>>>> multiple threads, but the worst consequence is that the loader is not
>>>> cached. I also think that even in the presence of races, the
>>>> cachedLoader is eventually cleared when all calls to OIS complete. I
>>>> couldn't think of a situation where such cached loader would remain
>>>> hanging off the completed OIS because of races.
>>>>
>>>> Well, there is one such situation but for a different reason. For
>>>> example, if an OIS subclass is constructed solely to override
>>>> resolveClass method to make it accessible to custom code (for example,
>>>> make it public and call super.resolveClass()) in order to provide a
>>>> utility for resolving classes with the default OIS semantics, but such
>>>> OIS instance is never used for deserialization itself
>>>> (readObject()/readUnshared() is never called).
>>>>
>>>> To solve this problem, resolveClass() logic, including lazy caching,
>>>> should be moved to a private method (resolveClass0()) with protected
>>>> resolveClass() treated like public readObject()/readUnshared() with
>>>> before/after treatment of cached loader around delegation to
>>>> resolveClass0(). All OIS internal uses of resolveClass() should then
>>>> be redirected to resolveClass0().
>>> Oops, this would not work for subclasses that override resolveClass()
>>> with custom logic. Hm...
>>>
>>> The correct and optimal solution is a little bit more involved, I think.
>>> Here's what I think should work (did not run any tests yet):
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Eplevart_jdk10-2Ddev_8188858-5FOIS.latestUserDefinedLoader.caching_webrev.01_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=PbaGqOdJOR6jMQkXDVYmjn6832m7o0LU2bzwt2awUgQ&s=gKz_rwcTcGIw8JvmRqlg1-OtjqFNXmIs4oQmIXlF3Wc&e= 
>>>
>>>
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>>
>>>
>>
> 

From OGATAK at jp.ibm.com  Tue Oct 24 10:53:16 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Tue, 24 Oct 2017 19:53:16 +0900
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <OF64D397E2.26E0B836-ON002581C3.0025854D@LocalDomain>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
 <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
 <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>
 <1238393b-0d7f-9fea-eb75-3fd816c951a5@gmail.com>
 <OFA0D9E522.56232230-ON492581BC.003EF1D9-492581BC.0040E6BF@notes.na.collabserv.com>
 <e2b5c5bf-1622-65bb-29d0-310f3b185529@gmail.com>
 <d27acb55-12fc-2a3d-1fa9-490a038
 <OF64D397E2.26E0B836-ON002581C3.0025854D@LocalDomain>
Message-ID: <OFD71AE604.154EE836-ON492581C3.003A96A9-492581C3.003BD067@notes.na.collabserv.com>

Hi David,

Yes I think the code works correctly even if cachedLoader is not volatile. 
 When a thread see a non-volatile value, it is either a Thread or 
CachedLoader object and the thread can check if it owns the cache.  If it 
does, the thread uses the cache and cleans it up on return.  If two or 
more threads see null, each of them tries to grab the cache by putting its 
Thread object, but one of them will win.  Then, the won thread use the 
cache and cleans it up on return.

I update webrev by adding a few lines of comment as:

2442     // This field is left non-volatile although there is a benign 
race here.
2443     // The thread that see a non-null value can always check if the 
cache is for
2444     // the thread, and such thread always cleans up the cache on 
return.

Comments for revising the text (and fixing my poor English) are welcome.

Webrev: http://cr.openjdk.java.net/~horii/8188858/webrev.04/


Regards,
Ogata




From:   David Holmes <david.holmes at oracle.com>
To:     Peter Levart <peter.levart at gmail.com>, Kazunori Ogata 
<OGATAK at jp.ibm.com>
Cc:     core-libs-dev at openjdk.java.net
Date:   2017/10/24 15:49
Subject:        Re: RFR: 8188858: Caching latestUserDefinedLoader() 
results in ObjectInputStream.readObject()



Hi Peter, Ogata,

Are you saying this is correct even if cachedLoader is not volatile? If 
so then that needs to be clearly documented.

Cheers,
David

On 24/10/2017 3:11 PM, Peter Levart wrote:
> Hi,
> 
> I think that what Ogata has in webrev.03 is correct and the reasoning 
> could be as follows:
> 
> - each thread writes to field 'cachedLoader' only from its own set of 
> values that are distinct from the sets of values that may be written by 
> any other thread, except null value.
> - each thread reads field 'cachedLoader' and can verfy that it has read 
> a value that belongs to the set of its own written values, or null value 

> (in other words, a thread can verify that it has read a value that was 
> written by self or null value).
> - reads and writes of own set of non-null values always appear in 
> program order since they are performed by same thread
> - a sequence of writes of own set of non-null values performed by some 
> thread begins after this thread 1st observes a null value read from the 
> field and ends before this thread finally writes null value back to the 
> field. The last write performed by some thread is therefore always a 
> write of null value.
> 
> No matter how writes performed by a mixture of threads finally hit the 
> actual field, since each thread that writes to it issues its final write 

> of null value, the value that eventually ends in the field is null 
value.
> 
> Does this make sense?
> 
> Regards, Peter
> 
> On 10/23/17 22:47, Peter Levart wrote:
>> Hi Ogata,
>>
>> Sorry for late reply. You are absolutely right. Good catch! I missed 
>> this scenario. The criteria for placing the mark (current Thread) on a 
>> cachedLoader must include the check that validates previous value for 
>> later restoration which uses the same criteria. Only in such case will 
>> one thread never restore something that has not been placed by it. And 
>> this guarantees that consumed OIS will never retain a reference to any 
>> ClassLoader or Thread. Your webrev.03 looks good to me.
>>
>> Regards, Peter
>>
>> On 10/17/17 13:48, Kazunori Ogata wrote:
>>> Hi Peter,
>>>
>>> Thank you for your comments and the fix.  It's a good idea to mark
>>> cachedLoader with the Thread object.
>>>
>>>
>>> I think we need to check the marking thread of cachedLoader before
>>> updating it.  Otherwise, there is a scenario that can leak a 
>>> CachedLoader
>>> object:
>>>
>>> //1. Thread-A enters readObject() and then call resolveClass()
>>> outerCL-A <- null
>>> cachedLoader <- Thread-A
>>> cachedLoader <- CachedLoader-A
>>>
>>> //2. Thread-B enters readObject() and then call resolveClass()
>>> outerCL-B <- CachedLoader-A
>>> cachedLoader <- Thread-B
>>> cachedLoader <- CachedLoader-B1
>>>
>>> //3. Thread-B returns from readObject()
>>> cachedLoader is unchanged because outerCL.thread == Thread-A
>>>
>>> //4. Thread-B enters readObject() again and then call resolveClass()
>>> outerCL-B <- CachedLoader-B1
>>> cachedLoader <- Thread-B
>>> cachedLoader <- CachedLoader-B2
>>>
>>> //5. Thread-A returns from readObject()
>>> cachedLoader <- null
>>>
>>> //6. Thread-B returns from readObject()
>>> cachedLoader <- CachedLoader-B1  // Because outerCL-B.thread is 
Thread-B
>>>
>>>
>>> By adding checking before updating the mark, Thread-B won't update
>>> cachedLoader, or it only saves null when race occurs (and always 
>>> restores
>>> to null on exit).
>>>
>>>
>>> Here is the updated webrev:
>>> 
https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ehorii_8188858_webrev.03_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=Lh5fRAQa1sl79bnwNQva_URzWaEPL1yhaq0KTsohwN4&s=YMrI-UsCdrRwbHvcIXT5VlVXRVi3PRCjjt11k8G8jHE&e=

>>>
>>> I also made minor changes to reduce the number of invocation of the 
JNI
>>> method Thread.currentThread().
>>>
>>>
>>> Regards,
>>> Ogata
>>>
>>>
>>>
>>> From:   Peter Levart<peter.levart at gmail.com>
>>> To:     Kazunori Ogata<OGATAK at jp.ibm.com>, Alan Bateman
>>> <Alan.Bateman at oracle.com>
>>> Cc:core-libs-dev at openjdk.java.net
>>> Date:   2017/10/16 19:58
>>> Subject:        Re: RFR: 8188858: Caching latestUserDefinedLoader()
>>> results in ObjectInputStream.readObject()
>>>
>>>
>>>
>>> Hi Ogata,
>>>
>>> I found a problem in my last suggestion. See below...
>>>
>>> On 10/16/2017 11:36 AM, Peter Levart wrote:
>>>> On 10/16/2017 11:02 AM, Peter Levart wrote:
>>>>> For example:
>>>>> - let public readObject() / readUnshared() entry and exit points 
just
>>>>> clear the cached loader (set it to null).
>>>> An alternative would be for entry point to save and clear the cached
>>>> loader while exit point would restore / clear it if it is from 
correct
>>>> thread / when the call was not nested. Like the following:
>>>>
>>>> public Object readObject() {
>>>>      CachedLoader outerCL = cachedLoader;
>>>>      cachedLoader = null;
>>>>      try {
>>>>          ...
>>>>      } finally {
>>>>          if (outerCL == null || outerCL.thread ==
>>>> Thread.currentThread()) {
>>>>              // restore/clear cached loader when nested/outer call 
ends
>>>>              cachedLoader = outerCL;
>>>>          }
>>>>      }
>>>> }
>>>>
>>>> with resolveClass() fragment repeated here for comparison:
>>>>
>>>>            CachedLoader cl = cachedLoader;
>>>>            Thread curThread = Thread.currentThread();
>>>>            ClassLoader loader;
>>>>            if (cl == null) {
>>>>                loader = latestUserDefinedLoader();
>>>>                cachedLoader = new CachedLoader(loader, curThread);
>>>>            } else if (cl.thread == curThread) {
>>>>                loader = cl.loader;
>>>>            } else {
>>>>                // multi threaded use
>>>>                loader = latestUserDefinedLoader();
>>>>            }
>>>>
>>>>            // and then...
>>>>            return Class.forName(name, false, loader);
>>>>
>>>>
>>>> There are all sorts of races possible when called concurrently from
>>>> multiple threads, but the worst consequence is that the loader is not
>>>> cached. I also think that even in the presence of races, the
>>>> cachedLoader is eventually cleared when all calls to OIS complete. I
>>>> couldn't think of a situation where such cached loader would remain
>>>> hanging off the completed OIS because of races.
>>>>
>>>> Well, there is one such situation but for a different reason. For
>>>> example, if an OIS subclass is constructed solely to override
>>>> resolveClass method to make it accessible to custom code (for 
example,
>>>> make it public and call super.resolveClass()) in order to provide a
>>>> utility for resolving classes with the default OIS semantics, but 
such
>>>> OIS instance is never used for deserialization itself
>>>> (readObject()/readUnshared() is never called).
>>>>
>>>> To solve this problem, resolveClass() logic, including lazy caching,
>>>> should be moved to a private method (resolveClass0()) with protected
>>>> resolveClass() treated like public readObject()/readUnshared() with
>>>> before/after treatment of cached loader around delegation to
>>>> resolveClass0(). All OIS internal uses of resolveClass() should then
>>>> be redirected to resolveClass0().
>>> Oops, this would not work for subclasses that override resolveClass()
>>> with custom logic. Hm...
>>>
>>> The correct and optimal solution is a little bit more involved, I 
think.
>>> Here's what I think should work (did not run any tests yet):
>>>
>>> 
https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Eplevart_jdk10-2Ddev_8188858-5FOIS.latestUserDefinedLoader.caching_webrev.01_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=PbaGqOdJOR6jMQkXDVYmjn6832m7o0LU2bzwt2awUgQ&s=gKz_rwcTcGIw8JvmRqlg1-OtjqFNXmIs4oQmIXlF3Wc&e= 

>>>
>>>
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>>
>>>
>>
> 





From naoto.sato at oracle.com  Tue Oct 24 15:00:40 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 24 Oct 2017 08:00:40 -0700
Subject: [10] RFR: 8189272 & 8189291
In-Reply-To: <3f337987-1628-62eb-1f6c-0aaa7e1ebc8e@oracle.com>
References: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>
 <0a8bc81d-694e-aa8d-8530-e21f890b3507@oracle.com>
 <6d9c21d5-4baa-89b7-28be-519e70f88f10@oracle.com>
 <3f337987-1628-62eb-1f6c-0aaa7e1ebc8e@oracle.com>
Message-ID: <9a46809b-eea1-9da8-4427-3665a82e98fe@oracle.com>

Hi Mandy,

Sorry, I seem to have generated/uploaded an incorrect webrev for 
8189291. Here is the correct one:

http://cr.openjdk.java.net/~naoto/8189291/webrev.02/

Naoto

On 10/23/17 5:48 PM, mandy chung wrote:
> 
> 
> On 10/20/17 5:05 PM, Naoto Sato wrote:
>> Hi Mandy,
>>
>> Thanks for the review. Webrevs updated as suggested:
>>
>> http://cr.openjdk.java.net/~naoto/8189272/webrev.01/
>> http://cr.openjdk.java.net/~naoto/8189291/webrev.01/
>>
> 
> DEFAULT_POLICY in test/jdk/java/util/logging/* tests can be moved to the 
> enclosing class as suggested.
> 
> Other than that, the change looks good.
> 
> Mandy
> 
>> Naoto
>>
>> On 10/20/17 2:45 PM, mandy chung wrote:
>>>
>>>
>>> On 10/20/17 2:20 PM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the changes for the following two issues:
>>>>
>>>> 8189272: CLDR and JRE LocaleProviderAdapters silently swallow 
>>>> exceptions [1]
>>>> 8189291: Test policy should extend the default system policy [2]
>>>>
>>>> The proposed fixes for the above issues are located below, 
>>>> respectively:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8189272/webrev.00/
>>>
>>> Looks fine.? The installed providers are our implementation and 
>>> silently ignore any exception would make it really hard to diagnose 
>>> problems. This change will help the diagnosability.
>>>
>>>> http://cr.openjdk.java.net/~naoto/8189291/webrev.00/
>>>>
>>>
>>> If the default policy is not cached early before any test policy is 
>>> constructed, the test might get the wrong Policy object set by the 
>>> test previously (for example, if it runs in agentvm mode).?? It would 
>>> be more reliable if this is cached as the static field in the test 
>>> class (i.e. the enclosing class of the policy subclass) - like 
>>> CallerSensitiveTest.
>>>
>>> test/jdk/sun/util/locale/provider/Bug8038436.java
>>> - I think the test fix should be part of JDK-8189272, right?
>>>
>>> Mandy
>>>> The fix to 8189272 will throw exceptions that were swallowed in 
>>>> those providers, which should not happen in proper environment. That 
>>>> fix makes test cases with security manager fail. The fix to 8189291 
>>>> addresses it.
>>>>
>>>> Naoto
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8189272
>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8189291
>>>
> 

From mandy.chung at oracle.com  Tue Oct 24 15:41:42 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 24 Oct 2017 08:41:42 -0700
Subject: [10] RFR: 8189272 & 8189291
In-Reply-To: <9a46809b-eea1-9da8-4427-3665a82e98fe@oracle.com>
References: <2ef8d50d-605c-305c-cef8-290682e9a954@oracle.com>
 <0a8bc81d-694e-aa8d-8530-e21f890b3507@oracle.com>
 <6d9c21d5-4baa-89b7-28be-519e70f88f10@oracle.com>
 <3f337987-1628-62eb-1f6c-0aaa7e1ebc8e@oracle.com>
 <9a46809b-eea1-9da8-4427-3665a82e98fe@oracle.com>
Message-ID: <f5d1bbc8-1507-7f86-8839-90d675e23d6f@oracle.com>



On 10/24/17 8:00 AM, Naoto Sato wrote:
> Hi Mandy,
>
> Sorry, I seem to have generated/uploaded an incorrect webrev for 
> 8189291. Here is the correct one:
>
> http://cr.openjdk.java.net/~naoto/8189291/webrev.02/
>

+1

Mandy


From peter.levart at gmail.com  Tue Oct 24 21:17:22 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 24 Oct 2017 23:17:22 +0200
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <OFD71AE604.154EE836-ON492581C3.003A96A9-492581C3.003BD067@notes.na.collabserv.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
 <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
 <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>
 <1238393b-0d7f-9fea-eb75-3fd816c951a5@gmail.com>
 <OFA0D9E522.56232230-ON492581BC.003EF1D9-492581BC.0040E6BF@notes.na.collabserv.com>
 <e2b5c5bf-1622-65bb-29d0-310f3b185529@gmail.com>
 <d27acb55-12fc-2a3d-1fa9-490a038
 <OF64D397E2.26E0B836-ON002581C3.0025854D@LocalDomain>
 <OFD71AE604.154EE836-ON492581C3.003A96A9-492581C3.003BD067@notes.na.collabserv.com>
Message-ID: <e479d23e-72af-9bdf-9392-518a99166298@gmail.com>

Hi Ogata, David,

On 10/24/17 12:53, Kazunori Ogata wrote:
> Hi David,
>
> Yes I think the code works correctly even if cachedLoader is not volatile.
>   When a thread see a non-volatile value, it is either a Thread or
> CachedLoader object and the thread can check if it owns the cache.  If it
> does, the thread uses the cache and cleans it up on return.  If two or
> more threads see null, each of them tries to grab the cache by putting its
> Thread object, but one of them will win.  Then, the won thread use the
> cache and cleans it up on return.

It may happen that two or more threads that see null all "win". For example:

Thread-A and Thread-B see null 'cachedLoader' field and each writes a 
reference to its own Thread object to it.
In a concurrent call to resolveClass(), both threads issue a read from 
'cachedLoader' and each see a reference to a Thread object. Since this 
is not a volatile field, each thread may see either its own Thread 
object or the other Thread object. All 4 combinations are allowed. So it 
may happen that each thread sees its own Thread object, so each thread 
evaluates its own VM.latestUserDefinedLoader(), wraps it with 
CachedLoader and writes a reference to 'cachedLoader' field.
Both threads then may or may not use its own cached value in subsequent 
internal calls to resolveClass(), depending on which value of 
'cachedLoader' they see. They may see its own value or some other 
thread's value. Each thread only uses it's own value and ignores other 
thread's values.
What is important it that finally both threads write null to 
'cachedLoader' before returning from external call to ObjectInputStream.
When non volatile field is accessed by multiple threads, it may behave 
like volatile field on one end of the spectrum or like a thread-local 
variable on the other end, but usually something in between. The code 
behaves correctly for either end or anything in between.

It's not that we want only one thread to use the cache. We want two things:

- if cached ClassLoader is used by some thread then we must guarantee 
that it is a ClassLoader that was evaluated 
(VM.latestUserDefinedLoader()) by the same thread in the same external 
ObjectInputStream call. This is guaranteed by the fact that we keep the 
evaluated ClassLoader and the evaluating Thread together in the 
CachedLoader object and only use the cached ClassLoader if current 
thread is the same as the one that evaluated it.
- if a thread uses cache in some ObjectInputStream call, then the thread 
must also clean-up the cache to not retain either Thread or ClassLoader 
objects for more time than needed. This guarantee has been described in 
my previous email and could be summarized by the following assertion: if 
some thread writes values to 'cachedLoader' field in some external call 
to ObjectInputStream, then the last value written by such thread in such 
call is null value.

These two things are all we need to be sure of. And of course, that the 
cache is effective for the common (and the only valid) case of using 
ObjectInputStream instance in a single thread.

Regards, Peter

> I update webrev by adding a few lines of comment as:
>
> 2442     // This field is left non-volatile although there is a benign
> race here.
> 2443     // The thread that see a non-null value can always check if the
> cache is for
> 2444     // the thread, and such thread always cleans up the cache on
> return.
>
> Comments for revising the text (and fixing my poor English) are welcome.

It's hard to come up with a nice short explanation that is 
understandable to anyone. I'll try to come up with something tomorrow.

Regards, Peter

> Webrev: http://cr.openjdk.java.net/~horii/8188858/webrev.04/
>
>
> Regards,
> Ogata
>
>
>
>
> From:   David Holmes <david.holmes at oracle.com>
> To:     Peter Levart <peter.levart at gmail.com>, Kazunori Ogata
> <OGATAK at jp.ibm.com>
> Cc:     core-libs-dev at openjdk.java.net
> Date:   2017/10/24 15:49
> Subject:        Re: RFR: 8188858: Caching latestUserDefinedLoader()
> results in ObjectInputStream.readObject()
>
>
>
> Hi Peter, Ogata,
>
> Are you saying this is correct even if cachedLoader is not volatile? If
> so then that needs to be clearly documented.
>
> Cheers,
> David
>
> On 24/10/2017 3:11 PM, Peter Levart wrote:
>> Hi,
>>
>> I think that what Ogata has in webrev.03 is correct and the reasoning
>> could be as follows:
>>
>> - each thread writes to field 'cachedLoader' only from its own set of
>> values that are distinct from the sets of values that may be written by
>> any other thread, except null value.
>> - each thread reads field 'cachedLoader' and can verfy that it has read
>> a value that belongs to the set of its own written values, or null value
>> (in other words, a thread can verify that it has read a value that was
>> written by self or null value).
>> - reads and writes of own set of non-null values always appear in
>> program order since they are performed by same thread
>> - a sequence of writes of own set of non-null values performed by some
>> thread begins after this thread 1st observes a null value read from the
>> field and ends before this thread finally writes null value back to the
>> field. The last write performed by some thread is therefore always a
>> write of null value.
>>
>> No matter how writes performed by a mixture of threads finally hit the
>> actual field, since each thread that writes to it issues its final write
>> of null value, the value that eventually ends in the field is null
> value.
>> Does this make sense?
>>
>> Regards, Peter
>>
>> On 10/23/17 22:47, Peter Levart wrote:
>>> Hi Ogata,
>>>
>>> Sorry for late reply. You are absolutely right. Good catch! I missed
>>> this scenario. The criteria for placing the mark (current Thread) on a
>>> cachedLoader must include the check that validates previous value for
>>> later restoration which uses the same criteria. Only in such case will
>>> one thread never restore something that has not been placed by it. And
>>> this guarantees that consumed OIS will never retain a reference to any
>>> ClassLoader or Thread. Your webrev.03 looks good to me.
>>>
>>> Regards, Peter
>>>
>>> On 10/17/17 13:48, Kazunori Ogata wrote:
>>>> Hi Peter,
>>>>
>>>> Thank you for your comments and the fix.  It's a good idea to mark
>>>> cachedLoader with the Thread object.
>>>>
>>>>
>>>> I think we need to check the marking thread of cachedLoader before
>>>> updating it.  Otherwise, there is a scenario that can leak a
>>>> CachedLoader
>>>> object:
>>>>
>>>> //1. Thread-A enters readObject() and then call resolveClass()
>>>> outerCL-A <- null
>>>> cachedLoader <- Thread-A
>>>> cachedLoader <- CachedLoader-A
>>>>
>>>> //2. Thread-B enters readObject() and then call resolveClass()
>>>> outerCL-B <- CachedLoader-A
>>>> cachedLoader <- Thread-B
>>>> cachedLoader <- CachedLoader-B1
>>>>
>>>> //3. Thread-B returns from readObject()
>>>> cachedLoader is unchanged because outerCL.thread == Thread-A
>>>>
>>>> //4. Thread-B enters readObject() again and then call resolveClass()
>>>> outerCL-B <- CachedLoader-B1
>>>> cachedLoader <- Thread-B
>>>> cachedLoader <- CachedLoader-B2
>>>>
>>>> //5. Thread-A returns from readObject()
>>>> cachedLoader <- null
>>>>
>>>> //6. Thread-B returns from readObject()
>>>> cachedLoader <- CachedLoader-B1  // Because outerCL-B.thread is
> Thread-B
>>>> By adding checking before updating the mark, Thread-B won't update
>>>> cachedLoader, or it only saves null when race occurs (and always
>>>> restores
>>>> to null on exit).
>>>>
>>>>
>>>> Here is the updated webrev:
>>>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ehorii_8188858_webrev.03_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=Lh5fRAQa1sl79bnwNQva_URzWaEPL1yhaq0KTsohwN4&s=YMrI-UsCdrRwbHvcIXT5VlVXRVi3PRCjjt11k8G8jHE&e=
>
>>>> I also made minor changes to reduce the number of invocation of the
> JNI
>>>> method Thread.currentThread().
>>>>
>>>>
>>>> Regards,
>>>> Ogata
>>>>
>>>>
>>>>
>>>> From:   Peter Levart<peter.levart at gmail.com>
>>>> To:     Kazunori Ogata<OGATAK at jp.ibm.com>, Alan Bateman
>>>> <Alan.Bateman at oracle.com>
>>>> Cc:core-libs-dev at openjdk.java.net
>>>> Date:   2017/10/16 19:58
>>>> Subject:        Re: RFR: 8188858: Caching latestUserDefinedLoader()
>>>> results in ObjectInputStream.readObject()
>>>>
>>>>
>>>>
>>>> Hi Ogata,
>>>>
>>>> I found a problem in my last suggestion. See below...
>>>>
>>>> On 10/16/2017 11:36 AM, Peter Levart wrote:
>>>>> On 10/16/2017 11:02 AM, Peter Levart wrote:
>>>>>> For example:
>>>>>> - let public readObject() / readUnshared() entry and exit points
> just
>>>>>> clear the cached loader (set it to null).
>>>>> An alternative would be for entry point to save and clear the cached
>>>>> loader while exit point would restore / clear it if it is from
> correct
>>>>> thread / when the call was not nested. Like the following:
>>>>>
>>>>> public Object readObject() {
>>>>>       CachedLoader outerCL = cachedLoader;
>>>>>       cachedLoader = null;
>>>>>       try {
>>>>>           ...
>>>>>       } finally {
>>>>>           if (outerCL == null || outerCL.thread ==
>>>>> Thread.currentThread()) {
>>>>>               // restore/clear cached loader when nested/outer call
> ends
>>>>>               cachedLoader = outerCL;
>>>>>           }
>>>>>       }
>>>>> }
>>>>>
>>>>> with resolveClass() fragment repeated here for comparison:
>>>>>
>>>>>             CachedLoader cl = cachedLoader;
>>>>>             Thread curThread = Thread.currentThread();
>>>>>             ClassLoader loader;
>>>>>             if (cl == null) {
>>>>>                 loader = latestUserDefinedLoader();
>>>>>                 cachedLoader = new CachedLoader(loader, curThread);
>>>>>             } else if (cl.thread == curThread) {
>>>>>                 loader = cl.loader;
>>>>>             } else {
>>>>>                 // multi threaded use
>>>>>                 loader = latestUserDefinedLoader();
>>>>>             }
>>>>>
>>>>>             // and then...
>>>>>             return Class.forName(name, false, loader);
>>>>>
>>>>>
>>>>> There are all sorts of races possible when called concurrently from
>>>>> multiple threads, but the worst consequence is that the loader is not
>>>>> cached. I also think that even in the presence of races, the
>>>>> cachedLoader is eventually cleared when all calls to OIS complete. I
>>>>> couldn't think of a situation where such cached loader would remain
>>>>> hanging off the completed OIS because of races.
>>>>>
>>>>> Well, there is one such situation but for a different reason. For
>>>>> example, if an OIS subclass is constructed solely to override
>>>>> resolveClass method to make it accessible to custom code (for
> example,
>>>>> make it public and call super.resolveClass()) in order to provide a
>>>>> utility for resolving classes with the default OIS semantics, but
> such
>>>>> OIS instance is never used for deserialization itself
>>>>> (readObject()/readUnshared() is never called).
>>>>>
>>>>> To solve this problem, resolveClass() logic, including lazy caching,
>>>>> should be moved to a private method (resolveClass0()) with protected
>>>>> resolveClass() treated like public readObject()/readUnshared() with
>>>>> before/after treatment of cached loader around delegation to
>>>>> resolveClass0(). All OIS internal uses of resolveClass() should then
>>>>> be redirected to resolveClass0().
>>>> Oops, this would not work for subclasses that override resolveClass()
>>>> with custom logic. Hm...
>>>>
>>>> The correct and optimal solution is a little bit more involved, I
> think.
>>>> Here's what I think should work (did not run any tests yet):
>>>>
>>>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Eplevart_jdk10-2Ddev_8188858-5FOIS.latestUserDefinedLoader.caching_webrev.01_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=PbaGqOdJOR6jMQkXDVYmjn6832m7o0LU2bzwt2awUgQ&s=gKz_rwcTcGIw8JvmRqlg1-OtjqFNXmIs4oQmIXlF3Wc&e=
>
>>>> Regards, Peter
>>>>
>>>>
>>>>
>>>>
>
>


From brent.christian at oracle.com  Wed Oct 25 00:21:16 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 24 Oct 2017 17:21:16 -0700
Subject: RFR: 8183901 : Fix broken links to "Package Sealing" in the JAR spec
Message-ID: <513ce70e-7369-a919-aa33-e944c85f6213@oracle.com>

Hi,

Please review my fix of a few broken links to the "Package Sealing" 
section of the Jar Spec[1].

http://cr.openjdk.java.net/~bchristi/8183901/

Thanks,
-Brent

1. https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#package-sealing

From mandy.chung at oracle.com  Wed Oct 25 00:49:53 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 24 Oct 2017 17:49:53 -0700
Subject: RFR: 8183901 : Fix broken links to "Package Sealing" in the JAR
 spec
In-Reply-To: <513ce70e-7369-a919-aa33-e944c85f6213@oracle.com>
References: <513ce70e-7369-a919-aa33-e944c85f6213@oracle.com>
Message-ID: <42285e9a-8e14-b48e-2f67-4d7b50f3d039@oracle.com>

+1

Mandy

On 10/24/17 5:21 PM, Brent Christian wrote:
> Hi,
>
> Please review my fix of a few broken links to the "Package Sealing" 
> section of the Jar Spec[1].
>
> http://cr.openjdk.java.net/~bchristi/8183901/
>
> Thanks,
> -Brent
>
> 1. 
> https://docs.oracle.com/javase/9/docs/specs/jar/jar.html#package-sealing


From zheng.jun.li at oracle.com  Wed Oct 25 02:00:50 2017
From: zheng.jun.li at oracle.com (Jack Li)
Date: Wed, 25 Oct 2017 10:00:50 +0800
Subject: RFR: 8187954 Update JAX-WS RI integration to latest version
In-Reply-To: <50F96A1B-78C3-4FC4-82E5-691E06749F29@oracle.com>
References: <12668CC3-A8DB-4BDC-9F21-5068CA559DA8@oracle.com>
 <DE008EE6-ABC3-455F-85D0-C83239CD4622@oracle.com>
 <A9736FE3-E30D-4EDD-839F-6FFAB6A4BF38@oracle.com>
 <B53D7902-137F-4082-930F-713D427E3CDF@oracle.com>
 <95066DA9-03A6-4BF1-8895-6A442548EC60@oracle.com>
 <50F96A1B-78C3-4FC4-82E5-691E06749F29@oracle.com>
Message-ID: <A6E211A7-10B2-4242-939E-F6CEB6BFC726@oracle.com>

Hi Lance,

The webrev is updated, can you please review it again?

JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> 
Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01 <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/01>

Summary of changes:

jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module

jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
And also contains the fixes for importing nodes for SOAPDocumentFragment


Patch also contains several small bugfixes, not tracked in JBS.

> On Oct 11, 2017, at 18:47, Lance Andersen <lance.andersen at oracle.com> wrote:
> 
> Hi Jack,
> 
> I would prefer to see an updated webrev so that we do not inadvertently
> push these changes.
> 
> Best
> Lance
>> On Oct 11, 2017, at 3:26 AM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>> 
>> Hi Lance
>> 
>> I will update them in Metro repository, do I need to regenerate webrev?
>> or can you skip the files this time and I fix it in next integration?
>> 
>>> On Oct 9, 2017, at 19:35, Lance Andersen <lance.andersen at oracle.com <mailto:lance.andersen at oracle.com>> wrote:
>>> 
>>> Hi Jack,
>>> 
>>> UnMarshaller also has the same issue.  I would update the webrev given the number of places to help sanity check for omissions
>>> 
>>> Best
>>> Lance
>>>> On Oct 8, 2017, at 9:22 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>> 
>>>> Hi Lance,
>>>> 
>>>> the change is incorrect, it should be ?javax/xml/bind?.
>>>> thanks a lot for your finding, do you think I need to fix it and resubmit the webrev this time?
>>>> or can you skip this file this time and I fix it in next integration?
>>>> 
>>>>> On Oct 4, 2017, at 02:09, Lance Andersen <Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>> wrote:
>>>>> 
>>>>> Hi Jack,
>>>>> 
>>>>> Is this change correct:
>>>>> 
>>>>> -------------
>>>>> --- old/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.968185273 +0100
>>>>> +++ new/src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java	2017-09-29 13:58:31.676185267 +0100
>>>>> @@ -373,7 +373,7 @@
>>>>>       *      If the {@link ValidationEventHandler ValidationEventHandler}
>>>>>       *      returns false from its {@code handleEvent} method or the
>>>>>       *      {@code Marshaller} is unable to marshal {@code jaxbElement} (or any
>>>>> -     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/javax/xml/bind/Marshaller.html#elementMarshalling">
>>>>> +     *      object reachable from {@code jaxbElement}).  See <a href="{@docRoot}/java/xml/bind/Marshaller.html#elementMarshalling">
>>>>>       *      Marshalling a JAXB element</a>.
>>>>> 
>>>>> ------------
>>>>> 
>>>>> The URL that is being changed currently works
>>>>> 
>>>>> Best
>>>>> Lance
>>>>> On Sep 29, 2017, at 10:55 PM, Jack Li <zheng.jun.li at oracle.com <mailto:zheng.jun.li at oracle.com>> wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>>>> 
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954> <https://bugs.openjdk.java.net/browse/JDK-8187954 <https://bugs.openjdk.java.net/browse/JDK-8187954>>
>>>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/> <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/ <http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8187954/10/00/>>
>>>>>> 
>>>>>> Summary of changes:
>>>>>> 
>>>>>> jaxws/src/java.xml.bind/share/classes/javax/xml/bind/*
>>>>>> JDK-8186946 - Fix accessibility and other issues in the java.xml.bind module
>>>>>> 
>>>>>> jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/**
>>>>>> JDK-8186314 - code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change
>>>>>> And also contains the fixes for importing nodes for SOAPDocumentFragment
>>>>>> 
>>>>>> 
>>>>>> Patch also contains several small bugfixes, not tracked in JBS.
>>>>>> 
>>>>>> ----------------
>>>>>> Best regards
>>>>>> Jack Li
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> <oracle_sig_logo.gif>
>>>>> 
>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>>> Oracle?Java Engineering?
>>>>> 1 Network Drive?
>>>>> Burlington, MA 01803
>>>>>  <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>>>> 
>>>> ----------------
>>>> Best regards
>>>> Jack Li
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> <oracle_sig_logo.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>
>>>  <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>
>>> 
>>> 
>>> 
>> 
>> 
>> ----------------
>> Best regards
>> Jack Li
> 
> <oracle_sig_logo.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>
>  <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>
> 
> 
> 


----------------
Best regards
Jack Li







From david.holmes at oracle.com  Wed Oct 25 05:25:13 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Oct 2017 15:25:13 +1000
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <e479d23e-72af-9bdf-9392-518a99166298@gmail.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
 <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
 <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>
 <1238393b-0d7f-9fea-eb75-3fd816c951a5@gmail.com>
 <OFA0D9E522.56232230-ON492581BC.003EF1D9-492581BC.0040E6BF@notes.na.collabserv.com>
 <e2b5c5bf-1622-65bb-29d0-310f3b185529@gmail.com>
 <d27acb55-12fc-2a3d-1fa9-490a038
 <OF64D397E2.26E0B836-ON002581C3.0025854D@LocalDomain>
 <OFD71AE604.154EE836-ON492581C3.003A96A9-492581C3.003BD067@notes.na.collabserv.com>
 <e479d23e-72af-9bdf-9392-518a99166298@gmail.com>
Message-ID: <ecd98c34-7981-35ea-684c-15af263f280b@oracle.com>

Hi Peter,

I understand the explanation - thanks. I think some documentation is 
needed else down the track someone will spot the race and also note the 
lack of volatile and "fix it".

Ogata's comment doesn't quite address things as the volatile-ness does 
not affect the race that exists.

Thanks,
David

On 25/10/2017 7:17 AM, Peter Levart wrote:
> Hi Ogata, David,
> 
> On 10/24/17 12:53, Kazunori Ogata wrote:
>> Hi David,
>>
>> Yes I think the code works correctly even if cachedLoader is not volatile.
>>   When a thread see a non-volatile value, it is either a Thread or
>> CachedLoader object and the thread can check if it owns the cache.  If it
>> does, the thread uses the cache and cleans it up on return.  If two or
>> more threads see null, each of them tries to grab the cache by putting its
>> Thread object, but one of them will win.  Then, the won thread use the
>> cache and cleans it up on return.
> 
> It may happen that two or more threads that see null all "win". For example:
> 
> Thread-A and Thread-B see null 'cachedLoader' field and each writes a 
> reference to its own Thread object to it.
> In a concurrent call to resolveClass(), both threads issue a read from 
> 'cachedLoader' and each see a reference to a Thread object. Since this 
> is not a volatile field, each thread may see either its own Thread 
> object or the other Thread object. All 4 combinations are allowed. So it 
> may happen that each thread sees its own Thread object, so each thread 
> evaluates its own VM.latestUserDefinedLoader(), wraps it with 
> CachedLoader and writes a reference to 'cachedLoader' field.
> Both threads then may or may not use its own cached value in subsequent 
> internal calls to resolveClass(), depending on which value of 
> 'cachedLoader' they see. They may see its own value or some other 
> thread's value. Each thread only uses it's own value and ignores other 
> thread's values.
> What is important it that finally both threads write null to 
> 'cachedLoader' before returning from external call to ObjectInputStream.
> When non volatile field is accessed by multiple threads, it may behave 
> like volatile field on one end of the spectrum or like a thread-local 
> variable on the other end, but usually something in between. The code 
> behaves correctly for either end or anything in between.
> 
> It's not that we want only one thread to use the cache. We want two things:
> 
> - if cached ClassLoader is used by some thread then we must guarantee 
> that it is a ClassLoader that was evaluated 
> (VM.latestUserDefinedLoader()) by the same thread in the same external 
> ObjectInputStream call. This is guaranteed by the fact that we keep the 
> evaluated ClassLoader and the evaluating Thread together in the 
> CachedLoader object and only use the cached ClassLoader if current 
> thread is the same as the one that evaluated it.
> - if a thread uses cache in some ObjectInputStream call, then the thread 
> must also clean-up the cache to not retain either Thread or ClassLoader 
> objects for more time than needed. This guarantee has been described in 
> my previous email and could be summarized by the following assertion: if 
> some thread writes values to 'cachedLoader' field in some external call 
> to ObjectInputStream, then the last value written by such thread in such 
> call is null value.
> 
> These two things are all we need to be sure of. And of course, that the 
> cache is effective for the common (and the only valid) case of using 
> ObjectInputStream instance in a single thread.
> 
> Regards, Peter
> 
>> I update webrev by adding a few lines of comment as:
>>
>> 2442     // This field is left non-volatile although there is a benign
>> race here.
>> 2443     // The thread that see a non-null value can always check if the
>> cache is for
>> 2444     // the thread, and such thread always cleans up the cache on
>> return.
>>
>> Comments for revising the text (and fixing my poor English) are welcome.
> 
> It's hard to come up with a nice short explanation that is 
> understandable to anyone. I'll try to come up with something tomorrow.
> 
> Regards, Peter
> 
>> Webrev:http://cr.openjdk.java.net/~horii/8188858/webrev.04/
>>
>>
>> Regards,
>> Ogata
>>
>>
>>
>>
>> From:   David Holmes<david.holmes at oracle.com>
>> To:     Peter Levart<peter.levart at gmail.com>, Kazunori Ogata
>> <OGATAK at jp.ibm.com>
>> Cc:core-libs-dev at openjdk.java.net
>> Date:   2017/10/24 15:49
>> Subject:        Re: RFR: 8188858: Caching latestUserDefinedLoader()
>> results in ObjectInputStream.readObject()
>>
>>
>>
>> Hi Peter, Ogata,
>>
>> Are you saying this is correct even if cachedLoader is not volatile? If
>> so then that needs to be clearly documented.
>>
>> Cheers,
>> David
>>
>> On 24/10/2017 3:11 PM, Peter Levart wrote:
>>> Hi,
>>>
>>> I think that what Ogata has in webrev.03 is correct and the reasoning
>>> could be as follows:
>>>
>>> - each thread writes to field 'cachedLoader' only from its own set of
>>> values that are distinct from the sets of values that may be written by
>>> any other thread, except null value.
>>> - each thread reads field 'cachedLoader' and can verfy that it has read
>>> a value that belongs to the set of its own written values, or null value
>>> (in other words, a thread can verify that it has read a value that was
>>> written by self or null value).
>>> - reads and writes of own set of non-null values always appear in
>>> program order since they are performed by same thread
>>> - a sequence of writes of own set of non-null values performed by some
>>> thread begins after this thread 1st observes a null value read from the
>>> field and ends before this thread finally writes null value back to the
>>> field. The last write performed by some thread is therefore always a
>>> write of null value.
>>>
>>> No matter how writes performed by a mixture of threads finally hit the
>>> actual field, since each thread that writes to it issues its final write
>>> of null value, the value that eventually ends in the field is null
>> value.
>>> Does this make sense?
>>>
>>> Regards, Peter
>>>
>>> On 10/23/17 22:47, Peter Levart wrote:
>>>> Hi Ogata,
>>>>
>>>> Sorry for late reply. You are absolutely right. Good catch! I missed
>>>> this scenario. The criteria for placing the mark (current Thread) on a
>>>> cachedLoader must include the check that validates previous value for
>>>> later restoration which uses the same criteria. Only in such case will
>>>> one thread never restore something that has not been placed by it. And
>>>> this guarantees that consumed OIS will never retain a reference to any
>>>> ClassLoader or Thread. Your webrev.03 looks good to me.
>>>>
>>>> Regards, Peter
>>>>
>>>> On 10/17/17 13:48, Kazunori Ogata wrote:
>>>>> Hi Peter,
>>>>>
>>>>> Thank you for your comments and the fix.  It's a good idea to mark
>>>>> cachedLoader with the Thread object.
>>>>>
>>>>>
>>>>> I think we need to check the marking thread of cachedLoader before
>>>>> updating it.  Otherwise, there is a scenario that can leak a
>>>>> CachedLoader
>>>>> object:
>>>>>
>>>>> //1. Thread-A enters readObject() and then call resolveClass()
>>>>> outerCL-A <- null
>>>>> cachedLoader <- Thread-A
>>>>> cachedLoader <- CachedLoader-A
>>>>>
>>>>> //2. Thread-B enters readObject() and then call resolveClass()
>>>>> outerCL-B <- CachedLoader-A
>>>>> cachedLoader <- Thread-B
>>>>> cachedLoader <- CachedLoader-B1
>>>>>
>>>>> //3. Thread-B returns from readObject()
>>>>> cachedLoader is unchanged because outerCL.thread == Thread-A
>>>>>
>>>>> //4. Thread-B enters readObject() again and then call resolveClass()
>>>>> outerCL-B <- CachedLoader-B1
>>>>> cachedLoader <- Thread-B
>>>>> cachedLoader <- CachedLoader-B2
>>>>>
>>>>> //5. Thread-A returns from readObject()
>>>>> cachedLoader <- null
>>>>>
>>>>> //6. Thread-B returns from readObject()
>>>>> cachedLoader <- CachedLoader-B1  // Because outerCL-B.thread is
>> Thread-B
>>>>> By adding checking before updating the mark, Thread-B won't update
>>>>> cachedLoader, or it only saves null when race occurs (and always
>>>>> restores
>>>>> to null on exit).
>>>>>
>>>>>
>>>>> Here is the updated webrev:
>>>>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Ehorii_8188858_webrev.03_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=Lh5fRAQa1sl79bnwNQva_URzWaEPL1yhaq0KTsohwN4&s=YMrI-UsCdrRwbHvcIXT5VlVXRVi3PRCjjt11k8G8jHE&e=
>>
>>>>> I also made minor changes to reduce the number of invocation of the
>> JNI
>>>>> method Thread.currentThread().
>>>>>
>>>>>
>>>>> Regards,
>>>>> Ogata
>>>>>
>>>>>
>>>>>
>>>>> From:   Peter Levart<peter.levart at gmail.com>
>>>>> To:     Kazunori Ogata<OGATAK at jp.ibm.com>, Alan Bateman
>>>>> <Alan.Bateman at oracle.com>
>>>>> Cc:core-libs-dev at openjdk.java.net
>>>>> Date:   2017/10/16 19:58
>>>>> Subject:        Re: RFR: 8188858: Caching latestUserDefinedLoader()
>>>>> results in ObjectInputStream.readObject()
>>>>>
>>>>>
>>>>>
>>>>> Hi Ogata,
>>>>>
>>>>> I found a problem in my last suggestion. See below...
>>>>>
>>>>> On 10/16/2017 11:36 AM, Peter Levart wrote:
>>>>>> On 10/16/2017 11:02 AM, Peter Levart wrote:
>>>>>>> For example:
>>>>>>> - let public readObject() / readUnshared() entry and exit points
>> just
>>>>>>> clear the cached loader (set it to null).
>>>>>> An alternative would be for entry point to save and clear the cached
>>>>>> loader while exit point would restore / clear it if it is from
>> correct
>>>>>> thread / when the call was not nested. Like the following:
>>>>>>
>>>>>> public Object readObject() {
>>>>>>       CachedLoader outerCL = cachedLoader;
>>>>>>       cachedLoader = null;
>>>>>>       try {
>>>>>>           ...
>>>>>>       } finally {
>>>>>>           if (outerCL == null || outerCL.thread ==
>>>>>> Thread.currentThread()) {
>>>>>>               // restore/clear cached loader when nested/outer call
>> ends
>>>>>>               cachedLoader = outerCL;
>>>>>>           }
>>>>>>       }
>>>>>> }
>>>>>>
>>>>>> with resolveClass() fragment repeated here for comparison:
>>>>>>
>>>>>>             CachedLoader cl = cachedLoader;
>>>>>>             Thread curThread = Thread.currentThread();
>>>>>>             ClassLoader loader;
>>>>>>             if (cl == null) {
>>>>>>                 loader = latestUserDefinedLoader();
>>>>>>                 cachedLoader = new CachedLoader(loader, curThread);
>>>>>>             } else if (cl.thread == curThread) {
>>>>>>                 loader = cl.loader;
>>>>>>             } else {
>>>>>>                 // multi threaded use
>>>>>>                 loader = latestUserDefinedLoader();
>>>>>>             }
>>>>>>
>>>>>>             // and then...
>>>>>>             return Class.forName(name, false, loader);
>>>>>>
>>>>>>
>>>>>> There are all sorts of races possible when called concurrently from
>>>>>> multiple threads, but the worst consequence is that the loader is not
>>>>>> cached. I also think that even in the presence of races, the
>>>>>> cachedLoader is eventually cleared when all calls to OIS complete. I
>>>>>> couldn't think of a situation where such cached loader would remain
>>>>>> hanging off the completed OIS because of races.
>>>>>>
>>>>>> Well, there is one such situation but for a different reason. For
>>>>>> example, if an OIS subclass is constructed solely to override
>>>>>> resolveClass method to make it accessible to custom code (for
>> example,
>>>>>> make it public and call super.resolveClass()) in order to provide a
>>>>>> utility for resolving classes with the default OIS semantics, but
>> such
>>>>>> OIS instance is never used for deserialization itself
>>>>>> (readObject()/readUnshared() is never called).
>>>>>>
>>>>>> To solve this problem, resolveClass() logic, including lazy caching,
>>>>>> should be moved to a private method (resolveClass0()) with protected
>>>>>> resolveClass() treated like public readObject()/readUnshared() with
>>>>>> before/after treatment of cached loader around delegation to
>>>>>> resolveClass0(). All OIS internal uses of resolveClass() should then
>>>>>> be redirected to resolveClass0().
>>>>> Oops, this would not work for subclasses that override resolveClass()
>>>>> with custom logic. Hm...
>>>>>
>>>>> The correct and optimal solution is a little bit more involved, I
>> think.
>>>>> Here's what I think should work (did not run any tests yet):
>>>>>
>>>>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Eplevart_jdk10-2Ddev_8188858-5FOIS.latestUserDefinedLoader.caching_webrev.01_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=PbaGqOdJOR6jMQkXDVYmjn6832m7o0LU2bzwt2awUgQ&s=gKz_rwcTcGIw8JvmRqlg1-OtjqFNXmIs4oQmIXlF3Wc&e=  
>>
>>>>> Regards, Peter
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
> 

From david.holmes at oracle.com  Wed Oct 25 12:53:06 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Oct 2017 22:53:06 +1000
Subject: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be
 exited by java
In-Reply-To: <OFF7A3AF0A.6966753E-ON002581BB.00565D42-802581BD.003E10E1@notes.na.collabserv.com>
References: <OFFB8A8A7A.5AE2F216-ON002581B8.003FC147-802581B8.00437393@notes.na.collabserv.com>
 <OFE060B054.F433A001-ON002581B8.004A4A39@LocalDomain>
 <OFF7A3AF0A.6966753E-ON002581BB.00565D42-802581BD.003E10E1@notes.na.collabserv.com>
Message-ID: <0218889e-b99f-8e6e-f1c1-97e16afe13a3@oracle.com>

Hi Adam,

On 18/10/2017 9:17 PM, Adam Farley8 wrote:
> Hi All,
> 
> Updated summary, based on the responses:

I think this is a good summary. Thanks.

I can file a bug for this, but it will take some work to see how to fit 
this into the existing specifications and file CSR requests for those 
changes. This won't make 18.3 (or whatever it gets called). You will 
need a "champion" to help flesh this out in full and work with you on 
those CSR requests. I can't volunteer to do that at this time.

> 1) Exit(0) (during VM startup) is a big bug because it imitates 
> successful completion of external cpp code accessing JNI methods.
> 2) One solution for (1) is to specify a new return code for JNI.
> 3) The supplied code (diff) generates, facilitates, and handles that 
> return code for the exit(0) scenario: -agentlib:jdwp=help
> 4) The exit(0) problem (in general) is worth fixing, however we may 
> choose not to support the use of this new code in the jdwp example case.
> 5) The supplied test confirms that the supplied code works (run via 
> unzip, and then bash TestStart.sh <path to jdk home dir that contains 
> bin dir>).
> 6) To implement this new return code, plus the code that handles it, we 
> would need to follow the CSR process to modify the JNI spec.
> 7) To implement the jdwp scenario fix, if we choose to support it at 
> all, we would also need to use the CSR process the JVM TI spec.
> 8) To address all of the worst instances of exit(0), we would need to 
> search for exit(0) and raise a bug for each significant one (or group).
> 9) To solve (8) in one bug would be a lot of work, arguably too much 
> work for a single bug.
> 10) If the new return code is identified as the appropriate solution to 
> this problem, we will need to agree on the right name and return code 
> value.
> 
> Also, here's a shortlist of the main questions I recall being raised 
> here, plus answers people have given.
> 
> A) What are the potential solutions for the exit(0) problem?
>  ? ? i) New JNI Return Code.
>  ? ? ii) Remove the info-only options, at least via the JNI, and return 
> a standard error code if they are used.
>  ? ? iii) Remove the info-only options, at least via the JNI, and filter 
> them out if they are used.
>  ? ? iv) Retain existing behaviour, and document a need for the user to 
> filter out help options before starting the VM via the JNI.
> 
> B) What are the criteria for the "Best" solution?
>  ? ? i) It must prevent "exit(0)" calls.
>  ? ? ii) It must be proven to work.
>  ? ? iii) It should require minimal (none, ideally) behaviour change 
> from the java.exe user.
>  ? ? iv) It should allow the external cpp code accessing the JNI to 
> complete normally, without being prematurely terminated.
> 
> C) Which solutions meet the (B) criteria?
>  ? ? i) Both the "new return code" and the "remove info-only options" 
> solutions meet the (B) criteria.
> 
> D) Is it right to have any "Do X and then exit." arguments at all, and 
> (if no) what would be the alternatives?
>  ? ?i) ?

Given the VM is a loadable shared library the answer should be No. We 
should not have any "Do X and then exit" arguments. The alternatives 
would be a mix of:
- added Dcmds to "Do X"
- added launcher smarts to recognize options that need a Dcmd and "then 
exit".

I find the notion of "help" options problematic for a shared library. 
But I don't have a good answer for how else to document things.

That all said I think this ship has sailed and we're unlikely to want to 
invest the time and effort in trying to clean this up this way.

Thanks,
David

> Best Regards
> 
> Adam Farley
> 
> P.S. As per Alan and David's emails, the exit(#) references have been 
> removed entirely, as discussing them alongside the original exit(0) 
> problem risks scope creep.
> 
> This bug, if raised, should only cover the exit(0) cases. I believe we 
> have consensus here.
> 
> 
> 
> From: David Holmes <david.holmes at oracle.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>, Alan Bateman 
> <Alan.Bateman at oracle.com>, core-libs-dev at openjdk.java.net, 
> hotspot-runtime-dev at openjdk.java.net, thomas.stuefe at gmail.com
> Date: 13/10/2017 14:31
> Subject: Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be 
> exited by java
> ------------------------------------------------------------------------
> 
> 
> 
> Hi Adam,
> 
> On 13/10/2017 10:16 PM, Adam Farley8 wrote:
>  > Hi All,
>  >
>  > Here's a summary of the email below (which is intended, partly, as a
>  > summary of the emails before it).
>  >
>  > Let me know if you agree/disagree with any of these points.
>  >
>  > 1) Exit(#) during vm startup is a bug because it should return a code
>  > regardless of the state of the VM.
> 
> Yes it's a bug but not one that is likely to be addressed in any
> foreseeable timeframe. There are simply too many "exit on error" paths.
> If we were to start using C++ exceptions within the VM that might
> provide a way to quickly get back to the CreateJavaVM routine where we
> could return an error code - but that is itself a major project that has
> barely even been discussed AFAIK. (Compiler folk have talked about it
> because compiler paths are fairly self-contained - though that was
> before Graal and AOT.)
> 
>  > 2) Exit(0) is an *especially* big bug because it imitates successful
>  > completion of external cpp code accessing JNI methods.
>  > 3) One solution is to specify a new return code for JNI.
> 
> A solution for 2) yes.
> 
>  > 4) The supplied code (diff) generates, facilitates, and handles that
>  > return code for the exit(0) scenario: -agentlib:jdwp=help
>  > 5) The supplied test confirms that the supplied code works (run via
>  > unzip, and then bash TestStart.sh <path to jdk home dir that contains
>  > bin dir>).
>  > 6) To implement this new return code, plus the code that handles it, we
>  > would need to follow the CSR process.
>  > 7) To implement the fix for the scenario used as an example of the new
>  > return code's use, we would need to modify the JVM TI spec.
> 
> Yes you have demonstrated a potential solution for the agent case. The
> question is, is it the right solution? Is it a worthwhile solution? (As
> I've said I'd prefer not to have any "do something then exit" VM
> arguments.) And can we make it fit into the existing specs without
> contorting things too much.
> 
> I still think it easier/preferable for whatever loads the VM to filter
> out the VM args that trigger this behaviour. I mean if you pass
> -Xshare:dump you don't have any right to expect a functioning VM after
> JNI_CreateJavaVM returns - at least I don't think so. Just don't do it.
> Yes it is an imperfection in the invocation API, but life isn't perfect.
> 
>  > 8) To address all of the worst instances of exit(#), we would need to
>  > search for exit(#) and raise a bug for each significant one (or group).
>  > 9) To solve (8) in one bug would be a lot of work, arguably too much
>  > work for a single bug.
> 
> This is simply impractical. You may be able to pick off a few
> low-hanging cases, but that won't really make any practical difference.
> 
>  > 10) If the new return code is chosen as the appropriate solution to this
>  > problem, we may need to choose a better name for the return code.
>  >
>  > Is this a fair assessment of the current state of the debate?
> 
> It's a fair summary of your position and proposal.
> 
> Cheers,
> David
> 
>  > I'm on IRC every weekday from 9am-5pm (4pm fridays) BST (GMT+1) if
>  > anyone wants to discuss this in real-time on the openjdk channel.
>  >
>  > Best Regards
>  >
>  > Adam Farley
>  >
>  >
>  >
>  > -- Previous Email --
>  >
>  > Hi David, Alan,
>  >
>  > You are right in that the changes to HotSpot would be nontrivial.
>  > I see a number of places in (e.g.) arguments.cpp that seem to
>  > exit in the same manner as Xlog (such as -Xinternalversion).
>  >
>  > I would advise ploughing through the CSR process to alter the
>  > JNI spec, and simultaneously identify some key paths that can
>  > be raised as bugs. That way, when people have time to address
>  > these issues, the mechanism to handle a silent exit is already
>  > in place.
>  >
>  > The JDWP fix can be raised separately as one of these bugs, if
>  > it would make things simpler.
>  >
>  > As for the name, JNI_SILENT_EXIT is a placeholder, and can be
>  > readily changed. Do you have any suggestions?
>  >
>  > Lastly, in an ideal world, the VM initialisation should never exit(#). It
>  > should return a return code that tells the caller something, pass or
>  > fail, messy or tidy. That way, if someone is using the JNI as part of
>  > something bigger (like a database or a web server), one of these
>  > scenarios is just a bug, rather than a world-ender like exit(#).
>  >
>  > And now for the individual messages. :)
>  >
>  > David: Having help data returned by the launcher seems like a
>  > good way to avoid exit(0) calls, but I'm not sure how we'd prevent
>  > a JNI-caller using those options. Ultimately, to be sure, we'd have
>  > to remove the logic for those options, centralise the data to better
>  > enable launcher access, and add some logic in there so it can find
>  > any other help data (e.g. from the jdwp agent library). I feel this would
>  > be a bigger task than adding the new return code and changing the
>  > vm, plus it wouldn't provide for any non-help scenarios where the
>  > vm wants to shut down without error during initialisation.
>  >
>  > Alan: I should mention that the silent exit solution is already in
>  > use in the OpenJ9 VM. Not all of the exit paths have been
>  > resolved, but many have.
>  >
>  > The code is open and can be found here: 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_openj9&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=c_McLiDSKtlzF_gNlWcAvBTNbDqyGHyW325GY3_3QkU&s=0QVowxRejNRAXI0Vv5whKQFWGTO36XVICmPYCG8EqIU&e=>
>  > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_openj9&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=c_McLiDSKtlzF_gNlWcAvBTNbDqyGHyW325GY3_3QkU&s=0QVowxRejNRAXI0Vv5whKQFWGTO36XVICmPYCG8EqIU&e=
>  >
>  > And though the silent exit code is disabled for the time being, it
>  > can be re-enabled by entering this class:
>  >
>  > runtime/vm/jvminit.c
>  >
>  > and altering line 2343 ( ctrl-f for exit(1) if it's not there).
>  >
>  > I won't paste the full code here in case people are concerned
>  > about contamination, but I would assert that this code (and the
>  > associated vm files) prove that the concept is possible.
>  >
>  > Note that that code should not be enabled until after we've
>  > integrated the code that can handle a silent exit.
>  >
>  > Best Regards
>  >
>  > Adam Farley
>  >
>  > P.S. Thank you both for your efforts on this. :)
>  >
>  >
>  >
>  > From: David Holmes <david.holmes at oracle.com>
>  > To: Alan Bateman <Alan.Bateman at oracle.com>, Adam Farley8
>  > <adam.farley at uk.ibm.com>, core-libs-dev at openjdk.java.net,
>  > hotspot-runtime-dev at openjdk.java.net, thomas.stuefe at gmail.com
>  > Date: 15/09/2017 12:03
>  > Subject: Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be
>  > exited by java
>  > ------------------------------------------------------------------------
>  >
>  >
>  >
>  >
>  >
>  > On 15/09/2017 8:17 PM, Alan Bateman wrote:
>  > ?> On 15/09/2017 02:47, David Holmes wrote:
>  > ?>> Hi Adam,
>  > ?>>
>  > ?>> I am still very much torn over this one. I think the idea of
>  > ?>> print-and-exit flags for a potentially hosted library like the JVM is
>  > ?>> just wrong - we should never have done that, but we did. Fixing that
>  > ?>> by moving the flags to the launcher is far from trivial**. Endorsing
>  > ?>> and encouraging these sorts of flag by adding JNI support seems to be
>  > ?>> sending the wrong message.
>  > ?>>
>  > ?>> ** I can envisage a "help xxx" Dcmd that can read back the info from
>  > ?>> the VM. The launcher can send the Dcmd, print the output and 
> exit. The
>  > ?>> launcher would not need to know what the xxx values mean, but would
>  > ?>> have to intercept the existing ones.
>  > ?>>
>  > ?>> Another option is just to be aware of these flags (are there more 
> than
>  > ?>> jdwp and Xlog?) and deal with them specially in your custom 
> launcher -
>  > ?>> either filter them out and ignore them, or else launch the VM in its
>  > ?>> own process to respond to them.
>  > ?>>
>  > ?>> Any changes to the JNI specification need to go through the CSR 
> process.
>  > ?> Yes, it would require an update to the JNI spec, also a change to the
>  > ?> JVM TI spec where Agent_OnLoad returning a non-0 value is specified to
>  > ?> terminates the VM. The name and value needs discussion too, esp. 
> as the
>  > ?> JNI spec uses negative values for failure.
>  > ?>
>  > ?> In any case, I'm also torn over this one as it's a corner case that is
>  > ?> only interesting for custom launchers that load agents with 
> options that
>  > ?> print usage messages. It wouldn't be hard to have the Agent_OnLoad
>  > ?> specify a printf hook that the agent could use for output although 
> there
>  > ?> are complications with agents such as JDWP that also announce their
>  > ?> transport end point. Beyond that there is still the issue of the 
> custom
>  > ?> launcher that would need to know to destroy the VM without 
> reporting an
>  > ?> error.
>  > ?>
>  > ?> So what happened to the more meaty part to this which is fixing the
>  > ?> various cases in HotSpot that terminate the process during
>  > ?> initialization? I would expect some progress could be made on those
>  > ?> cases while trying to decide whether to rev the JNI and JVM TI 
> specs to
>  > ?> cover the help case.
>  >
>  > Trying to eliminate the vm_exit_during_initialization paths in hotspot
>  > is a huge undertaking IMHO.
>  >
>  > David
>  >
>  > ?>
>  > ?> -Alan
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
> PO6 3AU
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From Alan.Bateman at oracle.com  Wed Oct 25 13:00:36 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 25 Oct 2017 14:00:36 +0100
Subject: RFR: 8183901 : Fix broken links to "Package Sealing" in the JAR
 spec
In-Reply-To: <513ce70e-7369-a919-aa33-e944c85f6213@oracle.com>
References: <513ce70e-7369-a919-aa33-e944c85f6213@oracle.com>
Message-ID: <9c3c6f41-0d5d-0ea8-8f17-e2aae0860897@oracle.com>



On 25/10/2017 01:21, Brent Christian wrote:
> Hi,
>
> Please review my fix of a few broken links to the "Package Sealing" 
> section of the Jar Spec[1].
>
> http://cr.openjdk.java.net/~bchristi/8183901/
Looks good.

From adam.farley at uk.ibm.com  Wed Oct 25 15:23:34 2017
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Wed, 25 Oct 2017 16:23:34 +0100
Subject: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be
 exited by java
In-Reply-To: <OFFA94FF63.8A15F679-ON002581C4.0046CD42@LocalDomain>
References: <OFFB8A8A7A.5AE2F216-ON002581B8.003FC147-802581B8.00437393@notes.na.collabserv.com>
 <OFE060B054.F433A001-ON002581B8.004A4A39@LocalDomain>
 <OFF7A3AF0A.6966753E-ON002581BB.00565D42-802581BD.003E10E1@notes.na.collabserv.com>
 <OFFA94FF63.8A15F679-ON002581C4.0046CD42@LocalDomain>
Message-ID: <OF1A09A9BC.11ED2D77-ON002581C4.0053DA09-802581C4.00548EEC@notes.na.collabserv.com>

Thanks David :)

Please let me know what the bug number is when you have time.

Everyone else: Any volunteers to champion this?

I'm on IRC 9-5 from monday-friday if anyone wants to discuss it.

Best Regards

Adam Farley

P.S. Here's the summary including David's addition, minus the chevrons:

1) Exit(0) (during VM startup) is a big bug because it imitates successful 
completion of external cpp code accessing JNI methods.
2) One solution for (1) is to specify a new return code for JNI.
3) The supplied code (diff) generates, facilitates, and handles that 
return code for the exit(0) scenario: -agentlib:jdwp=help
4) The exit(0) problem (in general) is worth fixing, however we may choose 
not to support the use of this new code in the jdwp example case.
5) The supplied test confirms that the supplied code works (run via unzip, 
and then bash TestStart.sh <path to jdk home dir that contains bin dir>).
6) To implement this new return code, plus the code that handles it, we 
would need to follow the CSR process to modify the JNI spec.
7) To implement the jdwp scenario fix, if we choose to support it at all, 
we would also need to use the CSR process the JVM TI spec.
8) To address all of the worst instances of exit(0), we would need to 
search for exit(0) and raise a bug for each significant one (or group).
9) To solve (8) in one bug would be a lot of work, arguably too much work 
for a single bug.
10) If the new return code is identified as the appropriate solution to 
this problem, we will need to agree on the right name and return code 
value.

Also, here's a shortlist of the main questions I recall being raised here, 
plus answers people have given.

A) What are the potential solutions for the exit(0) problem?
    i) New JNI Return Code.
    ii) Remove the info-only options, at least via the JNI, and return a 
standard error code if they are used.
    iii) Remove the info-only options, at least via the JNI, and filter 
them out if they are used.
    iv) Retain existing behaviour, and document a need for the user to 
filter out help options before starting the VM via the JNI.

B) What are the criteria for the "Best" solution?
    i) It must prevent "exit(0)" calls.
    ii) It must be proven to work.
    iii) It should require minimal (none, ideally) behaviour change from 
the java.exe user.
    iv) It should allow the external cpp code accessing the JNI to 
complete normally, without being prematurely terminated.

C) Which solutions meet the (B) criteria?
    i) Both the "new return code" and the "remove info-only options" 
solutions meet the (B) criteria.

D) Is it right to have any "Do X and then exit." arguments at all, and (if 
no) what would be the alternatives?
    i) Given the VM is a loadable shared library the answer should be No. 
We should not have any "Do X and then exit" 
        arguments. The alternatives would be a mix of:
        - added Dcmds to "Do X"
        - added launcher smarts to recognize options that need a Dcmd and 
"then exit".

        Note from David: 
        I find the notion of "help" options problematic for a shared 
library. But I don't have a good answer for how else 
        to document things.

        That all said I think this ship has sailed and we're unlikely to 
want to invest the time and effort in trying to clean 
        this up this way.



From:   David Holmes <david.holmes at oracle.com>
To:     Adam Farley8 <adam.farley at uk.ibm.com>
Cc:     Alan Bateman <Alan.Bateman at oracle.com>, 
core-libs-dev at openjdk.java.net, hotspot-runtime-dev at openjdk.java.net, 
thomas.stuefe at gmail.com
Date:   25/10/2017 13:53
Subject:        Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM 
can be exited by java



Hi Adam,

On 18/10/2017 9:17 PM, Adam Farley8 wrote:
> Hi All,
> 
> Updated summary, based on the responses:

I think this is a good summary. Thanks.

I can file a bug for this, but it will take some work to see how to fit 
this into the existing specifications and file CSR requests for those 
changes. This won't make 18.3 (or whatever it gets called). You will 
need a "champion" to help flesh this out in full and work with you on 
those CSR requests. I can't volunteer to do that at this time.

> 1) Exit(0) (during VM startup) is a big bug because it imitates 
> successful completion of external cpp code accessing JNI methods.
> 2) One solution for (1) is to specify a new return code for JNI.
> 3) The supplied code (diff) generates, facilitates, and handles that 
> return code for the exit(0) scenario: -agentlib:jdwp=help
> 4) The exit(0) problem (in general) is worth fixing, however we may 
> choose not to support the use of this new code in the jdwp example case.
> 5) The supplied test confirms that the supplied code works (run via 
> unzip, and then bash TestStart.sh <path to jdk home dir that contains 
> bin dir>).
> 6) To implement this new return code, plus the code that handles it, we 
> would need to follow the CSR process to modify the JNI spec.
> 7) To implement the jdwp scenario fix, if we choose to support it at 
> all, we would also need to use the CSR process the JVM TI spec.
> 8) To address all of the worst instances of exit(0), we would need to 
> search for exit(0) and raise a bug for each significant one (or group).
> 9) To solve (8) in one bug would be a lot of work, arguably too much 
> work for a single bug.
> 10) If the new return code is identified as the appropriate solution to 
> this problem, we will need to agree on the right name and return code 
> value.
> 
> Also, here's a shortlist of the main questions I recall being raised 
> here, plus answers people have given.
> 
> A) What are the potential solutions for the exit(0) problem?
>      i) New JNI Return Code.
>      ii) Remove the info-only options, at least via the JNI, and return 
> a standard error code if they are used.
>      iii) Remove the info-only options, at least via the JNI, and filter 

> them out if they are used.
>      iv) Retain existing behaviour, and document a need for the user to 
> filter out help options before starting the VM via the JNI.
> 
> B) What are the criteria for the "Best" solution?
>      i) It must prevent "exit(0)" calls.
>      ii) It must be proven to work.
>      iii) It should require minimal (none, ideally) behaviour change 
> from the java.exe user.
>      iv) It should allow the external cpp code accessing the JNI to 
> complete normally, without being prematurely terminated.
> 
> C) Which solutions meet the (B) criteria?
>      i) Both the "new return code" and the "remove info-only options" 
> solutions meet the (B) criteria.
> 
> D) Is it right to have any "Do X and then exit." arguments at all, and 
> (if no) what would be the alternatives?
>     i) ?

Given the VM is a loadable shared library the answer should be No. We 
should not have any "Do X and then exit" arguments. The alternatives 
would be a mix of:
- added Dcmds to "Do X"
- added launcher smarts to recognize options that need a Dcmd and "then 
exit".

I find the notion of "help" options problematic for a shared library. 
But I don't have a good answer for how else to document things.

That all said I think this ship has sailed and we're unlikely to want to 
invest the time and effort in trying to clean this up this way.

Thanks,
David

> Best Regards
> 
> Adam Farley
> 
> P.S. As per Alan and David's emails, the exit(#) references have been 
> removed entirely, as discussing them alongside the original exit(0) 
> problem risks scope creep.
> 
> This bug, if raised, should only cover the exit(0) cases. I believe we 
> have consensus here.
> 
> 
> 
> From: David Holmes <david.holmes at oracle.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>, Alan Bateman 
> <Alan.Bateman at oracle.com>, core-libs-dev at openjdk.java.net, 
> hotspot-runtime-dev at openjdk.java.net, thomas.stuefe at gmail.com
> Date: 13/10/2017 14:31
> Subject: Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be 

> exited by java
> ------------------------------------------------------------------------
> 
> 
> 
> Hi Adam,
> 
> On 13/10/2017 10:16 PM, Adam Farley8 wrote:
>  > Hi All,
>  >
>  > Here's a summary of the email below (which is intended, partly, as a
>  > summary of the emails before it).
>  >
>  > Let me know if you agree/disagree with any of these points.
>  >
>  > 1) Exit(#) during vm startup is a bug because it should return a code
>  > regardless of the state of the VM.
> 
> Yes it's a bug but not one that is likely to be addressed in any
> foreseeable timeframe. There are simply too many "exit on error" paths.
> If we were to start using C++ exceptions within the VM that might
> provide a way to quickly get back to the CreateJavaVM routine where we
> could return an error code - but that is itself a major project that has
> barely even been discussed AFAIK. (Compiler folk have talked about it
> because compiler paths are fairly self-contained - though that was
> before Graal and AOT.)
> 
>  > 2) Exit(0) is an *especially* big bug because it imitates successful
>  > completion of external cpp code accessing JNI methods.
>  > 3) One solution is to specify a new return code for JNI.
> 
> A solution for 2) yes.
> 
>  > 4) The supplied code (diff) generates, facilitates, and handles that
>  > return code for the exit(0) scenario: -agentlib:jdwp=help
>  > 5) The supplied test confirms that the supplied code works (run via
>  > unzip, and then bash TestStart.sh <path to jdk home dir that contains
>  > bin dir>).
>  > 6) To implement this new return code, plus the code that handles it, 
we
>  > would need to follow the CSR process.
>  > 7) To implement the fix for the scenario used as an example of the 
new
>  > return code's use, we would need to modify the JVM TI spec.
> 
> Yes you have demonstrated a potential solution for the agent case. The
> question is, is it the right solution? Is it a worthwhile solution? (As
> I've said I'd prefer not to have any "do something then exit" VM
> arguments.) And can we make it fit into the existing specs without
> contorting things too much.
> 
> I still think it easier/preferable for whatever loads the VM to filter
> out the VM args that trigger this behaviour. I mean if you pass
> -Xshare:dump you don't have any right to expect a functioning VM after
> JNI_CreateJavaVM returns - at least I don't think so. Just don't do it.
> Yes it is an imperfection in the invocation API, but life isn't perfect.
> 
>  > 8) To address all of the worst instances of exit(#), we would need to
>  > search for exit(#) and raise a bug for each significant one (or 
group).
>  > 9) To solve (8) in one bug would be a lot of work, arguably too much
>  > work for a single bug.
> 
> This is simply impractical. You may be able to pick off a few
> low-hanging cases, but that won't really make any practical difference.
> 
>  > 10) If the new return code is chosen as the appropriate solution to 
this
>  > problem, we may need to choose a better name for the return code.
>  >
>  > Is this a fair assessment of the current state of the debate?
> 
> It's a fair summary of your position and proposal.
> 
> Cheers,
> David
> 
>  > I'm on IRC every weekday from 9am-5pm (4pm fridays) BST (GMT+1) if
>  > anyone wants to discuss this in real-time on the openjdk channel.
>  >
>  > Best Regards
>  >
>  > Adam Farley
>  >
>  >
>  >
>  > -- Previous Email --
>  >
>  > Hi David, Alan,
>  >
>  > You are right in that the changes to HotSpot would be nontrivial.
>  > I see a number of places in (e.g.) arguments.cpp that seem to
>  > exit in the same manner as Xlog (such as -Xinternalversion).
>  >
>  > I would advise ploughing through the CSR process to alter the
>  > JNI spec, and simultaneously identify some key paths that can
>  > be raised as bugs. That way, when people have time to address
>  > these issues, the mechanism to handle a silent exit is already
>  > in place.
>  >
>  > The JDWP fix can be raised separately as one of these bugs, if
>  > it would make things simpler.
>  >
>  > As for the name, JNI_SILENT_EXIT is a placeholder, and can be
>  > readily changed. Do you have any suggestions?
>  >
>  > Lastly, in an ideal world, the VM initialisation should never 
exit(#). It
>  > should return a return code that tells the caller something, pass or
>  > fail, messy or tidy. That way, if someone is using the JNI as part of
>  > something bigger (like a database or a web server), one of these
>  > scenarios is just a bug, rather than a world-ender like exit(#).
>  >
>  > And now for the individual messages. :)
>  >
>  > David: Having help data returned by the launcher seems like a
>  > good way to avoid exit(0) calls, but I'm not sure how we'd prevent
>  > a JNI-caller using those options. Ultimately, to be sure, we'd have
>  > to remove the logic for those options, centralise the data to better
>  > enable launcher access, and add some logic in there so it can find
>  > any other help data (e.g. from the jdwp agent library). I feel this 
would
>  > be a bigger task than adding the new return code and changing the
>  > vm, plus it wouldn't provide for any non-help scenarios where the
>  > vm wants to shut down without error during initialisation.
>  >
>  > Alan: I should mention that the silent exit solution is already in
>  > use in the OpenJ9 VM. Not all of the exit paths have been
>  > resolved, but many have.
>  >
>  > The code is open and can be found here: 
> <
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_openj9&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=c_McLiDSKtlzF_gNlWcAvBTNbDqyGHyW325GY3_3QkU&s=0QVowxRejNRAXI0Vv5whKQFWGTO36XVICmPYCG8EqIU&e=
>
>  > 
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_openj9&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=c_McLiDSKtlzF_gNlWcAvBTNbDqyGHyW325GY3_3QkU&s=0QVowxRejNRAXI0Vv5whKQFWGTO36XVICmPYCG8EqIU&e=

>  >
>  > And though the silent exit code is disabled for the time being, it
>  > can be re-enabled by entering this class:
>  >
>  > runtime/vm/jvminit.c
>  >
>  > and altering line 2343 ( ctrl-f for exit(1) if it's not there).
>  >
>  > I won't paste the full code here in case people are concerned
>  > about contamination, but I would assert that this code (and the
>  > associated vm files) prove that the concept is possible.
>  >
>  > Note that that code should not be enabled until after we've
>  > integrated the code that can handle a silent exit.
>  >
>  > Best Regards
>  >
>  > Adam Farley
>  >
>  > P.S. Thank you both for your efforts on this. :)
>  >
>  >
>  >
>  > From: David Holmes <david.holmes at oracle.com>
>  > To: Alan Bateman <Alan.Bateman at oracle.com>, Adam Farley8
>  > <adam.farley at uk.ibm.com>, core-libs-dev at openjdk.java.net,
>  > hotspot-runtime-dev at openjdk.java.net, thomas.stuefe at gmail.com
>  > Date: 15/09/2017 12:03
>  > Subject: Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can 
be
>  > exited by java
>  > 
------------------------------------------------------------------------
>  >
>  >
>  >
>  >
>  >
>  > On 15/09/2017 8:17 PM, Alan Bateman wrote:
>  >  > On 15/09/2017 02:47, David Holmes wrote:
>  >  >> Hi Adam,
>  >  >>
>  >  >> I am still very much torn over this one. I think the idea of
>  >  >> print-and-exit flags for a potentially hosted library like the 
JVM is
>  >  >> just wrong - we should never have done that, but we did. Fixing 
that
>  >  >> by moving the flags to the launcher is far from trivial**. 
Endorsing
>  >  >> and encouraging these sorts of flag by adding JNI support seems 
to be
>  >  >> sending the wrong message.
>  >  >>
>  >  >> ** I can envisage a "help xxx" Dcmd that can read back the info 
from
>  >  >> the VM. The launcher can send the Dcmd, print the output and 
> exit. The
>  >  >> launcher would not need to know what the xxx values mean, but 
would
>  >  >> have to intercept the existing ones.
>  >  >>
>  >  >> Another option is just to be aware of these flags (are there more 

> than
>  >  >> jdwp and Xlog?) and deal with them specially in your custom 
> launcher -
>  >  >> either filter them out and ignore them, or else launch the VM in 
its
>  >  >> own process to respond to them.
>  >  >>
>  >  >> Any changes to the JNI specification need to go through the CSR 
> process.
>  >  > Yes, it would require an update to the JNI spec, also a change to 
the
>  >  > JVM TI spec where Agent_OnLoad returning a non-0 value is 
specified to
>  >  > terminates the VM. The name and value needs discussion too, esp. 
> as the
>  >  > JNI spec uses negative values for failure.
>  >  >
>  >  > In any case, I'm also torn over this one as it's a corner case 
that is
>  >  > only interesting for custom launchers that load agents with 
> options that
>  >  > print usage messages. It wouldn't be hard to have the Agent_OnLoad
>  >  > specify a printf hook that the agent could use for output although 

> there
>  >  > are complications with agents such as JDWP that also announce 
their
>  >  > transport end point. Beyond that there is still the issue of the 
> custom
>  >  > launcher that would need to know to destroy the VM without 
> reporting an
>  >  > error.
>  >  >
>  >  > So what happened to the more meaty part to this which is fixing 
the
>  >  > various cases in HotSpot that terminate the process during
>  >  > initialization? I would expect some progress could be made on 
those
>  >  > cases while trying to decide whether to rev the JNI and JVM TI 
> specs to
>  >  > cover the help case.
>  >
>  > Trying to eliminate the vm_exit_during_initialization paths in 
hotspot
>  > is a huge undertaking IMHO.
>  >
>  > David
>  >
>  >  >
>  >  > -Alan
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with 
number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
> PO6 3AU
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 

> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From david.holmes at oracle.com  Thu Oct 26 02:12:34 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 26 Oct 2017 12:12:34 +1000
Subject: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be
 exited by java
In-Reply-To: <OF1A09A9BC.11ED2D77-ON002581C4.0053DA09-802581C4.00548EEC@notes.na.collabserv.com>
References: <OFFB8A8A7A.5AE2F216-ON002581B8.003FC147-802581B8.00437393@notes.na.collabserv.com>
 <OFE060B054.F433A001-ON002581B8.004A4A39@LocalDomain>
 <OFF7A3AF0A.6966753E-ON002581BB.00565D42-802581BD.003E10E1@notes.na.collabserv.com>
 <OFFA94FF63.8A15F679-ON002581C4.0046CD42@LocalDomain>
 <OF1A09A9BC.11ED2D77-ON002581C4.0053DA09-802581C4.00548EEC@notes.na.collabserv.com>
Message-ID: <a1165a5a-9fcf-9b19-98f1-cbf4e8ffae46@oracle.com>

Filed:

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

"JVM options that cause the VM to "do X then exit" are incompatible with 
the JNI Invocation API"

David

On 26/10/2017 1:23 AM, Adam Farley8 wrote:
> Thanks David :)
> 
> Please let me know what the bug number is when you have time.
> 
> Everyone else: Any volunteers to champion this?
> 
> I'm on IRC 9-5 from monday-friday if anyone wants to discuss it.
> 
> Best Regards
> 
> Adam Farley
> 
> P.S. Here's the summary including David's addition, minus the chevrons:
> 
> 1) Exit(0) (during VM startup) is a big bug because it imitates 
> successful completion of external cpp code accessing JNI methods.
> 2) One solution for (1) is to specify a new return code for JNI.
> 3) The supplied code (diff) generates, facilitates, and handles that 
> return code for the exit(0) scenario: -agentlib:jdwp=help
> 4) The exit(0) problem (in general) is worth fixing, however we may 
> choose not to support the use of this new code in the jdwp example case.
> 5) The supplied test confirms that the supplied code works (run via 
> unzip, and then bash TestStart.sh <path to jdk home dir that contains 
> bin dir>).
> 6) To implement this new return code, plus the code that handles it, we 
> would need to follow the CSR process to modify the JNI spec.
> 7) To implement the jdwp scenario fix, if we choose to support it at 
> all, we would also need to use the CSR process the JVM TI spec.
> 8) To address all of the worst instances of exit(0), we would need to 
> search for exit(0) and raise a bug for each significant one (or group).
> 9) To solve (8) in one bug would be a lot of work, arguably too much 
> work for a single bug.
> 10) If the new return code is identified as the appropriate solution to 
> this problem, we will need to agree on the right name and return code 
> value.
> 
> Also, here's a shortlist of the main questions I recall being raised 
> here, plus answers people have given.
> 
> A) What are the potential solutions for the exit(0) problem?
> i) New JNI Return Code.
> ii) Remove the info-only options, at least via the JNI, and return a 
> standard error code if they are used.
> iii) Remove the info-only options, at least via the JNI, and filter them 
> out if they are used.
> iv) Retain existing behaviour, and document a need for the user to 
> filter out help options before starting the VM via the JNI.
> 
> B) What are the criteria for the "Best" solution?
> i) It must prevent "exit(0)" calls.
> ii) It must be proven to work.
> iii) It should require minimal (none, ideally) behaviour change from the 
> java.exe user.
> iv) It should allow the external cpp code accessing the JNI to complete 
> normally, without being prematurely terminated.
> 
> C) Which solutions meet the (B) criteria?
> i) Both the "new return code" and the "remove info-only options" 
> solutions meet the (B) criteria.
> 
> D) Is it right to have any "Do X and then exit." arguments at all, and 
> (if no) what would be the alternatives?
>  ? ?i) Given the VM is a loadable shared library the answer should be 
> No. We should not have any "Do X and then exit"
>  ? ? arguments. The alternatives would be a mix of:
>  ? ? ? ?- added Dcmds to "Do X"
>  ? ? ? ?- added launcher smarts to recognize options that need a Dcmd 
> and "then exit".
> 
>  ? ? ? ?Note from David:
>  ? ? I find the notion of "help" options problematic for a shared 
> library. But I don't have a good answer for how else
>  ? ? to document things.
> 
>  ? ? ? ?That all said I think this ship has sailed and we're unlikely to 
> want to invest the time and effort in trying to clean
>  ? ? this up this way.
> 
> 
> 
> From: David Holmes <david.holmes at oracle.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>
> Cc: Alan Bateman <Alan.Bateman at oracle.com>, 
> core-libs-dev at openjdk.java.net, hotspot-runtime-dev at openjdk.java.net, 
> thomas.stuefe at gmail.com
> Date: 25/10/2017 13:53
> Subject: Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be 
> exited by java
> ------------------------------------------------------------------------
> 
> 
> 
> Hi Adam,
> 
> On 18/10/2017 9:17 PM, Adam Farley8 wrote:
>> Hi All,
>> 
>> Updated summary, based on the responses:
> 
> I think this is a good summary. Thanks.
> 
> I can file a bug for this, but it will take some work to see how to fit
> this into the existing specifications and file CSR requests for those
> changes. This won't make 18.3 (or whatever it gets called). You will
> need a "champion" to help flesh this out in full and work with you on
> those CSR requests. I can't volunteer to do that at this time.
> 
>> 1) Exit(0) (during VM startup) is a big bug because it imitates 
>> successful completion of external cpp code accessing JNI methods.
>> 2) One solution for (1) is to specify a new return code for JNI.
>> 3) The supplied code (diff) generates, facilitates, and handles that
>> return code for the exit(0) scenario: -agentlib:jdwp=help
>> 4) The exit(0) problem (in general) is worth fixing, however we may
>> choose not to support the use of this new code in the jdwp example  case.
>> 5) The supplied test confirms that the supplied code works (run via
>> unzip, and then bash TestStart.sh <path to jdk home dir that contains
>> bin dir>).
>> 6) To implement this new return code, plus the code that handles it,  we
>> would need to follow the CSR process to modify the JNI spec.
>> 7) To implement the jdwp scenario fix, if we choose to support it  at
>> all, we would also need to use the CSR process the JVM TI spec.
>> 8) To address all of the worst instances of exit(0), we would need  to
>> search for exit(0) and raise a bug for each significant one (or group).
>> 9) To solve (8) in one bug would be a lot of work, arguably too much
>> work for a single bug.
>> 10) If the new return code is identified as the appropriate solution  to
>> this problem, we will need to agree on the right name and return code
>> value.
>> 
>> Also, here's a shortlist of the main questions I recall being raised
>> here, plus answers people have given.
>> 
>> A) What are the potential solutions for the exit(0) problem?
>> ?? ? i) New JNI Return Code.
>> ?? ? ii) Remove the info-only options, at least via  the JNI, and return
>> a standard error code if they are used.
>> ?? ? iii) Remove the info-only options, at least via  the JNI, and filter
>> them out if they are used.
>> ?? ? iv) Retain existing behaviour, and document a  need for the user to
>> filter out help options before starting the VM via the JNI.
>> 
>> B) What are the criteria for the "Best" solution?
>> ?? ? i) It must prevent "exit(0)" calls.
>> ?? ? ii) It must be proven to work.
>> ?? ? iii) It should require minimal (none, ideally)  behaviour change
>> from the java.exe user.
>> ?? ? iv) It should allow the external cpp code accessing  the JNI to
>> complete normally, without being prematurely terminated.
>> 
>> C) Which solutions meet the (B) criteria?
>> ?? ? i) Both the "new return code" and the  "remove info-only options"
>> solutions meet the (B) criteria.
>> 
>> D) Is it right to have any "Do X and then exit." arguments  at all, and
>> (if no) what would be the alternatives?
>> ?? ?i) ?
> 
> Given the VM is a loadable shared library the answer should be No. We
> should not have any "Do X and then exit" arguments. The alternatives
> would be a mix of:
> - added Dcmds to "Do X"
> - added launcher smarts to recognize options that need a Dcmd and "then
> exit".
> 
> I find the notion of "help" options problematic for a shared library.
> But I don't have a good answer for how else to document things.
> 
> That all said I think this ship has sailed and we're unlikely to want to
> invest the time and effort in trying to clean this up this way.
> 
> Thanks,
> David
> 
>> Best Regards
>> 
>> Adam Farley
>> 
>> P.S. As per Alan and David's emails, the exit(#) references have been
>> removed entirely, as discussing them alongside the original exit(0)
>> problem risks scope creep.
>> 
>> This bug, if raised, should only cover the exit(0) cases. I believe  we
>> have consensus here.
>> 
>> 
>> 
>> From: David Holmes <david.holmes at oracle.com>
>> To: Adam Farley8 <adam.farley at uk.ibm.com>, Alan Bateman 
>> <Alan.Bateman at oracle.com>, core-libs-dev at openjdk.java.net, 
>> hotspot-runtime-dev at openjdk.java.net, thomas.stuefe at gmail.com
>> Date: 13/10/2017 14:31
>> Subject: Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM  can be
>> exited by java
>> ------------------------------------------------------------------------
>> 
>> 
>> 
>> Hi Adam,
>> 
>> On 13/10/2017 10:16 PM, Adam Farley8 wrote:
>> ?> Hi All,
>> ?>
>> ?> Here's a summary of the email below (which is intended,  partly, as a
>> ?> summary of the emails before it).
>> ?>
>> ?> Let me know if you agree/disagree with any of these points.
>> ?>
>> ?> 1) Exit(#) during vm startup is a bug because it should  return a code
>> ?> regardless of the state of the VM.
>> 
>> Yes it's a bug but not one that is likely to be addressed in any
>> foreseeable timeframe. There are simply too many "exit on error"  paths.
>> If we were to start using C++ exceptions within the VM that might
>> provide a way to quickly get back to the CreateJavaVM routine where  we
>> could return an error code - but that is itself a major project that  has
>> barely even been discussed AFAIK. (Compiler folk have talked about  it
>> because compiler paths are fairly self-contained - though that was
>> before Graal and AOT.)
>> 
>> ?> 2) Exit(0) is an *especially* big bug because it imitates  successful
>> ?> completion of external cpp code accessing JNI methods.
>> ?> 3) One solution is to specify a new return code for JNI.
>> 
>> A solution for 2) yes.
>> 
>> ?> 4) The supplied code (diff) generates, facilitates, and  handles that
>> ?> return code for the exit(0) scenario: -agentlib:jdwp=help
>> ?> 5) The supplied test confirms that the supplied code works  (run via
>> ?> unzip, and then bash TestStart.sh <path to jdk home  dir that contains
>> ?> bin dir>).
>> ?> 6) To implement this new return code, plus the code that  handles it, we
>> ?> would need to follow the CSR process.
>> ?> 7) To implement the fix for the scenario used as an example  of the new
>> ?> return code's use, we would need to modify the JVM TI spec.
>> 
>> Yes you have demonstrated a potential solution for the agent case.  The
>> question is, is it the right solution? Is it a worthwhile solution?  (As
>> I've said I'd prefer not to have any "do something then exit"  VM
>> arguments.) And can we make it fit into the existing specs without
>> contorting things too much.
>> 
>> I still think it easier/preferable for whatever loads the VM to filter
>> out the VM args that trigger this behaviour. I mean if you pass
>> -Xshare:dump you don't have any right to expect a functioning VM after
>> JNI_CreateJavaVM returns - at least I don't think so. Just don't do  it.
>> Yes it is an imperfection in the invocation API, but life isn't perfect.
>> 
>> ?> 8) To address all of the worst instances of exit(#), we  would need to
>> ?> search for exit(#) and raise a bug for each significant  one (or group).
>> ?> 9) To solve (8) in one bug would be a lot of work, arguably  too much
>> ?> work for a single bug.
>> 
>> This is simply impractical. You may be able to pick off a few
>> low-hanging cases, but that won't really make any practical difference.
>> 
>> ?> 10) If the new return code is chosen as the appropriate  solution to this
>> ?> problem, we may need to choose a better name for the return  code.
>> ?>
>> ?> Is this a fair assessment of the current state of the debate?
>> 
>> It's a fair summary of your position and proposal.
>> 
>> Cheers,
>> David
>> 
>> ?> I'm on IRC every weekday from 9am-5pm (4pm fridays) BST  (GMT+1) if
>> ?> anyone wants to discuss this in real-time on the openjdk  channel.
>> ?>
>> ?> Best Regards
>> ?>
>> ?> Adam Farley
>> ?>
>> ?>
>> ?>
>> ?> -- Previous Email --
>> ?>
>> ?> Hi David, Alan,
>> ?>
>> ?> You are right in that the changes to HotSpot would be nontrivial.
>> ?> I see a number of places in (e.g.) arguments.cpp that seem  to
>> ?> exit in the same manner as Xlog (such as -Xinternalversion).
>> ?>
>> ?> I would advise ploughing through the CSR process to alter  the
>> ?> JNI spec, and simultaneously identify some key paths that  can
>> ?> be raised as bugs. That way, when people have time to address
>> ?> these issues, the mechanism to handle a silent exit is  already
>> ?> in place.
>> ?>
>> ?> The JDWP fix can be raised separately as one of these bugs,  if
>> ?> it would make things simpler.
>> ?>
>> ?> As for the name, JNI_SILENT_EXIT is a placeholder, and  can be
>> ?> readily changed. Do you have any suggestions?
>> ?>
>> ?> Lastly, in an ideal world, the VM initialisation should  never exit(#). It
>> ?> should return a return code that tells the caller something,  pass or
>> ?> fail, messy or tidy. That way, if someone is using the  JNI as part of
>> ?> something bigger (like a database or a web server), one  of these
>> ?> scenarios is just a bug, rather than a world-ender like  exit(#).
>> ?>
>> ?> And now for the individual messages. :)
>> ?>
>> ?> David: Having help data returned by the launcher seems  like a
>> ?> good way to avoid exit(0) calls, but I'm not sure how we'd  prevent
>> ?> a JNI-caller using those options. Ultimately, to be sure,  we'd have
>> ?> to remove the logic for those options, centralise the data  to better
>> ?> enable launcher access, and add some logic in there so  it can find
>> ?> any other help data (e.g. from the jdwp agent library).  I feel this would
>> ?> be a bigger task than adding the new return code and changing  the
>> ?> vm, plus it wouldn't provide for any non-help scenarios  where the
>> ?> vm wants to shut down without error during initialisation.
>> ?>
>> ?> Alan: I should mention that the silent exit solution is  already in
>> ?> use in the OpenJ9 VM. Not all of the exit paths have been
>> ?> resolved, but many have.
>> ?>
>> ?> The code is open and can be found here: 
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_openj9&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=c_McLiDSKtlzF_gNlWcAvBTNbDqyGHyW325GY3_3QkU&s=0QVowxRejNRAXI0Vv5whKQFWGTO36XVICmPYCG8EqIU&e=>
>> ?> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_openj9&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=c_McLiDSKtlzF_gNlWcAvBTNbDqyGHyW325GY3_3QkU&s=0QVowxRejNRAXI0Vv5whKQFWGTO36XVICmPYCG8EqIU&e=
>> ?>
>> ?> And though the silent exit code is disabled for the time  being, it
>> ?> can be re-enabled by entering this class:
>> ?>
>> ?> runtime/vm/jvminit.c
>> ?>
>> ?> and altering line 2343 ( ctrl-f for exit(1) if it's not  there).
>> ?>
>> ?> I won't paste the full code here in case people are concerned
>> ?> about contamination, but I would assert that this code  (and the
>> ?> associated vm files) prove that the concept is possible.
>> ?>
>> ?> Note that that code should not be enabled until after we've
>> ?> integrated the code that can handle a silent exit.
>> ?>
>> ?> Best Regards
>> ?>
>> ?> Adam Farley
>> ?>
>> ?> P.S. Thank you both for your efforts on this. :)
>> ?>
>> ?>
>> ?>
>> ?> From: David Holmes <david.holmes at oracle.com>
>> ?> To: Alan Bateman <Alan.Bateman at oracle.com>, Adam  Farley8
>> ?> <adam.farley at uk.ibm.com>, core-libs-dev at openjdk.java.net,
>> ?> hotspot-runtime-dev at openjdk.java.net, thomas.stuefe at gmail.com
>> ?> Date: 15/09/2017 12:03
>> ?> Subject: Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM  can be
>> ?> exited by java
>> ?> ------------------------------------------------------------------------
>> ?>
>> ?>
>> ?>
>> ?>
>> ?>
>> ?> On 15/09/2017 8:17 PM, Alan Bateman wrote:
>> ?> ?> On 15/09/2017 02:47, David Holmes wrote:
>> ?> ?>> Hi Adam,
>> ?> ?>>
>> ?> ?>> I am still very much torn over this one.  I think the idea of
>> ?> ?>> print-and-exit flags for a potentially hosted  library like the JVM is
>> ?> ?>> just wrong - we should never have done that,  but we did. Fixing that
>> ?> ?>> by moving the flags to the launcher is far  from trivial**. Endorsing
>> ?> ?>> and encouraging these sorts of flag by adding  JNI support seems to be
>> ?> ?>> sending the wrong message.
>> ?> ?>>
>> ?> ?>> ** I can envisage a "help xxx"  Dcmd that can read back the info from
>> ?> ?>> the VM. The launcher can send the Dcmd,  print the output and
>> exit. The
>> ?> ?>> launcher would not need to know what the  xxx values mean, but would
>> ?> ?>> have to intercept the existing ones.
>> ?> ?>>
>> ?> ?>> Another option is just to be aware of these  flags (are there more
>> than
>> ?> ?>> jdwp and Xlog?) and deal with them specially  in your custom
>> launcher -
>> ?> ?>> either filter them out and ignore them,  or else launch the VM in its
>> ?> ?>> own process to respond to them.
>> ?> ?>>
>> ?> ?>> Any changes to the JNI specification need  to go through the CSR
>> process.
>> ?> ?> Yes, it would require an update to the JNI spec,  also a change to the
>> ?> ?> JVM TI spec where Agent_OnLoad returning a non-0  value is specified to
>> ?> ?> terminates the VM. The name and value needs  discussion too, esp.
>> as the
>> ?> ?> JNI spec uses negative values for failure.
>> ?> ?>
>> ?> ?> In any case, I'm also torn over this one as  it's a corner case that is
>> ?> ?> only interesting for custom launchers that load  agents with
>> options that
>> ?> ?> print usage messages. It wouldn't be hard to  have the Agent_OnLoad
>> ?> ?> specify a printf hook that the agent could use  for output although
>> there
>> ?> ?> are complications with agents such as JDWP that  also announce their
>> ?> ?> transport end point. Beyond that there is still  the issue of the
>> custom
>> ?> ?> launcher that would need to know to destroy  the VM without
>> reporting an
>> ?> ?> error.
>> ?> ?>
>> ?> ?> So what happened to the more meaty part to this  which is fixing the
>> ?> ?> various cases in HotSpot that terminate the  process during
>> ?> ?> initialization? I would expect some progress  could be made on those
>> ?> ?> cases while trying to decide whether to rev  the JNI and JVM TI
>> specs to
>> ?> ?> cover the help case.
>> ?>
>> ?> Trying to eliminate the vm_exit_during_initialization paths  in hotspot
>> ?> is a huge undertaking IMHO.
>> ?>
>> ?> David
>> ?>
>> ?> ?>
>> ?> ?> -Alan
>> ?>
>> ?> Unless stated otherwise above:
>> ?> IBM United Kingdom Limited - Registered in England and  Wales with number
>> ?> 741598.
>> ?> Registered office: PO Box 41, North Harbour, Portsmouth,  Hampshire
>> PO6 3AU
>> 
>> 
>> 
>> 
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with  number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire  PO6 3AU
> 
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

From Alan.Bateman at oracle.com  Thu Oct 26 10:31:53 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Oct 2017 11:31:53 +0100
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <OFD71AE604.154EE836-ON492581C3.003A96A9-492581C3.003BD067@notes.na.collabserv.com>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <8d95c7f3-f7d8-d22d-9e50-d20ccf45d860@oracle.com>
 <OFC814E49A.E055B99B-ON492581B7.0021714D-492581B7.0021B27A@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
 <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
 <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>
 <1238393b-0d7f-9fea-eb75-3fd816c951a5@gmail.com>
 <OFA0D9E522.56232230-ON492581BC.003EF1D9-492581BC.0040E6BF@notes.na.collabserv.com>
 <e2b5c5bf-1622-65bb-29d0-310f3b185529@gmail.com>
 <d27acb55-12fc-2a3d-1fa9-490a038
 <OF64D397E2.26E0B836-ON002581C3.0025854D@LocalDomain>
 <OFD71AE604.154EE836-ON492581C3.003A96A9-492581C3.003BD067@notes.na.collabserv.com>
Message-ID: <5cab197d-3804-1e17-9c3b-bc4193064bd3@oracle.com>

On 24/10/2017 11:53, Kazunori Ogata wrote:
> :
>
> Comments for revising the text (and fixing my poor English) are welcome.
>
> Webrev: http://cr.openjdk.java.net/~horii/8188858/webrev.04/
>
I've read through webrev.03 and webrev.04 and they seem correct. Are 
there are more comments on the implementation? I'd like to get someone 
in the security area to review this before it is sponsored, the reason 
is that original patches could be abused and this is security-sensitive 
area.

One comment, or suggestion, is to find a better name for the 
cachedLoader field, esp. as its value may be a Thread or a CachedLoader 
object. If CachedLoader were renamed to ReaderContext and cachedLoader 
changed to something like currentReader then it might be a bit clearer. 
I'm sure there are better names, the important thing is that future 
maintainers can quickly understand the code.

-Alan



From scolebourne at joda.org  Thu Oct 26 15:10:04 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 26 Oct 2017 16:10:04 +0100
Subject: Module naming for logging implementations
Message-ID: <CACzrW9AS91Te2nV3i4DjYkeDn1R9vPkGM=m8DuPkkZBdZWuC_w@mail.gmail.com>

I've spent some time discussing module names for logging
implementations recently:
https://github.com/jodastephen/jpms-module-names/wiki/Logging-APIs
https://issues.apache.org/jira/browse/LOG4J2-2056
https://jira.qos.ch/browse/SLF4J-407?jql=text%20~%20%22jpms%22

Most logging projects are split in two - an API and an Implementation
- where the recommended solution going forwards is to use
ServiceLoader to find the implementations. A few old projects don't
have this split, and have API and Implementation together (eg
Commons-Logging).

Everyone agrees that the module name for the API must always be the
same. ie. if the SLF4J team provides a module that simulates the
Commons-Logging then it must have the same module name as
Commons-Logging.

However, there are two choices for the implementation jars.

Option 1:
All modules that implement a particular logging API must have the same
module name
eg. every module that implements "org.slf4j" (the API) must be named
"org.slf4j.impl"

Option 2:
The module name of the implementation can be whatever name makes sense.


For most service providers, option 2 is obvious, however for logging
it is generally the case that only one implementation should be
present. If all the jar files that implement a specific logging API
had the same module name (option 1) then the module system could
ensure that only one was loaded. This is a particular concern as it is
not uncommon for a jar file in Maven Central to depend on a specific
implementation of logging when it should only be depending on the API.


I'm leaning towards option 2, as it is simpler and does not require
all implementations to have the same module name (which would be
difficult to require). Any other considerations I'm missing?

Stephen

From paul.sandoz at oracle.com  Thu Oct 26 17:03:15 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 26 Oct 2017 10:03:15 -0700
Subject: [10] RFR 8186046 Minimal ConstantDynamic support 
Message-ID: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>

Hi,

Please review the following patch for minimal dynamic constant support:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>

  https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
  https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>

This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.

By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.

A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).

Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.

The CSR for the VM specification is here:

  https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>

the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).

Any AoT-related work will be deferred to a future release.

?

This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).

We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.

?

Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.

One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.

?

Paul.

From joe.darcy at oracle.com  Fri Oct 27 00:24:57 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 26 Oct 2017 17:24:57 -0700
Subject: JDK 10 RFR of JDK-8189952: New methods on String: chars() and
 codePoints() should be marked since 9
Message-ID: <897606df-c1aa-a5fe-c995-9202c5346ab7@oracle.com>

Hello,

The initial changeset which introduced these the methods String.chars() 
and String.codePoints(), JDK-8071477 , had the expected @since tags for 
the time (@since 1.9), but subsequent changes to String seem to have 
removed them.

Please review the patch below to add them back.

Thanks,

-Joe

--- a/src/java.base/share/classes/java/lang/String.java    Thu Oct 26 
17:06:52 2017 -0700
+++ b/src/java.base/share/classes/java/lang/String.java    Thu Oct 26 
17:24:42 2017 -0700
@@ -2664,6 +2664,7 @@
       * point</a> is passed through uninterpreted.
       *
       * @return an IntStream of char values from this sequence
+     * @since 9
       */
      @Override
      public IntStream chars() {
@@ -2683,6 +2684,7 @@
       * {@code int} values which are then passed to the stream.
       *
       * @return an IntStream of Unicode code points from this sequence
+     * @since 9
       */
      @Override
      public IntStream codePoints() {


From brian.burkhalter at oracle.com  Fri Oct 27 00:29:26 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 26 Oct 2017 17:29:26 -0700
Subject: JDK 10 RFR of JDK-8189952: New methods on String: chars() and
 codePoints() should be marked since 9
In-Reply-To: <897606df-c1aa-a5fe-c995-9202c5346ab7@oracle.com>
References: <897606df-c1aa-a5fe-c995-9202c5346ab7@oracle.com>
Message-ID: <01C5E3B2-0AC8-4E00-84CE-905588B022BF@oracle.com>

Hi Joe,

Looks fine.

Thanks,

Brian

On Oct 26, 2017, at 5:24 PM, joe darcy <joe.darcy at oracle.com> wrote:

> The initial changeset which introduced these the methods String.chars() and String.codePoints(), JDK-8071477 , had the expected @since tags for the time (@since 1.9), but subsequent changes to String seem to have removed them.
> 
> Please review the patch below to add them back.


From brent.christian at oracle.com  Fri Oct 27 01:43:26 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 26 Oct 2017 18:43:26 -0700
Subject: RFR 8189319 : Add a java.util.Properties constructor that takes an
 initial capacity
Message-ID: <326a2344-79e3-b95d-18a6-731d022097d4@oracle.com>

Hi,

It would be useful to have a Properties constructor that takes an 
argument to set the initial capacity. Such a constructor is present on 
many of the other Map implementations in the JDK, including Hashtable, 
the superclass of Properties.

In particular, being able to specify the initial capacity of the 
Properties object created to store the system properties could reduce 
startup time.  The current initial capacity of 8 is insufficient.  We 
could eliminate ~25,000 bytecodes currently spent resizing the 
Properties by creating one of sufficient initial size.

There are ~60 system properties in a minimal Java app.  I chose 84 - it 
provides a good amount of wiggle room (and results in an internal 
ConcurrentHashMap with a table size of 128; 64 would be too small, IMO).

Please review this change:

Issue:  https://bugs.openjdk.java.net/browse/JDK-8189319
Webrev: http://cr.openjdk.java.net/~bchristi/8189319/webrev.01/

Thanks,
-Brent

From paul.sandoz at oracle.com  Fri Oct 27 03:38:31 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 26 Oct 2017 20:38:31 -0700
Subject: JDK 10 RFR of JDK-8189952: New methods on String: chars() and
 codePoints() should be marked since 9
In-Reply-To: <897606df-c1aa-a5fe-c995-9202c5346ab7@oracle.com>
References: <897606df-c1aa-a5fe-c995-9202c5346ab7@oracle.com>
Message-ID: <00598BAA-C39A-4155-95D4-4F21D5D3A220@oracle.com>


> On 26 Oct 2017, at 17:24, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> The initial changeset which introduced these the methods String.chars() and String.codePoints(), JDK-8071477 , had the expected @since tags for the time (@since 1.9), but subsequent changes to String seem to have removed them.
> 
> Please review the patch below to add them back.
> 

+1

Paul.

> Thanks,
> 
> -Joe
> 
> --- a/src/java.base/share/classes/java/lang/String.java    Thu Oct 26 17:06:52 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/String.java    Thu Oct 26 17:24:42 2017 -0700
> @@ -2664,6 +2664,7 @@
>      * point</a> is passed through uninterpreted.
>      *
>      * @return an IntStream of char values from this sequence
> +     * @since 9
>      */
>     @Override
>     public IntStream chars() {
> @@ -2683,6 +2684,7 @@
>      * {@code int} values which are then passed to the stream.
>      *
>      * @return an IntStream of Unicode code points from this sequence
> +     * @since 9
>      */
>     @Override
>     public IntStream codePoints() {
> 


From rachna.goel at oracle.com  Fri Oct 27 06:24:54 2017
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 27 Oct 2017 11:54:54 +0530
Subject: JDK10 RFR of JDK-8185841:Values from getFirstDayOfWeek() are
 inconsistent with CLDR
Message-ID: <ffb58a71-ca80-7b78-9a9f-427aba94086e@oracle.com>

Hi,

Kindly review the fix to JDK-8185841.

Bug : https://bugs.openjdk.java.net/browse/JDK-8185841.

patch : http://cr.openjdk.java.net/~rgoel/JDK-8185841/webrev.08/

Fix is to relocate this region dependent data. New Bundle will be 
generated when Locale id has non empty script and country code and it 
contains region dependent data.
  e.g for "az_Latn_AZ" locale, CalendarData_az_AZ.java Bundle will be 
generated and the data currently in CalendarData_az_Latn_AZ.java should 
be relocated into it.

-- 
Thanks,
Rachna


From ramanand.patil at oracle.com  Fri Oct 27 07:08:28 2017
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Fri, 27 Oct 2017 00:08:28 -0700 (PDT)
Subject: tzdata2017c is out
In-Reply-To: <CA+kOe0_DybcdO4-LGmESMcYevNK8psBQZfAYiRoD3h_8hZ6sXg@mail.gmail.com>
References: <CA+kOe0_DybcdO4-LGmESMcYevNK8psBQZfAYiRoD3h_8hZ6sXg@mail.gmail.com>
Message-ID: <a26ceaed-6f7f-4787-8d5d-79914dc4e9ad@default>

Hi Martin,

Thank you very much for the heads-up. I have filed a bug for the same: https://bugs.openjdk.java.net/browse/JDK-8190259

Thank you for the patch as well. This will be integrated into JDK along with the tzdata2017c.

?

Regards,

Ramanand.

?

From: Martin Buchholz [mailto:martinrb at google.com] 
Sent: Tuesday, October 24, 2017 2:05 AM
To: i18n-dev at openjdk.java.net; core-libs-dev <core-libs-dev at openjdk.java.net>; Ramanand Patil <ramanand.patil at oracle.com>; Stephen Colebourne <scolebourne at joda.org>
Subject: tzdata2017c is out

?

tzdata2017c came out today, and the elves at Google are working hard to incorporate changes in hours or days instead of weeks or quarters.? One thing we noticed is that one of the java.time tck tests was broken by tzdata rewrite of history.? Here's the fix we're applying (s/1879/1892/g):

?

@@ -941,21 +941,21 @@

? ? ?}

?

? ? ?public void test_Apia_jumpForwardOverInternationalDateLine_P12_to_M12() {

-? ? ? ? // transition occurred at 1879-07-04T00:00+12:33:04

+? ? ? ? // transition occurred at 1892-07-04T00:00+12:33:04

? ? ? ? ?ZoneRules test = pacificApia();

-? ? ? ? Instant instantBefore = LocalDate.of(1879, 7, 2).atStartOfDay(ZoneOffset.UTC).toInstant();

+? ? ? ? Instant instantBefore = LocalDate.of(1892, 7, 2).atStartOfDay(ZoneOffset.UTC).toInstant();

? ? ? ? ?ZoneOffsetTransition trans = test.nextTransition(instantBefore);

-? ? ? ? assertEquals(trans.getDateTimeBefore(), LocalDateTime.of(1879, 7, 5, 0, 0));

-? ? ? ? assertEquals(trans.getDateTimeAfter(), LocalDateTime.of(1879, 7, 4, 0, 0));

+? ? ? ? assertEquals(trans.getDateTimeBefore(), LocalDateTime.of(1892, 7, 5, 0, 0));

+? ? ? ? assertEquals(trans.getDateTimeAfter(), LocalDateTime.of(1892, 7, 4, 0, 0));

? ? ? ? ?assertEquals(trans.isGap(), false);

? ? ? ? ?assertEquals(trans.isOverlap(), true);

? ? ? ? ?assertEquals(trans.isValidOffset(ZoneOffset.ofHoursMinutesSeconds(+12, 33, 4)), true);

? ? ? ? ?assertEquals(trans.isValidOffset(ZoneOffset.ofHoursMinutesSeconds(-11, -26, -56)), true);

? ? ? ? ?assertEquals(trans.getDuration(), Duration.ofHours(-24));

-? ? ? ? assertEquals(trans.getInstant(), LocalDateTime.of(1879, 7, 4, 0, 0).toInstant(ZoneOffset.ofHoursMinutesSeconds(-11, -26, -56)));

+? ? ? ? assertEquals(trans.getInstant(), LocalDateTime.of(1892, 7, 4, 0, 0).toInstant(ZoneOffset.ofHoursMinutesSeconds(-11, -26, -56)));

?

-? ? ? ? ZonedDateTime zdt = ZonedDateTime.of(1879, 7, 4, 23, 0, 0, 0, ZoneId.of("Pacific/Apia"));

-? ? ? ? assertEquals(zdt.plusHours(2).toLocalDateTime(), LocalDateTime.of(1879, 7, 4, 1, 0, 0));

+? ? ? ? ZonedDateTime zdt = ZonedDateTime.of(1892, 7, 4, 23, 0, 0, 0, ZoneId.of("Pacific/Apia"));

+? ? ? ? assertEquals(zdt.plusHours(2).toLocalDateTime(), LocalDateTime.of(1892, 7, 4, 1, 0, 0));

? ? ?}

?

? ? ?//-------------------------------------------------------------------------

?

From OGATAK at jp.ibm.com  Fri Oct 27 13:10:38 2017
From: OGATAK at jp.ibm.com (Kazunori Ogata)
Date: Fri, 27 Oct 2017 22:10:38 +0900
Subject: RFR: 8188858: Caching latestUserDefinedLoader() results in
 ObjectInputStream.readObject()
In-Reply-To: <OF9C8AD19A.1F549141-ON002581C5.0039BF0E@LocalDomain>
References: <OF7EBE99F5.683BDB58-ON492581B1.00397812-492581B1.003A178E@notes.na.collabserv.com>
 <1cebd1ff-1cb3-834e-7e41-0f82f029776e@oracle.com>
 <OF329C52F9.252FEA42-ON492581B8.0031EB65-492581B8.00454F68@notes.na.collabserv.com>
 <9624742e-b4e0-18c5-9c5e-131b3fe45284@gmail.com>
 <62072034-c11d-f52b-258c-17514c3b39b6@gmail.com>
 <1238393b-0d7f-9fea-eb75-3fd816c951a5@gmail.com>
 <OFA0D9E522.56232230-ON492581BC.003EF1D9-492581BC.0040E6BF@notes.na.collabserv.com>
 <e2b5c5bf-1622-65bb-29d0-310f3b185529@gmail.com>
 <d27acb55-12fc-2a3d-1fa9-490a038
 <OF64D397E2.26E0B836-ON002581C3.0025854D@LocalDomain>
 <OFD71AE604.154EE836-ON492581C3.003A96A9-492581C3.003BD067@notes.na.collabserv.
 <OF9C8AD19A.1F549141-ON002581C5.0039BF0E@LocalDomain>
Message-ID: <OFA0E4291E.211C5B74-ON492581C6.0047A4DB-492581C6.004865F6@notes.na.collabserv.com>

Hi Alan,

Thank you for your review and comments.

I updated webrev based on your comments: 
http://cr.openjdk.java.net/~horii/8188858/webrev.05/


Alan Bateman <Alan.Bateman at oracle.com> wrote on 2017/10/26 19:31:53:

> I've read through webrev.03 and webrev.04 and they seem correct. Are 
> there are more comments on the implementation? I'd like to get someone 
> in the security area to review this before it is sponsored, the reason 
> is that original patches could be abused and this is security-sensitive 
> area.

I added/revised comments, though I'm not sure it is sufficient.  It is 
helpful if you could point out the changes that merely have insufficient 
comments.


> One comment, or suggestion, is to find a better name for the 
> cachedLoader field, esp. as its value may be a Thread or a CachedLoader 
> object. If CachedLoader were renamed to ReaderContext and cachedLoader 
> changed to something like currentReader then it might be a bit clearer. 
> I'm sure there are better names, the important thing is that future 
> maintainers can quickly understand the code.

Agreed. I renamed CachedLoader to ReaderContext, and also renamed other 
variables to make it easier to identify they are related to ReaderContext.


Regards,
Ogata


From christoph.dreis at freenet.de  Fri Oct 27 15:23:09 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Fri, 27 Oct 2017 17:23:09 +0200
Subject: [Proposal/Question] Provide mechanism to monitor thread states more
 efficiently
Message-ID: <000001d34f37$7fb5c1d0$7f214570$@freenet.de>

Hey,

I don't know if this is the correct mailing list for this specific topic.
Please let me know in case it isn't.

I'm currently trying to improve the live-monitoring of an application and
would like to get a simple overview of how many threads are in state
RUNNABLE, BLOCKED and so on.
For this I need to get all threads in the first place to iterate on. I know
of two ways how to do that programmatically:

1) ThreadMXBean.dumpAllThreads() which gives me an array of ThreadInfo
objects on which I could call getThreadState()
2) Thread.getAllStackTraces().keySet() which gives me a Set of Thread
objects on which I could call getState()

Either 1) or 2) both dump the threads, which seems like a lot of overhead
for this task and therefore presumably aren't supposed to be executed every
X seconds. Using reflection to make the private native Thread.getThreads()
available - if that's even possible(?) - doesn't seem correct either. Is
there an alternative for this?

If not, I'd like to suggest the addition of two in my opinion more
lightweight alternative APIs in Thread and/or ThreadMXBean (ThreadImpl).
Here is what I'm thinking of in a rough and untested state:

	public static Map<Thread.State, Integer> getAllThreadStateCounts() {
		// Get a snapshot of the list of all threads
		Thread[] threads = getThreads();
		Map<Thread.State, Integer> m = new
EnumMap<>(Thread.State.class);
		for (int i = 0; i < threads.length; i++) {
			m.merge(threads[i].getState(), 1, Integer::sum);
		}
		return m;
	}

	public static int getThreadCountByState(Thread.State state) {
		// Get a snapshot of the list of all threads
		Thread[] threads = getThreads();
		int counter = 0;
		for (int i = 0; i < threads.length; i++) {
			if (state == threads[i].getState()) {
				counter++;
			}
		}
		return counter;
	}


Is this something that could be worthwhile? Let me know what you think.

Cheers,
Christoph


From Roger.Riggs at Oracle.com  Fri Oct 27 15:38:30 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Oct 2017 11:38:30 -0400
Subject: [Proposal/Question] Provide mechanism to monitor thread states
 more efficiently
In-Reply-To: <000001d34f37$7fb5c1d0$7f214570$@freenet.de>
References: <000001d34f37$7fb5c1d0$7f214570$@freenet.de>
Message-ID: <4510ff7b-780b-8934-cbb6-fc57ed394128@Oracle.com>

Hi Christoph,

You might use ThreadGroup.enumerate(Thread[], recurse) after walking up 
the parents to the root ThreadGroup.

$.02, Roger


On 10/27/2017 11:23 AM, Christoph Dreis wrote:
> Hey,
>
> I don't know if this is the correct mailing list for this specific topic.
> Please let me know in case it isn't.
>
> I'm currently trying to improve the live-monitoring of an application and
> would like to get a simple overview of how many threads are in state
> RUNNABLE, BLOCKED and so on.
> For this I need to get all threads in the first place to iterate on. I know
> of two ways how to do that programmatically:
>
> 1) ThreadMXBean.dumpAllThreads() which gives me an array of ThreadInfo
> objects on which I could call getThreadState()
> 2) Thread.getAllStackTraces().keySet() which gives me a Set of Thread
> objects on which I could call getState()
>
> Either 1) or 2) both dump the threads, which seems like a lot of overhead
> for this task and therefore presumably aren't supposed to be executed every
> X seconds. Using reflection to make the private native Thread.getThreads()
> available - if that's even possible(?) - doesn't seem correct either. Is
> there an alternative for this?
>
> If not, I'd like to suggest the addition of two in my opinion more
> lightweight alternative APIs in Thread and/or ThreadMXBean (ThreadImpl).
> Here is what I'm thinking of in a rough and untested state:
>
> 	public static Map<Thread.State, Integer> getAllThreadStateCounts() {
> 		// Get a snapshot of the list of all threads
> 		Thread[] threads = getThreads();
> 		Map<Thread.State, Integer> m = new
> EnumMap<>(Thread.State.class);
> 		for (int i = 0; i < threads.length; i++) {
> 			m.merge(threads[i].getState(), 1, Integer::sum);
> 		}
> 		return m;
> 	}
>
> 	public static int getThreadCountByState(Thread.State state) {
> 		// Get a snapshot of the list of all threads
> 		Thread[] threads = getThreads();
> 		int counter = 0;
> 		for (int i = 0; i < threads.length; i++) {
> 			if (state == threads[i].getState()) {
> 				counter++;
> 			}
> 		}
> 		return counter;
> 	}
>
>
> Is this something that could be worthwhile? Let me know what you think.
>
> Cheers,
> Christoph
>


From christoph.dreis at freenet.de  Fri Oct 27 16:12:17 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Fri, 27 Oct 2017 18:12:17 +0200
Subject: [Proposal/Question] Provide mechanism to monitor thread states
 more efficiently
In-Reply-To: <4510ff7b-780b-8934-cbb6-fc57ed394128@Oracle.com>
References: <000001d34f37$7fb5c1d0$7f214570$@freenet.de>
 <4510ff7b-780b-8934-cbb6-fc57ed394128@Oracle.com>
Message-ID: <000101d34f3e$5c81bf50$15853df0$@freenet.de>

Hi Roger,

> You might use ThreadGroup.enumerate(Thread[], recurse) after walking up
> the parents to the root ThreadGroup.

Thanks. Isn't this method silently dropping threads in case it can't hold what you specified upfront as an array? Apart from that: Would it be a candidate for live-monitoring - e.g. what's the overhead of it based on your experience compared to other approaches?

And to make it more clear - preferably my suggestion would move into the ThreadMXBean interface as well to be fetchable via the management interfaces, which I think has no ThreadGroup.enumerate(Thread[], recurse)  alternative at the moment. Am I right?

Cheers,
Christoph

> On 10/27/2017 11:23 AM, Christoph Dreis wrote:
> > Hey,
> >
> > I don't know if this is the correct mailing list for this specific topic.
> > Please let me know in case it isn't.
> >
> > I'm currently trying to improve the live-monitoring of an application
> > and would like to get a simple overview of how many threads are in
> > state RUNNABLE, BLOCKED and so on.
> > For this I need to get all threads in the first place to iterate on. I
> > know of two ways how to do that programmatically:
> >
> > 1) ThreadMXBean.dumpAllThreads() which gives me an array of ThreadInfo
> > objects on which I could call getThreadState()
> > 2) Thread.getAllStackTraces().keySet() which gives me a Set of Thread
> > objects on which I could call getState()
> >
> > Either 1) or 2) both dump the threads, which seems like a lot of
> > overhead for this task and therefore presumably aren't supposed to be
> > executed every X seconds. Using reflection to make the private native
> > Thread.getThreads() available - if that's even possible(?) - doesn't
> > seem correct either. Is there an alternative for this?
> >
> > If not, I'd like to suggest the addition of two in my opinion more
> > lightweight alternative APIs in Thread and/or ThreadMXBean (ThreadImpl).
> > Here is what I'm thinking of in a rough and untested state:
> >
> > 	public static Map<Thread.State, Integer> getAllThreadStateCounts() {
> > 		// Get a snapshot of the list of all threads
> > 		Thread[] threads = getThreads();
> > 		Map<Thread.State, Integer> m = new
> > EnumMap<>(Thread.State.class);
> > 		for (int i = 0; i < threads.length; i++) {
> > 			m.merge(threads[i].getState(), 1, Integer::sum);
> > 		}
> > 		return m;
> > 	}
> >
> > 	public static int getThreadCountByState(Thread.State state) {
> > 		// Get a snapshot of the list of all threads
> > 		Thread[] threads = getThreads();
> > 		int counter = 0;
> > 		for (int i = 0; i < threads.length; i++) {
> > 			if (state == threads[i].getState()) {
> > 				counter++;
> > 			}
> > 		}
> > 		return counter;
> > 	}
> >
> >
> > Is this something that could be worthwhile? Let me know what you think.
> >
> > Cheers,
> > Christoph
> >



From kumar.x.srinivasan at oracle.com  Fri Oct 27 17:12:43 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 27 Oct 2017 10:12:43 -0700
Subject: RFR: 8190287: Update JDK's internal ASM to ASMv6
Message-ID: <59F3690B.6070309@oracle.com>

Hello Remi, Sundar and others,

Please review the webrev [1] to update JDK's internal ASM to v6.

To help with review areas, you can use the browser to search for mq 
patches commented with //

Highlights of changes:
1. updated ASMv6 // jdk-new-asmv6.patch
2. changes to jlink and jar to add ModuleMainClass and ModulePackages 
attributes //jdk-new-asm-update.patch
3. adjustments to jdk tests  //jdk-new-asm-test.patch
4. minor adjustments  to hotspot tests  //jdk-new-hotspot-test.patch

Tests:
jdk_tier1, jdk_tier2, testset hotspot, hotspot_tier1, nashorn ant tests,
Alan has also run several tests.

Big thanks to Alan for #2 and #3 as part of [3].

Thanks
Kumar

[1] http://cr.openjdk.java.net/~ksrini/8190287/webrev.00/index.html
[2] https://bugs.openjdk.java.net/browse/JDK-8190287
[3] https://bugs.openjdk.java.net/browse/JDK-8186236


From mandy.chung at oracle.com  Fri Oct 27 18:19:43 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 27 Oct 2017 11:19:43 -0700
Subject: RFR 8189319 : Add a java.util.Properties constructor that takes
 an initial capacity
In-Reply-To: <326a2344-79e3-b95d-18a6-731d022097d4@oracle.com>
References: <326a2344-79e3-b95d-18a6-731d022097d4@oracle.com>
Message-ID: <bb76fcdd-8041-3423-633c-841593c38f23@oracle.com>



On 10/26/17 6:43 PM, Brent Christian wrote:
> Hi,
>
> It would be useful to have a Properties constructor that takes an 
> argument to set the initial capacity. Such a constructor is present on 
> many of the other Map implementations in the JDK, including Hashtable, 
> the superclass of Properties.
>
> In particular, being able to specify the initial capacity of the 
> Properties object created to store the system properties could reduce 
> startup time.? The current initial capacity of 8 is insufficient.? We 
> could eliminate ~25,000 bytecodes currently spent resizing the 
> Properties by creating one of sufficient initial size.
>
> There are ~60 system properties in a minimal Java app.? I chose 84 - 
> it provides a good amount of wiggle room (and results in an internal 
> ConcurrentHashMap with a table size of 128; 64 would be too small, IMO).
>
> Please review this change:
>
> Issue:? https://bugs.openjdk.java.net/browse/JDK-8189319
> Webrev: http://cr.openjdk.java.net/~bchristi/8189319/webrev.01/

Looks okay.

It may be cleaner to initialize the map in a single place e.g. a private 
constructor taking Properties and initialCapacity.

Mandy

From Roger.Riggs at Oracle.com  Fri Oct 27 20:46:36 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Oct 2017 16:46:36 -0400
Subject: [Proposal/Question] Provide mechanism to monitor thread states
 more efficiently
In-Reply-To: <000101d34f3e$5c81bf50$15853df0$@freenet.de>
References: <000001d34f37$7fb5c1d0$7f214570$@freenet.de>
 <4510ff7b-780b-8934-cbb6-fc57ed394128@Oracle.com>
 <000101d34f3e$5c81bf50$15853df0$@freenet.de>
Message-ID: <6ff5db2b-958a-ddbd-608c-b1184d3e499f@Oracle.com>

Hi,

I was just pointing out there already is access to the information you 
are requesting
without adding a new API.

ThreadGroup.activeCount() provides the number of active threads.
Of course, threads come and go asynchronously.

Yes, the Thread array has to be allocated by the caller and may be too 
small but
the caller can check the return count against the array size to determine if
any threads have been omitted and retry with a larger array.

For example, a Stream of threads:

     ?static Stream<Thread> a(ThreadGroup g) {
     ??????? int count = 0 ;
     ??????? Thread[] threads = new Thread[g.activeCount() + 100];
     ??????? do {
     ??????????? count = g.enumerate(threads, true);
     ??????? } while (count >= threads.length);
     ??????? return Arrays.stream(threads, 0, count);
     ??? }

Roger



On 10/27/2017 12:12 PM, Christoph Dreis wrote:
> Hi Roger,
>
>> You might use ThreadGroup.enumerate(Thread[], recurse) after walking up
>> the parents to the root ThreadGroup.
> Thanks. Isn't this method silently dropping threads in case it can't hold what you specified upfront as an array? Apart from that: Would it be a candidate for live-monitoring - e.g. what's the overhead of it based on your experience compared to other approaches?
>
> And to make it more clear - preferably my suggestion would move into the ThreadMXBean interface as well to be fetchable via the management interfaces, which I think has no ThreadGroup.enumerate(Thread[], recurse)  alternative at the moment. Am I right?
>
> Cheers,
> Christoph
>
>> On 10/27/2017 11:23 AM, Christoph Dreis wrote:
>>> Hey,
>>>
>>> I don't know if this is the correct mailing list for this specific topic.
>>> Please let me know in case it isn't.
>>>
>>> I'm currently trying to improve the live-monitoring of an application
>>> and would like to get a simple overview of how many threads are in
>>> state RUNNABLE, BLOCKED and so on.
>>> For this I need to get all threads in the first place to iterate on. I
>>> know of two ways how to do that programmatically:
>>>
>>> 1) ThreadMXBean.dumpAllThreads() which gives me an array of ThreadInfo
>>> objects on which I could call getThreadState()
>>> 2) Thread.getAllStackTraces().keySet() which gives me a Set of Thread
>>> objects on which I could call getState()
>>>
>>> Either 1) or 2) both dump the threads, which seems like a lot of
>>> overhead for this task and therefore presumably aren't supposed to be
>>> executed every X seconds. Using reflection to make the private native
>>> Thread.getThreads() available - if that's even possible(?) - doesn't
>>> seem correct either. Is there an alternative for this?
>>>
>>> If not, I'd like to suggest the addition of two in my opinion more
>>> lightweight alternative APIs in Thread and/or ThreadMXBean (ThreadImpl).
>>> Here is what I'm thinking of in a rough and untested state:
>>>
>>> 	public static Map<Thread.State, Integer> getAllThreadStateCounts() {
>>> 		// Get a snapshot of the list of all threads
>>> 		Thread[] threads = getThreads();
>>> 		Map<Thread.State, Integer> m = new
>>> EnumMap<>(Thread.State.class);
>>> 		for (int i = 0; i < threads.length; i++) {
>>> 			m.merge(threads[i].getState(), 1, Integer::sum);
>>> 		}
>>> 		return m;
>>> 	}
>>>
>>> 	public static int getThreadCountByState(Thread.State state) {
>>> 		// Get a snapshot of the list of all threads
>>> 		Thread[] threads = getThreads();
>>> 		int counter = 0;
>>> 		for (int i = 0; i < threads.length; i++) {
>>> 			if (state == threads[i].getState()) {
>>> 				counter++;
>>> 			}
>>> 		}
>>> 		return counter;
>>> 	}
>>>
>>>
>>> Is this something that could be worthwhile? Let me know what you think.
>>>
>>> Cheers,
>>> Christoph
>>>
>


From Roger.Riggs at Oracle.com  Fri Oct 27 20:50:53 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 27 Oct 2017 16:50:53 -0400
Subject: Fwd: Re: [Proposal/Question] Provide mechanism to monitor thread
 states more efficiently
In-Reply-To: <6ff5db2b-958a-ddbd-608c-b1184d3e499f@Oracle.com>
References: <6ff5db2b-958a-ddbd-608c-b1184d3e499f@Oracle.com>
Message-ID: <963b9823-5451-b19a-4c4f-1e1d75fdf3c6@Oracle.com>

Hi,

(A bit too quick on the send button; need to reallocate if the array is 
not big enough).

I was just pointing out there already is access to the information you 
are requesting
without adding a new API.

ThreadGroup.activeCount() provides the number of active threads.
Of course, threads come and go asynchronously.

Yes, the Thread array has to be allocated by the caller and may be too 
small but
the caller can check the return count against the array size to determine if
any threads have been omitted and retry with a larger array.

For example, a Stream of threads:

     ??? static Stream<Thread> a(ThreadGroup g) {
     ??????? int count = g.activeCount();
     ??????? Thread[] threads = null;
     ??????? do {
     ??????????? threads = new Thread[count+100];
     ??????????? count = g.enumerate(threads, true);
     ??????? } while (count >= threads.length);
     ??????? return Arrays.stream(threads, 0, count);
     ??? }

Roger



On 10/27/2017 12:12 PM, Christoph Dreis wrote:
> Hi Roger,
>
>> You might use ThreadGroup.enumerate(Thread[], recurse) after walking up
>> the parents to the root ThreadGroup.
> Thanks. Isn't this method silently dropping threads in case it can't hold what you specified upfront as an array? Apart from that: Would it be a candidate for live-monitoring - e.g. what's the overhead of it based on your experience compared to other approaches?
>
> And to make it more clear - preferably my suggestion would move into the ThreadMXBean interface as well to be fetchable via the management interfaces, which I think has no ThreadGroup.enumerate(Thread[], recurse)  alternative at the moment. Am I right?
>
> Cheers,
> Christoph
>
>> On 10/27/2017 11:23 AM, Christoph Dreis wrote:
>>> Hey,
>>>
>>> I don't know if this is the correct mailing list for this specific topic.
>>> Please let me know in case it isn't.
>>>
>>> I'm currently trying to improve the live-monitoring of an application
>>> and would like to get a simple overview of how many threads are in
>>> state RUNNABLE, BLOCKED and so on.
>>> For this I need to get all threads in the first place to iterate on. I
>>> know of two ways how to do that programmatically:
>>>
>>> 1) ThreadMXBean.dumpAllThreads() which gives me an array of ThreadInfo
>>> objects on which I could call getThreadState()
>>> 2) Thread.getAllStackTraces().keySet() which gives me a Set of Thread
>>> objects on which I could call getState()
>>>
>>> Either 1) or 2) both dump the threads, which seems like a lot of
>>> overhead for this task and therefore presumably aren't supposed to be
>>> executed every X seconds. Using reflection to make the private native
>>> Thread.getThreads() available - if that's even possible(?) - doesn't
>>> seem correct either. Is there an alternative for this?
>>>
>>> If not, I'd like to suggest the addition of two in my opinion more
>>> lightweight alternative APIs in Thread and/or ThreadMXBean (ThreadImpl).
>>> Here is what I'm thinking of in a rough and untested state:
>>>
>>> 	public static Map<Thread.State, Integer> getAllThreadStateCounts() {
>>> 		// Get a snapshot of the list of all threads
>>> 		Thread[] threads = getThreads();
>>> 		Map<Thread.State, Integer> m = new
>>> EnumMap<>(Thread.State.class);
>>> 		for (int i = 0; i < threads.length; i++) {
>>> 			m.merge(threads[i].getState(), 1, Integer::sum);
>>> 		}
>>> 		return m;
>>> 	}
>>>
>>> 	public static int getThreadCountByState(Thread.State state) {
>>> 		// Get a snapshot of the list of all threads
>>> 		Thread[] threads = getThreads();
>>> 		int counter = 0;
>>> 		for (int i = 0; i < threads.length; i++) {
>>> 			if (state == threads[i].getState()) {
>>> 				counter++;
>>> 			}
>>> 		}
>>> 		return counter;
>>> 	}
>>>
>>>
>>> Is this something that could be worthwhile? Let me know what you think.
>>>
>>> Cheers,
>>> Christoph
>>>


From martinrb at google.com  Fri Oct 27 20:53:13 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 27 Oct 2017 13:53:13 -0700
Subject: RFR 8189319 : Add a java.util.Properties constructor that takes
 an initial capacity
In-Reply-To: <326a2344-79e3-b95d-18a6-731d022097d4@oracle.com>
References: <326a2344-79e3-b95d-18a6-731d022097d4@oracle.com>
Message-ID: <CA+kOe0-_Y4A5zRmOb_8c7d9UhSA0_9f1bBMJ97tU6H1Gjw91uw@mail.gmail.com>

I completely missed the fact that Properties continues to inherit from
Hashtable but the data is actually stored in a CHM.  I would have been
afraid to make that change ...

Looks good!

On Thu, Oct 26, 2017 at 6:43 PM, Brent Christian <brent.christian at oracle.com
> wrote:

> Hi,
>
> It would be useful to have a Properties constructor that takes an argument
> to set the initial capacity. Such a constructor is present on many of the
> other Map implementations in the JDK, including Hashtable, the superclass
> of Properties.
>
> In particular, being able to specify the initial capacity of the
> Properties object created to store the system properties could reduce
> startup time.  The current initial capacity of 8 is insufficient.  We could
> eliminate ~25,000 bytecodes currently spent resizing the Properties by
> creating one of sufficient initial size.
>
> There are ~60 system properties in a minimal Java app.  I chose 84 - it
> provides a good amount of wiggle room (and results in an internal
> ConcurrentHashMap with a table size of 128; 64 would be too small, IMO).
>
> Please review this change:
>
> Issue:  https://bugs.openjdk.java.net/browse/JDK-8189319
> Webrev: http://cr.openjdk.java.net/~bchristi/8189319/webrev.01/
>
> Thanks,
> -Brent
>

From mandy.chung at oracle.com  Fri Oct 27 20:54:29 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 27 Oct 2017 13:54:29 -0700
Subject: [Proposal/Question] Provide mechanism to monitor thread states
 more efficiently
In-Reply-To: <000001d34f37$7fb5c1d0$7f214570$@freenet.de>
References: <000001d34f37$7fb5c1d0$7f214570$@freenet.de>
Message-ID: <635af57f-86d0-3983-091d-74cf4a47a9df@oracle.com>

serviceability-dev is the mailing list for discussing 
java.lang.management APIs.

Getting the stack trace is expensive. ThreadMXBean.getThreadInfos(ids) 
does not get the stack trace and locks information and is less expensive.

A typical lightweight monitoring application does BCI and call 
Thread::getState and collect all other monitoring data.

Mandy

On 10/27/17 8:23 AM, Christoph Dreis wrote:
> Hey,
>
> I don't know if this is the correct mailing list for this specific topic.
> Please let me know in case it isn't.
>
> I'm currently trying to improve the live-monitoring of an application and
> would like to get a simple overview of how many threads are in state
> RUNNABLE, BLOCKED and so on.
> For this I need to get all threads in the first place to iterate on. I know
> of two ways how to do that programmatically:
>
> 1) ThreadMXBean.dumpAllThreads() which gives me an array of ThreadInfo
> objects on which I could call getThreadState()
> 2) Thread.getAllStackTraces().keySet() which gives me a Set of Thread
> objects on which I could call getState()
>
> Either 1) or 2) both dump the threads, which seems like a lot of overhead
> for this task and therefore presumably aren't supposed to be executed every
> X seconds. Using reflection to make the private native Thread.getThreads()
> available - if that's even possible(?) - doesn't seem correct either. Is
> there an alternative for this?
>
> If not, I'd like to suggest the addition of two in my opinion more
> lightweight alternative APIs in Thread and/or ThreadMXBean (ThreadImpl).
> Here is what I'm thinking of in a rough and untested state:
>
> 	public static Map<Thread.State, Integer> getAllThreadStateCounts() {
> 		// Get a snapshot of the list of all threads
> 		Thread[] threads = getThreads();
> 		Map<Thread.State, Integer> m = new
> EnumMap<>(Thread.State.class);
> 		for (int i = 0; i < threads.length; i++) {
> 			m.merge(threads[i].getState(), 1, Integer::sum);
> 		}
> 		return m;
> 	}
>
> 	public static int getThreadCountByState(Thread.State state) {
> 		// Get a snapshot of the list of all threads
> 		Thread[] threads = getThreads();
> 		int counter = 0;
> 		for (int i = 0; i < threads.length; i++) {
> 			if (state == threads[i].getState()) {
> 				counter++;
> 			}
> 		}
> 		return counter;
> 	}
>
>
> Is this something that could be worthwhile? Let me know what you think.
>
> Cheers,
> Christoph
>


From chris.w.dennis at gmail.com  Fri Oct 27 20:56:02 2017
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Fri, 27 Oct 2017 16:56:02 -0400
Subject: Confusion (or bugs) regarding the 'UNORDERED' Collector Characteristic
Message-ID: <A00CF5D4-7F22-45C0-A032-B339E9CC8DBF@gmail.com>

Hi All,

I?m very confused about what was intended with the ?UNORDERED? Collector characteristic.  My logical inference was that unordered as a Collector characteristic meant that the result of this collector applied to any stream was independent of the order of element delivery.  This means that the stream backend could safely elide any ordered characteristic of the stream driving the collector and open up more possible execution pathways (parallelism for example).  The javadoc for unordered is two sentences:

/**
 * Indicates that the collection operation does not commit to preserving
 * the encounter order of input elements.  (This might be true if the
 * result container has no intrinsic order, such as a {@link Set}.)
 */

The first sentence makes sense, although it is phrased in a way that also explains the behavior seen if you flag an order sensitive collector as unordered.  The second sentence is weird, it implies a relation between collectors, encounter order, and an inherent ordering or iteration order of a collection object that might be the target of a collection. To me the important property of a Collection object with regards to ordering of a Collector that fills it is whether reordering the insertions to the collection can change the resultant state, for a Set this is clearly true since only the first presented element that is equal will be stored.

There is also a paragraph in the Collector javadoc:

* <p>For collectors that do not have the {@code UNORDERED} characteristic,
* two accumulated results {@code a1} and {@code a2} are equivalent if
* {@code finisher.apply(a1).equals(finisher.apply(a2))}.  For unordered
* collectors, equivalence is relaxed to allow for non-equality related to
* differences in order.  (For example, an unordered collector that accumulated
* elements to a {@code List} would consider two lists equivalent if they
* contained the same elements, ignoring order.)

This seems weird, why would we try to define correctness of a parallel reduction against a collector that was sensitive to ordering.

Finally, when investigating the properties of the collectors returned from the Collectors static factory I was surprised to discover that none of the collectors that are truly unordered were marked as such (counting, min, max, averaging, summing, summarizing), and the only collector that was marked as unordered was Collectors.toSet(), which although it is explicitly marked as unordered seems like it really shouldn?t be.

Whats going on here?  Which parts of all this are intended and which (if any) are bugs?

Thanks in advance for any enlightenment,

Chris Dennis

P.S. Coincidentally the unordered toSet() collector works perfectly at the moment due to the happy interaction of the Spliterator.trySplit() contract and the folding/combining behavior of the stream implementations parallel reduction algorithm.

From brent.christian at oracle.com  Fri Oct 27 21:37:21 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 27 Oct 2017 14:37:21 -0700
Subject: RFR 8189319 : Add a java.util.Properties constructor that takes
 an initial capacity
In-Reply-To: <bb76fcdd-8041-3423-633c-841593c38f23@oracle.com>
References: <326a2344-79e3-b95d-18a6-731d022097d4@oracle.com>
 <bb76fcdd-8041-3423-633c-841593c38f23@oracle.com>
Message-ID: <313e04f8-7e54-c388-e2f3-cf762c510f70@oracle.com>

On 10/27/2017 11:19 AM, mandy chung wrote:
> It may be cleaner to initialize the map in a single place e.g. a private
> constructor taking Properties and initialCapacity.

Yeah, that's a good idea.  See new webrev:

http://cr.openjdk.java.net/~bchristi/8189319/webrev.02/index.html

Thanks,
-Brent


From mandy.chung at oracle.com  Fri Oct 27 21:39:50 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Fri, 27 Oct 2017 14:39:50 -0700
Subject: RFR 8189319 : Add a java.util.Properties constructor that takes
 an initial capacity
In-Reply-To: <313e04f8-7e54-c388-e2f3-cf762c510f70@oracle.com>
References: <326a2344-79e3-b95d-18a6-731d022097d4@oracle.com>
 <bb76fcdd-8041-3423-633c-841593c38f23@oracle.com>
 <313e04f8-7e54-c388-e2f3-cf762c510f70@oracle.com>
Message-ID: <442cd672-39bf-0a8a-9354-3e49e0244d0b@oracle.com>



On 10/27/17 2:37 PM, Brent Christian wrote:
> On 10/27/2017 11:19 AM, mandy chung wrote:
>> It may be cleaner to initialize the map in a single place e.g. a private
>> constructor taking Properties and initialCapacity.
>
> Yeah, that's a good idea.? See new webrev:
>
> http://cr.openjdk.java.net/~bchristi/8189319/webrev.02/index.html

Looks good.

Mandy

From roger.riggs at oracle.com  Fri Oct 27 22:08:07 2017
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 27 Oct 2017 18:08:07 -0400
Subject: RFR 8189319 : Add a java.util.Properties constructor that takes
 an initial capacity
In-Reply-To: <442cd672-39bf-0a8a-9354-3e49e0244d0b@oracle.com>
References: <326a2344-79e3-b95d-18a6-731d022097d4@oracle.com>
 <bb76fcdd-8041-3423-633c-841593c38f23@oracle.com>
 <313e04f8-7e54-c388-e2f3-cf762c510f70@oracle.com>
 <442cd672-39bf-0a8a-9354-3e49e0244d0b@oracle.com>
Message-ID: <61f9ad8b-7c7f-9db2-c404-edc79f27a902@oracle.com>

+1

On 10/27/17 5:39 PM, mandy chung wrote:
>
>
> On 10/27/17 2:37 PM, Brent Christian wrote:
>> On 10/27/2017 11:19 AM, mandy chung wrote:
>>> It may be cleaner to initialize the map in a single place e.g. a 
>>> private
>>> constructor taking Properties and initialCapacity.
>>
>> Yeah, that's a good idea.? See new webrev:
>>
>> http://cr.openjdk.java.net/~bchristi/8189319/webrev.02/index.html
>
> Looks good.
>
> Mandy


From naoto.sato at oracle.com  Fri Oct 27 23:26:05 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 27 Oct 2017 16:26:05 -0700
Subject: <i18n dev> JDK10 RFR of JDK-8185841:Values from
 getFirstDayOfWeek() are inconsistent with CLDR
In-Reply-To: <ffb58a71-ca80-7b78-9a9f-427aba94086e@oracle.com>
References: <ffb58a71-ca80-7b78-9a9f-427aba94086e@oracle.com>
Message-ID: <22d6d459-a209-89c5-263a-2a82218a71a7@oracle.com>

Looks fine.

Naoto

On 10/26/17 11:24 PM, Rachna Goel wrote:
> Hi,
> 
> Kindly review the fix to JDK-8185841.
> 
> Bug : https://bugs.openjdk.java.net/browse/JDK-8185841.
> 
> patch : http://cr.openjdk.java.net/~rgoel/JDK-8185841/webrev.08/
> 
> Fix is to relocate this region dependent data. New Bundle will be 
> generated when Locale id has non empty script and country code and it 
> contains region dependent data.
>  ?e.g for "az_Latn_AZ" locale, CalendarData_az_AZ.java Bundle will be 
> generated and the data currently in CalendarData_az_Latn_AZ.java should 
> be relocated into it.
> 

From patrick at reini.net  Sat Oct 28 14:05:01 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Sat, 28 Oct 2017 16:05:01 +0200
Subject: JDK-8067661: transferTo proposal for Appendable
Message-ID: <15bb28d5-003c-ff0c-da16-5ce3920ea765@reini.net>

Hi There,

Based on the *transferTo* Method on the InputStream I would propose to
introduce a
default method on the Readable interface. In that way the method can be
used for
all existing implementations of Readable and still be implemented in a
special
way by a individual implementer.


?? /**

??? * Reads all characters from this readable and writes the characters to
??? * the given appendable in the order that they are read. On return, this
??? * readable will be at end its data.
??? * <p>
??? * This method may block indefinitely reading from the readable, or
??? * writing to the appendable. The behavior for the case where the
readable
??? * and/or appendable is <i>asynchronously closed</i>, or the thread
??? * interrupted during the transfer, is highly readable and appendable
??? * specific, and therefore not specified.
??? * <p>
??? * If an I/O error occurs reading from the readable or writing to the
??? * appendable, then it may do so after some characters have been read or
??? * written. Consequently the readable may not be at end of its data and
??? * one, or both participants may be in an inconsistent state. That in
mind
??? * all additional measures required by one or both participants in
order to
??? * eventually free their internal resources have to be taken by the
caller
??? * of this method.
??? *
??? * @param? out the appendable, non-null
??? * @return the number of characters transferred
??? * @throws IOException if an I/O error occurs when reading or writing
??? * @throws NullPointerException if {@code out} is {@code null}
??? *
??? * @since 18.3
??? */
?? default long transferTo(Appendable out) throws IOException {
?? ....
?? }


Cheers Patrick

From fw at deneb.enyo.de  Sat Oct 28 14:16:50 2017
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 28 Oct 2017 16:16:50 +0200
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner,
 not finalizers
In-Reply-To: <59CC3725.7080505@oracle.com> (Xueming Shen's message of "Wed, 27
 Sep 2017 16:41:25 -0700")
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com>
Message-ID: <871slnwe5p.fsf@mid.deneb.enyo.de>

* Xueming Shen:

> I removed the ln#657-#663, and updated the @apiNote in deflter, inflater
> and zipfile accordingly, mainly combined your comment and the approach
> for the fis/fo. they are "simpler" and straightforward now, at least for me.
>
> https://bugs.openjdk.java.net/browse/JDK-8187485
> http://cr.openjdk.java.net/~sherman/8185582/webrev

In ZipFile:

387                 Inflater inf = getInflater();
388                 InputStream is = new ZipFileInflaterInputStream(in, inf, (int)size,
389                                          () -> releaseInflater(inf));
390                 synchronized (streams) {
391                     streams.add(is);
392                 }

Doesn't this leak the inflater if Cleaner.register() and thus the
ZipFileInflaterInputStream constructor throw?

From xueming.shen at oracle.com  Sat Oct 28 17:33:49 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sat, 28 Oct 2017 10:33:49 -0700
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <871slnwe5p.fsf@mid.deneb.enyo.de>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
Message-ID: <59F4BF7D.9030703@oracle.com>

On 10/28/17, 7:16 AM, Florian Weimer wrote:
> * Xueming Shen:
>
>> I removed the ln#657-#663, and updated the @apiNote in deflter, inflater
>> and zipfile accordingly, mainly combined your comment and the approach
>> for the fis/fo. they are "simpler" and straightforward now, at least for me.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8187485
>> http://cr.openjdk.java.net/~sherman/8185582/webrev
> In ZipFile:
>
> 387                 Inflater inf = getInflater();
> 388                 InputStream is = new ZipFileInflaterInputStream(in, inf, (int)size,
> 389                                          () ->  releaseInflater(inf));
> 390                 synchronized (streams) {
> 391                     streams.add(is);
> 392                 }
>
> Doesn't this leak the inflater if Cleaner.register() and thus the
> ZipFileInflaterInputStream constructor throw?

Hi Florian, thanks for reviewing.

The answer is "yes", if Cleaner.register() fails and throws a runtime 
exception ( internal
error probably?)  somewhere inside its implementation. I'm now an expert 
on Cleaner's
implementation, but the "register" operation looks straightforward, 
creating the phantom
ref object and "inserting" the newly created phantom ref into the queue, 
which appears
unlikely to fail easily. The "assumption" of taking the approach to move 
away from finalize()
to cleaner is that "Cleaner.register()" should work as reliable as 
finalizer. But in situation it
really fails, I would assume there is really nothing can be done to save 
the world here. Similar
to the situation like "free()" fails (for the "calloc()/free()" pair) 
and the memory to be
deallocated might be left "un-freed"?

In the latest version (this webrev) the inflater's default "cleaner" is 
turned off via a package
private constructor, with the assumption that it is guaranteed that the 
inflater will always be
putback into the "inflaterCache" by the corresponding ZFIIS cleaner and 
all inflaters inside
"inflaterCache" is guaranteed to be cleaned up via the ZipFile cleaner. 
So yes arguably we are
less safe by removing that (if this is the concern) But if 
Cleaner.register() here can fail, there
is no guarantee inflater's default Cleaner.register() will not fail.

It might be possible to try-catch to expect Cleaner.register might fail, 
but I doubt it's really
necessary here and it is the recommended usage of Cleaner?

Thanks!
-Sherman


From peter.levart at gmail.com  Sat Oct 28 17:47:53 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 28 Oct 2017 19:47:53 +0200
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <871slnwe5p.fsf@mid.deneb.enyo.de>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
Message-ID: <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>

Hi Florian,

On 10/28/17 16:16, Florian Weimer wrote:
> * Xueming Shen:
>
>> https://bugs.openjdk.java.net/browse/JDK-8187485
>> http://cr.openjdk.java.net/~sherman/8185582/webrev
> In ZipFile:
>
> 387                 Inflater inf = getInflater();
> 388                 InputStream is = new ZipFileInflaterInputStream(in, inf, (int)size,
> 389                                          () -> releaseInflater(inf));
> 390                 synchronized (streams) {
> 391                     streams.add(is);
> 392                 }
>
> Doesn't this leak the inflater if Cleaner.register() and thus the
> ZipFileInflaterInputStream constructor throw?

Thanks for being alert. I think that all that can be thrown between 
getInfalter() call and streams.add() successfully returning is 
OutOfMemoryError or StackOverflowError. OOME can be thrown anywhere, not 
only as a consequence of Cleaner.register(). I see following potential 
places where allocation may be taking place:

- constructing the lambda instance (line 389)
-? allocating ZipFileInflaterInputStream object
- multiple places in ZipFileInflaterInputStream.<init> and 
InflaterInputStream.<init> (including but not limited to Cleaner.register())
- streams.add() (line 391)

Can we do anything about it? Let's see. For example:

Inflater inf = getInflater();
InputStream is;

try {
 ??? is = new ZipFileInflaterInputStream(in, inf, (int)size, () -> 
releaseInflater(inf));
} catch (OutOfMemoryError e) {
 ??? releaseInflater(inf);
 ??? throw e;
}

try {
 ??? synchronized (streams) {
 ??? ??? streams.add(is);
 ??? }
} catch (OutOfMemoryError e) {
 ??? try { is.close(); } catch (IOException ignore) {}
}

...but, even releaseInflater(inf) may throw OOME (in line 470):

 ?467???? private void releaseInflater(Inflater inf) {
 ?468???????? inf.reset();
 ?469???????? synchronized (inflaterCache) {
 ?470???????????? inflaterCache.add(inf);
 ?471???????? }
 ?472???? }

So we may change it to the following, which would make it more robust 
for other uses too:

private void releaseInflater(Inflater inf) {
 ?? inf.reset();
 ?? try {
 ?? ??? synchronized (inflaterCache) {
 ?????? ??? inflaterCache.add(inf);
 ?? ??? }
 ?? } catch (OutOfMemoryError e) {
 ?? ??? inf.end();
 ??? ?? throw e;
 ?? }
}

...and that's it for OOME, hopefully.

But what about StackOverflowError? If we want to go that far, we may 
need to create a special minimal critical method which encapsulates the 
logic of obtaining Inflater and creating ZipFileInflaterInputStream with 
it and then put a @ReservedStackAccess annotation on it. Like the following:

 ??? @ReservedStackAccess
 ??? private ZipFileInflaterInputStream createZipFileInflaterInputStream(
 ??????? ZipFileInputStream zfin, int size
 ??? ) {
 ??????? Inflater inf = getInflater();
 ??????? ZipFileInflaterInputStream is;
 ??????? try {
 ??????????? is = new ZipFileInflaterInputStream(zfin, inf, size,
 ??????????????????????????????????????????????? () -> 
releaseInflater(inf));
 ??????? } catch (OutOfMemoryError e) {
 ??????????? releaseInflater(inf);
 ??????????? throw e;
 ??????? }
 ??????? try {
 ??????????? synchronized (streams) {
 ??????????????? streams.add(is);
 ??????????? }
 ??????? } catch (OutOfMemoryError e) {
 ??????????? try {
 ??????????????? is.close();
 ??????????? } catch (IOException ignore) {
 ??????????????? // not really possible - just making javac happy
 ??????????? }
 ??????????? throw e;
 ??????? }
 ??????? return is;
 ??? }


What do you think, Sherman?

Regards, Peter


From Roger.Riggs at Oracle.com  Sat Oct 28 18:57:58 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Sat, 28 Oct 2017 14:57:58 -0400
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <15bb28d5-003c-ff0c-da16-5ce3920ea765@reini.net>
References: <15bb28d5-003c-ff0c-da16-5ce3920ea765@reini.net>
Message-ID: <0607f21d-0e5d-2d9e-89da-9e43144eae84@Oracle.com>

Hi Patrick,

Sounds like a good idea to me.

Do you have any suggestions for concrete implementations that may 
benefit from specialized
implementations?

As a 'push' API, an implementation will necessarily have to allocate a 
buffer and read
characters and then append them to the appendable.? I don't remember if 
a 'pull' API was
considered for streams in which the dest could provide its own buffer to 
the reader
and benefit from one less copy of the bytes.

Thanks, Roger


On 10/28/2017 10:05 AM, Patrick Reinhart wrote:
> Hi There,
>
> Based on the *transferTo* Method on the InputStream I would propose to
> introduce a
> default method on the Readable interface. In that way the method can be
> used for
> all existing implementations of Readable and still be implemented in a
> special
> way by a individual implementer.
>
>
>  ?? /**
>
>  ??? * Reads all characters from this readable and writes the characters to
>  ??? * the given appendable in the order that they are read. On return, this
>  ??? * readable will be at end its data.
>  ??? * <p>
>  ??? * This method may block indefinitely reading from the readable, or
>  ??? * writing to the appendable. The behavior for the case where the
> readable
>  ??? * and/or appendable is <i>asynchronously closed</i>, or the thread
>  ??? * interrupted during the transfer, is highly readable and appendable
>  ??? * specific, and therefore not specified.
>  ??? * <p>
>  ??? * If an I/O error occurs reading from the readable or writing to the
>  ??? * appendable, then it may do so after some characters have been read or
>  ??? * written. Consequently the readable may not be at end of its data and
>  ??? * one, or both participants may be in an inconsistent state. That in
> mind
>  ??? * all additional measures required by one or both participants in
> order to
>  ??? * eventually free their internal resources have to be taken by the
> caller
>  ??? * of this method.
>  ??? *
>  ??? * @param? out the appendable, non-null
>  ??? * @return the number of characters transferred
>  ??? * @throws IOException if an I/O error occurs when reading or writing
>  ??? * @throws NullPointerException if {@code out} is {@code null}
>  ??? *
>  ??? * @since 18.3
>  ??? */
>  ?? default long transferTo(Appendable out) throws IOException {
>  ?? ....
>  ?? }
>
>
> Cheers Patrick


From xueming.shen at oracle.com  Sat Oct 28 19:01:45 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Sat, 28 Oct 2017 12:01:45 -0700
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
Message-ID: <59F4D419.8070201@oracle.com>

On 10/28/17, 10:47 AM, Peter Levart wrote:
> Hi Florian,
>
> On 10/28/17 16:16, Florian Weimer wrote:
>> * Xueming Shen:
>>
>>> https://bugs.openjdk.java.net/browse/JDK-8187485
>>> http://cr.openjdk.java.net/~sherman/8185582/webrev
>> In ZipFile:
>>
>> 387                 Inflater inf = getInflater();
>> 388                 InputStream is = new ZipFileInflaterInputStream(in, inf, (int)size,
>> 389                                          () ->  releaseInflater(inf));
>> 390                 synchronized (streams) {
>> 391                     streams.add(is);
>> 392                 }
>>
>> Doesn't this leak the inflater if Cleaner.register() and thus the
>> ZipFileInflaterInputStream constructor throw?
>
> Thanks for being alert. I think that all that can be thrown between 
> getInfalter() call and streams.add() successfully returning is 
> OutOfMemoryError or StackOverflowError. OOME can be thrown anywhere, 
> not only as a consequence of Cleaner.register(). I see following 
> potential places where allocation may be taking place:
>
> - constructing the lambda instance (line 389)
> -  allocating ZipFileInflaterInputStream object
> - multiple places in ZipFileInflaterInputStream.<init> and 
> InflaterInputStream.<init> (including but not limited to 
> Cleaner.register())
> - streams.add() (line 391)
>
> Can we do anything about it? Let's see. For example:
>
> Inflater inf = getInflater();
> InputStream is;
>
> try {
>     is = new ZipFileInflaterInputStream(in, inf, (int)size, () -> 
> releaseInflater(inf));
> } catch (OutOfMemoryError e) {
>     releaseInflater(inf);
>     throw e;
> }
>
> try {
>     synchronized (streams) {
>         streams.add(is);
>     }
> } catch (OutOfMemoryError e) {
>     try { is.close(); } catch (IOException ignore) {}
> }
>
> ...but, even releaseInflater(inf) may throw OOME (in line 470):
>
>  467     private void releaseInflater(Inflater inf) {
>  468         inf.reset();
>  469         synchronized (inflaterCache) {
>  470             inflaterCache.add(inf);
>  471         }
>  472     }
>
> So we may change it to the following, which would make it more robust 
> for other uses too:
>
> private void releaseInflater(Inflater inf) {
>    inf.reset();
>    try {
>        synchronized (inflaterCache) {
>            inflaterCache.add(inf);
>        }
>    } catch (OutOfMemoryError e) {
>        inf.end();
>        throw e;
>    }
> }
>
> ...and that's it for OOME, hopefully.
>
> But what about StackOverflowError? If we want to go that far, we may 
> need to create a special minimal critical method which encapsulates 
> the logic of obtaining Inflater and creating 
> ZipFileInflaterInputStream with it and then put a @ReservedStackAccess 
> annotation on it. Like the following:
>
>     @ReservedStackAccess
>     private ZipFileInflaterInputStream createZipFileInflaterInputStream(
>         ZipFileInputStream zfin, int size
>     ) {
>         Inflater inf = getInflater();
>         ZipFileInflaterInputStream is;
>         try {
>             is = new ZipFileInflaterInputStream(zfin, inf, size,
>                                                 () -> 
> releaseInflater(inf));
>         } catch (OutOfMemoryError e) {
>             releaseInflater(inf);
>             throw e;
>         }
>         try {
>             synchronized (streams) {
>                 streams.add(is);
>             }
>         } catch (OutOfMemoryError e) {
>             try {
>                 is.close();
>             } catch (IOException ignore) {
>                 // not really possible - just making javac happy
>             }
>             throw e;
>         }
>         return is;
>     }
>
>
> What do you think, Sherman?
>

There is reason why those are VirutalMachineError erros. It appears in 
this situation the vm
is in a more critical status than a inflater is getting leaked out. I 
would assume you only catch
these errors if/when the consequence of not catching is more severe and 
the "thing" you are
going to do in catch is not going to trigger more errors. Sure we do 
that here and there in
the libraries code for various reasons, but wonder if here is the place 
that is worth doing that.
That said, if this is a real concern, instead of catching all the 
possible vm erros here and there
to make Cleaner work correctly, a better alternative might be to go back 
to the previous version
to leave the zipfile/deflater cleaner configured/registerd (give up the 
special constructor idea),
so the deflater can get cleaned by itself in case all upstream clean up 
mechanism failed and
the Cleaner mechanism somehow still functions. Opinion?

-Sherman


From fw at deneb.enyo.de  Sat Oct 28 20:22:17 2017
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sat, 28 Oct 2017 22:22:17 +0200
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner,
 not finalizers
In-Reply-To: <59F4BF7D.9030703@oracle.com> (Xueming Shen's message of "Sat, 28
 Oct 2017 10:33:49 -0700")
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <59F4BF7D.9030703@oracle.com>
Message-ID: <87mv4buio6.fsf@mid.deneb.enyo.de>

* Xueming Shen:

> It might be possible to try-catch to expect Cleaner.register might
> fail, but I doubt it's really necessary here and it is the
> recommended usage of Cleaner?

That is actually why I posted this. 8-)

For similar functionality in other languages, it is often necessary to
perform all the required allocations for cleanup registration upfront,
then allocate the resource, and finally install it in the cleanup
handler.

A straightforward translation to the Cleaner facility and the
CleaningExample in the documentation would not allocate the
state-to-be-cleaned in the State constructor, but in a separate method
which is called after Cleaner.register().  But I don't know if this
could run into any concurrency issues.

From christoph.dreis at freenet.de  Sun Oct 29 15:24:45 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Sun, 29 Oct 2017 16:24:45 +0100
Subject: [Bug][JDK10] Fix duplicated "the" occurrences in docs and inline
 comments
Message-ID: <006b01d350ca$0d0602f0$271208d0$@freenet.de>

Hey,

Just noticed an occurrence of a duplicated "the" in a Locale doc and looked
for other occurrences in java.base while being on it.

I don't know if documentation changes follow a special workflow because of
possible translations. Please let me know!

But I'd be happy if this is sponsored or moved to the appropriate mailing
list.

Cheers,
Christoph


===== PATCH ======
diff -r 359c604930af src/java.base/share/classes/java/lang/WeakPairMap.java
--- a/src/java.base/share/classes/java/lang/WeakPairMap.java	Fri Oct 27
09:51:48 2017 -0700
+++ b/src/java.base/share/classes/java/lang/WeakPairMap.java	Sun Oct 29
16:13:11 2017 +0100
@@ -88,7 +88,7 @@
      * Maps the specified key pair to the specified value in this
WeakPairMap.
      * Neither the keys nor the value can be null.
      * <p>The value can be retrieved by calling the {@link #get} method
-     * with the the same keys (compared by identity).
+     * with the same keys (compared by identity).
      *
      * @param k1 the 1st of the pair of keys with which the specified value
is to
      *           be associated

diff -r 359c604930af
src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
Fri Oct 27 09:51:48 2017 -0700
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
Sun Oct 29 16:13:11 2017 +0100
@@ -1196,7 +1196,7 @@
 
         static
         MethodHandle bindCaller(MethodHandle mh, Class<?> hostClass) {
-            // Code in the the boot layer should now be careful while
creating method handles or
+            // Code in the boot layer should now be careful while creating
method handles or
             // functional interface instances created from method
references to @CallerSensitive  methods,
             // it needs to be ensured the handles or interface instances
are kept safe and are not passed
             // from the boot layer to untrusted code.

diff -r 359c604930af
src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
--- a/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
Fri Oct 27 09:51:48 2017 -0700
+++ b/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
Sun Oct 29 16:13:11 2017 +0100
@@ -195,7 +195,7 @@
         // In case we need to double-back onto the StringConcatFactory
during this
         // static initialization, make sure we have the reasonable defaults
to complete
         // the static initialization properly. After that, actual users
would use the
-        // the proper values we have read from the the properties.
+        // the proper values we have read from the properties.
         STRATEGY = DEFAULT_STRATEGY;
         // CACHE_ENABLE = false; // implied
         // CACHE = null;         // implied

diff -r 359c604930af src/java.base/share/classes/java/util/Locale.java
--- a/src/java.base/share/classes/java/util/Locale.java	Fri Oct 27 09:51:48
2017 -0700
+++ b/src/java.base/share/classes/java/util/Locale.java	Sun Oct 29 16:13:11
2017 +0100
@@ -1909,7 +1909,7 @@
      * Returns a name for the locale that is appropriate for display to the
      * user. This will be the values returned by getDisplayLanguage(),
      * getDisplayScript(), getDisplayCountry(), and getDisplayVariant()
assembled
-     * into a single string. The the non-empty values are used in order,
+     * into a single string. The non-empty values are used in order,
      * with the second and subsequent names in parentheses.  For example:
      * <blockquote>
      * language (script, country, variant)<br>

diff -r 359c604930af
src/java.base/share/classes/java/util/ServiceLoader.java
--- a/src/java.base/share/classes/java/util/ServiceLoader.java	Fri Oct 27
09:51:48 2017 -0700
+++ b/src/java.base/share/classes/java/util/ServiceLoader.java	Sun Oct 29
16:13:11 2017 +0100
@@ -1409,7 +1409,7 @@
      *
      * <p> To achieve laziness the actual work of locating providers is
done
      * when processing the stream. If a service provider cannot be loaded
for any
-     * of the the reasons specified in the <a href="#errors">Errors</a>
section
+     * of the reasons specified in the <a href="#errors">Errors</a> section
      * above then {@link ServiceConfigurationError} is thrown by whatever
method
      * caused the service provider to be loaded. </p>
      *

diff -r 359c604930af
src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
--- a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
Fri Oct 27 09:51:48 2017 -0700
+++ b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
Sun Oct 29 16:13:11 2017 +0100
@@ -66,7 +66,7 @@
  * -m and --add-modules options. The modules are located on a module path
that
  * is constructed from the upgrade module path, system modules, and
application
  * module path. The Configuration is instantiated as the boot layer with
each
- * module in the the configuration defined to a class loader.
+ * module in the configuration defined to a class loader.
  */
 
 public final class ModuleBootstrap {

diff -r 359c604930af
src/java.base/share/classes/jdk/internal/module/ModuleHashesBuilder.java
---
a/src/java.base/share/classes/jdk/internal/module/ModuleHashesBuilder.java
Fri Oct 27 09:51:48 2017 -0700
+++
b/src/java.base/share/classes/jdk/internal/module/ModuleHashesBuilder.java
Sun Oct 29 16:13:11 2017 +0100
@@ -74,7 +74,7 @@
      * the outgoing edges from M to non-candidate modules.
      */
     public Map<String, ModuleHashes> computeHashes(Set<String> roots) {
-        // build a graph containing the the packaged modules and
+        // build a graph containing the packaged modules and
         // its transitive dependences matching --hash-modules
         Graph.Builder<String> builder = new Graph.Builder<>();
         Deque<ResolvedModule> deque = new
ArrayDeque<>(configuration.modules());

diff -r 359c604930af
src/java.base/share/classes/jdk/internal/module/Resources.java
--- a/src/java.base/share/classes/jdk/internal/module/Resources.java	Fri
Oct 27 09:51:48 2017 -0700
+++ b/src/java.base/share/classes/jdk/internal/module/Resources.java	Sun
Oct 29 16:13:11 2017 +0100
@@ -56,7 +56,7 @@
     /**
      * Derive a <em>package name</em> for a resource. The package name
      * returned by this method may not be a legal package name. This method
-     * returns null if the the resource name ends with a "/" (a directory)
+     * returns null if the resource name ends with a "/" (a directory)
      * or the resource name does not contain a "/".
      */
     public static String toPackageName(String name) {

diff -r 359c604930af
src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java
--- a/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java
Fri Oct 27 09:51:48 2017 -0700
+++ b/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java
Sun Oct 29 16:13:11 2017 +0100
@@ -192,7 +192,7 @@
     private static final int LOCAL = 0x2000000;
 
     /**
-     * Kind of the the types that are relative to the stack of an input
stack
+     * Kind of the types that are relative to the stack of an input stack
      * map frame. The value of such types is a position relatively to the
top of
      * this stack.
      */

diff -r 359c604930af
src/java.base/share/classes/sun/security/provider/certpath/ResponderId.java
---
a/src/java.base/share/classes/sun/security/provider/certpath/ResponderId.jav
a	Fri Oct 27 09:51:48 2017 -0700
+++
b/src/java.base/share/classes/sun/security/provider/certpath/ResponderId.jav
a	Sun Oct 29 16:13:11 2017 +0100
@@ -119,7 +119,7 @@
      * When encoded in DER this object will use the byKey option, a
      * SHA-1 hash of the responder's public key.
      *
-     * @param pubKey the the OCSP responder's public key
+     * @param pubKey the OCSP responder's public key
      *
      * @throws IOException if the internal DER-encoding of the
      *      {@code KeyIdentifier} fails.

diff -r 359c604930af
src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuilde
rException.java
---
a/src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuil
derException.java	Fri Oct 27 09:51:48 2017 -0700
+++
b/src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuil
derException.java	Sun Oct 29 16:13:11 2017 +0100
@@ -94,7 +94,7 @@
     }
 
     /**
-     * Creates a <code>SunCertPathBuilderException</code> withe the
specified
+     * Creates a <code>SunCertPathBuilderException</code> with the
specified
      * detail message and adjacency list.
      *
      * @param msg the detail message

diff -r 359c604930af
src/java.base/share/classes/sun/security/ssl/CertStatusReqItemV2.java
--- a/src/java.base/share/classes/sun/security/ssl/CertStatusReqItemV2.java
Fri Oct 27 09:51:48 2017 -0700
+++ b/src/java.base/share/classes/sun/security/ssl/CertStatusReqItemV2.java
Sun Oct 29 16:13:11 2017 +0100
@@ -145,7 +145,7 @@
      * @return the encoded length of this {@code CertStatusReqItemV2}
      */
     int length() {
-        // The length is the the status type (1 byte) + the request length
+        // The length is the status type (1 byte) + the request length
         // field (2 bytes) + the StatusRequest data length.
         return request.length() + 3;
     }

diff -r 359c604930af src/java.base/share/classes/sun/security/ssl/MAC.java
--- a/src/java.base/share/classes/sun/security/ssl/MAC.java	Fri Oct 27
09:51:48 2017 -0700
+++ b/src/java.base/share/classes/sun/security/ssl/MAC.java	Sun Oct 29
16:13:11 2017 +0100
@@ -188,7 +188,7 @@
      * @param type record type
      * @param bb a ByteBuffer in which the position and limit
      *        demarcate the data to be MAC'd.
-     * @param isSimulated if true, simulate the the MAC computation
+     * @param isSimulated if true, simulate the MAC computation
      *
      * @return the MAC result
      */

diff -r 359c604930af
src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java
--- a/src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java
Fri Oct 27 09:51:48 2017 -0700
+++ b/src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java
Sun Oct 29 16:13:11 2017 +0100
@@ -333,7 +333,7 @@
         }
 
         /**
-         * Load the the KeyStore as described in the specified descriptor.
+         * Load the KeyStore as described in the specified descriptor.
          */
         private static KeyStore loadKeyStore(
                 TrustStoreDescriptor descriptor) throws Exception {

diff -r 359c604930af
src/java.base/share/classes/sun/text/normalizer/Trie2.java
--- a/src/java.base/share/classes/sun/text/normalizer/Trie2.java	Fri
Oct 27 09:51:48 2017 -0700
+++ b/src/java.base/share/classes/sun/text/normalizer/Trie2.java	Sun
Oct 29 16:13:11 2017 +0100
@@ -592,7 +592,7 @@
         //   may be lower when iterating over the code points for a single
lead surrogate.
         private int            limitCP;
 
-        // True while iterating over the the Trie2 values for code points.
+        // True while iterating over the Trie2 values for code points.
         // False while iterating over the alternate values for lead
surrogates.
         private boolean        doingCodePoints = true;



From mike.skells1 at gmail.com  Sun Oct 29 22:09:23 2017
From: mike.skells1 at gmail.com (Michael Skells)
Date: Sun, 29 Oct 2017 22:09:23 +0000
Subject: parallel IO anomaly with windows REFS formatted drive
Message-ID: <CADOd3YwavoWmPvQ2ierBpBmc-yqEHBE9Di7rrBEdxMBqECK7UQ@mail.gmail.com>

Hi
It seems to me that some NIO based file creates don't scale work well with
REFS formatted drives
REFS is an alternative (to NTFS) drive format for Windows 8 and above

When working with NTFS on my test system, as we use more threads the
performance improves so some degree, (1000 files creates take 5-600 ms with
one thread and 2-300 ms with 4 threads)
when using REFS the single threaded times are roughly the same for 1 and 2
threads, but get much worse for 3 and 4 threads (1200 - 1600 ms)

this showdown is only when using FileChanel.open and synchronous IO, for
the AsynchronousFileChannel it seems roughly the to scale as expected

CSV attached for the test results, and some test code. The test code is in
scala, and I can convert if needed, but it just really 3 calls, to open
write and close the files

My test system is an I7 4 core window 10 pro with Norton installed, but an
exclusion for the specified drives, and indexing disabled. All writes are
to an M.2 SSD with write-though cache

Some background

I am working on the back end code generation of the scala compiler which
generates many thousand  small .class files, and part of that is to tune
the IO. For windows where the IO cost is significant, so I had a few test
app to simulate and measure the relative performance of the different
alternatives

Any ideas for a bulk file creation alternative welcome. I know we could
write to a JAR but that requires other re-tooling

Regards
Mike

From roger.riggs at oracle.com  Sun Oct 29 22:25:09 2017
From: roger.riggs at oracle.com (Roger Riggs)
Date: Sun, 29 Oct 2017 18:25:09 -0400
Subject: [Bug][JDK10] Fix duplicated "the" occurrences in docs and inline
 comments
In-Reply-To: <006b01d350ca$0d0602f0$271208d0$@freenet.de>
References: <006b01d350ca$0d0602f0$271208d0$@freenet.de>
Message-ID: <5c234686-2c1e-818c-7e28-64b1406b8637@oracle.com>

Hi Christoph,

I'll sponsor it.? [1]
BTW, email wrapped some of the lines in the patch; I'll fix it up.

Thanks, Roger

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


On 10/29/17 11:24 AM, Christoph Dreis wrote:
> Hey,
>
> Just noticed an occurrence of a duplicated "the" in a Locale doc and looked
> for other occurrences in java.base while being on it.
>
> I don't know if documentation changes follow a special workflow because of
> possible translations. Please let me know!
>
> But I'd be happy if this is sponsored or moved to the appropriate mailing
> list.
>
> Cheers,
> Christoph
>
>
> ===== PATCH ======
> diff -r 359c604930af src/java.base/share/classes/java/lang/WeakPairMap.java
> --- a/src/java.base/share/classes/java/lang/WeakPairMap.java	Fri Oct 27
> 09:51:48 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/WeakPairMap.java	Sun Oct 29
> 16:13:11 2017 +0100
> @@ -88,7 +88,7 @@
>        * Maps the specified key pair to the specified value in this
> WeakPairMap.
>        * Neither the keys nor the value can be null.
>        * <p>The value can be retrieved by calling the {@link #get} method
> -     * with the the same keys (compared by identity).
> +     * with the same keys (compared by identity).
>        *
>        * @param k1 the 1st of the pair of keys with which the specified value
> is to
>        *           be associated
>
> diff -r 359c604930af
> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
> Fri Oct 27 09:51:48 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
> Sun Oct 29 16:13:11 2017 +0100
> @@ -1196,7 +1196,7 @@
>   
>           static
>           MethodHandle bindCaller(MethodHandle mh, Class<?> hostClass) {
> -            // Code in the the boot layer should now be careful while
> creating method handles or
> +            // Code in the boot layer should now be careful while creating
> method handles or
>               // functional interface instances created from method
> references to @CallerSensitive  methods,
>               // it needs to be ensured the handles or interface instances
> are kept safe and are not passed
>               // from the boot layer to untrusted code.
>
> diff -r 359c604930af
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
> --- a/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
> Fri Oct 27 09:51:48 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
> Sun Oct 29 16:13:11 2017 +0100
> @@ -195,7 +195,7 @@
>           // In case we need to double-back onto the StringConcatFactory
> during this
>           // static initialization, make sure we have the reasonable defaults
> to complete
>           // the static initialization properly. After that, actual users
> would use the
> -        // the proper values we have read from the the properties.
> +        // the proper values we have read from the properties.
>           STRATEGY = DEFAULT_STRATEGY;
>           // CACHE_ENABLE = false; // implied
>           // CACHE = null;         // implied
>
> diff -r 359c604930af src/java.base/share/classes/java/util/Locale.java
> --- a/src/java.base/share/classes/java/util/Locale.java	Fri Oct 27 09:51:48
> 2017 -0700
> +++ b/src/java.base/share/classes/java/util/Locale.java	Sun Oct 29 16:13:11
> 2017 +0100
> @@ -1909,7 +1909,7 @@
>        * Returns a name for the locale that is appropriate for display to the
>        * user. This will be the values returned by getDisplayLanguage(),
>        * getDisplayScript(), getDisplayCountry(), and getDisplayVariant()
> assembled
> -     * into a single string. The the non-empty values are used in order,
> +     * into a single string. The non-empty values are used in order,
>        * with the second and subsequent names in parentheses.  For example:
>        * <blockquote>
>        * language (script, country, variant)<br>
>
> diff -r 359c604930af
> src/java.base/share/classes/java/util/ServiceLoader.java
> --- a/src/java.base/share/classes/java/util/ServiceLoader.java	Fri Oct 27
> 09:51:48 2017 -0700
> +++ b/src/java.base/share/classes/java/util/ServiceLoader.java	Sun Oct 29
> 16:13:11 2017 +0100
> @@ -1409,7 +1409,7 @@
>        *
>        * <p> To achieve laziness the actual work of locating providers is
> done
>        * when processing the stream. If a service provider cannot be loaded
> for any
> -     * of the the reasons specified in the <a href="#errors">Errors</a>
> section
> +     * of the reasons specified in the <a href="#errors">Errors</a> section
>        * above then {@link ServiceConfigurationError} is thrown by whatever
> method
>        * caused the service provider to be loaded. </p>
>        *
>
> diff -r 359c604930af
> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
> --- a/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
> Fri Oct 27 09:51:48 2017 -0700
> +++ b/src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java
> Sun Oct 29 16:13:11 2017 +0100
> @@ -66,7 +66,7 @@
>    * -m and --add-modules options. The modules are located on a module path
> that
>    * is constructed from the upgrade module path, system modules, and
> application
>    * module path. The Configuration is instantiated as the boot layer with
> each
> - * module in the the configuration defined to a class loader.
> + * module in the configuration defined to a class loader.
>    */
>   
>   public final class ModuleBootstrap {
>
> diff -r 359c604930af
> src/java.base/share/classes/jdk/internal/module/ModuleHashesBuilder.java
> ---
> a/src/java.base/share/classes/jdk/internal/module/ModuleHashesBuilder.java
> Fri Oct 27 09:51:48 2017 -0700
> +++
> b/src/java.base/share/classes/jdk/internal/module/ModuleHashesBuilder.java
> Sun Oct 29 16:13:11 2017 +0100
> @@ -74,7 +74,7 @@
>        * the outgoing edges from M to non-candidate modules.
>        */
>       public Map<String, ModuleHashes> computeHashes(Set<String> roots) {
> -        // build a graph containing the the packaged modules and
> +        // build a graph containing the packaged modules and
>           // its transitive dependences matching --hash-modules
>           Graph.Builder<String> builder = new Graph.Builder<>();
>           Deque<ResolvedModule> deque = new
> ArrayDeque<>(configuration.modules());
>
> diff -r 359c604930af
> src/java.base/share/classes/jdk/internal/module/Resources.java
> --- a/src/java.base/share/classes/jdk/internal/module/Resources.java	Fri
> Oct 27 09:51:48 2017 -0700
> +++ b/src/java.base/share/classes/jdk/internal/module/Resources.java	Sun
> Oct 29 16:13:11 2017 +0100
> @@ -56,7 +56,7 @@
>       /**
>        * Derive a <em>package name</em> for a resource. The package name
>        * returned by this method may not be a legal package name. This method
> -     * returns null if the the resource name ends with a "/" (a directory)
> +     * returns null if the resource name ends with a "/" (a directory)
>        * or the resource name does not contain a "/".
>        */
>       public static String toPackageName(String name) {
>
> diff -r 359c604930af
> src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java
> --- a/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java
> Fri Oct 27 09:51:48 2017 -0700
> +++ b/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java
> Sun Oct 29 16:13:11 2017 +0100
> @@ -192,7 +192,7 @@
>       private static final int LOCAL = 0x2000000;
>   
>       /**
> -     * Kind of the the types that are relative to the stack of an input
> stack
> +     * Kind of the types that are relative to the stack of an input stack
>        * map frame. The value of such types is a position relatively to the
> top of
>        * this stack.
>        */
>
> diff -r 359c604930af
> src/java.base/share/classes/sun/security/provider/certpath/ResponderId.java
> ---
> a/src/java.base/share/classes/sun/security/provider/certpath/ResponderId.jav
> a	Fri Oct 27 09:51:48 2017 -0700
> +++
> b/src/java.base/share/classes/sun/security/provider/certpath/ResponderId.jav
> a	Sun Oct 29 16:13:11 2017 +0100
> @@ -119,7 +119,7 @@
>        * When encoded in DER this object will use the byKey option, a
>        * SHA-1 hash of the responder's public key.
>        *
> -     * @param pubKey the the OCSP responder's public key
> +     * @param pubKey the OCSP responder's public key
>        *
>        * @throws IOException if the internal DER-encoding of the
>        *      {@code KeyIdentifier} fails.
>
> diff -r 359c604930af
> src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuilde
> rException.java
> ---
> a/src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuil
> derException.java	Fri Oct 27 09:51:48 2017 -0700
> +++
> b/src/java.base/share/classes/sun/security/provider/certpath/SunCertPathBuil
> derException.java	Sun Oct 29 16:13:11 2017 +0100
> @@ -94,7 +94,7 @@
>       }
>   
>       /**
> -     * Creates a <code>SunCertPathBuilderException</code> withe the
> specified
> +     * Creates a <code>SunCertPathBuilderException</code> with the
> specified
>        * detail message and adjacency list.
>        *
>        * @param msg the detail message
>
> diff -r 359c604930af
> src/java.base/share/classes/sun/security/ssl/CertStatusReqItemV2.java
> --- a/src/java.base/share/classes/sun/security/ssl/CertStatusReqItemV2.java
> Fri Oct 27 09:51:48 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/ssl/CertStatusReqItemV2.java
> Sun Oct 29 16:13:11 2017 +0100
> @@ -145,7 +145,7 @@
>        * @return the encoded length of this {@code CertStatusReqItemV2}
>        */
>       int length() {
> -        // The length is the the status type (1 byte) + the request length
> +        // The length is the status type (1 byte) + the request length
>           // field (2 bytes) + the StatusRequest data length.
>           return request.length() + 3;
>       }
>
> diff -r 359c604930af src/java.base/share/classes/sun/security/ssl/MAC.java
> --- a/src/java.base/share/classes/sun/security/ssl/MAC.java	Fri Oct 27
> 09:51:48 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/ssl/MAC.java	Sun Oct 29
> 16:13:11 2017 +0100
> @@ -188,7 +188,7 @@
>        * @param type record type
>        * @param bb a ByteBuffer in which the position and limit
>        *        demarcate the data to be MAC'd.
> -     * @param isSimulated if true, simulate the the MAC computation
> +     * @param isSimulated if true, simulate the MAC computation
>        *
>        * @return the MAC result
>        */
>
> diff -r 359c604930af
> src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java
> --- a/src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java
> Fri Oct 27 09:51:48 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java
> Sun Oct 29 16:13:11 2017 +0100
> @@ -333,7 +333,7 @@
>           }
>   
>           /**
> -         * Load the the KeyStore as described in the specified descriptor.
> +         * Load the KeyStore as described in the specified descriptor.
>            */
>           private static KeyStore loadKeyStore(
>                   TrustStoreDescriptor descriptor) throws Exception {
>
> diff -r 359c604930af
> src/java.base/share/classes/sun/text/normalizer/Trie2.java
> --- a/src/java.base/share/classes/sun/text/normalizer/Trie2.java	Fri
> Oct 27 09:51:48 2017 -0700
> +++ b/src/java.base/share/classes/sun/text/normalizer/Trie2.java	Sun
> Oct 29 16:13:11 2017 +0100
> @@ -592,7 +592,7 @@
>           //   may be lower when iterating over the code points for a single
> lead surrogate.
>           private int            limitCP;
>   
> -        // True while iterating over the the Trie2 values for code points.
> +        // True while iterating over the Trie2 values for code points.
>           // False while iterating over the alternate values for lead
> surrogates.
>           private boolean        doingCodePoints = true;
>
>


From roger.riggs at oracle.com  Mon Oct 30 00:24:51 2017
From: roger.riggs at oracle.com (Roger Riggs)
Date: Sun, 29 Oct 2017 20:24:51 -0400
Subject: ThreadPoolExecutor and finalization
Message-ID: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>

Hi,

With the deprecation of Object.finalize its time to look at its uses too 
see if
they can be removed or mitigated.

The ThreadPoolExecutor overrides finalize to shutdown the pool.
A simple but incomplete step is to retain the shutdown on finalize but 
remove it from
the specification of ThreadPoolExecutor.finalize (and remove the 
override).? [1]

For those familiar with Executors please take as look at the situation and
make a recommendation or suggestion.

Thanks, Roger

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





From ecki at zusammenkunft.net  Mon Oct 30 00:34:48 2017
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Mon, 30 Oct 2017 00:34:48 +0000
Subject: parallel IO anomaly with windows REFS formatted drive
In-Reply-To: <CADOd3YwavoWmPvQ2ierBpBmc-yqEHBE9Di7rrBEdxMBqECK7UQ@mail.gmail.com>
References: <CADOd3YwavoWmPvQ2ierBpBmc-yqEHBE9Di7rrBEdxMBqECK7UQ@mail.gmail.com>
Message-ID: <AM4PR08MB1219607A0D20291CD1BF6F7EFF590@AM4PR08MB1219.eurprd08.prod.outlook.com>

Just a FYI, I would not worry too much about this, Microsoft removed the ability to create ReFS volumes in Win 10 1710 as they seem to only want to support it with Servers and the new Workstation SKUs. Wouldn't it be enough to put a warning into the release notes?

However it is again and again interesting to see just how problematic the NIO2 implementations in some areas are...

Gruss
Bernd

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Michael Skells <mike.skells1 at gmail.com>
Sent: Sunday, October 29, 2017 11:09:23 PM
To: core-libs-dev at openjdk.java.net
Subject: parallel IO anomaly with windows REFS formatted drive

Hi
It seems to me that some NIO based file creates don't scale work well with
REFS formatted drives
REFS is an alternative (to NTFS) drive format for Windows 8 and above

When working with NTFS on my test system, as we use more threads the
performance improves so some degree, (1000 files creates take 5-600 ms with
one thread and 2-300 ms with 4 threads)
when using REFS the single threaded times are roughly the same for 1 and 2
threads, but get much worse for 3 and 4 threads (1200 - 1600 ms)

this showdown is only when using FileChanel.open and synchronous IO, for
the AsynchronousFileChannel it seems roughly the to scale as expected

CSV attached for the test results, and some test code. The test code is in
scala, and I can convert if needed, but it just really 3 calls, to open
write and close the files

My test system is an I7 4 core window 10 pro with Norton installed, but an
exclusion for the specified drives, and indexing disabled. All writes are
to an M.2 SSD with write-though cache

Some background

I am working on the back end code generation of the scala compiler which
generates many thousand  small .class files, and part of that is to tune
the IO. For windows where the IO cost is significant, so I had a few test
app to simulate and measure the relative performance of the different
alternatives

Any ideas for a bulk file creation alternative welcome. I know we could
write to a JAR but that requires other re-tooling

Regards
Mike

From david.holmes at oracle.com  Mon Oct 30 00:40:00 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Oct 2017 10:40:00 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
Message-ID: <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>

Hi Roger,

On 30/10/2017 10:24 AM, Roger Riggs wrote:
> Hi,
> 
> With the deprecation of Object.finalize its time to look at its uses too 
> see if they can be removed or mitigated.

So the nice thing about finalize was that it followed a 
nice/clean/simple OO model where a subclass could override, add their 
own cleanup and then call super.finalize(). With finalize() deprecated, 
and the new mechanism being Cleaners, how do Cleaners support such usages?

Thanks,
David

> 
> The ThreadPoolExecutor overrides finalize to shutdown the pool.
> A simple but incomplete step is to retain the shutdown on finalize but 
> remove it from
> the specification of ThreadPoolExecutor.finalize (and remove the 
> override).? [1]
> 
> For those familiar with Executors please take as look at the situation and
> make a recommendation or suggestion.
> 
> Thanks, Roger
> 
> [1]? https://bugs.openjdk.java.net/browse/JDK-8190324
> 
> 
> 
> 

From andrej.golovnin at gmail.com  Mon Oct 30 07:02:44 2017
From: andrej.golovnin at gmail.com (Andrej Golovnin)
Date: Mon, 30 Oct 2017 08:02:44 +0100
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
Message-ID: <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>

Hi David,

> On 30. Oct 2017, at 01:40, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Roger,
> 
> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>> Hi,
>> With the deprecation of Object.finalize its time to look at its uses too see if they can be removed or mitigated.
> 
> So the nice thing about finalize was that it followed a nice/clean/simple OO model where a subclass could override, add their own cleanup and then call super.finalize(). With finalize() deprecated, and the new mechanism being Cleaners, how do Cleaners support such usages?

Instead of ThreadPoolExecutor.finalize you can override ThreadPoolExecutor.terminated.

Best regards
Andrej Golovnin

From david.holmes at oracle.com  Mon Oct 30 07:31:53 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Oct 2017 17:31:53 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
Message-ID: <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>

Hi Andrej,

On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
> Hi David,
> 
>> On 30. Oct 2017, at 01:40, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Roger,
>>
>> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>>> Hi,
>>> With the deprecation of Object.finalize its time to look at its uses too see if they can be removed or mitigated.
>>
>> So the nice thing about finalize was that it followed a nice/clean/simple OO model where a subclass could override, add their own cleanup and then call super.finalize(). With finalize() deprecated, and the new mechanism being Cleaners, how do Cleaners support such usages?
> 
> Instead of ThreadPoolExecutor.finalize you can override ThreadPoolExecutor.terminated.

True. Though overriding shutdown() would be the semantic equivalent of 
overriding finalize(). :)

In the general case though finalize() might be invoking a final method.

Anyway I'm not sure we can actually do something to try to move away 
from use of finalize() in TPE. finalize() is only deprecated - it is 
still expected to work as it has always done. Existing subclasses that 
override finalize() must continue to work until some point where we say 
finalize() is not only deprecated but obsoleted (it no longer does 
anything). So until then is there actually any point in doing anything? 
Does having a Cleaner and a finalize() method make sense? Does it aid in 
the transition?

Cheers,
David

> Best regards
> Andrej Golovnin
> 

From christoph.dreis at freenet.de  Mon Oct 30 07:50:33 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Mon, 30 Oct 2017 08:50:33 +0100
Subject: [Bug][JDK10] Fix duplicated "the" occurrences in docs and inline
 comments
In-Reply-To: <5c234686-2c1e-818c-7e28-64b1406b8637@oracle.com>
References: <006b01d350ca$0d0602f0$271208d0$@freenet.de>
 <5c234686-2c1e-818c-7e28-64b1406b8637@oracle.com>
Message-ID: <007201d35153$c546c000$4fd44000$@freenet.de>

Hi Roger,

> I'll sponsor it.  [1]

Thank you! 

> BTW, email wrapped some of the lines in the patch; I'll fix it up.
Again - thanks. I'll need to get webrev to run for this somewhat "larger" patches. Is it okay to have this running on private domains? I know that some people don't like to open unknown links because of security concerns.

Cheers,
Christoph


From peter.levart at gmail.com  Mon Oct 30 10:21:05 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 30 Oct 2017 11:21:05 +0100
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <59F4D419.8070201@oracle.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
Message-ID: <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>

Hi Sherman,

On 10/28/2017 09:01 PM, Xueming Shen wrote:
> On 10/28/17, 10:47 AM, Peter Levart wrote:
>> Hi Florian,
>>
>> On 10/28/17 16:16, Florian Weimer wrote:
>>> * Xueming Shen:
>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8187485
>>>> http://cr.openjdk.java.net/~sherman/8185582/webrev
>>> In ZipFile:
>>>
>>> 387                 Inflater inf = getInflater();
>>> 388                 InputStream is = new ZipFileInflaterInputStream(in, inf, (int)size,
>>> 389                                          () -> releaseInflater(inf));
>>> 390                 synchronized (streams) {
>>> 391                     streams.add(is);
>>> 392                 }
>>>
>>> Doesn't this leak the inflater if Cleaner.register() and thus the
>>> ZipFileInflaterInputStream constructor throw?
>>
>>
>
> There is reason why those are VirutalMachineError erros. It appears in 
> this situation the vm
> is in a more critical status than a inflater is getting leaked out. I 
> would assume you only catch
> these errors if/when the consequence of not catching is more severe 
> and the "thing" you are
> going to do in catch is not going to trigger more errors. Sure we do 
> that here and there in
> the libraries code for various reasons, but wonder if here is the 
> place that is worth doing that.
> That said, if this is a real concern, instead of catching all the 
> possible vm erros here and there
> to make Cleaner work correctly, a better alternative might be to go 
> back to the previous version
> to leave the zipfile/deflater cleaner configured/registerd (give up 
> the special constructor idea),
> so the deflater can get cleaned by itself in case all upstream clean 
> up mechanism failed and
> the Cleaner mechanism somehow still functions. Opinion?
>
> -Sherman
>

I wouldn't go so far as to try to deal with potential 
StackOverflowError(s), but for OOMEs, I have the following opinion:

- going back to previous version (give up the special constructor idea) 
might not, as you say, be any better. If you just look at the public 
Inflater constructor:

 ?121???? public Inflater(boolean nowrap) {
 ?122???????? ZStreamRef ref = new ZStreamRef(init(nowrap), Inflater::end);
 ?123???????? this.zsRef = ref;
 ?124???????? this.cleanable = CleanerFactory.cleaner().register(this, 
ref);
 ?125???? }

...OOME can be thrown after init() and before successful Cleaner 
registration in multiple places:

- method reference construction
- ZStreamRef object allocation
- Cleaner.register()

and the probability of that occurring when there is heap exhaustion is 
not any smaller.

So I'm more inclined to try to make such code more robust. There will 
always be places in such code where some native resource is 1st 
allocated, then some logic is executed which allocates objects and 
finally Cleaner.register() is attempted. By carefully programming those 
steps, a potential native resource leak in case of heap exhaustion can 
be prevented. There will usually be a way to back-out (i.e. free the 
native resource just allocated) without provoking further trouble. In 
the above example, it would be possible to do this:

 ???? public Inflater(boolean nowrap) {
 ??????? long address = init(nowrap);
 ??????? try {
 ??????????? ZStreamRef ref = new ZStreamRef(address, Inflater::end);
 ??????????? this.zsRef = ref;
 ??????????? this.cleanable = CleanerFactory.cleaner().register(this, ref);
 ??????? } catch (OutOfMemoryError oome) {
 ??????????? end(address);
 ??????????? throw oome;
 ??????? }
 ??? }

An alternative would be to perform all steps that allocate objects 
upfront and then, as the final action, allocate the native resource and 
"inject" it into the final place:

 ??? public Inflater(boolean nowrap) {
 ??????? ZStreamRef ref = new ZStreamRef(Inflater::end);
 ??????? this.zsRef = ref;
 ??????? this.cleanable = CleanerFactory.cleaner().register(this, ref);
 ??????? ref.initAddress(init(nowrap));
 ??? }


Concerning ZipFile, I would make releaseInflater() more robust, because 
it is easy:

 ?private void releaseInflater(Inflater inf) {
 ?? inf.reset();
 ?? try {
 ?????? synchronized (inflaterCache) {
 ?????????? inflaterCache.add(inf);
 ?????? }
 ?? } catch (OutOfMemoryError e) {
 ??? ?? // Inflater.end() does no allocation
 ?????? inf.end();
 ?????? throw e;
 ?? }
}

For lines 387 ... 392, I would simply do this:

Inflater inf = getInflater();
InputStream is;

try {
 ??? is = new ZipFileInflaterInputStream(in, inf, (int)size, () -> 
releaseInflater(inf));
} catch (OutOfMemoryError e) {
 ??? // calling releaseInflater() is not sensible here, because it 
allocates and will
 ??? // probably result in Inflater.end() anyway...
 ??? inf.end();
 ??? throw e;
}

try {
 ??? synchronized (streams) {
 ??????? streams.add(is);
 ??? }
} catch (OutOfMemoryError e) {
 ??? // ZipFileInflaterInputStream.close() does not allocate, 
IOException is never thrown
 ??? try { is.close(); } catch (IOException ignore) {}
 ??? throw e;
}


Simply saying that "vm is in a more critical status than a inflater is 
getting leaked out" is, in my opinion, covering the problem under the 
rug. The VM is not in critical state - the program is. VM is robust 
enough to recover from OOMEs. The program might be in critical status 
(i.e. in inconsistent state) partly because of not accounting for such 
OOME situations. By taking care of them, the program has a better chance 
of recovering from such situation(s).

Handling native resources is one place where I think it is beneficial to 
complicate things in order to make native resource leaks (im/less 
)possible. The other such place is synchronization primitives. We must 
admit that finalization does have this benefit that it makes it hard to 
construct code that would allocate the native resource before cleanup 
registration (which is performed as part of Object.<init>, while logic 
to allocate native resource is usually invoked from subclass 
constructor). To achieve the same robustness with Cleaner API, one has 
to be careful to either perform registration upfront and then allocate 
native resource or arrange for back-out in case of trouble.

Regards, Peter


From roger.riggs at oracle.com  Mon Oct 30 13:26:30 2017
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 30 Oct 2017 09:26:30 -0400
Subject: [Bug][JDK10] Fix duplicated "the" occurrences in docs and inline
 comments
In-Reply-To: <007201d35153$c546c000$4fd44000$@freenet.de>
References: <006b01d350ca$0d0602f0$271208d0$@freenet.de>
 <5c234686-2c1e-818c-7e28-64b1406b8637@oracle.com>
 <007201d35153$c546c000$4fd44000$@freenet.de>
Message-ID: <e75572ad-d750-eb37-40ca-578376224bef@oracle.com>

Hi Christoph,

The core-libs-dev email should allow patches as attachments 
(specifically normal text with a .patch extension).
I'm not sure on the precise filter rules but give that a try.
For webrev's they would need to be on cr.openjdk.java.net; so until you 
have author status
someone will need to sponsor them.

Roger


On 10/30/17 3:50 AM, Christoph Dreis wrote:
> Hi Roger,
>
>> I'll sponsor it.  [1]
> Thank you!
>
>> BTW, email wrapped some of the lines in the patch; I'll fix it up.
> Again - thanks. I'll need to get webrev to run for this somewhat "larger" patches. Is it okay to have this running on private domains? I know that some people don't like to open unknown links because of security concerns.
>
> Cheers,
> Christoph
>


From Roger.Riggs at Oracle.com  Mon Oct 30 14:43:27 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 30 Oct 2017 10:43:27 -0400
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
Message-ID: <81a7c918-239b-c205-a946-672e894576be@Oracle.com>

Hi David,

On 10/30/2017 3:31 AM, David Holmes wrote:
> Hi Andrej,
>
> On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
>> Hi David,
>>
>>> On 30. Oct 2017, at 01:40, David Holmes <david.holmes at oracle.com> 
>>> wrote:
>>>
>>> Hi Roger,
>>>
>>> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>>>> Hi,
>>>> With the deprecation of Object.finalize its time to look at its 
>>>> uses too see if they can be removed or mitigated.
>>>
>>> So the nice thing about finalize was that it followed a 
>>> nice/clean/simple OO model where a subclass could override, add 
>>> their own cleanup and then call super.finalize(). With finalize() 
>>> deprecated, and the new mechanism being Cleaners, how do Cleaners 
>>> support such usages?
>>
>> Instead of ThreadPoolExecutor.finalize you can override 
>> ThreadPoolExecutor.terminated.
>
> True. Though overriding shutdown() would be the semantic equivalent of 
> overriding finalize(). :)
>
> In the general case though finalize() might be invoking a final method.
>
> Anyway I'm not sure we can actually do something to try to move away 
> from use of finalize() in TPE. finalize() is only deprecated - it is 
> still expected to work as it has always done. Existing subclasses that 
> override finalize() must continue to work until some point where we 
> say finalize() is not only deprecated but obsoleted (it no longer does 
> anything). So until then is there actually any point in doing 
> anything? Does having a Cleaner and a finalize() method make sense? 
> Does it aid in the transition?
As you observe, the alternatives directly using PhantomRefs or the 
Cleanup do not provide
as nice a model.? Unfortunately, that model has been recognized to have 
a number of
issues [1].? Finalization is a poor substitute for explicit shutdown, it 
is unpredictable and unreliable,
and not guaranteed to be executed.

ThreadPoolExecutor has a responsibility to cleanup any native resources 
it has allocated (threads)
and it should be free to use whatever mechanism is appropriate. 
Currently, the spec for finalize
does not give it that freedom.

The initiative is to identify and remediate existing uses of 
finalization in the JDK.
The primary concern is about subclasses that reply on the current spec.
If I'm using grepcode correctly[2], it does not show any subclasses of 
ThreadPoolExecutor that
override finalize; so it may be a non-issue.

Regards, Roger

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

[2] 
http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root at jdk%24openjdk at 8u40-b25@java%24util%24concurrent at ThreadPoolExecutor@finalize%28%29&k=d


From david.lloyd at redhat.com  Mon Oct 30 15:02:59 2017
From: david.lloyd at redhat.com (David Lloyd)
Date: Mon, 30 Oct 2017 10:02:59 -0500
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
Message-ID: <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>

On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> ThreadPoolExecutor has a responsibility to cleanup any native resources it
> has allocated (threads) and it should be free to use whatever mechanism is appropriate.

I wonder though whether TPE.finalize() is ever actually hit in
practice: TPE is (by definition) a thread pool, and every live thread
in that pool has (by way of TPE.Worker) a strong reference to the TPE
itself via an outer class reference which is passed around in enough
places to make me think that it would never actually be collectable in
a real-world situation, unless all core threads were allowed to time
out.

-- 
- DML

From Roger.Riggs at Oracle.com  Mon Oct 30 15:27:36 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 30 Oct 2017 11:27:36 -0400
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
Message-ID: <bfd6c977-df4d-53ba-a59c-8e2a6c04f2eb@Oracle.com>

Hi,

There is a test 
<repo>/test/jdk/java/util/concurrent/Executors/AutoShutdown.java

It only tests it for Executors of newSingleThreadExecutor, not for the 
others
so I wondered if there was some open issue.

Roger


On 10/30/2017 11:02 AM, David Lloyd wrote:
> On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> ThreadPoolExecutor has a responsibility to cleanup any native resources it
>> has allocated (threads) and it should be free to use whatever mechanism is appropriate.
> I wonder though whether TPE.finalize() is ever actually hit in
> practice: TPE is (by definition) a thread pool, and every live thread
> in that pool has (by way of TPE.Worker) a strong reference to the TPE
> itself via an outer class reference which is passed around in enough
> places to make me think that it would never actually be collectable in
> a real-world situation, unless all core threads were allowed to time
> out.
>


From christoph.dreis at freenet.de  Mon Oct 30 15:58:43 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Mon, 30 Oct 2017 16:58:43 +0100
Subject: [Bug][JDK10] Fix duplicated "a" occurrences in docs
Message-ID: <007701d35197$f6440200$e2cc0600$@freenet.de>

Hey,

similar to JDK-8190323 the attached patch removes duplicated "a" occurrences
in java.base docs. 

Would be happy if this is sponsored.

I wasn't sure about the capitalization change on EventObject. What's the
rule of thumb in cases where the class does not follow the guidelines for
docs[1]? Sticking to the overall class scheme or aligning everything?

Cheers,
Christoph
[1] http://www.oracle.com/technetwork/articles/java/index-137868.html


From christoph.dreis at freenet.de  Mon Oct 30 16:05:53 2017
From: christoph.dreis at freenet.de (Christoph Dreis)
Date: Mon, 30 Oct 2017 17:05:53 +0100
Subject: [Bug][JDK10] Fix duplicated "a" occurrences in docs
In-Reply-To: <007701d35197$f6440200$e2cc0600$@freenet.de>
References: <007701d35197$f6440200$e2cc0600$@freenet.de>
Message-ID: <007d01d35198$f6ae1900$e40a4b00$@freenet.de>

The attached patched seems to have been dropped.

Sorry for any inconveniences.

===== PATCH ======
diff -r d87f89c74f54
src/java.base/share/classes/java/lang/invoke/VarHandle.java
--- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java	Mon
Oct 30 07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java	Mon
Oct 30 16:47:56 2017 +0100
@@ -423,7 +423,7 @@
  * {@link java.lang.invoke.MethodHandles#varHandleInvoker}.
  *
  * <h1>Interoperation between VarHandles and Java generics</h1>
- * A VarHandle can be obtained for a variable, such as a a field, which is
+ * A VarHandle can be obtained for a variable, such as a field, which is
  * declared with Java generic types.  As with the Core Reflection API, the
  * VarHandle's variable type will be constructed from the erasure of the
  * source-level type.  When a VarHandle access mode method is invoked, the

diff -r d87f89c74f54 src/java.base/share/classes/java/util/EventObject.java
--- a/src/java.base/share/classes/java/util/EventObject.java	Mon Oct 30
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/util/EventObject.java	Mon Oct 30
16:47:56 2017 +0100
@@ -70,7 +70,7 @@
     /**
      * Returns a String representation of this EventObject.
      *
-     * @return  A a String representation of this EventObject.
+     * @return a String representation of this EventObject.
      */
     public String toString() {
         return getClass().getName() + "[source=" + source + "]";

diff -r d87f89c74f54
src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/Parameter
izedTypeImpl.java
---
a/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/Paramet
erizedTypeImpl.java	Mon Oct 30 07:06:49 2017 -0700
+++
b/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/Paramet
erizedTypeImpl.java	Mon Oct 30 16:47:56 2017 +0100
@@ -66,7 +66,7 @@
     /**
      * Static factory. Given a (generic) class, actual type arguments
      * and an owner type, creates a parameterized type.
-     * This class can be instantiated with a a raw type that does not
+     * This class can be instantiated with a raw type that does not
      * represent a generic type, provided the list of actual type
      * arguments is empty.
      * If the ownerType argument is null, the declaring class of the


> Hey,
> 
> similar to JDK-8190323 the attached patch removes duplicated "a"
> occurrences in java.base docs.
> 
> Would be happy if this is sponsored.
> 
> I wasn't sure about the capitalization change on EventObject. What's the
rule
> of thumb in cases where the class does not follow the guidelines for
docs[1]?
> Sticking to the overall class scheme or aligning everything?
> 
> Cheers,
> Christoph
> [1] http://www.oracle.com/technetwork/articles/java/index-137868.html




From huizhe.wang at oracle.com  Mon Oct 30 17:03:36 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 30 Oct 2017 10:03:36 -0700
Subject: RFR (JDK10/JAXP) 8181155: Fix lint warnings in JAXP repo: fallthrough
 and static
Message-ID: <59F75B68.60803@oracle.com>

Hi,

Please review a cleanup of fallthrough and static warnings. For 
fallthrough, the majority of the changes are suppressing the warnings, 
while for static, replacing the instances with the class.

All jaxp tests and JCK passed.

JBS: https://bugs.openjdk.java.net/browse/JDK-8181155
webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181155/webrev/index.html

Thanks,
Joe

From lance.andersen at oracle.com  Mon Oct 30 17:09:27 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 30 Oct 2017 13:09:27 -0400
Subject: RFR (JDK10/JAXP) 8181155: Fix lint warnings in JAXP repo:
 fallthrough and static
In-Reply-To: <59F75B68.60803@oracle.com>
References: <59F75B68.60803@oracle.com>
Message-ID: <79517200-E8E7-42CF-A57A-903CC8F09919@oracle.com>

Hi Joe

The changes look OK

Best
Lance
> On Oct 30, 2017, at 1:03 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
> 
> Hi,
> 
> Please review a cleanup of fallthrough and static warnings. For fallthrough, the majority of the changes are suppressing the warnings, while for static, replacing the instances with the class.
> 
> All jaxp tests and JCK passed.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8181155
> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181155/webrev/index.html
> 
> 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 martinrb at google.com  Mon Oct 30 17:21:45 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 30 Oct 2017 10:21:45 -0700
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <bfd6c977-df4d-53ba-a59c-8e2a6c04f2eb@Oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
 <bfd6c977-df4d-53ba-a59c-8e2a6c04f2eb@Oracle.com>
Message-ID: <CA+kOe08vE5hXJRot0t8p==VnsY6DEaD0ipqcrMYPkhMOW=rzDg@mail.gmail.com>

On Mon, Oct 30, 2017 at 8:27 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi,
>
> There is a test <repo>/test/jdk/java/util/conc
> urrent/Executors/AutoShutdown.java
>
> It only tests it for Executors of newSingleThreadExecutor, not for the
> others
> so I wondered if there was some open issue.
>

I wrote that test long ago.  But I've always been confused about automatic
thread pool shutdown; it's not very reliable, especially given that all the
threads need to terminate.  Should TPE's finalization spec apply to STPE?

TPE is a brittle class; we avoid doing too much surgery on it (even though
we're in the middle of doing exactly that to fix an actual bug).

> The initiative is to identify and remediate existing uses of finalization
in the JDK.

I've been skeptical about this initiative as stated.  I would not have
deprecated finalize(). We will never remove finalize() from the JDK, and I
don't see how switching TPE from finalize to some other mechanism such as
Cleaner has real benefits for users.  There aren't enough instances of TPE
created for finalization to be a real user performance problem.

TPE's spec currently has a finalize deprecation warning, but this is not
helpful for users.
(a documentation readability regression!)
https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/ThreadPoolExecutor.html#finalize--

From huizhe.wang at oracle.com  Mon Oct 30 17:25:40 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 30 Oct 2017 10:25:40 -0700
Subject: RFR (JDK10/JAXP) 8181155: Fix lint warnings in JAXP repo:
 fallthrough and static
In-Reply-To: <79517200-E8E7-42CF-A57A-903CC8F09919@oracle.com>
References: <59F75B68.60803@oracle.com>
 <79517200-E8E7-42CF-A57A-903CC8F09919@oracle.com>
Message-ID: <59F76094.3000302@oracle.com>

Thanks Lance!

Best,
Joe

On 10/30/17, 10:09 AM, Lance Andersen wrote:
> Hi Joe
>
> The changes look OK
>
> Best
> Lance
>> On Oct 30, 2017, at 1:03 PM, Joe Wang <huizhe.wang at oracle.com 
>> <mailto:huizhe.wang at oracle.com>> wrote:
>>
>> Hi,
>>
>> Please review a cleanup of fallthrough and static warnings. For 
>> fallthrough, the majority of the changes are suppressing the 
>> warnings, while for static, replacing the instances with the class.
>>
>> All jaxp tests and JCK passed.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181155
>> webrevs: 
>> http://cr.openjdk.java.net/~joehw/jdk10/8181155/webrev/index.html 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk10/8181155/webrev/index.html>
>>
>> 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 Roger.Riggs at Oracle.com  Mon Oct 30 18:14:01 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 30 Oct 2017 14:14:01 -0400
Subject: RFR (JDK10/JAXP) 8181155: Fix lint warnings in JAXP repo:
 fallthrough and static
In-Reply-To: <79517200-E8E7-42CF-A57A-903CC8F09919@oracle.com>
References: <59F75B68.60803@oracle.com>
 <79517200-E8E7-42CF-A57A-903CC8F09919@oracle.com>
Message-ID: <c5b5abeb-48bf-2200-5825-e16fb511d359@Oracle.com>

Hi Joe,

+1

Is there a useful comment on the @SuppressWarnings like in other files:

XSDHandler.java: 3028
DTMDocumentImpl: 1700
DOM2DTM.java: 1654
FilterExprWalker.java: 65

A few of the added breaks would have been hiding bugs.
It might be worth mentioning them in the issue.

Roger



On 10/30/2017 1:09 PM, Lance Andersen wrote:
> Hi Joe
>
> The changes look OK
>
> Best
> Lance
>> On Oct 30, 2017, at 1:03 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review a cleanup of fallthrough and static warnings. For fallthrough, the majority of the changes are suppressing the warnings, while for static, replacing the instances with the class.
>>
>> All jaxp tests and JCK passed.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181155
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8181155/webrev/index.html
>>
>> 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 fw at deneb.enyo.de  Mon Oct 30 18:21:34 2017
From: fw at deneb.enyo.de (Florian Weimer)
Date: Mon, 30 Oct 2017 19:21:34 +0100
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner,
 not finalizers
In-Reply-To: <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com> (Peter Levart's
 message of "Mon, 30 Oct 2017 11:21:05 +0100")
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
Message-ID: <87y3nscx8x.fsf@mid.deneb.enyo.de>

* Peter Levart:

> Simply saying that "vm is in a more critical status than a inflater is 
> getting leaked out" is, in my opinion, covering the problem under the 
> rug. The VM is not in critical state - the program is. VM is robust 
> enough to recover from OOMEs. The program might be in critical status 
> (i.e. in inconsistent state) partly because of not accounting for such 
> OOME situations. By taking care of them, the program has a better chance 
> of recovering from such situation(s).

On the other hand, memory leaks on OOM are extremely common, and for
the Inflater/ZStreamRef case, it might not be that critical to get
this absolutely airtight (particularly if the fix has non-trivial
concurrency implications).

> Handling native resources is one place where I think it is beneficial to 
> complicate things in order to make native resource leaks (im/less 
> )possible. The other such place is synchronization primitives. We must 
> admit that finalization does have this benefit that it makes it hard to 
> construct code that would allocate the native resource before cleanup 
> registration (which is performed as part of Object.<init>, while logic 
> to allocate native resource is usually invoked from subclass 
> constructor). To achieve the same robustness with Cleaner API, one has 
> to be careful to either perform registration upfront and then allocate 
> native resource or arrange for back-out in case of trouble.

If you allocate multiple resources, you probably need to apply the
same level of care with finalizers.  And the difficulty there lies in
implementing a close() operating which releases resources and inhibits
the effect of finalization.

From xueming.shen at oracle.com  Mon Oct 30 18:45:46 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 30 Oct 2017 11:45:46 -0700
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
Message-ID: <59F7735A.3000501@oracle.com>

Peter,

Given we have to put in those "make it more robust" code in ZipFile to make cleaner
work correctly with the zipfile/inflater in those vm error circumstances I would assume
it is a wrong design decision to have the short-cut Inflater constructor to try to save
some runtime circle for ZipFile/Inflater/cleaner. If the only purpose of those code is to
deal with the rare vm error situation in which we can't call inflater.end() normally, then
arguably this is the main reason we have the cleaner mechanism at first place, and
we probably should just let the cleaner to do the job (clean the resource when the
normal cleanup/release path does not work), instead of having yet another mechanism
to replace it, and with more code to workaround the possible rare circumstances.

Yes, if the vm error is a concern, the usage/implementation in Deflater/Inflater/ZStreamRef
has the similar problem. Potentially the try/catch approach might have issues. Arguably
the OOME might come from "register", and in theory there is no way to know whether
or not the OOME is triggered before the "cleaner" has been successfully put in the Queue
already or after If later, the cleaner might still be invoked later by the Cleaner to try to
release the memory one more time.

      public Inflater(boolean nowrap) {
         long address = init(nowrap);
         try {
             ZStreamRef ref = new ZStreamRef(address, Inflater::end);
             this.zsRef = ref;
             this.cleanable = CleanerFactory.cleaner().register(this, ref);
         } catch (OutOfMemoryError oome) {
             end(address);
             throw oome;
         }
     }

A normal return from register tells us everything is fine, the cleaner is registered
and it will perform as expected, but an unexpected RuntimeException/Error from
register really tells us nothing for now. The only "safe" approach seems to be the
"alternative".

As you suggested "..To achieve the same robustness with Cleaner API, one has to
be careful to either perform registration upfront and then allocate native resource
or arrange for back-out in case of trouble." It appears this might to be a very general
usage issue of the "cleaner" mechanism. Now other than the "cleaning code should
not have object reference the object being registered" restriction, it might be dirsired
to have another suggestion/warning somewhere on the "order" of register the cleaner
and the creation of the resource to be cleaned, and probably some guarantee that
the "state" of the registered cleaner, still functional or thrown away, when the
unexpected happens, such as a VM Error gets thrown during registration. Which
reminds me the question asked early regarding other Cleaner use scenario. It
appears, based on my experience of using Cleaner in this case, even the finalize()
mechanism has "lots" of issues in its implementation, it provides a "nice/clean/simple"
API to the "clean up the resource when not used" problem, while the Cleaner API
appears to have lots of restriction to use it correctly.

Webrev has been updated to (1) remove the special Inflater() (2) "allocate the
resource and inject it later" for in/deflater.

http://cr.openjdk.java.net/~sherman/8185582/webrev
(the preview webrev has been rename to webrev.04)

thanks,
Sherman





From huizhe.wang at oracle.com  Mon Oct 30 19:17:14 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 30 Oct 2017 12:17:14 -0700
Subject: RFR (JDK10/JAXP) 8181155: Fix lint warnings in JAXP repo:
 fallthrough and static
In-Reply-To: <c5b5abeb-48bf-2200-5825-e16fb511d359@Oracle.com>
References: <59F75B68.60803@oracle.com>
 <79517200-E8E7-42CF-A57A-903CC8F09919@oracle.com>
 <c5b5abeb-48bf-2200-5825-e16fb511d359@Oracle.com>
Message-ID: <59F77ABA.7070504@oracle.com>



On 10/30/17, 11:14 AM, Roger Riggs wrote:
> Hi Joe,
>
> +1
>
> Is there a useful comment on the @SuppressWarnings like in other files:
>
> XSDHandler.java: 3028
> DTMDocumentImpl: 1700
> DOM2DTM.java: 1654
> FilterExprWalker.java: 65

For the methods with long or very long switch statements, I added a note 
following the SuppressWarnings annotation to indicate where fallthrough 
would happen and in which case warnings were suppressed. But for the 
pretty short ones like the above, I thought it's quite obvious where 
fallthrough might happen, I didn't therefore add any comment.

>
> A few of the added breaks would have been hiding bugs.
> It might be worth mentioning them in the issue.

I added a note to the issue.

Thanks,
Joe

>
> Roger
>
>
>
> On 10/30/2017 1:09 PM, Lance Andersen wrote:
>> Hi Joe
>>
>> The changes look OK
>>
>> Best
>> Lance
>>> On Oct 30, 2017, at 1:03 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
>>>
>>> Hi,
>>>
>>> Please review a cleanup of fallthrough and static warnings. For 
>>> fallthrough, the majority of the changes are suppressing the 
>>> warnings, while for static, replacing the instances with the class.
>>>
>>> All jaxp tests and JCK passed.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181155
>>> webrevs: 
>>> http://cr.openjdk.java.net/~joehw/jdk10/8181155/webrev/index.html
>>>
>>> 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 xueming.shen at oracle.com  Mon Oct 30 19:21:14 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 30 Oct 2017 12:21:14 -0700
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <59F7735A.3000501@oracle.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
Message-ID: <59F77BAA.2030506@oracle.com>


...
   long t0 = System.nanoTime();
   this.zsrc = Source.get(file, (mode & OPEN_DELETE) != 0);
   this.streams = Collections.newSetFromMap(new WeakHashMap<>
   this.inflaterCache = new ArrayDeque<>();
   this.cleanable = CleanerFactory.cleaner().register(this,
           new Releaser(this.streams, this.inflaterCache, this.zsrc));
...

Now look at the "cleaner" for ZipFile. Obviously the
new Releaser(...) might trigger OOME ... So we have to
do something similar and move this piece to the top of the ZipFile
constructor before any resource gets allocated, before we have the
"zsrc"... yes, we have to inject the "zsrc" later. As, the zsrc will not
get released if we allocate it before register.

It appears we have a general usage issue here with the Cleaner? if the
unexpected throwable needs to be taken care of. The resource needed
to be released must be obtained after you have the cleaner created and
successfully registered. Otherwise it might be leaked out if the "cleaner
creation and registration" throws an unexpected throwable. As I suggested
in my early email, try/catch might not simply work here as well, as an
unexpected throwable from CleanerFactory.cleaner().register(...) really
tells nothing about the status of the cleaner being registered, so the
"cleaner" implementation will have to be crafted specially to take care of
this situation.

Sherman

On 10/30/2017 11:45 AM, Xueming Shen wrote:
> Peter,
>
> Given we have to put in those "make it more robust" code in ZipFile to make cleaner
> work correctly with the zipfile/inflater in those vm error circumstances I would assume
> it is a wrong design decision to have the short-cut Inflater constructor to try to save
> some runtime circle for ZipFile/Inflater/cleaner. If the only purpose of those code is to
> deal with the rare vm error situation in which we can't call inflater.end() normally, then
> arguably this is the main reason we have the cleaner mechanism at first place, and
> we probably should just let the cleaner to do the job (clean the resource when the
> normal cleanup/release path does not work), instead of having yet another mechanism
> to replace it, and with more code to workaround the possible rare circumstances.
>
> Yes, if the vm error is a concern, the usage/implementation in Deflater/Inflater/ZStreamRef
> has the similar problem. Potentially the try/catch approach might have issues. Arguably
> the OOME might come from "register", and in theory there is no way to know whether
> or not the OOME is triggered before the "cleaner" has been successfully put in the Queue
> already or after If later, the cleaner might still be invoked later by the Cleaner to try to
> release the memory one more time.
>
>      public Inflater(boolean nowrap) {
>         long address = init(nowrap);
>         try {
>             ZStreamRef ref = new ZStreamRef(address, Inflater::end);
>             this.zsRef = ref;
>             this.cleanable = CleanerFactory.cleaner().register(this, ref);
>         } catch (OutOfMemoryError oome) {
>             end(address);
>             throw oome;
>         }
>     }
>
> A normal return from register tells us everything is fine, the cleaner is registered
> and it will perform as expected, but an unexpected RuntimeException/Error from
> register really tells us nothing for now. The only "safe" approach seems to be the
> "alternative".
>
> As you suggested "..To achieve the same robustness with Cleaner API, one has to
> be careful to either perform registration upfront and then allocate native resource
> or arrange for back-out in case of trouble." It appears this might to be a very general
> usage issue of the "cleaner" mechanism. Now other than the "cleaning code should
> not have object reference the object being registered" restriction, it might be dirsired
> to have another suggestion/warning somewhere on the "order" of register the cleaner
> and the creation of the resource to be cleaned, and probably some guarantee that
> the "state" of the registered cleaner, still functional or thrown away, when the
> unexpected happens, such as a VM Error gets thrown during registration. Which
> reminds me the question asked early regarding other Cleaner use scenario. It
> appears, based on my experience of using Cleaner in this case, even the finalize()
> mechanism has "lots" of issues in its implementation, it provides a "nice/clean/simple"
> API to the "clean up the resource when not used" problem, while the Cleaner API
> appears to have lots of restriction to use it correctly.
>
> Webrev has been updated to (1) remove the special Inflater() (2) "allocate the
> resource and inject it later" for in/deflater.
>
> http://cr.openjdk.java.net/~sherman/8185582/webrev
> (the preview webrev has been rename to webrev.04)
>
> thanks,
> Sherman
>
>
>
>


From Roger.Riggs at Oracle.com  Mon Oct 30 19:22:56 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 30 Oct 2017 15:22:56 -0400
Subject: RFR (JDK10/JAXP) 8181155: Fix lint warnings in JAXP repo:
 fallthrough and static
In-Reply-To: <59F77ABA.7070504@oracle.com>
References: <59F75B68.60803@oracle.com>
 <79517200-E8E7-42CF-A57A-903CC8F09919@oracle.com>
 <c5b5abeb-48bf-2200-5825-e16fb511d359@Oracle.com>
 <59F77ABA.7070504@oracle.com>
Message-ID: <48216d66-089f-5530-ac4b-8b6767a0b147@Oracle.com>

That's fine.? Thanks

On 10/30/2017 3:17 PM, Joe Wang wrote:
>
>
> On 10/30/17, 11:14 AM, Roger Riggs wrote:
>> Hi Joe,
>>
>> +1
>>
>> Is there a useful comment on the @SuppressWarnings like in other files:
>>
>> XSDHandler.java: 3028
>> DTMDocumentImpl: 1700
>> DOM2DTM.java: 1654
>> FilterExprWalker.java: 65
>
> For the methods with long or very long switch statements, I added a 
> note following the SuppressWarnings annotation to indicate where 
> fallthrough would happen and in which case warnings were suppressed. 
> But for the pretty short ones like the above, I thought it's quite 
> obvious where fallthrough might happen, I didn't therefore add any 
> comment.
>
>>
>> A few of the added breaks would have been hiding bugs.
>> It might be worth mentioning them in the issue.
>
> I added a note to the issue.
>
> Thanks,
> Joe
>


From joe.darcy at oracle.com  Mon Oct 30 19:22:55 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 30 Oct 2017 12:22:55 -0700
Subject: RFR (JDK10/JAXP) 8181155: Fix lint warnings in JAXP repo:
 fallthrough and static
In-Reply-To: <59F77ABA.7070504@oracle.com>
References: <59F75B68.60803@oracle.com>
 <79517200-E8E7-42CF-A57A-903CC8F09919@oracle.com>
 <c5b5abeb-48bf-2200-5825-e16fb511d359@Oracle.com>
 <59F77ABA.7070504@oracle.com>
Message-ID: <76713c16-a60c-1d9f-4b46-cd6a42524ef2@oracle.com>

Hi Joe,

As an alternative, consider documenting the semantics/correctness of the 
fall-through at the location of the fall-through rather than at the top 
of the switch or method.

Thanks,

-Joe


On 10/30/2017 12:17 PM, Joe Wang wrote:
>
>
> On 10/30/17, 11:14 AM, Roger Riggs wrote:
>> Hi Joe,
>>
>> +1
>>
>> Is there a useful comment on the @SuppressWarnings like in other files:
>>
>> XSDHandler.java: 3028
>> DTMDocumentImpl: 1700
>> DOM2DTM.java: 1654
>> FilterExprWalker.java: 65
>
> For the methods with long or very long switch statements, I added a 
> note following the SuppressWarnings annotation to indicate where 
> fallthrough would happen and in which case warnings were suppressed. 
> But for the pretty short ones like the above, I thought it's quite 
> obvious where fallthrough might happen, I didn't therefore add any 
> comment.
>
>>
>> A few of the added breaks would have been hiding bugs.
>> It might be worth mentioning them in the issue.
>
> I added a note to the issue.
>
> Thanks,
> Joe
>
>>
>> Roger
>>
>>
>>
>> On 10/30/2017 1:09 PM, Lance Andersen wrote:
>>> Hi Joe
>>>
>>> The changes look OK
>>>
>>> Best
>>> Lance
>>>> On Oct 30, 2017, at 1:03 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review a cleanup of fallthrough and static warnings. For 
>>>> fallthrough, the majority of the changes are suppressing the 
>>>> warnings, while for static, replacing the instances with the class.
>>>>
>>>> All jaxp tests and JCK passed.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181155
>>>> webrevs: 
>>>> http://cr.openjdk.java.net/~joehw/jdk10/8181155/webrev/index.html
>>>>
>>>> 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 paul.sandoz at oracle.com  Mon Oct 30 19:44:54 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 30 Oct 2017 12:44:54 -0700
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <b8c8d33a-2782-cfba-64df-fc32151ac117@bell-sw.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <b8c8d33a-2782-cfba-64df-fc32151ac117@bell-sw.com>
Message-ID: <93431280-9CBF-4722-961D-F2D2D0F83B4E@oracle.com>

Hi,

Thanks for reviewing.

> On 30 Oct 2017, at 11:05, Dmitry Samersoff <dmitry.samersoff at bell-sw.com> wrote:
> 
> Paul,
> 
> templateTable_x86.cpp:
> 
> 564   const Register flags = rcx;
> 565   const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
> 
> Should we use another register for rarg under NOT_LP64 ?
> 

I think it should be ok, it i ain?t an expert here on the interpreter and the calling conventions, so please correct me.

Some more context:

+  const Register flags = rcx;
+  const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
+  __ movl(rarg, (int)bytecode());

The current bytecode code is loaded into ?rarg?

+  call_VM(obj, CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_ldc), rarg);

Then ?rarg" is the argument to the call to InterpreterRuntime::resolve_ldc, after which it is no longer referred to.

+#ifndef _LP64
+  // borrow rdi from locals
+  __ get_thread(rdi);
+  __ get_vm_result_2(flags, rdi);
+  __ restore_locals();
+#else
+  __ get_vm_result_2(flags, r15_thread);
+#endif

The result from the call is then loaded into flags.

So i don?t think it matters in this case if rcx is aliased.

Paul.

> -Dmitry
> 
> 
> On 10/26/2017 08:03 PM, Paul Sandoz wrote:
>> Hi,
>> 
>> Please review the following patch for minimal dynamic constant support:
>> 
>>  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
>> 
>>  https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
>>  https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>
>> 
>> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.
>> 
>> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.
>> 
>> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).
>> 
>> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.
>> 
>> The CSR for the VM specification is here:
>> 
>>  https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>
>> 
>> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).
>> 
>> Any AoT-related work will be deferred to a future release.
>> 
>> ?
>> 
>> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).
>> 
>> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.
>> 
>> ?
>> 
>> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.
>> 
>> One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.
>> 
>> ?
>> 
>> Paul.
>> 
> 


From huizhe.wang at oracle.com  Mon Oct 30 19:59:04 2017
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 30 Oct 2017 12:59:04 -0700
Subject: RFR (JDK10/JAXP) 8181155: Fix lint warnings in JAXP repo:
 fallthrough and static
In-Reply-To: <76713c16-a60c-1d9f-4b46-cd6a42524ef2@oracle.com>
References: <59F75B68.60803@oracle.com>
 <79517200-E8E7-42CF-A57A-903CC8F09919@oracle.com>
 <c5b5abeb-48bf-2200-5825-e16fb511d359@Oracle.com>
 <59F77ABA.7070504@oracle.com>
 <76713c16-a60c-1d9f-4b46-cd6a42524ef2@oracle.com>
Message-ID: <59F78488.6090602@oracle.com>



On 10/30/17, 12:22 PM, joe darcy wrote:
> Hi Joe,
>
> As an alternative, consider documenting the semantics/correctness of 
> the fall-through at the location of the fall-through rather than at 
> the top of the switch or method.

Yes,  in many of these cases, there already have been comments such as 
"fall through" at the location of the fall-through. But since some of 
the methods were very long, I thought it would make it easies for others 
who might read these method to understand by searching the keywords 
"case ...". The ones I added then served as an additional pointer to 
where fallthrough happens.

Thanks,
Joe

>
> Thanks,
>
> -Joe
>
>
> On 10/30/2017 12:17 PM, Joe Wang wrote:
>>
>>
>> On 10/30/17, 11:14 AM, Roger Riggs wrote:
>>> Hi Joe,
>>>
>>> +1
>>>
>>> Is there a useful comment on the @SuppressWarnings like in other files:
>>>
>>> XSDHandler.java: 3028
>>> DTMDocumentImpl: 1700
>>> DOM2DTM.java: 1654
>>> FilterExprWalker.java: 65
>>
>> For the methods with long or very long switch statements, I added a 
>> note following the SuppressWarnings annotation to indicate where 
>> fallthrough would happen and in which case warnings were suppressed. 
>> But for the pretty short ones like the above, I thought it's quite 
>> obvious where fallthrough might happen, I didn't therefore add any 
>> comment.
>>
>>>
>>> A few of the added breaks would have been hiding bugs.
>>> It might be worth mentioning them in the issue.
>>
>> I added a note to the issue.
>>
>> Thanks,
>> Joe
>>
>>>
>>> Roger
>>>
>>>
>>>
>>> On 10/30/2017 1:09 PM, Lance Andersen wrote:
>>>> Hi Joe
>>>>
>>>> The changes look OK
>>>>
>>>> Best
>>>> Lance
>>>>> On Oct 30, 2017, at 1:03 PM, Joe Wang <huizhe.wang at oracle.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please review a cleanup of fallthrough and static warnings. For 
>>>>> fallthrough, the majority of the changes are suppressing the 
>>>>> warnings, while for static, replacing the instances with the class.
>>>>>
>>>>> All jaxp tests and JCK passed.
>>>>>
>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181155
>>>>> webrevs: 
>>>>> http://cr.openjdk.java.net/~joehw/jdk10/8181155/webrev/index.html
>>>>>
>>>>> 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 peter.levart at gmail.com  Mon Oct 30 20:34:15 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 30 Oct 2017 21:34:15 +0100
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <59F7735A.3000501@oracle.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
Message-ID: <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>

Hi Sherman,

On 10/30/17 19:45, Xueming Shen wrote:
> Peter,
>
> Given we have to put in those "make it more robust" code in ZipFile to 
> make cleaner
> work correctly with the zipfile/inflater in those vm error 
> circumstances I would assume
> it is a wrong design decision to have the short-cut Inflater 
> constructor to try to save
> some runtime circle for ZipFile/Inflater/cleaner. If the only purpose 
> of those code is to
> deal with the rare vm error situation in which we can't call 
> inflater.end() normally, then
> arguably this is the main reason we have the cleaner mechanism at 
> first place, and
> we probably should just let the cleaner to do the job (clean the 
> resource when the
> normal cleanup/release path does not work), instead of having yet 
> another mechanism
> to replace it, and with more code to workaround the possible rare 
> circumstances.

Ok, but in that case the Cleaner registration in Inflater should be 
reliable and not fail in the same circumstances.

>
> Yes, if the vm error is a concern, the usage/implementation in 
> Deflater/Inflater/ZStreamRef
> has the similar problem. Potentially the try/catch approach might have 
> issues. Arguably
> the OOME might come from "register", and in theory there is no way to 
> know whether
> or not the OOME is triggered before the "cleaner" has been 
> successfully put in the Queue
> already or after If later, the cleaner might still be invoked later by 
> the Cleaner to try to
> release the memory one more time.

The Cleaner.register() can only fail with OOME and only because the 
jdk.internal.ref.CleanerImpl.PhantomCleanableRef object allocation 
fails. This *is the only* allocation performed by Cleaner.register(). If 
PhantomCleanableRef object allocation fails (a PhantomReference 
subclass), no PhantomReference instance is created and therefore can not 
be discovered by GC and consequently no cleanup happens.

>
> ???? public Inflater(boolean nowrap) {
> ??????? long address = init(nowrap);
> ??????? try {
> ??????????? ZStreamRef ref = new ZStreamRef(address, Inflater::end);
> ??????????? this.zsRef = ref;
> ??????????? this.cleanable = CleanerFactory.cleaner().register(this, 
> ref);
> ??????? } catch (OutOfMemoryError oome) {
> ??????????? end(address);
> ??????????? throw oome;
> ??????? }
> ??? }
>
> A normal return from register tells us everything is fine, the cleaner 
> is registered
> and it will perform as expected, but an unexpected 
> RuntimeException/Error from
> register really tells us nothing for now. 

The only RuntimeException possible from Cleaner.register() is a 
NullPointerException because of null operands and the only possible 
Error is OOME which in both cases tells us that registration did not 
happen. As said, Cleaner.register() allocates a single instance - an 
instance of jdk.internal.ref.CleanerImpl.PhantomCleanableRef. Everything 
else is just "dancing with links".

> The only "safe" approach seems to be the
> "alternative".

I agree that it is a more direct and simple approach to just reorder the 
operations, rather than arrange for back-out, but I think it is equally 
safe. Might be good to put some comments just before the init() to 
explain why it is done last in Inflater constructor (same for Deflater)?

>
> As you suggested "..To achieve the same robustness with Cleaner API, 
> one has to
> be careful to either perform registration upfront and then allocate 
> native resource
> or arrange for back-out in case of trouble." It appears this might to 
> be a very general
> usage issue of the "cleaner" mechanism. 

Yes. It appears so. But OTOH it is something that is easily understood 
and might be beneficial to document in the Cleaner javadoc.

> Now other than the "cleaning code should
> not have object reference the object being registered" restriction, it 
> might be dirsired
> to have another suggestion/warning somewhere on the "order" of 
> register the cleaner
> and the creation of the resource to be cleaned, 

Right. To mimic the finalization registration, it might be a good to 
encourage the following coding pattern (using Inflater/ZStreamRef just 
as an example, not suggesting to do that here unless you like it):

class ZStreamRef implements Runnable {

 ??? private final LongConsumer end;
 ??? private volatile long address;
 ??? final Cleaner.Cleanable cleanable; // move cleanable from 
Inflater/Deflater to here

 ??? ZStreamRef (Object reference, LongSupplier init, LongConsumer end) {
 ??????? // perform registration as 1st thing in constructor
 ??????? cleanable = CleanerFactory.cleaner().register(reference, this);
 ??????? this.end = end;
 ??????? this.address = init.getAsLong();
 ??? }

 ??? long address() {
 ??????? return address;
 ??? }

 ??? public synchronized void run() {
 ??????? long addr = address;
 ??????? address = 0;
 ??????? if (addr != 0) {
 ??????????? end.accept(addr);
 ??????? }
 ??? }
}


// ... and then in Inflater / Deflater:

 ??? public Inflater(boolean nowrap) {
 ??????? this.zsRef = new ZStreamRef(this, () -> init(nowrap), 
Inflater::end);
 ??? }

 ??? public Deflater(int level, boolean nowrap) {
 ??????? this.level = level;
 ??????? this.strategy = DEFAULT_STRATEGY;
 ??????? this.zsRef = new ZStreamRef(
 ??? ??? ??? ??? ??? ??? ??? ??? ??? this,
 ??????????????????????????????????? () -> init(level, DEFAULT_STRATEGY, 
nowrap),
 ??????????????????????????????????? Deflater::end);
 ??? }

 ??? public void end() {
 ??????? synchronized (zsRef) {
 ??????????? zsRef.cleanable.clean();
 ??????????? buf = null;
 ??????? }
 ??? }


> and probably some guarantee that
> the "state" of the registered cleaner, still functional or thrown 
> away, when the
> unexpected happens, such as a VM Error gets thrown during registration. 

I'm pretty sure it is guaranteed that Cleaner.register() throwing OOME 
means that no registration happened.

> Which
> reminds me the question asked early regarding other Cleaner use 
> scenario. It
> appears, based on my experience of using Cleaner in this case, even 
> the finalize()
> mechanism has "lots" of issues in its implementation, it provides a 
> "nice/clean/simple"
> API to the "clean up the resource when not used" problem, while the 
> Cleaner API
> appears to have lots of restriction to use it correctly.

It is not trivial to use, but it has benefits that finalization lacks. 
Like on-demand cleanup with de-registration.

>
> Webrev has been updated to (1) remove the special Inflater() (2) 
> "allocate the
> resource and inject it later" for in/deflater.
>
> http://cr.openjdk.java.net/~sherman/8185582/webrev
> (the preview webrev has been rename to webrev.04)

The Inflater and Deflater now look fine (except you don't have to check 
for cleanable != null any more in Inflater.end()).

But what shall we do with ZipFile?

>
> thanks,
> Sherman
>

Regards, Peter


From peter.levart at gmail.com  Mon Oct 30 20:49:42 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 30 Oct 2017 21:49:42 +0100
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
 <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
Message-ID: <0ec13ca6-d542-ba81-c804-bfd524564f6a@gmail.com>

Hi again,

On 10/30/17 21:34, Peter Levart wrote:
> To mimic the finalization registration, it might be a good to 
> encourage the following coding pattern (using Inflater/ZStreamRef just 
> as an example, not suggesting to do that here unless you like it):
>
> class ZStreamRef implements Runnable {
>
> ??? private final LongConsumer end;
> ??? private volatile long address;
> ??? final Cleaner.Cleanable cleanable; // move cleanable from 
> Inflater/Deflater to here
>
> ??? ZStreamRef (Object reference, LongSupplier init, LongConsumer end) {
> ??????? // perform registration as 1st thing in constructor
> ??????? cleanable = CleanerFactory.cleaner().register(reference, this);
> ??????? this.end = end;
> ??????? this.address = init.getAsLong();
> ??? }
>
> ??? long address() {
> ??????? return address;
> ??? }
>
> ??? public synchronized void run() {
> ??????? long addr = address;
> ??????? address = 0;
> ??????? if (addr != 0) {
> ??????????? end.accept(addr);
> ??????? }
> ??? }
> }

...above example lends itself as a use case for the following equivalent 
alternative using internal low-level API where ZStreamRef becomes the 
Cleanable itself:

class ZStreamRef extends PhantomCleanable<Object> {

 ??? private final LongConsumer end;
 ??? private volatile long address;

 ??? ZStreamRef (Object referent, LongSupplier init, LongConsumer end) {
 ??? ??? // here the registration MUST happen as 1st thing - enforced by 
javac
 ??????? super(referent, CleanerFactory.cleaner());
 ??????? this.end = end;
 ??????? this.address = init.getAsLong();
 ??? }

 ??? long address() {
 ??????? return address;
 ??? }

 ??? @Override
 ??? protected void performCleanup() {
 ??????? long addr = address;
 ??????? address = 0;
 ??????? if (addr != 0) {
 ??????????? end.accept(addr);
 ??????? }
 ??? }
}


Inflater/Deflater constructor is unchanged while end() becomes:

 ???? public void end() {
 ??????? synchronized (zsRef) {
 ??????????? zsRef.clean(); // zsRef is-a Cleanable
 ??????????? buf = null;
 ??????? }
 ??? }


It's interesting that something that is considered a "low-level" API in 
above example forces you to do it right, while the high level API doesn't.

Regards, Peter


From mandy.chung at oracle.com  Mon Oct 30 21:08:53 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 30 Oct 2017 14:08:53 -0700
Subject: RFR: 8190287: Update JDK's internal ASM to ASMv6
In-Reply-To: <59F3690B.6070309@oracle.com>
References: <59F3690B.6070309@oracle.com>
Message-ID: <1d6c773a-8495-cf14-61b6-7616c8b80225@oracle.com>



On 10/27/17 10:12 AM, Kumar Srinivasan wrote:
> Hello Remi, Sundar and others,
>
> Please review the webrev [1] to update JDK's internal ASM to v6.
>
> [1] http://cr.openjdk.java.net/~ksrini/8190287/webrev.00/index.html

The jlink and module-related change looks fine to me.? I also skimmed 
through asm6 change which looks fine too.

Please update src/java.base/share/legal/asm.md to reflect the new version.

thanks
Mandy

From frederic.parain at oracle.com  Mon Oct 30 21:56:37 2017
From: frederic.parain at oracle.com (Frederic Parain)
Date: Mon, 30 Oct 2017 17:56:37 -0400
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <93431280-9CBF-4722-961D-F2D2D0F83B4E@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <b8c8d33a-2782-cfba-64df-fc32151ac117@bell-sw.com>
 <93431280-9CBF-4722-961D-F2D2D0F83B4E@oracle.com>
Message-ID: <EBC28788-F65A-42F8-A6AD-7B670FDB74C5@oracle.com>

I?m seeing no issue with rcx being aliased in this code.

Fred

> On Oct 30, 2017, at 15:44, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Thanks for reviewing.
> 
>> On 30 Oct 2017, at 11:05, Dmitry Samersoff <dmitry.samersoff at bell-sw.com> wrote:
>> 
>> Paul,
>> 
>> templateTable_x86.cpp:
>> 
>> 564   const Register flags = rcx;
>> 565   const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
>> 
>> Should we use another register for rarg under NOT_LP64 ?
>> 
> 
> I think it should be ok, it i ain?t an expert here on the interpreter and the calling conventions, so please correct me.
> 
> Some more context:
> 
> +  const Register flags = rcx;
> +  const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
> +  __ movl(rarg, (int)bytecode());
> 
> The current bytecode code is loaded into ?rarg?
> 
> +  call_VM(obj, CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_ldc), rarg);
> 
> Then ?rarg" is the argument to the call to InterpreterRuntime::resolve_ldc, after which it is no longer referred to.
> 
> +#ifndef _LP64
> +  // borrow rdi from locals
> +  __ get_thread(rdi);
> +  __ get_vm_result_2(flags, rdi);
> +  __ restore_locals();
> +#else
> +  __ get_vm_result_2(flags, r15_thread);
> +#endif
> 
> The result from the call is then loaded into flags.
> 
> So i don?t think it matters in this case if rcx is aliased.
> 
> Paul.
> 
>> -Dmitry
>> 
>> 
>> On 10/26/2017 08:03 PM, Paul Sandoz wrote:
>>> Hi,
>>> 
>>> Please review the following patch for minimal dynamic constant support:
>>> 
>>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
>>> https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>
>>> 
>>> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.
>>> 
>>> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.
>>> 
>>> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).
>>> 
>>> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.
>>> 
>>> The CSR for the VM specification is here:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>
>>> 
>>> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).
>>> 
>>> Any AoT-related work will be deferred to a future release.
>>> 
>>> ?
>>> 
>>> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).
>>> 
>>> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.
>>> 
>>> ?
>>> 
>>> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.
>>> 
>>> One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.
>>> 
>>> ?
>>> 
>>> Paul.
>>> 
>> 
> 


From patrick at reini.net  Mon Oct 30 22:05:02 2017
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 30 Oct 2017 23:05:02 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <0607f21d-0e5d-2d9e-89da-9e43144eae84@Oracle.com>
References: <15bb28d5-003c-ff0c-da16-5ce3920ea765@reini.net>
 <0607f21d-0e5d-2d9e-89da-9e43144eae84@Oracle.com>
Message-ID: <3bb8be78-c8ad-a28b-b799-4c763fa73310@reini.net>

I found around 30 usages of copy all data from a reader to an appendable
or writer like this within the jdk itself:

? StringBuilder sb = new StringBuilder(); // appendable
? char[] buf = new char[1024];
? int n;
? while ((n = reader.read(buf)) >= 0) {
????? sb.append(buf, 0, n);
? }

or

? Writer writer = ....
? char[] buf = new char[1024];
? int n;
? while ((n = reader.read(buf)) >= 0) {
????? writer.write(buf, 0, n);
? }

Also in our code base with around 5 million lines of code we got a lot
of copy from a readable/reader to a writer or appendable...

Cheers, Patrick



Am 28.10.2017 um 20:57 schrieb Roger Riggs:
> Hi Patrick,
>
> Sounds like a good idea to me.
>
> Do you have any suggestions for concrete implementations that may
> benefit from specialized
> implementations?
>
> As a 'push' API, an implementation will necessarily have to allocate a
> buffer and read
> characters and then append them to the appendable.? I don't remember
> if a 'pull' API was
> considered for streams in which the dest could provide its own buffer
> to the reader
> and benefit from one less copy of the bytes.
>
> Thanks, Roger
>
>
> On 10/28/2017 10:05 AM, Patrick Reinhart wrote:
>> Hi There,
>>
>> Based on the *transferTo* Method on the InputStream I would propose to
>> introduce a
>> default method on the Readable interface. In that way the method can be
>> used for
>> all existing implementations of Readable and still be implemented in a
>> special
>> way by a individual implementer.
>>
>>
>> ??? /**
>>
>> ???? * Reads all characters from this readable and writes the
>> characters to
>> ???? * the given appendable in the order that they are read. On
>> return, this
>> ???? * readable will be at end its data.
>> ???? * <p>
>> ???? * This method may block indefinitely reading from the readable, or
>> ???? * writing to the appendable. The behavior for the case where the
>> readable
>> ???? * and/or appendable is <i>asynchronously closed</i>, or the thread
>> ???? * interrupted during the transfer, is highly readable and
>> appendable
>> ???? * specific, and therefore not specified.
>> ???? * <p>
>> ???? * If an I/O error occurs reading from the readable or writing to
>> the
>> ???? * appendable, then it may do so after some characters have been
>> read or
>> ???? * written. Consequently the readable may not be at end of its
>> data and
>> ???? * one, or both participants may be in an inconsistent state.
>> That in
>> mind
>> ???? * all additional measures required by one or both participants in
>> order to
>> ???? * eventually free their internal resources have to be taken by the
>> caller
>> ???? * of this method.
>> ???? *
>> ???? * @param? out the appendable, non-null
>> ???? * @return the number of characters transferred
>> ???? * @throws IOException if an I/O error occurs when reading or
>> writing
>> ???? * @throws NullPointerException if {@code out} is {@code null}
>> ???? *
>> ???? * @since 18.3
>> ???? */
>> ??? default long transferTo(Appendable out) throws IOException {
>> ??? ....
>> ??? }
>>
>>
>> Cheers Patrick
>



From paul.sandoz at oracle.com  Mon Oct 30 22:49:25 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 30 Oct 2017 15:49:25 -0700
Subject: RFR Re: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
Message-ID: <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>

Hi Chris,

After some hiatus here is an updated webrev, i made some tweaks to the JavaDoc:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8178117-summary-constructors/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8178117-summary-constructors/webrev/>

And the CSR:

  https://bugs.openjdk.java.net/browse/JDK-8190381 <https://bugs.openjdk.java.net/browse/JDK-8190381>

The support for a double sum of consisting of an array of double is going beyond my complexity budget for this feature. If that is deemed important later on we can add another constructor.

Paul.

> On 11 Apr 2017, at 17:44, Chris Dennis <chris.w.dennis at gmail.com> wrote:
> 
> Updated patch with the changed parameter validation, updated javadoc and added test coverage.
> 
> <8178117.2.patch.txt>
> 
>> On Apr 11, 2017, at 4:48 PM, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>> 
>> Color me confused? what would the javadoc on the parameter say? It could I guess have an @implNote documenting the meanings of the parameters? but then what use is it? The proposed API simply limits the precision with which a DoubleSummaryStatistic can be copied to be the same as the precision with which it can be ?accessed?.  That doesn?t seem an enormous problem since I suspect that bulk of usages would be to marshall a ?finished? instance and therefore there is no real loss occuring. If we wanted to support arbitrary precision wouldn?t it be better to have a constructor variant that took a BigDecimal, and a matching getPreciseSum() that returned a BigDecimal?
>> 
>> Chris
>> 
>>> On Apr 11, 2017, at 4:16 PM, joe darcy <joe.darcy at oracle.com> wrote:
>>> 
>>> On an API design note, I would prefer to DoubleSummaryStatistics took a double... argument to pass in the state of the summation. This flexibility is necessary to more fully preserve the computed sum. Also, the we want flexibility to change the amount of internal state DoubleSummaryStats keeps so we don't want to hard-code that into as aspect of the API.
>>> 
>>> Thanks,
>>> 
>>> -Joe
>>> 
>>> 
>>> On 4/11/2017 12:53 PM, Paul Sandoz wrote:
>>>> Hi Chris,
>>>> 
>>>> Thanks for looking at this.
>>>> 
>>>> There is some rudimentary testing using streams in CollectAndSummaryStatisticsTest.java.
>>>> 
>>>> I think we should enforce constraints where we reliably can:
>>>> 
>>>> 1) count >= 0
>>>> 
>>>> 2) count = 0, then min/max/sum are ignored and it?s as if the default constructor was called. (I thought it might be appropriate to reject since a caller might be passing in incorrect information in error, but the defaults for min/max are important and would be a burden for the caller to pass those values.) In this respect having count as the first parameter of the constructor would be useful.
>>>> 
>>>> 3)  min <= max
>>>> 
>>>> Since for count > 0 the constraints, count * max >= sum, count * min <= sum, cannot be reliably enforced due to overflow i am inclined to not bother and just document.
>>>> 
>>>> 
>>>> Note this is gonna be blocked from pushing until the new Compatibility and Specification Review (CSR) process is opened up, which i understand is ?soon"ish :-) but that should not block adding some further tests in the interim and tidying up the javadoc.
>>>> 
>>>> Paul.
>>>> 
>>>> 
>>>>> On 6 Apr 2017, at 07:08, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>>>>> 
>>>>> Hi Paul (et al)
>>>>> 
>>>>> Like all things API there are wrinkles here when it comes to implementing.
>>>>> 
>>>>> This patch isn?t final, there appears to be no existing test coverage for these classes beyond testing the compensating summation used in the double implementation, and I left off adding any until it was decided how much parameter validation we want (since that?s the only testing that can really occur here).
>>>>> 
>>>>> The wrinkles relate to the issues around instances that have suffered overflow in count and/or sum which the existing implementation doesn?t defend against:
>>>>> 
>>>>> * I chose to ignore all parameters if 'count == 0? and just leave the instance empty. I held off from validating min, max and count however. This obviously 'breaks things? (beyond how broken they would already be) if count == 0 only due to overflow.
>>>>> * I chose to fail if count is negative.
>>>>> * I chose to enforce that max and min are logically consistent with count and sum, this can break the moment either one of the overflows as well (I?m also pretty sure that the FPU logic is going to suffer here too - there might be some magic I can do with a pessimistic bit of rounding on the FPU multiplication result).
>>>>> 
>>>>> I intentionally went with the most aggressive parameter validation here to establish one end of what could be implemented.  There are arguments for this and also arguments for the other extreme (no validation at all).  Personally I?m in favor of the current version where the creation will fail if the inputs are only possible through overflow (modulo fixing the FPU precision issues above) even though it?s at odds with approach of the existing implementation.
>>>>> 
>>>>> Would appreciate thoughts/feedback.  Thanks.
>>>>> 
>>>>> Chris
>>>>> 
>>>>> 
>>>>> P.S. I presume tests would be required for the parameter checking (once it is finalized)?
>>>>> 
>>>>> <8178117.patch>
>>> 
>> 
> 


From stuart.marks at oracle.com  Mon Oct 30 22:50:05 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 30 Oct 2017 15:50:05 -0700
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, 
 Map
Message-ID: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>

(also includes 8184690: add Collectors for collecting into unmodifiable List, 
Set, and Map)

Hi all,

Here's an updated webrev for this changeset; the previous review thread is here:

     http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html

This webrev includes the following:

* specification revisions to provide clearer definitions of "view" collections, 
"unmodifiable" collections, and "unmodifiable views"

* new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" methods

* new Collectors.toUnmodifiableList, Set, and Map methods

* tests for the new API methods

I've added some assertions that require some independence between the source 
collection (or map) and the result of the copyOf() method.

I've made a small but significant change to Set.copyOf compared to the previous 
round. Previously, it specified that the first of any equal elements was 
preserved. Now, it is explicitly unspecified which of any equals elements is 
preserved. This is consistent with Set.addAll, Collectors.toSet, and the newly 
added Collectors.toUnmodifiableSet, none of which specify which of duplicate 
elements is preserved.

(The outlier here is Stream.distinct, which specifies that the first element of 
any duplicates is preserved, if the stream is ordered.)

I've also made some minor wording/editorial changes in response to suggestions 
from David Holmes and Roger Riggs. I've kept the wording changes that give 
emphasis to "unmodifiable" over "immutable." The term "immutable" is 
inextricably intertwined with "persistent" when it comes to data structures, and 
I believe we'll be explaining this forever if Java's "immutable" means something 
different from everybody else's.

Webrev:

     http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/

Bugs:

     https://bugs.openjdk.java.net/browse/JDK-8177290
         add copy factory methods for unmodifiable List, Set, Map

     https://bugs.openjdk.java.net/browse/JDK-8184690
         add Collectors for collecting into unmodifiable List, Set, and Map

Thanks,

s'marks

From stuart.marks at oracle.com  Mon Oct 30 23:04:59 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 30 Oct 2017 16:04:59 -0700
Subject: [Bug][JDK10] Fix duplicated "a" occurrences in docs
In-Reply-To: <007d01d35198$f6ae1900$e40a4b00$@freenet.de>
References: <007701d35197$f6440200$e2cc0600$@freenet.de>
 <007d01d35198$f6ae1900$e40a4b00$@freenet.de>
Message-ID: <1f2b83c9-a25f-1bde-dce7-e6bf53322b93@oracle.com>

I'll take this one. I just ran across another minor error I wanted to fix so 
I'll piggyback mine on yours.

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

Thanks for pointing these out!

s'marks


On 10/30/17 9:05 AM, Christoph Dreis wrote:
> The attached patched seems to have been dropped.
> 
> Sorry for any inconveniences.
> 
> ===== PATCH ======
> diff -r d87f89c74f54
> src/java.base/share/classes/java/lang/invoke/VarHandle.java
> --- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java	Mon
> Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java	Mon
> Oct 30 16:47:56 2017 +0100
> @@ -423,7 +423,7 @@
>    * {@link java.lang.invoke.MethodHandles#varHandleInvoker}.
>    *
>    * <h1>Interoperation between VarHandles and Java generics</h1>
> - * A VarHandle can be obtained for a variable, such as a a field, which is
> + * A VarHandle can be obtained for a variable, such as a field, which is
>    * declared with Java generic types.  As with the Core Reflection API, the
>    * VarHandle's variable type will be constructed from the erasure of the
>    * source-level type.  When a VarHandle access mode method is invoked, the
> 
> diff -r d87f89c74f54 src/java.base/share/classes/java/util/EventObject.java
> --- a/src/java.base/share/classes/java/util/EventObject.java	Mon Oct 30
> 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/EventObject.java	Mon Oct 30
> 16:47:56 2017 +0100
> @@ -70,7 +70,7 @@
>       /**
>        * Returns a String representation of this EventObject.
>        *
> -     * @return  A a String representation of this EventObject.
> +     * @return a String representation of this EventObject.
>        */
>       public String toString() {
>           return getClass().getName() + "[source=" + source + "]";
> 
> diff -r d87f89c74f54
> src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/Parameter
> izedTypeImpl.java
> ---
> a/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/Paramet
> erizedTypeImpl.java	Mon Oct 30 07:06:49 2017 -0700
> +++
> b/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/Paramet
> erizedTypeImpl.java	Mon Oct 30 16:47:56 2017 +0100
> @@ -66,7 +66,7 @@
>       /**
>        * Static factory. Given a (generic) class, actual type arguments
>        * and an owner type, creates a parameterized type.
> -     * This class can be instantiated with a a raw type that does not
> +     * This class can be instantiated with a raw type that does not
>        * represent a generic type, provided the list of actual type
>        * arguments is empty.
>        * If the ownerType argument is null, the declaring class of the
> 
> 
>> Hey,
>>
>> similar to JDK-8190323 the attached patch removes duplicated "a"
>> occurrences in java.base docs.
>>
>> Would be happy if this is sponsored.
>>
>> I wasn't sure about the capitalization change on EventObject. What's the
> rule
>> of thumb in cases where the class does not follow the guidelines for
> docs[1]?
>> Sticking to the overall class scheme or aligning everything?
>>
>> Cheers,
>> Christoph
>> [1] http://www.oracle.com/technetwork/articles/java/index-137868.html
> 
> 
> 

From brian.burkhalter at oracle.com  Mon Oct 30 23:14:57 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 30 Oct 2017 16:14:57 -0700
Subject: RFR Re: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
 <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
Message-ID: <A7E04AF3-FFB6-41C4-9632-12ADB1925F6B@oracle.com>

Hi Paul,

On the specification, e.g., at line 95 of DoubleSummaryStatistics:

s/recorded the count of values/recorded count of values/

Brian

On Oct 30, 2017, at 3:49 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> And the CSR:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8190381<https://bugs.openjdk.java.net/browse/JDK-8190381>


From martinrb at google.com  Mon Oct 30 23:20:32 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 30 Oct 2017 16:20:32 -0700
Subject: [Bug][JDK10] Fix duplicated "a" occurrences in docs
In-Reply-To: <007701d35197$f6440200$e2cc0600$@freenet.de>
References: <007701d35197$f6440200$e2cc0600$@freenet.de>
Message-ID: <CA+kOe09K04HdXYJ1Vca3g7DfTLj=XLo44gj9R9QN7iRv=cHGAw@mail.gmail.com>

Thanks.

I tried to fix "all" the stutters back in
http://hg.openjdk.java.net/jdk10/master/rev/e576535359cc
but new ones have crept in and I didn't look for single-letter ones.

On Mon, Oct 30, 2017 at 8:58 AM, Christoph Dreis <christoph.dreis at freenet.de
> wrote:

> Hey,
>
> similar to JDK-8190323 the attached patch removes duplicated "a"
> occurrences
> in java.base docs.
>
> Would be happy if this is sponsored.
>
> I wasn't sure about the capitalization change on EventObject. What's the
> rule of thumb in cases where the class does not follow the guidelines for
> docs[1]? Sticking to the overall class scheme or aligning everything?
>
> Cheers,
> Christoph
> [1] http://www.oracle.com/technetwork/articles/java/index-137868.html
>
>

From paul.sandoz at oracle.com  Mon Oct 30 23:23:28 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 30 Oct 2017 16:23:28 -0700
Subject: RFR Re: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <A7E04AF3-FFB6-41C4-9632-12ADB1925F6B@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
 <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
 <A7E04AF3-FFB6-41C4-9632-12ADB1925F6B@oracle.com>
Message-ID: <FAA861C7-6B32-40BF-9E25-4A32AC9CACA0@oracle.com>


> On 30 Oct 2017, at 16:14, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Hi Paul,
> 
> On the specification, e.g., at line 95 of DoubleSummaryStatistics:
> 
> s/recorded the count of values/recorded count of values/
> 

Thanks! updated the webrev and CSR.

Paul.

> Brian
> 
> On Oct 30, 2017, at 3:49 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> 
>> And the CSR:
>> 
>>  https://bugs.openjdk.java.net/browse/JDK-8190381 <https://bugs.openjdk.java.net/browse/JDK-8190381><https://bugs.openjdk.java.net/browse/JDK-8190381 <https://bugs.openjdk.java.net/browse/JDK-8190381>>
> 


From mandy.chung at oracle.com  Mon Oct 30 23:25:00 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Mon, 30 Oct 2017 16:25:00 -0700
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <0ec13ca6-d542-ba81-c804-bfd524564f6a@gmail.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
 <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
 <0ec13ca6-d542-ba81-c804-bfd524564f6a@gmail.com>
Message-ID: <64f46e40-b641-b280-eed3-99606e9ad1d5@oracle.com>



On 10/30/17 1:49 PM, Peter Levart wrote:
>
> ...above example lends itself as a use case for the following 
> equivalent alternative using internal low-level API where ZStreamRef 
> becomes the Cleanable itself:
>
> class ZStreamRef extends PhantomCleanable<Object> {
>
> ??? private final LongConsumer end;
> ??? private volatile long address;
>
> ??? ZStreamRef (Object referent, LongSupplier init, LongConsumer end) {
> ??? ??? // here the registration MUST happen as 1st thing - enforced 
> by javac
> ??????? super(referent, CleanerFactory.cleaner());
> ??????? this.end = end;
> ??????? this.address = init.getAsLong();
> ??? }
>
> ??? long address() {
> ??????? return address;
> ??? }
>
> ??? @Override
> ??? protected void performCleanup() {
> ??????? long addr = address;
> ??????? address = 0;
> ??????? if (addr != 0) {
> ??????????? end.accept(addr);
> ??????? }
> ??? }
> }
>

I was thinking something along this line what could ensure the 
"cleanable" object is allocated before allocating the resources that the 
cleanable is responsible for clean up.?? I think it'd be a good RFE to 
improve the Cleaner API to address the OOM case.

Mandy

From xueming.shen at oracle.com  Mon Oct 30 23:32:49 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 30 Oct 2017 16:32:49 -0700
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
 <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
Message-ID: <59F7B6A1.5040303@oracle.com>

On 10/30/2017 01:34 PM, Peter Levart wrote:
>
> The Inflater and Deflater now look fine (except you don't have to check for cleanable != null any more in Inflater.end()).
>
> But what shall we do with ZipFile?
>

Peter,

The fundamental issue here is the gap between the resource allocation
and the cleaner registration, as far as these two are not an atomic
operation, it's hard to handle it in the normal use scenario. You might be
able to workaround it by registering the cleaner first and then send the
resource reference into the cleaner, as we are going to do for the deflater/
inflater. But it appears to be a more general issue and in some circumstance
even the "register-first-allocate-assign-in-later" approach might fail.
For example, you have N resource to allocate, something goes wrong
between the first and the Nth resource allocation completed/or simply say
before you can reach the "register()". The question then I would like to ask
again is if this is really something we want to support/cover with the Cleaner
mechanism. It doesn't appear to be supported under the finalize() mechanism.
For example, if someone throws out an exception inside the constructor, in
normal use scenario, regardless you catch or not catch that exception
(outside the constructor), the finalize() method is probably not going to
be called by the finalizer for this partially/incompletely constructed object,
if you don't purposely do something special to publish the object. Sure
arguably It appears to be out of the scope of Cleaner API and the only thing
needs to be addressed here is whether or not register(..) operation fails and
throws an Error. But it might be helpful to see if there is any different opinion
before going further?

Sherman






From brian.burkhalter at oracle.com  Mon Oct 30 23:34:53 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 30 Oct 2017 16:34:53 -0700
Subject: RFR Re: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <FAA861C7-6B32-40BF-9E25-4A32AC9CACA0@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
 <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
 <A7E04AF3-FFB6-41C4-9632-12ADB1925F6B@oracle.com>
 <FAA861C7-6B32-40BF-9E25-4A32AC9CACA0@oracle.com>
Message-ID: <27BEA3AD-04F4-4C77-8180-D824D8BCF7AB@oracle.com>

Looks good but I was wondering why there are static imports of a couple of j.l.Math methods in Int/LongSummaryStatistics.

Brian

On Oct 30, 2017, at 4:23 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Thanks! updated the webrev and CSR.


From janb at webtide.com  Mon Oct 30 23:54:28 2017
From: janb at webtide.com (Jan Bartel)
Date: Tue, 31 Oct 2017 10:54:28 +1100
Subject: Versioning of META-INF/services
Message-ID: <CAEHc-32uV59gfCPLi5MQriZD8nFZvrnwhCLg+fD1B-XmO0-k5g@mail.gmail.com>

I asked this question over on the jdk9-dev list and they suggested I ask it
here instead:

http://openjdk.java.net/jeps/238 says:

"JAR metadata, such as that found in the MANIFEST.MF file and the
META-INF/services directory, need not be versioned."

Does the language "need not" actually mean "is not", or is the intention to
leave the door open to versioning of META-INF/services?

If it is possible to version services, is there any requirement that the
annotations on a service must be the same for all versions of that service
in a multi-release jar?

The motivation for the question is a scenario where we need to support
build and pre-deployment discovery of services on a different version of
the jvm (ie 9) to deployment/runtime (ie 8).  During discovery we examine
services returned from the ServiceLoader for particular annotations, such
as the @HandlesTypes annotation from the servlet spec.  If services can be
versioned, and annotations may be different between versions, we would need
some support from the jvm to be able to ensure we examine the correct
version for the target runtime jvm version.

thanks,
Jan
-- 
Jan Bartel <janb at webtide.com>
www.webtide.com
*Expert assistance from the creators of Jetty and CometD*

From brent.christian at oracle.com  Mon Oct 30 23:55:07 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 30 Oct 2017 16:55:07 -0700
Subject: RFR 8189319 : Add a java.util.Properties constructor that takes
 an initial capacity
In-Reply-To: <61f9ad8b-7c7f-9db2-c404-edc79f27a902@oracle.com>
References: <326a2344-79e3-b95d-18a6-731d022097d4@oracle.com>
 <bb76fcdd-8041-3423-633c-841593c38f23@oracle.com>
 <313e04f8-7e54-c388-e2f3-cf762c510f70@oracle.com>
 <442cd672-39bf-0a8a-9354-3e49e0244d0b@oracle.com>
 <61f9ad8b-7c7f-9db2-c404-edc79f27a902@oracle.com>
Message-ID: <67551d08-e62a-5aee-e43d-e6392a3580ff@oracle.com>

Thank you for the reviews!

-Brent


From joe.darcy at oracle.com  Tue Oct 31 00:19:01 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 30 Oct 2017 17:19:01 -0700
Subject: RFR Re: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
 <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
Message-ID: <59F7C175.7010705@oracle.com>

Hello,

Is it intentional that "DoubleSummaryStatistics" is used in a sentence like

   91      * @apiNote
   92      * The enforcement of argument correctness means that the 
retrieved set of
   93      * recorded values obtained from a {@code 
DoubleSummaryStatistics} source

in all three types being updated?

For the code in the constructor, if you don't want to have something 
like an explicit switch on Long.signum(count), I'd prefer to see at 
least a comment like

// Use default field values if count == 0

For the double case, I'd recommend future work change the new 
constructor to

     DoubleSummaryStatistics(long count, double min, double max, double 
sum, double... additionalSum)

where the final argument could be used to convey additional state.

For the double case, if a NaN is used than max and min will be NaN. 
Therefore, I'd recommend change the correctness constraint for that type to

     <li>{@code min} &le; {@code max} || (isNaN(min) && isNaN(max)) </li>

with an analogous update to the code.

Thanks,

-Joe

On 10/30/2017 3:49 PM, Paul Sandoz wrote:
> Hi Chris,
>
> After some hiatus here is an updated webrev, i made some tweaks to the 
> JavaDoc:
>
> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8178117-summary-constructors/webrev/ 
> <http://cr.openjdk.java.net/%7Epsandoz/jdk10/JDK-8178117-summary-constructors/webrev/>
>
> And the CSR:
>
> https://bugs.openjdk.java.net/browse/JDK-8190381
>
> The support for a double sum of consisting of an array of double is 
> going beyond my complexity budget for this feature. If that is deemed 
> important later on we can add another constructor.
>
> Paul.
>
>> On 11 Apr 2017, at 17:44, Chris Dennis <chris.w.dennis at gmail.com 
>> <mailto:chris.w.dennis at gmail.com>> wrote:
>>
>> Updated patch with the changed parameter validation, updated javadoc 
>> and added test coverage.
>>
>> <8178117.2.patch.txt>
>>
>>> On Apr 11, 2017, at 4:48 PM, Chris Dennis <chris.w.dennis at gmail.com 
>>> <mailto:chris.w.dennis at gmail.com>> wrote:
>>>
>>> Color me confused? what would the javadoc on the parameter say? It 
>>> could I guess have an @implNote documenting the meanings of the 
>>> parameters? but then what use is it? The proposed API simply limits 
>>> the precision with which a DoubleSummaryStatistic can be copied to 
>>> be the same as the precision with which it can be ?accessed?.  That 
>>> doesn?t seem an enormous problem since I suspect that bulk of usages 
>>> would be to marshall a ?finished? instance and therefore there is no 
>>> real loss occuring. If we wanted to support arbitrary precision 
>>> wouldn?t it be better to have a constructor variant that took a 
>>> BigDecimal, and a matching getPreciseSum() that returned a BigDecimal?
>>>
>>> Chris
>>>
>>>> On Apr 11, 2017, at 4:16 PM, joe darcy <joe.darcy at oracle.com 
>>>> <mailto:joe.darcy at oracle.com>> wrote:
>>>>
>>>> On an API design note, I would prefer to DoubleSummaryStatistics 
>>>> took a double... argument to pass in the state of the summation. 
>>>> This flexibility is necessary to more fully preserve the computed 
>>>> sum. Also, the we want flexibility to change the amount of internal 
>>>> state DoubleSummaryStats keeps so we don't want to hard-code that 
>>>> into as aspect of the API.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>>
>>>> On 4/11/2017 12:53 PM, Paul Sandoz wrote:
>>>>> Hi Chris,
>>>>>
>>>>> Thanks for looking at this.
>>>>>
>>>>> There is some rudimentary testing using streams in 
>>>>> CollectAndSummaryStatisticsTest.java.
>>>>>
>>>>> I think we should enforce constraints where we reliably can:
>>>>>
>>>>> 1) count >= 0
>>>>>
>>>>> 2) count = 0, then min/max/sum are ignored and it?s as if the 
>>>>> default constructor was called. (I thought it might be appropriate 
>>>>> to reject since a caller might be passing in incorrect information 
>>>>> in error, but the defaults for min/max are important and would be 
>>>>> a burden for the caller to pass those values.) In this respect 
>>>>> having count as the first parameter of the constructor would be 
>>>>> useful.
>>>>>
>>>>> 3)  min <= max
>>>>>
>>>>> Since for count > 0 the constraints, count * max >= sum, count * 
>>>>> min <= sum, cannot be reliably enforced due to overflow i am 
>>>>> inclined to not bother and just document.
>>>>>
>>>>>
>>>>> Note this is gonna be blocked from pushing until the new 
>>>>> Compatibility and Specification Review (CSR) process is opened up, 
>>>>> which i understand is ?soon"ish :-) but that should not block 
>>>>> adding some further tests in the interim and tidying up the javadoc.
>>>>>
>>>>> Paul.
>>>>>
>>>>>
>>>>>> On 6 Apr 2017, at 07:08, Chris Dennis <chris.w.dennis at gmail.com 
>>>>>> <mailto:chris.w.dennis at gmail.com>> wrote:
>>>>>>
>>>>>> Hi Paul (et al)
>>>>>>
>>>>>> Like all things API there are wrinkles here when it comes to 
>>>>>> implementing.
>>>>>>
>>>>>> This patch isn?t final, there appears to be no existing test 
>>>>>> coverage for these classes beyond testing the compensating 
>>>>>> summation used in the double implementation, and I left off 
>>>>>> adding any until it was decided how much parameter validation we 
>>>>>> want (since that?s the only testing that can really occur here).
>>>>>>
>>>>>> The wrinkles relate to the issues around instances that have 
>>>>>> suffered overflow in count and/or sum which the existing 
>>>>>> implementation doesn?t defend against:
>>>>>>
>>>>>> * I chose to ignore all parameters if 'count == 0? and just leave 
>>>>>> the instance empty. I held off from validating min, max and count 
>>>>>> however. This obviously 'breaks things? (beyond how broken they 
>>>>>> would already be) if count == 0 only due to overflow.
>>>>>> * I chose to fail if count is negative.
>>>>>> * I chose to enforce that max and min are logically consistent 
>>>>>> with count and sum, this can break the moment either one of the 
>>>>>> overflows as well (I?m also pretty sure that the FPU logic is 
>>>>>> going to suffer here too - there might be some magic I can do 
>>>>>> with a pessimistic bit of rounding on the FPU multiplication result).
>>>>>>
>>>>>> I intentionally went with the most aggressive parameter 
>>>>>> validation here to establish one end of what could be 
>>>>>> implemented.  There are arguments for this and also arguments for 
>>>>>> the other extreme (no validation at all).  Personally I?m in 
>>>>>> favor of the current version where the creation will fail if the 
>>>>>> inputs are only possible through overflow (modulo fixing the FPU 
>>>>>> precision issues above) even though it?s at odds with approach of 
>>>>>> the existing implementation.
>>>>>>
>>>>>> Would appreciate thoughts/feedback.  Thanks.
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>> P.S. I presume tests would be required for the parameter checking 
>>>>>> (once it is finalized)?
>>>>>>
>>>>>> <8178117.patch>
>>>>
>>>
>>
>


From stuart.marks at oracle.com  Tue Oct 31 00:29:05 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 30 Oct 2017 17:29:05 -0700
Subject: [Bug][JDK10] Fix duplicated "a" occurrences in docs
In-Reply-To: <CA+kOe09K04HdXYJ1Vca3g7DfTLj=XLo44gj9R9QN7iRv=cHGAw@mail.gmail.com>
References: <007701d35197$f6440200$e2cc0600$@freenet.de>
 <CA+kOe09K04HdXYJ1Vca3g7DfTLj=XLo44gj9R9QN7iRv=cHGAw@mail.gmail.com>
Message-ID: <40cd4c5a-57eb-18de-0e18-d20cdfa416bd@oracle.com>

Hi all,

Please review the patch below. I'm sending this for review because it's expanded 
considerably beyond the original patch that Christoph had submitted. I ran a 
full-text search over the java.base source files looking for "the the" and "a a" 
and it found a bunch of additional occurrences that were split across line 
breaks. I also fixed up a few other places that I happened to notice.

Christoph wrote:
> I wasn't sure about the capitalization change on EventObject. What's the
> rule of thumb in cases where the class does not follow the guidelines for
> docs[1]? Sticking to the overall class scheme or aligning everything?

Good question. The first rule of styling is to stick with the prevailing style 
in the file. In this case, changing just the text of that one @return tag would 
have conflicted with the style in use in the rest of the file, even though that 
style is arguably incorrect; the rest of the file uses an initial capital and 
ends the description with a period (full stop), whereas the recommended style is 
to use a noun phrase (a sentence fragment), without an initial capital, and 
without a trailing period (since there is no sentence following).

However, the file is small, and there were only three or four other places that 
needed to be changed in order to bring the file into compliance with the 
preferred style, so I just fixed them all.


Thanks,

s'marks



# HG changeset patch
# User smarks
# Date 1509409127 25200
#      Mon Oct 30 17:18:47 2017 -0700
# Node ID d2823a0c8dfab9e95e5c482794a96864b2592aad
# Parent  d87f89c74f54873f273c4fbd8e6d49d7cbf3930b
8190382: fix small typographic errors in comments
Reviewed-by: XXX
Contributed-by: christoph.dreis at freenet.de

diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/io/FilePermission.java
--- a/src/java.base/share/classes/java/io/FilePermission.java	Mon Oct 30 
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/io/FilePermission.java	Mon Oct 30 
17:18:47 2017 -0700
@@ -698,7 +698,7 @@
              if (p2.equals(EMPTY_PATH)) {
                  return 0;
              } else if (p2.getName(0).equals(DOTDOT_PATH)) {
-                // "." contains p2 iif p2 has no "..". Since a
+                // "." contains p2 iff p2 has no "..". Since
                  // a normalized path can only have 0 or more
                  // ".." at the beginning. We only need to look
                  // at the head.
@@ -711,7 +711,7 @@
          } else if (p2.equals(EMPTY_PATH)) {
              int c1 = p1.getNameCount();
              if (!p1.getName(c1 - 1).equals(DOTDOT_PATH)) {
-                // "." is inside p1 iif p1 is 1 or more "..".
+                // "." is inside p1 iff p1 is 1 or more "..".
                  // For the same reason above, we only need to
                  // look at the tail.
                  return -1;
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/lang/invoke/MethodHandle.java
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandle.java	Mon Oct 30 
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandle.java	Mon Oct 30 
17:18:47 2017 -0700
@@ -765,7 +765,7 @@
       * In every other case, all conversions are applied <em>pairwise</em>,
       * which means that each argument or return value is converted to
       * exactly one argument or return value (or no return value).
-     * The applied conversions are defined by consulting the
+     * The applied conversions are defined by consulting
       * the corresponding component types of the old and new
       * method handle types.
       * <p>
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
--- a/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java	Mon 
Oct 30 07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java	Mon 
Oct 30 17:18:47 2017 -0700
@@ -194,7 +194,7 @@
      static {
          // In case we need to double-back onto the StringConcatFactory during this
          // static initialization, make sure we have the reasonable defaults to 
complete
-        // the static initialization properly. After that, actual users would 
use the
+        // the static initialization properly. After that, actual users would use
          // the proper values we have read from the properties.
          STRATEGY = DEFAULT_STRATEGY;
          // CACHE_ENABLE = false; // implied
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/lang/invoke/VarHandle.java
--- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java	Mon Oct 30 
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java	Mon Oct 30 
17:18:47 2017 -0700
@@ -205,7 +205,7 @@
   * and {@code double} on 32-bit platforms.
   *
   * <p>Access modes will override any memory ordering effects specified at
- * the declaration site of a variable.  For example, a VarHandle accessing a
+ * the declaration site of a variable.  For example, a VarHandle accessing
   * a field using the {@code get} access mode will access the field as
   * specified <em>by its access mode</em> even if that field is declared
   * {@code volatile}.  When mixed access is performed extreme care should be
@@ -423,7 +423,7 @@
   * {@link java.lang.invoke.MethodHandles#varHandleInvoker}.
   *
   * <h1>Interoperation between VarHandles and Java generics</h1>
- * A VarHandle can be obtained for a variable, such as a a field, which is
+ * A VarHandle can be obtained for a variable, such as a field, which is
   * declared with Java generic types.  As with the Core Reflection API, the
   * VarHandle's variable type will be constructed from the erasure of the
   * source-level type.  When a VarHandle access mode method is invoked, the
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/net/DatagramSocket.java
--- a/src/java.base/share/classes/java/net/DatagramSocket.java	Mon Oct 30 
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/net/DatagramSocket.java	Mon Oct 30 
17:18:47 2017 -0700
@@ -988,7 +988,7 @@

      /**
       * Sets the SO_RCVBUF option to the specified value for this
-     * {@code DatagramSocket}. The SO_RCVBUF option is used by the
+     * {@code DatagramSocket}. The SO_RCVBUF option is used by
       * the network implementation as a hint to size the underlying
       * network I/O buffers. The SO_RCVBUF setting may also be used
       * by the network implementation to determine the maximum size
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/net/Inet4Address.java
--- a/src/java.base/share/classes/java/net/Inet4Address.java	Mon Oct 30 07:06:49 
2017 -0700
+++ b/src/java.base/share/classes/java/net/Inet4Address.java	Mon Oct 30 17:18:47 
2017 -0700
@@ -143,7 +143,7 @@
          /**
           * Prior to 1.4 an InetAddress was created with a family
           * based on the platform AF_INET value (usually 2).
-         * For compatibility reasons we must therefore write the
+         * For compatibility reasons we must therefore write
           * the InetAddress with this family.
           */
          inet.holder().family = 2;
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/net/SocketImpl.java
--- a/src/java.base/share/classes/java/net/SocketImpl.java	Mon Oct 30 07:06:49 
2017 -0700
+++ b/src/java.base/share/classes/java/net/SocketImpl.java	Mon Oct 30 17:18:47 
2017 -0700
@@ -333,7 +333,7 @@
       * latency, and low latency above short connection time, then it could
       * invoke this method with the values {@code (0, 1, 2)}.
       *
-     * By default, this method does nothing, unless it is overridden in a
+     * By default, this method does nothing, unless it is overridden in
       * a sub-class.
       *
       * @param  connectionTime
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/net/SocksSocketImpl.java
--- a/src/java.base/share/classes/java/net/SocksSocketImpl.java	Mon Oct 30 
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/net/SocksSocketImpl.java	Mon Oct 30 
17:18:47 2017 -0700
@@ -657,7 +657,7 @@

      /**
       * Sends the Bind request to the SOCKS proxy. In the SOCKS protocol, bind
-     * means "accept incoming connection from", so the SocketAddress is the
+     * means "accept incoming connection from", so the SocketAddress is
       * the one of the host we do accept connection from.
       *
       * @param      saddr   the Socket address of the remote host.
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/net/URLConnection.java
--- a/src/java.base/share/classes/java/net/URLConnection.java	Mon Oct 30 
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/net/URLConnection.java	Mon Oct 30 
17:18:47 2017 -0700
@@ -785,7 +785,7 @@
       * required to make the connection. By default, this method
       * returns {@code java.security.AllPermission}. Subclasses
       * should override this method and return the permission
-     * that best represents the permission required to make a
+     * that best represents the permission required to make
       * a connection to the URL. For example, a {@code URLConnection}
       * representing a {@code file:} URL would return a
       * {@code java.io.FilePermission} object.
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java
--- a/src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java 
Mon Oct 30 07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java 
Mon Oct 30 17:18:47 2017 -0700
@@ -165,7 +165,7 @@
       * <tr>
       *   <th scope="row" > {@link StandardOpenOption#DELETE_ON_CLOSE 
DELETE_ON_CLOSE} </th>
       *   <td> When this option is present then the implementation makes a
-     *   <em>best effort</em> attempt to delete the file when closed by the
+     *   <em>best effort</em> attempt to delete the file when closed by
       *   the {@link #close close} method. If the {@code close} method is not
       *   invoked then a <em>best effort</em> attempt is made to delete the file
       *   when the Java virtual machine terminates. </td>
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/nio/channels/FileChannel.java
--- a/src/java.base/share/classes/java/nio/channels/FileChannel.java	Mon Oct 30 
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/nio/channels/FileChannel.java	Mon Oct 30 
17:18:47 2017 -0700
@@ -216,7 +216,7 @@
       * <tr>
       *   <th scope="row" > {@link StandardOpenOption#DELETE_ON_CLOSE 
DELETE_ON_CLOSE} </th>
       *   <td> When this option is present then the implementation makes a
-     *   <em>best effort</em> attempt to delete the file when closed by the
+     *   <em>best effort</em> attempt to delete the file when closed by
       *   the {@link #close close} method. If the {@code close} method is not
       *   invoked then a <em>best effort</em> attempt is made to delete the file
       *   when the Java virtual machine terminates. </td>
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/nio/file/Files.java
--- a/src/java.base/share/classes/java/nio/file/Files.java	Mon Oct 30 07:06:49 
2017 -0700
+++ b/src/java.base/share/classes/java/nio/file/Files.java	Mon Oct 30 17:18:47 
2017 -0700
@@ -3301,7 +3301,7 @@
      }

      /**
-     * Writes bytes to a file. The {@code options} parameter specifies how the
+     * Writes bytes to a file. The {@code options} parameter specifies how
       * the file is created or opened. If no options are present then this method
       * works as if the {@link StandardOpenOption#CREATE CREATE}, {@link
       * StandardOpenOption#TRUNCATE_EXISTING TRUNCATE_EXISTING}, and {@link
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/security/KeyPairGenerator.java
--- a/src/java.base/share/classes/java/security/KeyPairGenerator.java	Mon Oct 30 
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/security/KeyPairGenerator.java	Mon Oct 30 
17:18:47 2017 -0700
@@ -84,7 +84,7 @@
   * exists (e.g., so-called <i>community parameters</i> in DSA), there are two
   * {@link #initialize(java.security.spec.AlgorithmParameterSpec)
   * initialize} methods that have an {@code AlgorithmParameterSpec}
- * argument. One also has a {@code SecureRandom} argument, while the
+ * argument. One also has a {@code SecureRandom} argument, while
   * the other uses the {@code SecureRandom}
   * implementation of the highest-priority installed provider as the source
   * of randomness. (If none of the installed providers supply an implementation
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
--- a/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java 
Mon Oct 30 07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java 
Mon Oct 30 17:18:47 2017 -0700
@@ -4775,7 +4775,7 @@
      //-----------------------------------------------------------------------
      /**
       * Prints or parses a localized pattern from a localized field.
-     * The specific formatter and parameters is not selected until the
+     * The specific formatter and parameters is not selected until
       * the field is to be printed or parsed.
       * The locale is needed to select the proper WeekFields from which
       * the field for day-of-week, week-of-month, or week-of-year is selected.
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/time/temporal/WeekFields.java
--- a/src/java.base/share/classes/java/time/temporal/WeekFields.java	Mon Oct 30 
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/time/temporal/WeekFields.java	Mon Oct 30 
17:18:47 2017 -0700
@@ -311,7 +311,7 @@
       * the new month or year.
       * <p>
       * WeekFields instances are singletons; for each unique combination
-     * of {@code firstDayOfWeek} and {@code minimalDaysInFirstWeek} the
+     * of {@code firstDayOfWeek} and {@code minimalDaysInFirstWeek}
       * the same instance will be returned.
       *
       * @param firstDayOfWeek  the first day of the week, not null
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/util/Base64.java
--- a/src/java.base/share/classes/java/util/Base64.java	Mon Oct 30 07:06:49 2017 
-0700
+++ b/src/java.base/share/classes/java/util/Base64.java	Mon Oct 30 17:18:47 2017 
-0700
@@ -56,7 +56,7 @@
   *     base64 alphabet.</p></li>
   *
   * <li><a id="mime"><b>MIME</b></a>
- * <p> Uses the "The Base64 Alphabet" as specified in Table 1 of
+ * <p> Uses "The Base64 Alphabet" as specified in Table 1 of
   *     RFC 2045 for encoding and decoding operation. The encoded output
   *     must be represented in lines of no more than 76 characters each
   *     and uses a carriage return {@code '\r'} followed immediately by
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/util/EventObject.java
--- a/src/java.base/share/classes/java/util/EventObject.java	Mon Oct 30 07:06:49 
2017 -0700
+++ b/src/java.base/share/classes/java/util/EventObject.java	Mon Oct 30 17:18:47 
2017 -0700
@@ -43,13 +43,13 @@
      /**
       * The object on which the Event initially occurred.
       */
-    protected transient Object  source;
+    protected transient Object source;

      /**
       * Constructs a prototypical Event.
       *
-     * @param    source    The object on which the Event initially occurred.
-     * @exception  IllegalArgumentException  if source is null.
+     * @param source the object on which the Event initially occurred
+     * @throws IllegalArgumentException if source is null
       */
      public EventObject(Object source) {
          if (source == null)
@@ -61,7 +61,7 @@
      /**
       * The object on which the Event initially occurred.
       *
-     * @return   The object on which the Event initially occurred.
+     * @return the object on which the Event initially occurred
       */
      public Object getSource() {
          return source;
@@ -70,7 +70,7 @@
      /**
       * Returns a String representation of this EventObject.
       *
-     * @return  A a String representation of this EventObject.
+     * @return a String representation of this EventObject
       */
      public String toString() {
          return getClass().getName() + "[source=" + source + "]";
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/util/FormattableFlags.java
--- a/src/java.base/share/classes/java/util/FormattableFlags.java	Mon Oct 30 
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/util/FormattableFlags.java	Mon Oct 30 
17:18:47 2017 -0700
@@ -26,7 +26,7 @@
  package java.util;

  /**
- * FomattableFlags are passed to the {@link Formattable#formatTo
+ * FormattableFlags are passed to the {@link Formattable#formatTo
   * Formattable.formatTo()} method and modify the output format for {@linkplain
   * Formattable Formattables}.  Implementations of {@link Formattable} are
   * responsible for interpreting and validating any flags.
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/java/util/ResourceBundle.java
--- a/src/java.base/share/classes/java/util/ResourceBundle.java	Mon Oct 30 
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/java/util/ResourceBundle.java	Mon Oct 30 
17:18:47 2017 -0700
@@ -2743,7 +2743,7 @@
           * of multiple subtags separated by underscore, generate candidate
           * <code>Locale</code>s by omitting the variant subtags one by one, then
           * insert them after every occurrence of <code> Locale</code>s with the
-         * full variant value in the original list.  For example, if the
+         * full variant value in the original list.  For example, if
           * the variant consists of two subtags <em>V1</em> and <em>V2</em>:
           *
           * <ul>
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java
--- a/src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java	Mon 
Oct 30 07:06:49 2017 -0700
+++ b/src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java	Mon 
Oct 30 17:18:47 2017 -0700
@@ -238,7 +238,7 @@
      // This way we could simply do things like:
      //    push((logger) -> logger.log(level, msg));
      // Unfortunately, if we come to here it means we are in the bootsraping
-    // phase where using lambdas is not safe yet - so we have to use a
+    // phase where using lambdas is not safe yet - so we have to use
      // a data object instead...
      //
      static final class LogEvent {
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
--- 
a/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java 
Mon Oct 30 07:06:49 2017 -0700
+++ 
b/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java 
Mon Oct 30 17:18:47 2017 -0700
@@ -2888,7 +2888,7 @@
              /*
               * If we have an input stream this means we received a response
               * from the server. That stream may have been read to EOF and
-             * dependening on the stream type may already be closed or the
+             * depending on the stream type may already be closed or
               * the http client may be returned to the keep-alive cache.
               * If the http client has been returned to the keep-alive cache
               * it may be closed (idle timeout) or may be allocated to
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
--- 
a/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
Mon Oct 30 07:06:49 2017 -0700
+++ 
b/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
Mon Oct 30 17:18:47 2017 -0700
@@ -66,7 +66,7 @@
      /**
       * Static factory. Given a (generic) class, actual type arguments
       * and an owner type, creates a parameterized type.
-     * This class can be instantiated with a a raw type that does not
+     * This class can be instantiated with a raw type that does not
       * represent a generic type, provided the list of actual type
       * arguments is empty.
       * If the ownerType argument is null, the declaring class of the
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java
--- a/src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java	Mon 
Oct 30 07:06:49 2017 -0700
+++ b/src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java	Mon 
Oct 30 17:18:47 2017 -0700
@@ -411,7 +411,7 @@
                          certs = null;
                      }

-                    // only add if we had no signer or we had a
+                    // only add if we had no signer or we had
                      // a signer and found the keys for it.
                      if (certs != null || pe.signedBy == null) {
                              Permission perm = new UnresolvedPermission(
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/sun/security/provider/PolicyFile.java
--- a/src/java.base/share/classes/sun/security/provider/PolicyFile.java	Mon Oct 
30 07:06:49 2017 -0700
+++ b/src/java.base/share/classes/sun/security/provider/PolicyFile.java	Mon Oct 
30 17:18:47 2017 -0700
@@ -789,7 +789,7 @@
                          certs = null;
                      }

-                    // only add if we had no signer or we had a
+                    // only add if we had no signer or we had
                      // a signer and found the keys for it.
                      if (certs != null || pe.signedBy == null) {
                          Permission perm = new UnresolvedPermission(
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java
--- a/src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java 
Mon Oct 30 07:06:49 2017 -0700
+++ b/src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java 
Mon Oct 30 17:18:47 2017 -0700
@@ -154,7 +154,7 @@
       *
       * @param codesource the <code>CodeSource</code> to compare against.
       *
-     * @return true if this <code>SubjectCodeSource</code> implies the
+     * @return true if this <code>SubjectCodeSource</code> implies
       *          the specified <code>CodeSource</code>.
       */
      public boolean implies(CodeSource codesource) {
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java
--- a/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java	Mon Oct 
30 07:06:49 2017 -0700
+++ b/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java	Mon Oct 
30 17:18:47 2017 -0700
@@ -539,7 +539,7 @@

                  // Should be repacked for suitable fragment length.
                  //
-                // Note that the acquiring processes will reassemble the
+                // Note that the acquiring processes will reassemble
                  // the fragments later.
                  return compareToSequence(o.recordEpoch, o.recordSeq);
              }
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/sun/security/x509/X509CertImpl.java
--- a/src/java.base/share/classes/sun/security/x509/X509CertImpl.java	Mon Oct 30 
07:06:49 2017 -0700
+++ b/src/java.base/share/classes/sun/security/x509/X509CertImpl.java	Mon Oct 30 
17:18:47 2017 -0700
@@ -1485,7 +1485,7 @@
      }

      /**
-     * Get the certificate constraints path length from the
+     * Get the certificate constraints path length from
       * the critical BasicConstraints extension, (oid = 2.5.29.19).
       * @return the length of the constraint.
       */
diff -r d87f89c74f54 -r d2823a0c8dfa 
src/java.base/share/classes/sun/util/logging/PlatformLogger.java
--- a/src/java.base/share/classes/sun/util/logging/PlatformLogger.java	Mon Oct 
30 07:06:49 2017 -0700
+++ b/src/java.base/share/classes/sun/util/logging/PlatformLogger.java	Mon Oct 
30 17:18:47 2017 -0700
@@ -45,7 +45,7 @@
   *
   * If the logging facility is not enabled, the platform loggers
   * will output log messages per the default logging configuration
- * (see below). In this implementation, it does not log the
+ * (see below). In this implementation, it does not log
   * the stack frame information issuing the log message.
   *
   * When the logging facility is enabled (at startup or runtime),


From martinrb at google.com  Tue Oct 31 00:38:50 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 30 Oct 2017 17:38:50 -0700
Subject: [Bug][JDK10] Fix duplicated "a" occurrences in docs
In-Reply-To: <40cd4c5a-57eb-18de-0e18-d20cdfa416bd@oracle.com>
References: <007701d35197$f6440200$e2cc0600$@freenet.de>
 <CA+kOe09K04HdXYJ1Vca3g7DfTLj=XLo44gj9R9QN7iRv=cHGAw@mail.gmail.com>
 <40cd4c5a-57eb-18de-0e18-d20cdfa416bd@oracle.com>
Message-ID: <CA+kOe0_skmFEzH+OSSKRgOF+Yh5ohrMasCGG2ecob3YfA9MjDQ@mail.gmail.com>

Looks good!

On Mon, Oct 30, 2017 at 5:29 PM, Stuart Marks <stuart.marks at oracle.com>
wrote:

> Hi all,
>
> Please review the patch below. I'm sending this for review because it's
> expanded considerably beyond the original patch that Christoph had
> submitted. I ran a full-text search over the java.base source files looking
> for "the the" and "a a" and it found a bunch of additional occurrences that
> were split across line breaks. I also fixed up a few other places that I
> happened to notice.
>
> Christoph wrote:
>
>> I wasn't sure about the capitalization change on EventObject. What's the
>> rule of thumb in cases where the class does not follow the guidelines for
>> docs[1]? Sticking to the overall class scheme or aligning everything?
>>
>
> Good question. The first rule of styling is to stick with the prevailing
> style in the file. In this case, changing just the text of that one @return
> tag would have conflicted with the style in use in the rest of the file,
> even though that style is arguably incorrect; the rest of the file uses an
> initial capital and ends the description with a period (full stop), whereas
> the recommended style is to use a noun phrase (a sentence fragment),
> without an initial capital, and without a trailing period (since there is
> no sentence following).
>
> However, the file is small, and there were only three or four other places
> that needed to be changed in order to bring the file into compliance with
> the preferred style, so I just fixed them all.
>
>
> Thanks,
>
> s'marks
>
>
>
> # HG changeset patch
> # User smarks
> # Date 1509409127 25200
> #      Mon Oct 30 17:18:47 2017 -0700
> # Node ID d2823a0c8dfab9e95e5c482794a96864b2592aad
> # Parent  d87f89c74f54873f273c4fbd8e6d49d7cbf3930b
> 8190382: fix small typographic errors in comments
> Reviewed-by: XXX
> Contributed-by: christoph.dreis at freenet.de
>
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/io/FilePermission.java
> --- a/src/java.base/share/classes/java/io/FilePermission.java   Mon Oct
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/io/FilePermission.java   Mon Oct
> 30 17:18:47 2017 -0700
> @@ -698,7 +698,7 @@
>              if (p2.equals(EMPTY_PATH)) {
>                  return 0;
>              } else if (p2.getName(0).equals(DOTDOT_PATH)) {
> -                // "." contains p2 iif p2 has no "..". Since a
> +                // "." contains p2 iff p2 has no "..". Since
>                  // a normalized path can only have 0 or more
>                  // ".." at the beginning. We only need to look
>                  // at the head.
> @@ -711,7 +711,7 @@
>          } else if (p2.equals(EMPTY_PATH)) {
>              int c1 = p1.getNameCount();
>              if (!p1.getName(c1 - 1).equals(DOTDOT_PATH)) {
> -                // "." is inside p1 iif p1 is 1 or more "..".
> +                // "." is inside p1 iff p1 is 1 or more "..".
>                  // For the same reason above, we only need to
>                  // look at the tail.
>                  return -1;
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/lang/invoke/MethodHandle.java
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandle.java
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandle.java
> Mon Oct 30 17:18:47 2017 -0700
> @@ -765,7 +765,7 @@
>       * In every other case, all conversions are applied <em>pairwise</em>,
>       * which means that each argument or return value is converted to
>       * exactly one argument or return value (or no return value).
> -     * The applied conversions are defined by consulting the
> +     * The applied conversions are defined by consulting
>       * the corresponding component types of the old and new
>       * method handle types.
>       * <p>
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/lang/invoke/StringConcatFactory.java
> --- a/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>    Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>    Mon Oct 30 17:18:47 2017 -0700
> @@ -194,7 +194,7 @@
>      static {
>          // In case we need to double-back onto the StringConcatFactory
> during this
>          // static initialization, make sure we have the reasonable
> defaults to complete
> -        // the static initialization properly. After that, actual users
> would use the
> +        // the static initialization properly. After that, actual users
> would use
>          // the proper values we have read from the properties.
>          STRATEGY = DEFAULT_STRATEGY;
>          // CACHE_ENABLE = false; // implied
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/lang/invoke/VarHandle.java
> --- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java
>  Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java
>  Mon Oct 30 17:18:47 2017 -0700
> @@ -205,7 +205,7 @@
>   * and {@code double} on 32-bit platforms.
>   *
>   * <p>Access modes will override any memory ordering effects specified at
> - * the declaration site of a variable.  For example, a VarHandle
> accessing a
> + * the declaration site of a variable.  For example, a VarHandle accessing
>   * a field using the {@code get} access mode will access the field as
>   * specified <em>by its access mode</em> even if that field is declared
>   * {@code volatile}.  When mixed access is performed extreme care should
> be
> @@ -423,7 +423,7 @@
>   * {@link java.lang.invoke.MethodHandles#varHandleInvoker}.
>   *
>   * <h1>Interoperation between VarHandles and Java generics</h1>
> - * A VarHandle can be obtained for a variable, such as a a field, which is
> + * A VarHandle can be obtained for a variable, such as a field, which is
>   * declared with Java generic types.  As with the Core Reflection API, the
>   * VarHandle's variable type will be constructed from the erasure of the
>   * source-level type.  When a VarHandle access mode method is invoked, the
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/net/DatagramSocket.java
> --- a/src/java.base/share/classes/java/net/DatagramSocket.java  Mon Oct
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/DatagramSocket.java  Mon Oct
> 30 17:18:47 2017 -0700
> @@ -988,7 +988,7 @@
>
>      /**
>       * Sets the SO_RCVBUF option to the specified value for this
> -     * {@code DatagramSocket}. The SO_RCVBUF option is used by the
> +     * {@code DatagramSocket}. The SO_RCVBUF option is used by
>       * the network implementation as a hint to size the underlying
>       * network I/O buffers. The SO_RCVBUF setting may also be used
>       * by the network implementation to determine the maximum size
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/net/Inet4Address.java
> --- a/src/java.base/share/classes/java/net/Inet4Address.java    Mon Oct
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/Inet4Address.java    Mon Oct
> 30 17:18:47 2017 -0700
> @@ -143,7 +143,7 @@
>          /**
>           * Prior to 1.4 an InetAddress was created with a family
>           * based on the platform AF_INET value (usually 2).
> -         * For compatibility reasons we must therefore write the
> +         * For compatibility reasons we must therefore write
>           * the InetAddress with this family.
>           */
>          inet.holder().family = 2;
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/net/SocketImpl.java
> --- a/src/java.base/share/classes/java/net/SocketImpl.java      Mon Oct
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/SocketImpl.java      Mon Oct
> 30 17:18:47 2017 -0700
> @@ -333,7 +333,7 @@
>       * latency, and low latency above short connection time, then it could
>       * invoke this method with the values {@code (0, 1, 2)}.
>       *
> -     * By default, this method does nothing, unless it is overridden in a
> +     * By default, this method does nothing, unless it is overridden in
>       * a sub-class.
>       *
>       * @param  connectionTime
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/net/SocksSocketImpl.java
> --- a/src/java.base/share/classes/java/net/SocksSocketImpl.java Mon Oct
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/SocksSocketImpl.java Mon Oct
> 30 17:18:47 2017 -0700
> @@ -657,7 +657,7 @@
>
>      /**
>       * Sends the Bind request to the SOCKS proxy. In the SOCKS protocol,
> bind
> -     * means "accept incoming connection from", so the SocketAddress is
> the
> +     * means "accept incoming connection from", so the SocketAddress is
>       * the one of the host we do accept connection from.
>       *
>       * @param      saddr   the Socket address of the remote host.
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/net/URLConnection.java
> --- a/src/java.base/share/classes/java/net/URLConnection.java   Mon Oct
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/URLConnection.java   Mon Oct
> 30 17:18:47 2017 -0700
> @@ -785,7 +785,7 @@
>       * required to make the connection. By default, this method
>       * returns {@code java.security.AllPermission}. Subclasses
>       * should override this method and return the permission
> -     * that best represents the permission required to make a
> +     * that best represents the permission required to make
>       * a connection to the URL. For example, a {@code URLConnection}
>       * representing a {@code file:} URL would return a
>       * {@code java.io.FilePermission} object.
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/nio/channels/AsynchronousFileChannel.java
> --- a/src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java
> Mon Oct 30 17:18:47 2017 -0700
> @@ -165,7 +165,7 @@
>       * <tr>
>       *   <th scope="row" > {@link StandardOpenOption#DELETE_ON_CLOSE
> DELETE_ON_CLOSE} </th>
>       *   <td> When this option is present then the implementation makes a
> -     *   <em>best effort</em> attempt to delete the file when closed by
> the
> +     *   <em>best effort</em> attempt to delete the file when closed by
>       *   the {@link #close close} method. If the {@code close} method is
> not
>       *   invoked then a <em>best effort</em> attempt is made to delete
> the file
>       *   when the Java virtual machine terminates. </td>
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/nio/channels/FileChannel.java
> --- a/src/java.base/share/classes/java/nio/channels/FileChannel.java
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/nio/channels/FileChannel.java
> Mon Oct 30 17:18:47 2017 -0700
> @@ -216,7 +216,7 @@
>       * <tr>
>       *   <th scope="row" > {@link StandardOpenOption#DELETE_ON_CLOSE
> DELETE_ON_CLOSE} </th>
>       *   <td> When this option is present then the implementation makes a
> -     *   <em>best effort</em> attempt to delete the file when closed by
> the
> +     *   <em>best effort</em> attempt to delete the file when closed by
>       *   the {@link #close close} method. If the {@code close} method is
> not
>       *   invoked then a <em>best effort</em> attempt is made to delete
> the file
>       *   when the Java virtual machine terminates. </td>
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/nio/file/Files.java
> --- a/src/java.base/share/classes/java/nio/file/Files.java      Mon Oct
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/nio/file/Files.java      Mon Oct
> 30 17:18:47 2017 -0700
> @@ -3301,7 +3301,7 @@
>      }
>
>      /**
> -     * Writes bytes to a file. The {@code options} parameter specifies
> how the
> +     * Writes bytes to a file. The {@code options} parameter specifies how
>       * the file is created or opened. If no options are present then this
> method
>       * works as if the {@link StandardOpenOption#CREATE CREATE}, {@link
>       * StandardOpenOption#TRUNCATE_EXISTING TRUNCATE_EXISTING}, and
> {@link
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/security/KeyPairGenerator.java
> --- a/src/java.base/share/classes/java/security/KeyPairGenerator.java
>  Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/security/KeyPairGenerator.java
>  Mon Oct 30 17:18:47 2017 -0700
> @@ -84,7 +84,7 @@
>   * exists (e.g., so-called <i>community parameters</i> in DSA), there are
> two
>   * {@link #initialize(java.security.spec.AlgorithmParameterSpec)
>   * initialize} methods that have an {@code AlgorithmParameterSpec}
> - * argument. One also has a {@code SecureRandom} argument, while the
> + * argument. One also has a {@code SecureRandom} argument, while
>   * the other uses the {@code SecureRandom}
>   * implementation of the highest-priority installed provider as the source
>   * of randomness. (If none of the installed providers supply an
> implementation
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/time/format/DateTimeFormatterBuilder.java
> --- a/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
> Mon Oct 30 17:18:47 2017 -0700
> @@ -4775,7 +4775,7 @@
>      //---------------------------------------------------------
> --------------
>      /**
>       * Prints or parses a localized pattern from a localized field.
> -     * The specific formatter and parameters is not selected until the
> +     * The specific formatter and parameters is not selected until
>       * the field is to be printed or parsed.
>       * The locale is needed to select the proper WeekFields from which
>       * the field for day-of-week, week-of-month, or week-of-year is
> selected.
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/time/temporal/WeekFields.java
> --- a/src/java.base/share/classes/java/time/temporal/WeekFields.java
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/time/temporal/WeekFields.java
> Mon Oct 30 17:18:47 2017 -0700
> @@ -311,7 +311,7 @@
>       * the new month or year.
>       * <p>
>       * WeekFields instances are singletons; for each unique combination
> -     * of {@code firstDayOfWeek} and {@code minimalDaysInFirstWeek} the
> +     * of {@code firstDayOfWeek} and {@code minimalDaysInFirstWeek}
>       * the same instance will be returned.
>       *
>       * @param firstDayOfWeek  the first day of the week, not null
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/util/Base64.java
> --- a/src/java.base/share/classes/java/util/Base64.java Mon Oct 30
> 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/Base64.java Mon Oct 30
> 17:18:47 2017 -0700
> @@ -56,7 +56,7 @@
>   *     base64 alphabet.</p></li>
>   *
>   * <li><a id="mime"><b>MIME</b></a>
> - * <p> Uses the "The Base64 Alphabet" as specified in Table 1 of
> + * <p> Uses "The Base64 Alphabet" as specified in Table 1 of
>   *     RFC 2045 for encoding and decoding operation. The encoded output
>   *     must be represented in lines of no more than 76 characters each
>   *     and uses a carriage return {@code '\r'} followed immediately by
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/util/EventObject.java
> --- a/src/java.base/share/classes/java/util/EventObject.java    Mon Oct
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/EventObject.java    Mon Oct
> 30 17:18:47 2017 -0700
> @@ -43,13 +43,13 @@
>      /**
>       * The object on which the Event initially occurred.
>       */
> -    protected transient Object  source;
> +    protected transient Object source;
>
>      /**
>       * Constructs a prototypical Event.
>       *
> -     * @param    source    The object on which the Event initially
> occurred.
> -     * @exception  IllegalArgumentException  if source is null.
> +     * @param source the object on which the Event initially occurred
> +     * @throws IllegalArgumentException if source is null
>       */
>      public EventObject(Object source) {
>          if (source == null)
> @@ -61,7 +61,7 @@
>      /**
>       * The object on which the Event initially occurred.
>       *
> -     * @return   The object on which the Event initially occurred.
> +     * @return the object on which the Event initially occurred
>       */
>      public Object getSource() {
>          return source;
> @@ -70,7 +70,7 @@
>      /**
>       * Returns a String representation of this EventObject.
>       *
> -     * @return  A a String representation of this EventObject.
> +     * @return a String representation of this EventObject
>       */
>      public String toString() {
>          return getClass().getName() + "[source=" + source + "]";
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/util/FormattableFlags.java
> --- a/src/java.base/share/classes/java/util/FormattableFlags.java
>  Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/FormattableFlags.java
>  Mon Oct 30 17:18:47 2017 -0700
> @@ -26,7 +26,7 @@
>  package java.util;
>
>  /**
> - * FomattableFlags are passed to the {@link Formattable#formatTo
> + * FormattableFlags are passed to the {@link Formattable#formatTo
>   * Formattable.formatTo()} method and modify the output format for
> {@linkplain
>   * Formattable Formattables}.  Implementations of {@link Formattable} are
>   * responsible for interpreting and validating any flags.
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/ja
> va/util/ResourceBundle.java
> --- a/src/java.base/share/classes/java/util/ResourceBundle.java Mon Oct
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java Mon Oct
> 30 17:18:47 2017 -0700
> @@ -2743,7 +2743,7 @@
>           * of multiple subtags separated by underscore, generate candidate
>           * <code>Locale</code>s by omitting the variant subtags one by
> one, then
>           * insert them after every occurrence of <code> Locale</code>s
> with the
> -         * full variant value in the original list.  For example, if the
> +         * full variant value in the original list.  For example, if
>           * the variant consists of two subtags <em>V1</em> and
> <em>V2</em>:
>           *
>           * <ul>
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/jd
> k/internal/logger/BootstrapLogger.java
> --- a/src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java
>     Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java
>     Mon Oct 30 17:18:47 2017 -0700
> @@ -238,7 +238,7 @@
>      // This way we could simply do things like:
>      //    push((logger) -> logger.log(level, msg));
>      // Unfortunately, if we come to here it means we are in the
> bootsraping
> -    // phase where using lambdas is not safe yet - so we have to use a
> +    // phase where using lambdas is not safe yet - so we have to use
>      // a data object instead...
>      //
>      static final class LogEvent {
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/su
> n/net/www/protocol/http/HttpURLConnection.java
> --- a/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
> Mon Oct 30 17:18:47 2017 -0700
> @@ -2888,7 +2888,7 @@
>              /*
>               * If we have an input stream this means we received a
> response
>               * from the server. That stream may have been read to EOF and
> -             * dependening on the stream type may already be closed or the
> +             * depending on the stream type may already be closed or
>               * the http client may be returned to the keep-alive cache.
>               * If the http client has been returned to the keep-alive
> cache
>               * it may be closed (idle timeout) or may be allocated to
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/su
> n/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
> --- a/src/java.base/share/classes/sun/reflect/generics/reflectiv
> eObjects/ParameterizedTypeImpl.java Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/reflect/generics/reflectiv
> eObjects/ParameterizedTypeImpl.java Mon Oct 30 17:18:47 2017 -0700
> @@ -66,7 +66,7 @@
>      /**
>       * Static factory. Given a (generic) class, actual type arguments
>       * and an owner type, creates a parameterized type.
> -     * This class can be instantiated with a a raw type that does not
> +     * This class can be instantiated with a raw type that does not
>       * represent a generic type, provided the list of actual type
>       * arguments is empty.
>       * If the ownerType argument is null, the declaring class of the
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/su
> n/security/provider/AuthPolicyFile.java
> --- a/src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java
>    Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java
>    Mon Oct 30 17:18:47 2017 -0700
> @@ -411,7 +411,7 @@
>                          certs = null;
>                      }
>
> -                    // only add if we had no signer or we had a
> +                    // only add if we had no signer or we had
>                      // a signer and found the keys for it.
>                      if (certs != null || pe.signedBy == null) {
>                              Permission perm = new UnresolvedPermission(
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/su
> n/security/provider/PolicyFile.java
> --- a/src/java.base/share/classes/sun/security/provider/PolicyFile.java
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/provider/PolicyFile.java
> Mon Oct 30 17:18:47 2017 -0700
> @@ -789,7 +789,7 @@
>                          certs = null;
>                      }
>
> -                    // only add if we had no signer or we had a
> +                    // only add if we had no signer or we had
>                      // a signer and found the keys for it.
>                      if (certs != null || pe.signedBy == null) {
>                          Permission perm = new UnresolvedPermission(
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/su
> n/security/provider/SubjectCodeSource.java
> --- a/src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java
> Mon Oct 30 17:18:47 2017 -0700
> @@ -154,7 +154,7 @@
>       *
>       * @param codesource the <code>CodeSource</code> to compare against.
>       *
> -     * @return true if this <code>SubjectCodeSource</code> implies the
> +     * @return true if this <code>SubjectCodeSource</code> implies
>       *          the specified <code>CodeSource</code>.
>       */
>      public boolean implies(CodeSource codesource) {
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/su
> n/security/ssl/DTLSInputRecord.java
> --- a/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java
> Mon Oct 30 17:18:47 2017 -0700
> @@ -539,7 +539,7 @@
>
>                  // Should be repacked for suitable fragment length.
>                  //
> -                // Note that the acquiring processes will reassemble the
> +                // Note that the acquiring processes will reassemble
>                  // the fragments later.
>                  return compareToSequence(o.recordEpoch, o.recordSeq);
>              }
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/su
> n/security/x509/X509CertImpl.java
> --- a/src/java.base/share/classes/sun/security/x509/X509CertImpl.java
>  Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/x509/X509CertImpl.java
>  Mon Oct 30 17:18:47 2017 -0700
> @@ -1485,7 +1485,7 @@
>      }
>
>      /**
> -     * Get the certificate constraints path length from the
> +     * Get the certificate constraints path length from
>       * the critical BasicConstraints extension, (oid = 2.5.29.19).
>       * @return the length of the constraint.
>       */
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/su
> n/util/logging/PlatformLogger.java
> --- a/src/java.base/share/classes/sun/util/logging/PlatformLogger.java
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/util/logging/PlatformLogger.java
> Mon Oct 30 17:18:47 2017 -0700
> @@ -45,7 +45,7 @@
>   *
>   * If the logging facility is not enabled, the platform loggers
>   * will output log messages per the default logging configuration
> - * (see below). In this implementation, it does not log the
> + * (see below). In this implementation, it does not log
>   * the stack frame information issuing the log message.
>   *
>   * When the logging facility is enabled (at startup or runtime),
>
>

From lance.andersen at oracle.com  Tue Oct 31 00:43:06 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 30 Oct 2017 20:43:06 -0400
Subject: [Bug][JDK10] Fix duplicated "a" occurrences in docs
In-Reply-To: <40cd4c5a-57eb-18de-0e18-d20cdfa416bd@oracle.com>
References: <007701d35197$f6440200$e2cc0600$@freenet.de>
 <CA+kOe09K04HdXYJ1Vca3g7DfTLj=XLo44gj9R9QN7iRv=cHGAw@mail.gmail.com>
 <40cd4c5a-57eb-18de-0e18-d20cdfa416bd@oracle.com>
Message-ID: <17A260D8-9DD6-4CD6-AA15-9113A50E96BA@oracle.com>

looks fine Stuart

Best
Lance
> On Oct 30, 2017, at 8:29 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi all,
> 
> Please review the patch below. I'm sending this for review because it's expanded considerably beyond the original patch that Christoph had submitted. I ran a full-text search over the java.base source files looking for "the the" and "a a" and it found a bunch of additional occurrences that were split across line breaks. I also fixed up a few other places that I happened to notice.
> 
> Christoph wrote:
>> I wasn't sure about the capitalization change on EventObject. What's the
>> rule of thumb in cases where the class does not follow the guidelines for
>> docs[1]? Sticking to the overall class scheme or aligning everything?
> 
> Good question. The first rule of styling is to stick with the prevailing style in the file. In this case, changing just the text of that one @return tag would have conflicted with the style in use in the rest of the file, even though that style is arguably incorrect; the rest of the file uses an initial capital and ends the description with a period (full stop), whereas the recommended style is to use a noun phrase (a sentence fragment), without an initial capital, and without a trailing period (since there is no sentence following).
> 
> However, the file is small, and there were only three or four other places that needed to be changed in order to bring the file into compliance with the preferred style, so I just fixed them all.
> 
> 
> Thanks,
> 
> s'marks
> 
> 
> 
> # HG changeset patch
> # User smarks
> # Date 1509409127 25200
> #      Mon Oct 30 17:18:47 2017 -0700
> # Node ID d2823a0c8dfab9e95e5c482794a96864b2592aad
> # Parent  d87f89c74f54873f273c4fbd8e6d49d7cbf3930b
> 8190382: fix small typographic errors in comments
> Reviewed-by: XXX
> Contributed-by: christoph.dreis at freenet.de
> 
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/io/FilePermission.java
> --- a/src/java.base/share/classes/java/io/FilePermission.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/io/FilePermission.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -698,7 +698,7 @@
>             if (p2.equals(EMPTY_PATH)) {
>                 return 0;
>             } else if (p2.getName(0).equals(DOTDOT_PATH)) {
> -                // "." contains p2 iif p2 has no "..". Since a
> +                // "." contains p2 iff p2 has no "..". Since
>                 // a normalized path can only have 0 or more
>                 // ".." at the beginning. We only need to look
>                 // at the head.
> @@ -711,7 +711,7 @@
>         } else if (p2.equals(EMPTY_PATH)) {
>             int c1 = p1.getNameCount();
>             if (!p1.getName(c1 - 1).equals(DOTDOT_PATH)) {
> -                // "." is inside p1 iif p1 is 1 or more "..".
> +                // "." is inside p1 iff p1 is 1 or more "..".
>                 // For the same reason above, we only need to
>                 // look at the tail.
>                 return -1;
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/lang/invoke/MethodHandle.java
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandle.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandle.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -765,7 +765,7 @@
>      * In every other case, all conversions are applied <em>pairwise</em>,
>      * which means that each argument or return value is converted to
>      * exactly one argument or return value (or no return value).
> -     * The applied conversions are defined by consulting the
> +     * The applied conversions are defined by consulting
>      * the corresponding component types of the old and new
>      * method handle types.
>      * <p>
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
> --- a/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -194,7 +194,7 @@
>     static {
>         // In case we need to double-back onto the StringConcatFactory during this
>         // static initialization, make sure we have the reasonable defaults to complete
> -        // the static initialization properly. After that, actual users would use the
> +        // the static initialization properly. After that, actual users would use
>         // the proper values we have read from the properties.
>         STRATEGY = DEFAULT_STRATEGY;
>         // CACHE_ENABLE = false; // implied
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/lang/invoke/VarHandle.java
> --- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -205,7 +205,7 @@
>  * and {@code double} on 32-bit platforms.
>  *
>  * <p>Access modes will override any memory ordering effects specified at
> - * the declaration site of a variable.  For example, a VarHandle accessing a
> + * the declaration site of a variable.  For example, a VarHandle accessing
>  * a field using the {@code get} access mode will access the field as
>  * specified <em>by its access mode</em> even if that field is declared
>  * {@code volatile}.  When mixed access is performed extreme care should be
> @@ -423,7 +423,7 @@
>  * {@link java.lang.invoke.MethodHandles#varHandleInvoker}.
>  *
>  * <h1>Interoperation between VarHandles and Java generics</h1>
> - * A VarHandle can be obtained for a variable, such as a a field, which is
> + * A VarHandle can be obtained for a variable, such as a field, which is
>  * declared with Java generic types.  As with the Core Reflection API, the
>  * VarHandle's variable type will be constructed from the erasure of the
>  * source-level type.  When a VarHandle access mode method is invoked, the
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/net/DatagramSocket.java
> --- a/src/java.base/share/classes/java/net/DatagramSocket.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/DatagramSocket.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -988,7 +988,7 @@
> 
>     /**
>      * Sets the SO_RCVBUF option to the specified value for this
> -     * {@code DatagramSocket}. The SO_RCVBUF option is used by the
> +     * {@code DatagramSocket}. The SO_RCVBUF option is used by
>      * the network implementation as a hint to size the underlying
>      * network I/O buffers. The SO_RCVBUF setting may also be used
>      * by the network implementation to determine the maximum size
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/net/Inet4Address.java
> --- a/src/java.base/share/classes/java/net/Inet4Address.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/Inet4Address.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -143,7 +143,7 @@
>         /**
>          * Prior to 1.4 an InetAddress was created with a family
>          * based on the platform AF_INET value (usually 2).
> -         * For compatibility reasons we must therefore write the
> +         * For compatibility reasons we must therefore write
>          * the InetAddress with this family.
>          */
>         inet.holder().family = 2;
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/net/SocketImpl.java
> --- a/src/java.base/share/classes/java/net/SocketImpl.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/SocketImpl.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -333,7 +333,7 @@
>      * latency, and low latency above short connection time, then it could
>      * invoke this method with the values {@code (0, 1, 2)}.
>      *
> -     * By default, this method does nothing, unless it is overridden in a
> +     * By default, this method does nothing, unless it is overridden in
>      * a sub-class.
>      *
>      * @param  connectionTime
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/net/SocksSocketImpl.java
> --- a/src/java.base/share/classes/java/net/SocksSocketImpl.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/SocksSocketImpl.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -657,7 +657,7 @@
> 
>     /**
>      * Sends the Bind request to the SOCKS proxy. In the SOCKS protocol, bind
> -     * means "accept incoming connection from", so the SocketAddress is the
> +     * means "accept incoming connection from", so the SocketAddress is
>      * the one of the host we do accept connection from.
>      *
>      * @param      saddr   the Socket address of the remote host.
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/net/URLConnection.java
> --- a/src/java.base/share/classes/java/net/URLConnection.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/URLConnection.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -785,7 +785,7 @@
>      * required to make the connection. By default, this method
>      * returns {@code java.security.AllPermission}. Subclasses
>      * should override this method and return the permission
> -     * that best represents the permission required to make a
> +     * that best represents the permission required to make
>      * a connection to the URL. For example, a {@code URLConnection}
>      * representing a {@code file:} URL would return a
>      * {@code java.io.FilePermission} object.
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java
> --- a/src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java Mon Oct 30 17:18:47 2017 -0700
> @@ -165,7 +165,7 @@
>      * <tr>
>      *   <th scope="row" > {@link StandardOpenOption#DELETE_ON_CLOSE DELETE_ON_CLOSE} </th>
>      *   <td> When this option is present then the implementation makes a
> -     *   <em>best effort</em> attempt to delete the file when closed by the
> +     *   <em>best effort</em> attempt to delete the file when closed by
>      *   the {@link #close close} method. If the {@code close} method is not
>      *   invoked then a <em>best effort</em> attempt is made to delete the file
>      *   when the Java virtual machine terminates. </td>
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/nio/channels/FileChannel.java
> --- a/src/java.base/share/classes/java/nio/channels/FileChannel.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/nio/channels/FileChannel.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -216,7 +216,7 @@
>      * <tr>
>      *   <th scope="row" > {@link StandardOpenOption#DELETE_ON_CLOSE DELETE_ON_CLOSE} </th>
>      *   <td> When this option is present then the implementation makes a
> -     *   <em>best effort</em> attempt to delete the file when closed by the
> +     *   <em>best effort</em> attempt to delete the file when closed by
>      *   the {@link #close close} method. If the {@code close} method is not
>      *   invoked then a <em>best effort</em> attempt is made to delete the file
>      *   when the Java virtual machine terminates. </td>
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/nio/file/Files.java
> --- a/src/java.base/share/classes/java/nio/file/Files.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/nio/file/Files.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -3301,7 +3301,7 @@
>     }
> 
>     /**
> -     * Writes bytes to a file. The {@code options} parameter specifies how the
> +     * Writes bytes to a file. The {@code options} parameter specifies how
>      * the file is created or opened. If no options are present then this method
>      * works as if the {@link StandardOpenOption#CREATE CREATE}, {@link
>      * StandardOpenOption#TRUNCATE_EXISTING TRUNCATE_EXISTING}, and {@link
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/security/KeyPairGenerator.java
> --- a/src/java.base/share/classes/java/security/KeyPairGenerator.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/security/KeyPairGenerator.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -84,7 +84,7 @@
>  * exists (e.g., so-called <i>community parameters</i> in DSA), there are two
>  * {@link #initialize(java.security.spec.AlgorithmParameterSpec)
>  * initialize} methods that have an {@code AlgorithmParameterSpec}
> - * argument. One also has a {@code SecureRandom} argument, while the
> + * argument. One also has a {@code SecureRandom} argument, while
>  * the other uses the {@code SecureRandom}
>  * implementation of the highest-priority installed provider as the source
>  * of randomness. (If none of the installed providers supply an implementation
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
> --- a/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java Mon Oct 30 17:18:47 2017 -0700
> @@ -4775,7 +4775,7 @@
>     //-----------------------------------------------------------------------
>     /**
>      * Prints or parses a localized pattern from a localized field.
> -     * The specific formatter and parameters is not selected until the
> +     * The specific formatter and parameters is not selected until
>      * the field is to be printed or parsed.
>      * The locale is needed to select the proper WeekFields from which
>      * the field for day-of-week, week-of-month, or week-of-year is selected.
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/time/temporal/WeekFields.java
> --- a/src/java.base/share/classes/java/time/temporal/WeekFields.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/time/temporal/WeekFields.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -311,7 +311,7 @@
>      * the new month or year.
>      * <p>
>      * WeekFields instances are singletons; for each unique combination
> -     * of {@code firstDayOfWeek} and {@code minimalDaysInFirstWeek} the
> +     * of {@code firstDayOfWeek} and {@code minimalDaysInFirstWeek}
>      * the same instance will be returned.
>      *
>      * @param firstDayOfWeek  the first day of the week, not null
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/util/Base64.java
> --- a/src/java.base/share/classes/java/util/Base64.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/Base64.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -56,7 +56,7 @@
>  *     base64 alphabet.</p></li>
>  *
>  * <li><a id="mime"><b>MIME</b></a>
> - * <p> Uses the "The Base64 Alphabet" as specified in Table 1 of
> + * <p> Uses "The Base64 Alphabet" as specified in Table 1 of
>  *     RFC 2045 for encoding and decoding operation. The encoded output
>  *     must be represented in lines of no more than 76 characters each
>  *     and uses a carriage return {@code '\r'} followed immediately by
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/util/EventObject.java
> --- a/src/java.base/share/classes/java/util/EventObject.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/EventObject.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -43,13 +43,13 @@
>     /**
>      * The object on which the Event initially occurred.
>      */
> -    protected transient Object  source;
> +    protected transient Object source;
> 
>     /**
>      * Constructs a prototypical Event.
>      *
> -     * @param    source    The object on which the Event initially occurred.
> -     * @exception  IllegalArgumentException  if source is null.
> +     * @param source the object on which the Event initially occurred
> +     * @throws IllegalArgumentException if source is null
>      */
>     public EventObject(Object source) {
>         if (source == null)
> @@ -61,7 +61,7 @@
>     /**
>      * The object on which the Event initially occurred.
>      *
> -     * @return   The object on which the Event initially occurred.
> +     * @return the object on which the Event initially occurred
>      */
>     public Object getSource() {
>         return source;
> @@ -70,7 +70,7 @@
>     /**
>      * Returns a String representation of this EventObject.
>      *
> -     * @return  A a String representation of this EventObject.
> +     * @return a String representation of this EventObject
>      */
>     public String toString() {
>         return getClass().getName() + "[source=" + source + "]";
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/util/FormattableFlags.java
> --- a/src/java.base/share/classes/java/util/FormattableFlags.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/FormattableFlags.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -26,7 +26,7 @@
> package java.util;
> 
> /**
> - * FomattableFlags are passed to the {@link Formattable#formatTo
> + * FormattableFlags are passed to the {@link Formattable#formatTo
>  * Formattable.formatTo()} method and modify the output format for {@linkplain
>  * Formattable Formattables}.  Implementations of {@link Formattable} are
>  * responsible for interpreting and validating any flags.
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/java/util/ResourceBundle.java
> --- a/src/java.base/share/classes/java/util/ResourceBundle.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -2743,7 +2743,7 @@
>          * of multiple subtags separated by underscore, generate candidate
>          * <code>Locale</code>s by omitting the variant subtags one by one, then
>          * insert them after every occurrence of <code> Locale</code>s with the
> -         * full variant value in the original list.  For example, if the
> +         * full variant value in the original list.  For example, if
>          * the variant consists of two subtags <em>V1</em> and <em>V2</em>:
>          *
>          * <ul>
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java
> --- a/src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -238,7 +238,7 @@
>     // This way we could simply do things like:
>     //    push((logger) -> logger.log(level, msg));
>     // Unfortunately, if we come to here it means we are in the bootsraping
> -    // phase where using lambdas is not safe yet - so we have to use a
> +    // phase where using lambdas is not safe yet - so we have to use
>     // a data object instead...
>     //
>     static final class LogEvent {
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
> --- a/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Mon Oct 30 17:18:47 2017 -0700
> @@ -2888,7 +2888,7 @@
>             /*
>              * If we have an input stream this means we received a response
>              * from the server. That stream may have been read to EOF and
> -             * dependening on the stream type may already be closed or the
> +             * depending on the stream type may already be closed or
>              * the http client may be returned to the keep-alive cache.
>              * If the http client has been returned to the keep-alive cache
>              * it may be closed (idle timeout) or may be allocated to
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java
> --- a/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java Mon Oct 30 17:18:47 2017 -0700
> @@ -66,7 +66,7 @@
>     /**
>      * Static factory. Given a (generic) class, actual type arguments
>      * and an owner type, creates a parameterized type.
> -     * This class can be instantiated with a a raw type that does not
> +     * This class can be instantiated with a raw type that does not
>      * represent a generic type, provided the list of actual type
>      * arguments is empty.
>      * If the ownerType argument is null, the declaring class of the
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java
> --- a/src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -411,7 +411,7 @@
>                         certs = null;
>                     }
> 
> -                    // only add if we had no signer or we had a
> +                    // only add if we had no signer or we had
>                     // a signer and found the keys for it.
>                     if (certs != null || pe.signedBy == null) {
>                             Permission perm = new UnresolvedPermission(
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/sun/security/provider/PolicyFile.java
> --- a/src/java.base/share/classes/sun/security/provider/PolicyFile.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/provider/PolicyFile.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -789,7 +789,7 @@
>                         certs = null;
>                     }
> 
> -                    // only add if we had no signer or we had a
> +                    // only add if we had no signer or we had
>                     // a signer and found the keys for it.
>                     if (certs != null || pe.signedBy == null) {
>                         Permission perm = new UnresolvedPermission(
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java
> --- a/src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java Mon Oct 30 17:18:47 2017 -0700
> @@ -154,7 +154,7 @@
>      *
>      * @param codesource the <code>CodeSource</code> to compare against.
>      *
> -     * @return true if this <code>SubjectCodeSource</code> implies the
> +     * @return true if this <code>SubjectCodeSource</code> implies
>      *          the specified <code>CodeSource</code>.
>      */
>     public boolean implies(CodeSource codesource) {
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java
> --- a/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -539,7 +539,7 @@
> 
>                 // Should be repacked for suitable fragment length.
>                 //
> -                // Note that the acquiring processes will reassemble the
> +                // Note that the acquiring processes will reassemble
>                 // the fragments later.
>                 return compareToSequence(o.recordEpoch, o.recordSeq);
>             }
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/sun/security/x509/X509CertImpl.java
> --- a/src/java.base/share/classes/sun/security/x509/X509CertImpl.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/x509/X509CertImpl.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -1485,7 +1485,7 @@
>     }
> 
>     /**
> -     * Get the certificate constraints path length from the
> +     * Get the certificate constraints path length from
>      * the critical BasicConstraints extension, (oid = 2.5.29.19).
>      * @return the length of the constraint.
>      */
> diff -r d87f89c74f54 -r d2823a0c8dfa src/java.base/share/classes/sun/util/logging/PlatformLogger.java
> --- a/src/java.base/share/classes/sun/util/logging/PlatformLogger.java	Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/util/logging/PlatformLogger.java	Mon Oct 30 17:18:47 2017 -0700
> @@ -45,7 +45,7 @@
>  *
>  * If the logging facility is not enabled, the platform loggers
>  * will output log messages per the default logging configuration
> - * (see below). In this implementation, it does not log the
> + * (see below). In this implementation, it does not log
>  * the stack frame information issuing the log message.
>  *
>  * When the logging facility is enabled (at startup or runtime),
> 

 <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 david.holmes at oracle.com  Tue Oct 31 01:00:55 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Oct 2017 11:00:55 +1000
Subject: [Bug][JDK10] Fix duplicated "a" occurrences in docs
In-Reply-To: <40cd4c5a-57eb-18de-0e18-d20cdfa416bd@oracle.com>
References: <007701d35197$f6440200$e2cc0600$@freenet.de>
 <CA+kOe09K04HdXYJ1Vca3g7DfTLj=XLo44gj9R9QN7iRv=cHGAw@mail.gmail.com>
 <40cd4c5a-57eb-18de-0e18-d20cdfa416bd@oracle.com>
Message-ID: <ee252e05-cea9-9d05-ba03-46a3ae6335c9@oracle.com>

Does this duplicate the the patch Christoph sent regarding the the? ;-) 
Roger was handling that one.

David

On 31/10/2017 10:29 AM, Stuart Marks wrote:
> Hi all,
> 
> Please review the patch below. I'm sending this for review because it's 
> expanded considerably beyond the original patch that Christoph had 
> submitted. I ran a full-text search over the java.base source files 
> looking for "the the" and "a a" and it found a bunch of additional 
> occurrences that were split across line breaks. I also fixed up a few 
> other places that I happened to notice.
> 
> Christoph wrote:
>> I wasn't sure about the capitalization change on EventObject. What's the
>> rule of thumb in cases where the class does not follow the guidelines for
>> docs[1]? Sticking to the overall class scheme or aligning everything?
> 
> Good question. The first rule of styling is to stick with the prevailing 
> style in the file. In this case, changing just the text of that one 
> @return tag would have conflicted with the style in use in the rest of 
> the file, even though that style is arguably incorrect; the rest of the 
> file uses an initial capital and ends the description with a period 
> (full stop), whereas the recommended style is to use a noun phrase (a 
> sentence fragment), without an initial capital, and without a trailing 
> period (since there is no sentence following).
> 
> However, the file is small, and there were only three or four other 
> places that needed to be changed in order to bring the file into 
> compliance with the preferred style, so I just fixed them all.
> 
> 
> Thanks,
> 
> s'marks
> 
> 
> 
> # HG changeset patch
> # User smarks
> # Date 1509409127 25200
> #????? Mon Oct 30 17:18:47 2017 -0700
> # Node ID d2823a0c8dfab9e95e5c482794a96864b2592aad
> # Parent? d87f89c74f54873f273c4fbd8e6d49d7cbf3930b
> 8190382: fix small typographic errors in comments
> Reviewed-by: XXX
> Contributed-by: christoph.dreis at freenet.de
> 
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/io/FilePermission.java
> --- a/src/java.base/share/classes/java/io/FilePermission.java??? Mon Oct 
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/io/FilePermission.java??? Mon Oct 
> 30 17:18:47 2017 -0700
> @@ -698,7 +698,7 @@
>  ???????????? if (p2.equals(EMPTY_PATH)) {
>  ???????????????? return 0;
>  ???????????? } else if (p2.getName(0).equals(DOTDOT_PATH)) {
> -??????????????? // "." contains p2 iif p2 has no "..". Since a
> +??????????????? // "." contains p2 iff p2 has no "..". Since
>  ???????????????? // a normalized path can only have 0 or more
>  ???????????????? // ".." at the beginning. We only need to look
>  ???????????????? // at the head.
> @@ -711,7 +711,7 @@
>  ???????? } else if (p2.equals(EMPTY_PATH)) {
>  ???????????? int c1 = p1.getNameCount();
>  ???????????? if (!p1.getName(c1 - 1).equals(DOTDOT_PATH)) {
> -??????????????? // "." is inside p1 iif p1 is 1 or more "..".
> +??????????????? // "." is inside p1 iff p1 is 1 or more "..".
>  ???????????????? // For the same reason above, we only need to
>  ???????????????? // look at the tail.
>  ???????????????? return -1;
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/lang/invoke/MethodHandle.java
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandle.java    
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandle.java    
> Mon Oct 30 17:18:47 2017 -0700
> @@ -765,7 +765,7 @@
>  ????? * In every other case, all conversions are applied 
> <em>pairwise</em>,
>  ????? * which means that each argument or return value is converted to
>  ????? * exactly one argument or return value (or no return value).
> -???? * The applied conversions are defined by consulting the
> +???? * The applied conversions are defined by consulting
>  ????? * the corresponding component types of the old and new
>  ????? * method handle types.
>  ????? * <p>
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
> --- 
> a/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java    
> Mon Oct 30 07:06:49 2017 -0700
> +++ 
> b/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java    
> Mon Oct 30 17:18:47 2017 -0700
> @@ -194,7 +194,7 @@
>  ???? static {
>  ???????? // In case we need to double-back onto the StringConcatFactory 
> during this
>  ???????? // static initialization, make sure we have the reasonable 
> defaults to complete
> -??????? // the static initialization properly. After that, actual users 
> would use the
> +??????? // the static initialization properly. After that, actual users 
> would use
>  ???????? // the proper values we have read from the properties.
>  ???????? STRATEGY = DEFAULT_STRATEGY;
>  ???????? // CACHE_ENABLE = false; // implied
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/lang/invoke/VarHandle.java
> --- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java??? Mon 
> Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java??? Mon 
> Oct 30 17:18:47 2017 -0700
> @@ -205,7 +205,7 @@
>  ? * and {@code double} on 32-bit platforms.
>  ? *
>  ? * <p>Access modes will override any memory ordering effects specified at
> - * the declaration site of a variable.? For example, a VarHandle 
> accessing a
> + * the declaration site of a variable.? For example, a VarHandle accessing
>  ? * a field using the {@code get} access mode will access the field as
>  ? * specified <em>by its access mode</em> even if that field is declared
>  ? * {@code volatile}.? When mixed access is performed extreme care 
> should be
> @@ -423,7 +423,7 @@
>  ? * {@link java.lang.invoke.MethodHandles#varHandleInvoker}.
>  ? *
>  ? * <h1>Interoperation between VarHandles and Java generics</h1>
> - * A VarHandle can be obtained for a variable, such as a a field, which is
> + * A VarHandle can be obtained for a variable, such as a field, which is
>  ? * declared with Java generic types.? As with the Core Reflection API, 
> the
>  ? * VarHandle's variable type will be constructed from the erasure of the
>  ? * source-level type.? When a VarHandle access mode method is invoked, 
> the
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/net/DatagramSocket.java
> --- a/src/java.base/share/classes/java/net/DatagramSocket.java??? Mon 
> Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/DatagramSocket.java??? Mon 
> Oct 30 17:18:47 2017 -0700
> @@ -988,7 +988,7 @@
> 
>  ???? /**
>  ????? * Sets the SO_RCVBUF option to the specified value for this
> -???? * {@code DatagramSocket}. The SO_RCVBUF option is used by the
> +???? * {@code DatagramSocket}. The SO_RCVBUF option is used by
>  ????? * the network implementation as a hint to size the underlying
>  ????? * network I/O buffers. The SO_RCVBUF setting may also be used
>  ????? * by the network implementation to determine the maximum size
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/net/Inet4Address.java
> --- a/src/java.base/share/classes/java/net/Inet4Address.java??? Mon Oct 
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/Inet4Address.java??? Mon Oct 
> 30 17:18:47 2017 -0700
> @@ -143,7 +143,7 @@
>  ???????? /**
>  ????????? * Prior to 1.4 an InetAddress was created with a family
>  ????????? * based on the platform AF_INET value (usually 2).
> -???????? * For compatibility reasons we must therefore write the
> +???????? * For compatibility reasons we must therefore write
>  ????????? * the InetAddress with this family.
>  ????????? */
>  ???????? inet.holder().family = 2;
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/net/SocketImpl.java
> --- a/src/java.base/share/classes/java/net/SocketImpl.java??? Mon Oct 30 
> 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/SocketImpl.java??? Mon Oct 30 
> 17:18:47 2017 -0700
> @@ -333,7 +333,7 @@
>  ????? * latency, and low latency above short connection time, then it 
> could
>  ????? * invoke this method with the values {@code (0, 1, 2)}.
>  ????? *
> -???? * By default, this method does nothing, unless it is overridden in a
> +???? * By default, this method does nothing, unless it is overridden in
>  ????? * a sub-class.
>  ????? *
>  ????? * @param? connectionTime
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/net/SocksSocketImpl.java
> --- a/src/java.base/share/classes/java/net/SocksSocketImpl.java??? Mon 
> Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/SocksSocketImpl.java??? Mon 
> Oct 30 17:18:47 2017 -0700
> @@ -657,7 +657,7 @@
> 
>  ???? /**
>  ????? * Sends the Bind request to the SOCKS proxy. In the SOCKS 
> protocol, bind
> -???? * means "accept incoming connection from", so the SocketAddress is 
> the
> +???? * means "accept incoming connection from", so the SocketAddress is
>  ????? * the one of the host we do accept connection from.
>  ????? *
>  ????? * @param????? saddr?? the Socket address of the remote host.
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/net/URLConnection.java
> --- a/src/java.base/share/classes/java/net/URLConnection.java??? Mon Oct 
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/net/URLConnection.java??? Mon Oct 
> 30 17:18:47 2017 -0700
> @@ -785,7 +785,7 @@
>  ????? * required to make the connection. By default, this method
>  ????? * returns {@code java.security.AllPermission}. Subclasses
>  ????? * should override this method and return the permission
> -???? * that best represents the permission required to make a
> +???? * that best represents the permission required to make
>  ????? * a connection to the URL. For example, a {@code URLConnection}
>  ????? * representing a {@code file:} URL would return a
>  ????? * {@code java.io.FilePermission} object.
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java
> --- 
> a/src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java 
> Mon Oct 30 07:06:49 2017 -0700
> +++ 
> b/src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java 
> Mon Oct 30 17:18:47 2017 -0700
> @@ -165,7 +165,7 @@
>  ????? * <tr>
>  ????? *?? <th scope="row" > {@link StandardOpenOption#DELETE_ON_CLOSE 
> DELETE_ON_CLOSE} </th>
>  ????? *?? <td> When this option is present then the implementation makes a
> -???? *?? <em>best effort</em> attempt to delete the file when closed by 
> the
> +???? *?? <em>best effort</em> attempt to delete the file when closed by
>  ????? *?? the {@link #close close} method. If the {@code close} method 
> is not
>  ????? *?? invoked then a <em>best effort</em> attempt is made to delete 
> the file
>  ????? *?? when the Java virtual machine terminates. </td>
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/nio/channels/FileChannel.java
> --- a/src/java.base/share/classes/java/nio/channels/FileChannel.java    
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/nio/channels/FileChannel.java    
> Mon Oct 30 17:18:47 2017 -0700
> @@ -216,7 +216,7 @@
>  ????? * <tr>
>  ????? *?? <th scope="row" > {@link StandardOpenOption#DELETE_ON_CLOSE 
> DELETE_ON_CLOSE} </th>
>  ????? *?? <td> When this option is present then the implementation makes a
> -???? *?? <em>best effort</em> attempt to delete the file when closed by 
> the
> +???? *?? <em>best effort</em> attempt to delete the file when closed by
>  ????? *?? the {@link #close close} method. If the {@code close} method 
> is not
>  ????? *?? invoked then a <em>best effort</em> attempt is made to delete 
> the file
>  ????? *?? when the Java virtual machine terminates. </td>
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/nio/file/Files.java
> --- a/src/java.base/share/classes/java/nio/file/Files.java??? Mon Oct 30 
> 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/nio/file/Files.java??? Mon Oct 30 
> 17:18:47 2017 -0700
> @@ -3301,7 +3301,7 @@
>  ???? }
> 
>  ???? /**
> -???? * Writes bytes to a file. The {@code options} parameter specifies 
> how the
> +???? * Writes bytes to a file. The {@code options} parameter specifies how
>  ????? * the file is created or opened. If no options are present then 
> this method
>  ????? * works as if the {@link StandardOpenOption#CREATE CREATE}, {@link
>  ????? * StandardOpenOption#TRUNCATE_EXISTING TRUNCATE_EXISTING}, and 
> {@link
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/security/KeyPairGenerator.java
> --- a/src/java.base/share/classes/java/security/KeyPairGenerator.java    
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/security/KeyPairGenerator.java    
> Mon Oct 30 17:18:47 2017 -0700
> @@ -84,7 +84,7 @@
>  ? * exists (e.g., so-called <i>community parameters</i> in DSA), there 
> are two
>  ? * {@link #initialize(java.security.spec.AlgorithmParameterSpec)
>  ? * initialize} methods that have an {@code AlgorithmParameterSpec}
> - * argument. One also has a {@code SecureRandom} argument, while the
> + * argument. One also has a {@code SecureRandom} argument, while
>  ? * the other uses the {@code SecureRandom}
>  ? * implementation of the highest-priority installed provider as the 
> source
>  ? * of randomness. (If none of the installed providers supply an 
> implementation
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
> --- 
> a/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java 
> Mon Oct 30 07:06:49 2017 -0700
> +++ 
> b/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java 
> Mon Oct 30 17:18:47 2017 -0700
> @@ -4775,7 +4775,7 @@
>       
> //-----------------------------------------------------------------------
>  ???? /**
>  ????? * Prints or parses a localized pattern from a localized field.
> -???? * The specific formatter and parameters is not selected until the
> +???? * The specific formatter and parameters is not selected until
>  ????? * the field is to be printed or parsed.
>  ????? * The locale is needed to select the proper WeekFields from which
>  ????? * the field for day-of-week, week-of-month, or week-of-year is 
> selected.
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/time/temporal/WeekFields.java
> --- a/src/java.base/share/classes/java/time/temporal/WeekFields.java    
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/time/temporal/WeekFields.java    
> Mon Oct 30 17:18:47 2017 -0700
> @@ -311,7 +311,7 @@
>  ????? * the new month or year.
>  ????? * <p>
>  ????? * WeekFields instances are singletons; for each unique combination
> -???? * of {@code firstDayOfWeek} and {@code minimalDaysInFirstWeek} the
> +???? * of {@code firstDayOfWeek} and {@code minimalDaysInFirstWeek}
>  ????? * the same instance will be returned.
>  ????? *
>  ????? * @param firstDayOfWeek? the first day of the week, not null
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/util/Base64.java
> --- a/src/java.base/share/classes/java/util/Base64.java??? Mon Oct 30 
> 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/Base64.java??? Mon Oct 30 
> 17:18:47 2017 -0700
> @@ -56,7 +56,7 @@
>  ? *???? base64 alphabet.</p></li>
>  ? *
>  ? * <li><a id="mime"><b>MIME</b></a>
> - * <p> Uses the "The Base64 Alphabet" as specified in Table 1 of
> + * <p> Uses "The Base64 Alphabet" as specified in Table 1 of
>  ? *???? RFC 2045 for encoding and decoding operation. The encoded output
>  ? *???? must be represented in lines of no more than 76 characters each
>  ? *???? and uses a carriage return {@code '\r'} followed immediately by
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/util/EventObject.java
> --- a/src/java.base/share/classes/java/util/EventObject.java??? Mon Oct 
> 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/EventObject.java??? Mon Oct 
> 30 17:18:47 2017 -0700
> @@ -43,13 +43,13 @@
>  ???? /**
>  ????? * The object on which the Event initially occurred.
>  ????? */
> -??? protected transient Object? source;
> +??? protected transient Object source;
> 
>  ???? /**
>  ????? * Constructs a prototypical Event.
>  ????? *
> -???? * @param??? source??? The object on which the Event initially 
> occurred.
> -???? * @exception? IllegalArgumentException? if source is null.
> +???? * @param source the object on which the Event initially occurred
> +???? * @throws IllegalArgumentException if source is null
>  ????? */
>  ???? public EventObject(Object source) {
>  ???????? if (source == null)
> @@ -61,7 +61,7 @@
>  ???? /**
>  ????? * The object on which the Event initially occurred.
>  ????? *
> -???? * @return?? The object on which the Event initially occurred.
> +???? * @return the object on which the Event initially occurred
>  ????? */
>  ???? public Object getSource() {
>  ???????? return source;
> @@ -70,7 +70,7 @@
>  ???? /**
>  ????? * Returns a String representation of this EventObject.
>  ????? *
> -???? * @return? A a String representation of this EventObject.
> +???? * @return a String representation of this EventObject
>  ????? */
>  ???? public String toString() {
>  ???????? return getClass().getName() + "[source=" + source + "]";
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/util/FormattableFlags.java
> --- a/src/java.base/share/classes/java/util/FormattableFlags.java??? Mon 
> Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/FormattableFlags.java??? Mon 
> Oct 30 17:18:47 2017 -0700
> @@ -26,7 +26,7 @@
>  ?package java.util;
> 
>  ?/**
> - * FomattableFlags are passed to the {@link Formattable#formatTo
> + * FormattableFlags are passed to the {@link Formattable#formatTo
>  ? * Formattable.formatTo()} method and modify the output format for 
> {@linkplain
>  ? * Formattable Formattables}.? Implementations of {@link Formattable} are
>  ? * responsible for interpreting and validating any flags.
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/java/util/ResourceBundle.java
> --- a/src/java.base/share/classes/java/util/ResourceBundle.java??? Mon 
> Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java??? Mon 
> Oct 30 17:18:47 2017 -0700
> @@ -2743,7 +2743,7 @@
>  ????????? * of multiple subtags separated by underscore, generate 
> candidate
>  ????????? * <code>Locale</code>s by omitting the variant subtags one by 
> one, then
>  ????????? * insert them after every occurrence of <code> Locale</code>s 
> with the
> -???????? * full variant value in the original list.? For example, if the
> +???????? * full variant value in the original list.? For example, if
>  ????????? * the variant consists of two subtags <em>V1</em> and 
> <em>V2</em>:
>  ????????? *
>  ????????? * <ul>
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java
> --- 
> a/src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java??? Mon 
> Oct 30 07:06:49 2017 -0700
> +++ 
> b/src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java??? Mon 
> Oct 30 17:18:47 2017 -0700
> @@ -238,7 +238,7 @@
>  ???? // This way we could simply do things like:
>  ???? //??? push((logger) -> logger.log(level, msg));
>  ???? // Unfortunately, if we come to here it means we are in the 
> bootsraping
> -??? // phase where using lambdas is not safe yet - so we have to use a
> +??? // phase where using lambdas is not safe yet - so we have to use
>  ???? // a data object instead...
>  ???? //
>  ???? static final class LogEvent {
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java 
> 
> --- 
> a/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java 
> Mon Oct 30 07:06:49 2017 -0700
> +++ 
> b/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java 
> Mon Oct 30 17:18:47 2017 -0700
> @@ -2888,7 +2888,7 @@
>  ???????????? /*
>  ????????????? * If we have an input stream this means we received a 
> response
>  ????????????? * from the server. That stream may have been read to EOF and
> -???????????? * dependening on the stream type may already be closed or the
> +???????????? * depending on the stream type may already be closed or
>  ????????????? * the http client may be returned to the keep-alive cache.
>  ????????????? * If the http client has been returned to the keep-alive 
> cache
>  ????????????? * it may be closed (idle timeout) or may be allocated to
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
> 
> --- 
> a/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
> Mon Oct 30 07:06:49 2017 -0700
> +++ 
> b/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
> Mon Oct 30 17:18:47 2017 -0700
> @@ -66,7 +66,7 @@
>  ???? /**
>  ????? * Static factory. Given a (generic) class, actual type arguments
>  ????? * and an owner type, creates a parameterized type.
> -???? * This class can be instantiated with a a raw type that does not
> +???? * This class can be instantiated with a raw type that does not
>  ????? * represent a generic type, provided the list of actual type
>  ????? * arguments is empty.
>  ????? * If the ownerType argument is null, the declaring class of the
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java
> --- 
> a/src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java    
> Mon Oct 30 07:06:49 2017 -0700
> +++ 
> b/src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java    
> Mon Oct 30 17:18:47 2017 -0700
> @@ -411,7 +411,7 @@
>  ???????????????????????? certs = null;
>  ???????????????????? }
> 
> -??????????????????? // only add if we had no signer or we had a
> +??????????????????? // only add if we had no signer or we had
>  ???????????????????? // a signer and found the keys for it.
>  ???????????????????? if (certs != null || pe.signedBy == null) {
>  ???????????????????????????? Permission perm = new UnresolvedPermission(
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/sun/security/provider/PolicyFile.java
> --- 
> a/src/java.base/share/classes/sun/security/provider/PolicyFile.java    
> Mon Oct 30 07:06:49 2017 -0700
> +++ 
> b/src/java.base/share/classes/sun/security/provider/PolicyFile.java    
> Mon Oct 30 17:18:47 2017 -0700
> @@ -789,7 +789,7 @@
>  ???????????????????????? certs = null;
>  ???????????????????? }
> 
> -??????????????????? // only add if we had no signer or we had a
> +??????????????????? // only add if we had no signer or we had
>  ???????????????????? // a signer and found the keys for it.
>  ???????????????????? if (certs != null || pe.signedBy == null) {
>  ???????????????????????? Permission perm = new UnresolvedPermission(
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java
> --- 
> a/src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java 
> Mon Oct 30 07:06:49 2017 -0700
> +++ 
> b/src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java 
> Mon Oct 30 17:18:47 2017 -0700
> @@ -154,7 +154,7 @@
>  ????? *
>  ????? * @param codesource the <code>CodeSource</code> to compare against.
>  ????? *
> -???? * @return true if this <code>SubjectCodeSource</code> implies the
> +???? * @return true if this <code>SubjectCodeSource</code> implies
>  ????? *????????? the specified <code>CodeSource</code>.
>  ????? */
>  ???? public boolean implies(CodeSource codesource) {
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java
> --- 
> a/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java    
> Mon Oct 30 07:06:49 2017 -0700
> +++ 
> b/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java    
> Mon Oct 30 17:18:47 2017 -0700
> @@ -539,7 +539,7 @@
> 
>  ???????????????? // Should be repacked for suitable fragment length.
>  ???????????????? //
> -??????????????? // Note that the acquiring processes will reassemble the
> +??????????????? // Note that the acquiring processes will reassemble
>  ???????????????? // the fragments later.
>  ???????????????? return compareToSequence(o.recordEpoch, o.recordSeq);
>  ???????????? }
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/sun/security/x509/X509CertImpl.java
> --- a/src/java.base/share/classes/sun/security/x509/X509CertImpl.java    
> Mon Oct 30 07:06:49 2017 -0700
> +++ b/src/java.base/share/classes/sun/security/x509/X509CertImpl.java    
> Mon Oct 30 17:18:47 2017 -0700
> @@ -1485,7 +1485,7 @@
>  ???? }
> 
>  ???? /**
> -???? * Get the certificate constraints path length from the
> +???? * Get the certificate constraints path length from
>  ????? * the critical BasicConstraints extension, (oid = 2.5.29.19).
>  ????? * @return the length of the constraint.
>  ????? */
> diff -r d87f89c74f54 -r d2823a0c8dfa 
> src/java.base/share/classes/sun/util/logging/PlatformLogger.java
> --- 
> a/src/java.base/share/classes/sun/util/logging/PlatformLogger.java    
> Mon Oct 30 07:06:49 2017 -0700
> +++ 
> b/src/java.base/share/classes/sun/util/logging/PlatformLogger.java    
> Mon Oct 30 17:18:47 2017 -0700
> @@ -45,7 +45,7 @@
>  ? *
>  ? * If the logging facility is not enabled, the platform loggers
>  ? * will output log messages per the default logging configuration
> - * (see below). In this implementation, it does not log the
> + * (see below). In this implementation, it does not log
>  ? * the stack frame information issuing the log message.
>  ? *
>  ? * When the logging facility is enabled (at startup or runtime),
> 

From stuart.marks at oracle.com  Tue Oct 31 01:16:49 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 30 Oct 2017 18:16:49 -0700
Subject: [Bug][JDK10] Fix duplicated "a" occurrences in docs
In-Reply-To: <ee252e05-cea9-9d05-ba03-46a3ae6335c9@oracle.com>
References: <007701d35197$f6440200$e2cc0600$@freenet.de>
 <CA+kOe09K04HdXYJ1Vca3g7DfTLj=XLo44gj9R9QN7iRv=cHGAw@mail.gmail.com>
 <40cd4c5a-57eb-18de-0e18-d20cdfa416bd@oracle.com>
 <ee252e05-cea9-9d05-ba03-46a3ae6335c9@oracle.com>
Message-ID: <21f98480-6654-3a03-71cc-a1853f56a1c2@oracle.com>

No, Roger checked in the "the the" patch before Christophe posted a "a a" 
followup patch. :-)

s'marks

On 10/30/17 6:00 PM, David Holmes wrote:
> Does this duplicate the the patch Christoph sent regarding the the? ;-) Roger 
> was handling that one.
> 
> David
> 
> On 31/10/2017 10:29 AM, Stuart Marks wrote:
>> Hi all,
>>
>> Please review the patch below. I'm sending this for review because it's 
>> expanded considerably beyond the original patch that Christoph had submitted. 
>> I ran a full-text search over the java.base source files looking for "the the" 
>> and "a a" and it found a bunch of additional occurrences that were split 
>> across line breaks. I also fixed up a few other places that I happened to notice.
>>
>> Christoph wrote:
>>> I wasn't sure about the capitalization change on EventObject. What's the
>>> rule of thumb in cases where the class does not follow the guidelines for
>>> docs[1]? Sticking to the overall class scheme or aligning everything?
>>
>> Good question. The first rule of styling is to stick with the prevailing style 
>> in the file. In this case, changing just the text of that one @return tag 
>> would have conflicted with the style in use in the rest of the file, even 
>> though that style is arguably incorrect; the rest of the file uses an initial 
>> capital and ends the description with a period (full stop), whereas the 
>> recommended style is to use a noun phrase (a sentence fragment), without an 
>> initial capital, and without a trailing period (since there is no sentence 
>> following).
>>
>> However, the file is small, and there were only three or four other places 
>> that needed to be changed in order to bring the file into compliance with the 
>> preferred style, so I just fixed them all.
>>
>>
>> Thanks,
>>
>> s'marks
>>
>>
>>
>> # HG changeset patch
>> # User smarks
>> # Date 1509409127 25200
>> #????? Mon Oct 30 17:18:47 2017 -0700
>> # Node ID d2823a0c8dfab9e95e5c482794a96864b2592aad
>> # Parent? d87f89c74f54873f273c4fbd8e6d49d7cbf3930b
>> 8190382: fix small typographic errors in comments
>> Reviewed-by: XXX
>> Contributed-by: christoph.dreis at freenet.de
>>
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/io/FilePermission.java
>> --- a/src/java.base/share/classes/java/io/FilePermission.java??? Mon Oct 30 
>> 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/io/FilePermission.java??? Mon Oct 30 
>> 17:18:47 2017 -0700
>> @@ -698,7 +698,7 @@
>> ????????????? if (p2.equals(EMPTY_PATH)) {
>> ????????????????? return 0;
>> ????????????? } else if (p2.getName(0).equals(DOTDOT_PATH)) {
>> -??????????????? // "." contains p2 iif p2 has no "..". Since a
>> +??????????????? // "." contains p2 iff p2 has no "..". Since
>> ????????????????? // a normalized path can only have 0 or more
>> ????????????????? // ".." at the beginning. We only need to look
>> ????????????????? // at the head.
>> @@ -711,7 +711,7 @@
>> ????????? } else if (p2.equals(EMPTY_PATH)) {
>> ????????????? int c1 = p1.getNameCount();
>> ????????????? if (!p1.getName(c1 - 1).equals(DOTDOT_PATH)) {
>> -??????????????? // "." is inside p1 iif p1 is 1 or more "..".
>> +??????????????? // "." is inside p1 iff p1 is 1 or more "..".
>> ????????????????? // For the same reason above, we only need to
>> ????????????????? // look at the tail.
>> ????????????????? return -1;
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/lang/invoke/MethodHandle.java
>> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandle.java Mon Oct 
>> 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandle.java Mon Oct 
>> 30 17:18:47 2017 -0700
>> @@ -765,7 +765,7 @@
>> ?????? * In every other case, all conversions are applied <em>pairwise</em>,
>> ?????? * which means that each argument or return value is converted to
>> ?????? * exactly one argument or return value (or no return value).
>> -???? * The applied conversions are defined by consulting the
>> +???? * The applied conversions are defined by consulting
>> ?????? * the corresponding component types of the old and new
>> ?????? * method handle types.
>> ?????? * <p>
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
>> --- a/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java 
>> Mon Oct 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java 
>> Mon Oct 30 17:18:47 2017 -0700
>> @@ -194,7 +194,7 @@
>> ????? static {
>> ????????? // In case we need to double-back onto the StringConcatFactory 
>> during this
>> ????????? // static initialization, make sure we have the reasonable defaults 
>> to complete
>> -??????? // the static initialization properly. After that, actual users would 
>> use the
>> +??????? // the static initialization properly. After that, actual users would 
>> use
>> ????????? // the proper values we have read from the properties.
>> ????????? STRATEGY = DEFAULT_STRATEGY;
>> ????????? // CACHE_ENABLE = false; // implied
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/lang/invoke/VarHandle.java
>> --- a/src/java.base/share/classes/java/lang/invoke/VarHandle.java??? Mon Oct 
>> 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/lang/invoke/VarHandle.java??? Mon Oct 
>> 30 17:18:47 2017 -0700
>> @@ -205,7 +205,7 @@
>> ?? * and {@code double} on 32-bit platforms.
>> ?? *
>> ?? * <p>Access modes will override any memory ordering effects specified at
>> - * the declaration site of a variable.? For example, a VarHandle accessing a
>> + * the declaration site of a variable.? For example, a VarHandle accessing
>> ?? * a field using the {@code get} access mode will access the field as
>> ?? * specified <em>by its access mode</em> even if that field is declared
>> ?? * {@code volatile}.? When mixed access is performed extreme care should be
>> @@ -423,7 +423,7 @@
>> ?? * {@link java.lang.invoke.MethodHandles#varHandleInvoker}.
>> ?? *
>> ?? * <h1>Interoperation between VarHandles and Java generics</h1>
>> - * A VarHandle can be obtained for a variable, such as a a field, which is
>> + * A VarHandle can be obtained for a variable, such as a field, which is
>> ?? * declared with Java generic types.? As with the Core Reflection API, the
>> ?? * VarHandle's variable type will be constructed from the erasure of the
>> ?? * source-level type.? When a VarHandle access mode method is invoked, the
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/net/DatagramSocket.java
>> --- a/src/java.base/share/classes/java/net/DatagramSocket.java??? Mon Oct 30 
>> 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/net/DatagramSocket.java??? Mon Oct 30 
>> 17:18:47 2017 -0700
>> @@ -988,7 +988,7 @@
>>
>> ????? /**
>> ?????? * Sets the SO_RCVBUF option to the specified value for this
>> -???? * {@code DatagramSocket}. The SO_RCVBUF option is used by the
>> +???? * {@code DatagramSocket}. The SO_RCVBUF option is used by
>> ?????? * the network implementation as a hint to size the underlying
>> ?????? * network I/O buffers. The SO_RCVBUF setting may also be used
>> ?????? * by the network implementation to determine the maximum size
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/net/Inet4Address.java
>> --- a/src/java.base/share/classes/java/net/Inet4Address.java??? Mon Oct 30 
>> 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/net/Inet4Address.java??? Mon Oct 30 
>> 17:18:47 2017 -0700
>> @@ -143,7 +143,7 @@
>> ????????? /**
>> ?????????? * Prior to 1.4 an InetAddress was created with a family
>> ?????????? * based on the platform AF_INET value (usually 2).
>> -???????? * For compatibility reasons we must therefore write the
>> +???????? * For compatibility reasons we must therefore write
>> ?????????? * the InetAddress with this family.
>> ?????????? */
>> ????????? inet.holder().family = 2;
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/net/SocketImpl.java
>> --- a/src/java.base/share/classes/java/net/SocketImpl.java??? Mon Oct 30 
>> 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/net/SocketImpl.java??? Mon Oct 30 
>> 17:18:47 2017 -0700
>> @@ -333,7 +333,7 @@
>> ?????? * latency, and low latency above short connection time, then it could
>> ?????? * invoke this method with the values {@code (0, 1, 2)}.
>> ?????? *
>> -???? * By default, this method does nothing, unless it is overridden in a
>> +???? * By default, this method does nothing, unless it is overridden in
>> ?????? * a sub-class.
>> ?????? *
>> ?????? * @param? connectionTime
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/net/SocksSocketImpl.java
>> --- a/src/java.base/share/classes/java/net/SocksSocketImpl.java??? Mon Oct 30 
>> 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/net/SocksSocketImpl.java??? Mon Oct 30 
>> 17:18:47 2017 -0700
>> @@ -657,7 +657,7 @@
>>
>> ????? /**
>> ?????? * Sends the Bind request to the SOCKS proxy. In the SOCKS protocol, bind
>> -???? * means "accept incoming connection from", so the SocketAddress is the
>> +???? * means "accept incoming connection from", so the SocketAddress is
>> ?????? * the one of the host we do accept connection from.
>> ?????? *
>> ?????? * @param????? saddr?? the Socket address of the remote host.
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/net/URLConnection.java
>> --- a/src/java.base/share/classes/java/net/URLConnection.java??? Mon Oct 30 
>> 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/net/URLConnection.java??? Mon Oct 30 
>> 17:18:47 2017 -0700
>> @@ -785,7 +785,7 @@
>> ?????? * required to make the connection. By default, this method
>> ?????? * returns {@code java.security.AllPermission}. Subclasses
>> ?????? * should override this method and return the permission
>> -???? * that best represents the permission required to make a
>> +???? * that best represents the permission required to make
>> ?????? * a connection to the URL. For example, a {@code URLConnection}
>> ?????? * representing a {@code file:} URL would return a
>> ?????? * {@code java.io.FilePermission} object.
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java
>> --- 
>> a/src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java 
>> Mon Oct 30 07:06:49 2017 -0700
>> +++ 
>> b/src/java.base/share/classes/java/nio/channels/AsynchronousFileChannel.java 
>> Mon Oct 30 17:18:47 2017 -0700
>> @@ -165,7 +165,7 @@
>> ?????? * <tr>
>> ?????? *?? <th scope="row" > {@link StandardOpenOption#DELETE_ON_CLOSE 
>> DELETE_ON_CLOSE} </th>
>> ?????? *?? <td> When this option is present then the implementation makes a
>> -???? *?? <em>best effort</em> attempt to delete the file when closed by the
>> +???? *?? <em>best effort</em> attempt to delete the file when closed by
>> ?????? *?? the {@link #close close} method. If the {@code close} method is not
>> ?????? *?? invoked then a <em>best effort</em> attempt is made to delete the file
>> ?????? *?? when the Java virtual machine terminates. </td>
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/nio/channels/FileChannel.java
>> --- a/src/java.base/share/classes/java/nio/channels/FileChannel.java Mon Oct 
>> 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/nio/channels/FileChannel.java Mon Oct 
>> 30 17:18:47 2017 -0700
>> @@ -216,7 +216,7 @@
>> ?????? * <tr>
>> ?????? *?? <th scope="row" > {@link StandardOpenOption#DELETE_ON_CLOSE 
>> DELETE_ON_CLOSE} </th>
>> ?????? *?? <td> When this option is present then the implementation makes a
>> -???? *?? <em>best effort</em> attempt to delete the file when closed by the
>> +???? *?? <em>best effort</em> attempt to delete the file when closed by
>> ?????? *?? the {@link #close close} method. If the {@code close} method is not
>> ?????? *?? invoked then a <em>best effort</em> attempt is made to delete the file
>> ?????? *?? when the Java virtual machine terminates. </td>
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/nio/file/Files.java
>> --- a/src/java.base/share/classes/java/nio/file/Files.java??? Mon Oct 30 
>> 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/nio/file/Files.java??? Mon Oct 30 
>> 17:18:47 2017 -0700
>> @@ -3301,7 +3301,7 @@
>> ????? }
>>
>> ????? /**
>> -???? * Writes bytes to a file. The {@code options} parameter specifies how the
>> +???? * Writes bytes to a file. The {@code options} parameter specifies how
>> ?????? * the file is created or opened. If no options are present then this 
>> method
>> ?????? * works as if the {@link StandardOpenOption#CREATE CREATE}, {@link
>> ?????? * StandardOpenOption#TRUNCATE_EXISTING TRUNCATE_EXISTING}, and {@link
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/security/KeyPairGenerator.java
>> --- a/src/java.base/share/classes/java/security/KeyPairGenerator.java Mon Oct 
>> 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/security/KeyPairGenerator.java Mon Oct 
>> 30 17:18:47 2017 -0700
>> @@ -84,7 +84,7 @@
>> ?? * exists (e.g., so-called <i>community parameters</i> in DSA), there are two
>> ?? * {@link #initialize(java.security.spec.AlgorithmParameterSpec)
>> ?? * initialize} methods that have an {@code AlgorithmParameterSpec}
>> - * argument. One also has a {@code SecureRandom} argument, while the
>> + * argument. One also has a {@code SecureRandom} argument, while
>> ?? * the other uses the {@code SecureRandom}
>> ?? * implementation of the highest-priority installed provider as the source
>> ?? * of randomness. (If none of the installed providers supply an implementation
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
>> --- 
>> a/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java 
>> Mon Oct 30 07:06:49 2017 -0700
>> +++ 
>> b/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java 
>> Mon Oct 30 17:18:47 2017 -0700
>> @@ -4775,7 +4775,7 @@
>> //-----------------------------------------------------------------------
>> ????? /**
>> ?????? * Prints or parses a localized pattern from a localized field.
>> -???? * The specific formatter and parameters is not selected until the
>> +???? * The specific formatter and parameters is not selected until
>> ?????? * the field is to be printed or parsed.
>> ?????? * The locale is needed to select the proper WeekFields from which
>> ?????? * the field for day-of-week, week-of-month, or week-of-year is selected.
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/time/temporal/WeekFields.java
>> --- a/src/java.base/share/classes/java/time/temporal/WeekFields.java Mon Oct 
>> 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/time/temporal/WeekFields.java Mon Oct 
>> 30 17:18:47 2017 -0700
>> @@ -311,7 +311,7 @@
>> ?????? * the new month or year.
>> ?????? * <p>
>> ?????? * WeekFields instances are singletons; for each unique combination
>> -???? * of {@code firstDayOfWeek} and {@code minimalDaysInFirstWeek} the
>> +???? * of {@code firstDayOfWeek} and {@code minimalDaysInFirstWeek}
>> ?????? * the same instance will be returned.
>> ?????? *
>> ?????? * @param firstDayOfWeek? the first day of the week, not null
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/util/Base64.java
>> --- a/src/java.base/share/classes/java/util/Base64.java??? Mon Oct 30 07:06:49 
>> 2017 -0700
>> +++ b/src/java.base/share/classes/java/util/Base64.java??? Mon Oct 30 17:18:47 
>> 2017 -0700
>> @@ -56,7 +56,7 @@
>> ?? *???? base64 alphabet.</p></li>
>> ?? *
>> ?? * <li><a id="mime"><b>MIME</b></a>
>> - * <p> Uses the "The Base64 Alphabet" as specified in Table 1 of
>> + * <p> Uses "The Base64 Alphabet" as specified in Table 1 of
>> ?? *???? RFC 2045 for encoding and decoding operation. The encoded output
>> ?? *???? must be represented in lines of no more than 76 characters each
>> ?? *???? and uses a carriage return {@code '\r'} followed immediately by
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/util/EventObject.java
>> --- a/src/java.base/share/classes/java/util/EventObject.java??? Mon Oct 30 
>> 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/util/EventObject.java??? Mon Oct 30 
>> 17:18:47 2017 -0700
>> @@ -43,13 +43,13 @@
>> ????? /**
>> ?????? * The object on which the Event initially occurred.
>> ?????? */
>> -??? protected transient Object? source;
>> +??? protected transient Object source;
>>
>> ????? /**
>> ?????? * Constructs a prototypical Event.
>> ?????? *
>> -???? * @param??? source??? The object on which the Event initially occurred.
>> -???? * @exception? IllegalArgumentException? if source is null.
>> +???? * @param source the object on which the Event initially occurred
>> +???? * @throws IllegalArgumentException if source is null
>> ?????? */
>> ????? public EventObject(Object source) {
>> ????????? if (source == null)
>> @@ -61,7 +61,7 @@
>> ????? /**
>> ?????? * The object on which the Event initially occurred.
>> ?????? *
>> -???? * @return?? The object on which the Event initially occurred.
>> +???? * @return the object on which the Event initially occurred
>> ?????? */
>> ????? public Object getSource() {
>> ????????? return source;
>> @@ -70,7 +70,7 @@
>> ????? /**
>> ?????? * Returns a String representation of this EventObject.
>> ?????? *
>> -???? * @return? A a String representation of this EventObject.
>> +???? * @return a String representation of this EventObject
>> ?????? */
>> ????? public String toString() {
>> ????????? return getClass().getName() + "[source=" + source + "]";
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/util/FormattableFlags.java
>> --- a/src/java.base/share/classes/java/util/FormattableFlags.java??? Mon Oct 
>> 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/util/FormattableFlags.java??? Mon Oct 
>> 30 17:18:47 2017 -0700
>> @@ -26,7 +26,7 @@
>> ??package java.util;
>>
>> ??/**
>> - * FomattableFlags are passed to the {@link Formattable#formatTo
>> + * FormattableFlags are passed to the {@link Formattable#formatTo
>> ?? * Formattable.formatTo()} method and modify the output format for {@linkplain
>> ?? * Formattable Formattables}.? Implementations of {@link Formattable} are
>> ?? * responsible for interpreting and validating any flags.
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/java/util/ResourceBundle.java
>> --- a/src/java.base/share/classes/java/util/ResourceBundle.java??? Mon Oct 30 
>> 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/java/util/ResourceBundle.java??? Mon Oct 30 
>> 17:18:47 2017 -0700
>> @@ -2743,7 +2743,7 @@
>> ?????????? * of multiple subtags separated by underscore, generate candidate
>> ?????????? * <code>Locale</code>s by omitting the variant subtags one by one, 
>> then
>> ?????????? * insert them after every occurrence of <code> Locale</code>s with the
>> -???????? * full variant value in the original list.? For example, if the
>> +???????? * full variant value in the original list.? For example, if
>> ?????????? * the variant consists of two subtags <em>V1</em> and <em>V2</em>:
>> ?????????? *
>> ?????????? * <ul>
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java
>> --- a/src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java    
>> Mon Oct 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/jdk/internal/logger/BootstrapLogger.java    
>> Mon Oct 30 17:18:47 2017 -0700
>> @@ -238,7 +238,7 @@
>> ????? // This way we could simply do things like:
>> ????? //??? push((logger) -> logger.log(level, msg));
>> ????? // Unfortunately, if we come to here it means we are in the bootsraping
>> -??? // phase where using lambdas is not safe yet - so we have to use a
>> +??? // phase where using lambdas is not safe yet - so we have to use
>> ????? // a data object instead...
>> ????? //
>> ????? static final class LogEvent {
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>> --- 
>> a/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java 
>> Mon Oct 30 07:06:49 2017 -0700
>> +++ 
>> b/src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java 
>> Mon Oct 30 17:18:47 2017 -0700
>> @@ -2888,7 +2888,7 @@
>> ????????????? /*
>> ?????????????? * If we have an input stream this means we received a response
>> ?????????????? * from the server. That stream may have been read to EOF and
>> -???????????? * dependening on the stream type may already be closed or the
>> +???????????? * depending on the stream type may already be closed or
>> ?????????????? * the http client may be returned to the keep-alive cache.
>> ?????????????? * If the http client has been returned to the keep-alive cache
>> ?????????????? * it may be closed (idle timeout) or may be allocated to
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
>>
>> --- 
>> a/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
>> Mon Oct 30 07:06:49 2017 -0700
>> +++ 
>> b/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java 
>> Mon Oct 30 17:18:47 2017 -0700
>> @@ -66,7 +66,7 @@
>> ????? /**
>> ?????? * Static factory. Given a (generic) class, actual type arguments
>> ?????? * and an owner type, creates a parameterized type.
>> -???? * This class can be instantiated with a a raw type that does not
>> +???? * This class can be instantiated with a raw type that does not
>> ?????? * represent a generic type, provided the list of actual type
>> ?????? * arguments is empty.
>> ?????? * If the ownerType argument is null, the declaring class of the
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java
>> --- a/src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java 
>> Mon Oct 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/sun/security/provider/AuthPolicyFile.java 
>> Mon Oct 30 17:18:47 2017 -0700
>> @@ -411,7 +411,7 @@
>> ????????????????????????? certs = null;
>> ????????????????????? }
>>
>> -??????????????????? // only add if we had no signer or we had a
>> +??????????????????? // only add if we had no signer or we had
>> ????????????????????? // a signer and found the keys for it.
>> ????????????????????? if (certs != null || pe.signedBy == null) {
>> ????????????????????????????? Permission perm = new UnresolvedPermission(
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/sun/security/provider/PolicyFile.java
>> --- a/src/java.base/share/classes/sun/security/provider/PolicyFile.java Mon 
>> Oct 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/sun/security/provider/PolicyFile.java Mon 
>> Oct 30 17:18:47 2017 -0700
>> @@ -789,7 +789,7 @@
>> ????????????????????????? certs = null;
>> ????????????????????? }
>>
>> -??????????????????? // only add if we had no signer or we had a
>> +??????????????????? // only add if we had no signer or we had
>> ????????????????????? // a signer and found the keys for it.
>> ????????????????????? if (certs != null || pe.signedBy == null) {
>> ????????????????????????? Permission perm = new UnresolvedPermission(
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java
>> --- a/src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java 
>> Mon Oct 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/sun/security/provider/SubjectCodeSource.java 
>> Mon Oct 30 17:18:47 2017 -0700
>> @@ -154,7 +154,7 @@
>> ?????? *
>> ?????? * @param codesource the <code>CodeSource</code> to compare against.
>> ?????? *
>> -???? * @return true if this <code>SubjectCodeSource</code> implies the
>> +???? * @return true if this <code>SubjectCodeSource</code> implies
>> ?????? *????????? the specified <code>CodeSource</code>.
>> ?????? */
>> ????? public boolean implies(CodeSource codesource) {
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java
>> --- a/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java Mon 
>> Oct 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java Mon 
>> Oct 30 17:18:47 2017 -0700
>> @@ -539,7 +539,7 @@
>>
>> ????????????????? // Should be repacked for suitable fragment length.
>> ????????????????? //
>> -??????????????? // Note that the acquiring processes will reassemble the
>> +??????????????? // Note that the acquiring processes will reassemble
>> ????????????????? // the fragments later.
>> ????????????????? return compareToSequence(o.recordEpoch, o.recordSeq);
>> ????????????? }
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/sun/security/x509/X509CertImpl.java
>> --- a/src/java.base/share/classes/sun/security/x509/X509CertImpl.java Mon Oct 
>> 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/sun/security/x509/X509CertImpl.java Mon Oct 
>> 30 17:18:47 2017 -0700
>> @@ -1485,7 +1485,7 @@
>> ????? }
>>
>> ????? /**
>> -???? * Get the certificate constraints path length from the
>> +???? * Get the certificate constraints path length from
>> ?????? * the critical BasicConstraints extension, (oid = 2.5.29.19).
>> ?????? * @return the length of the constraint.
>> ?????? */
>> diff -r d87f89c74f54 -r d2823a0c8dfa 
>> src/java.base/share/classes/sun/util/logging/PlatformLogger.java
>> --- a/src/java.base/share/classes/sun/util/logging/PlatformLogger.java Mon Oct 
>> 30 07:06:49 2017 -0700
>> +++ b/src/java.base/share/classes/sun/util/logging/PlatformLogger.java Mon Oct 
>> 30 17:18:47 2017 -0700
>> @@ -45,7 +45,7 @@
>> ?? *
>> ?? * If the logging facility is not enabled, the platform loggers
>> ?? * will output log messages per the default logging configuration
>> - * (see below). In this implementation, it does not log the
>> + * (see below). In this implementation, it does not log
>> ?? * the stack frame information issuing the log message.
>> ?? *
>> ?? * When the logging facility is enabled (at startup or runtime),
>>

From david.holmes at oracle.com  Tue Oct 31 04:12:57 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Oct 2017 14:12:57 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
Message-ID: <81dd2a19-0818-9c1e-7d7f-30132c008f02@oracle.com>

On 31/10/2017 1:02 AM, David Lloyd wrote:
> On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> ThreadPoolExecutor has a responsibility to cleanup any native resources it
>> has allocated (threads) and it should be free to use whatever mechanism is appropriate.
> 
> I wonder though whether TPE.finalize() is ever actually hit in
> practice: TPE is (by definition) a thread pool, and every live thread
> in that pool has (by way of TPE.Worker) a strong reference to the TPE
> itself via an outer class reference which is passed around in enough
> places to make me think that it would never actually be collectable in
> a real-world situation, unless all core threads were allowed to time
> out.

The docs for TPE cover this in detail: [1]

Finalization
     A pool that is no longer referenced in a program AND has no 
remaining threads will be shutdown automatically. If you would like to 
ensure that unreferenced pools are reclaimed even if users forget to 
call shutdown(), then you must arrange that unused threads eventually 
die, by setting appropriate keep-alive times, using a lower bound of 
zero core threads and/or setting allowCoreThreadTimeOut(boolean).

David
-----

[1] 
https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/ThreadPoolExecutor.html


From sundararajan.athijegannathan at oracle.com  Tue Oct 31 04:27:35 2017
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 31 Oct 2017 09:57:35 +0530
Subject: RFR: 8190287: Update JDK's internal ASM to ASMv6
In-Reply-To: <59F3690B.6070309@oracle.com>
References: <59F3690B.6070309@oracle.com>
Message-ID: <59F7FBB7.2080400@oracle.com>

jlink changes look good.

I ran jlink tests and all nashorn tests (jtreg as well as ant 
test/test262parallel) after applying the patch locally. All fine!

+1

-Sundar

On 27/10/17, 10:42 PM, Kumar Srinivasan wrote:
> Hello Remi, Sundar and others,
>
> Please review the webrev [1] to update JDK's internal ASM to v6.
>
> To help with review areas, you can use the browser to search for mq 
> patches commented with //
>
> Highlights of changes:
> 1. updated ASMv6 // jdk-new-asmv6.patch
> 2. changes to jlink and jar to add ModuleMainClass and ModulePackages 
> attributes //jdk-new-asm-update.patch
> 3. adjustments to jdk tests  //jdk-new-asm-test.patch
> 4. minor adjustments  to hotspot tests  //jdk-new-hotspot-test.patch
>
> Tests:
> jdk_tier1, jdk_tier2, testset hotspot, hotspot_tier1, nashorn ant tests,
> Alan has also run several tests.
>
> Big thanks to Alan for #2 and #3 as part of [3].
>
> Thanks
> Kumar
>
> [1] http://cr.openjdk.java.net/~ksrini/8190287/webrev.00/index.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8190287
> [3] https://bugs.openjdk.java.net/browse/JDK-8186236
>

From paul.sandoz at oracle.com  Tue Oct 31 04:33:02 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 30 Oct 2017 21:33:02 -0700
Subject: RFR Re: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <59F7C175.7010705@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
 <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
 <59F7C175.7010705@oracle.com>
Message-ID: <11BAC038-0D59-467C-AE0B-212049E5E46B@oracle.com>

Hi,

> On 30 Oct 2017, at 17:19, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Is it intentional that "DoubleSummaryStatistics" is used in a sentence like
> 
>   91      * @apiNote
>   92      * The enforcement of argument correctness means that the retrieved set of
>   93      * recorded values obtained from a {@code DoubleSummaryStatistics} source
> 
> in all three types being updated?
> 

No, copy?n?paste error. Fixed.


> For the code in the constructor, if you don't want to have something like an explicit switch on Long.signum(count), I'd prefer to see at least a comment like
> 
> // Use default field values if count == 0
> 

Done.


> For the double case, I'd recommend future work change the new constructor to 
> 
>     DoubleSummaryStatistics(long count, double min, double max, double sum, double... additionalSum)
> 
> where the final argument could be used to convey additional state.
> 

Ok.


> For the double case, if a NaN is used than max and min will be NaN. Therefore, I'd recommend change the correctness constraint for that type to
> 
>     <li>{@code min} &le; {@code max} || (isNaN(min) && isNaN(max)) </li>
> 
> with an analogous update to the code.
> 

In that case we need to double (sorry) down on the NaNs and include sum as well:

*   <li>{@code (min <= max && !isNaN(sum)) || (isNaN(min) && isNaN(max) && isNaN(sum))}</li>

I updated the webrev and added some more tests:

  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8178117-summary-constructors/webrev/

Thanks,
Paul.



> Thanks,
> 
> -Joe
> 
> On 10/30/2017 3:49 PM, Paul Sandoz wrote:
>> Hi Chris,
>> 
>> After some hiatus here is an updated webrev, i made some tweaks to the JavaDoc:
>> 
>>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8178117-summary-constructors/webrev/
>> 
>> And the CSR:
>> 
>>   https://bugs.openjdk.java.net/browse/JDK-8190381
>> 
>> The support for a double sum of consisting of an array of double is going beyond my complexity budget for this feature. If that is deemed important later on we can add another constructor.
>> 
>> Paul.
>> 
>>> On 11 Apr 2017, at 17:44, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>>> 
>>> Updated patch with the changed parameter validation, updated javadoc and added test coverage.
>>> 
>>> <8178117.2.patch.txt>
>>> 
>>>> On Apr 11, 2017, at 4:48 PM, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>>>> 
>>>> Color me confused? what would the javadoc on the parameter say? It could I guess have an @implNote documenting the meanings of the parameters? but then what use is it? The proposed API simply limits the precision with which a DoubleSummaryStatistic can be copied to be the same as the precision with which it can be ?accessed?.  That doesn?t seem an enormous problem since I suspect that bulk of usages would be to marshall a ?finished? instance and therefore there is no real loss occuring. If we wanted to support arbitrary precision wouldn?t it be better to have a constructor variant that took a BigDecimal, and a matching getPreciseSum() that returned a BigDecimal?
>>>> 
>>>> Chris
>>>> 
>>>>> On Apr 11, 2017, at 4:16 PM, joe darcy <joe.darcy at oracle.com> wrote:
>>>>> 
>>>>> On an API design note, I would prefer to DoubleSummaryStatistics took a double... argument to pass in the state of the summation. This flexibility is necessary to more fully preserve the computed sum. Also, the we want flexibility to change the amount of internal state DoubleSummaryStats keeps so we don't want to hard-code that into as aspect of the API.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> -Joe
>>>>> 
>>>>> 
>>>>> On 4/11/2017 12:53 PM, Paul Sandoz wrote:
>>>>>> Hi Chris,
>>>>>> 
>>>>>> Thanks for looking at this.
>>>>>> 
>>>>>> There is some rudimentary testing using streams in CollectAndSummaryStatisticsTest.java.
>>>>>> 
>>>>>> I think we should enforce constraints where we reliably can:
>>>>>> 
>>>>>> 1) count >= 0
>>>>>> 
>>>>>> 2) count = 0, then min/max/sum are ignored and it?s as if the default constructor was called. (I thought it might be appropriate to reject since a caller might be passing in incorrect information in error, but the defaults for min/max are important and would be a burden for the caller to pass those values.) In this respect having count as the first parameter of the constructor would be useful.
>>>>>> 
>>>>>> 3)  min <= max
>>>>>> 
>>>>>> Since for count > 0 the constraints, count * max >= sum, count * min <= sum, cannot be reliably enforced due to overflow i am inclined to not bother and just document.
>>>>>> 
>>>>>> 
>>>>>> Note this is gonna be blocked from pushing until the new Compatibility and Specification Review (CSR) process is opened up, which i understand is ?soon"ish :-) but that should not block adding some further tests in the interim and tidying up the javadoc.
>>>>>> 
>>>>>> Paul.
>>>>>> 
>>>>>> 
>>>>>>> On 6 Apr 2017, at 07:08, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>>>>>>> 
>>>>>>> Hi Paul (et al)
>>>>>>> 
>>>>>>> Like all things API there are wrinkles here when it comes to implementing.
>>>>>>> 
>>>>>>> This patch isn?t final, there appears to be no existing test coverage for these classes beyond testing the compensating summation used in the double implementation, and I left off adding any until it was decided how much parameter validation we want (since that?s the only testing that can really occur here).
>>>>>>> 
>>>>>>> The wrinkles relate to the issues around instances that have suffered overflow in count and/or sum which the existing implementation doesn?t defend against:
>>>>>>> 
>>>>>>> * I chose to ignore all parameters if 'count == 0? and just leave the instance empty. I held off from validating min, max and count however. This obviously 'breaks things? (beyond how broken they would already be) if count == 0 only due to overflow.
>>>>>>> * I chose to fail if count is negative.
>>>>>>> * I chose to enforce that max and min are logically consistent with count and sum, this can break the moment either one of the overflows as well (I?m also pretty sure that the FPU logic is going to suffer here too - there might be some magic I can do with a pessimistic bit of rounding on the FPU multiplication result).
>>>>>>> 
>>>>>>> I intentionally went with the most aggressive parameter validation here to establish one end of what could be implemented.  There are arguments for this and also arguments for the other extreme (no validation at all).  Personally I?m in favor of the current version where the creation will fail if the inputs are only possible through overflow (modulo fixing the FPU precision issues above) even though it?s at odds with approach of the existing implementation.
>>>>>>> 
>>>>>>> Would appreciate thoughts/feedback.  Thanks.
>>>>>>> 
>>>>>>> Chris
>>>>>>> 
>>>>>>> 
>>>>>>> P.S. I presume tests would be required for the parameter checking (once it is finalized)?
>>>>>>> 
>>>>>>> <8178117.patch>
>>>>> 
>>>> 
>>> 
>> 
> 


From david.holmes at oracle.com  Tue Oct 31 04:37:00 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Oct 2017 14:37:00 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
Message-ID: <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>

Hi Roger,

On 31/10/2017 12:43 AM, Roger Riggs wrote:
> Hi David,
> 
> On 10/30/2017 3:31 AM, David Holmes wrote:
>> Hi Andrej,
>>
>> On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
>>> Hi David,
>>>
>>>> On 30. Oct 2017, at 01:40, David Holmes <david.holmes at oracle.com> 
>>>> wrote:
>>>>
>>>> Hi Roger,
>>>>
>>>> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>>>>> Hi,
>>>>> With the deprecation of Object.finalize its time to look at its 
>>>>> uses too see if they can be removed or mitigated.
>>>>
>>>> So the nice thing about finalize was that it followed a 
>>>> nice/clean/simple OO model where a subclass could override, add 
>>>> their own cleanup and then call super.finalize(). With finalize() 
>>>> deprecated, and the new mechanism being Cleaners, how do Cleaners 
>>>> support such usages?
>>>
>>> Instead of ThreadPoolExecutor.finalize you can override 
>>> ThreadPoolExecutor.terminated.
>>
>> True. Though overriding shutdown() would be the semantic equivalent of 
>> overriding finalize(). :)
>>
>> In the general case though finalize() might be invoking a final method.
>>
>> Anyway I'm not sure we can actually do something to try to move away 
>> from use of finalize() in TPE. finalize() is only deprecated - it is 
>> still expected to work as it has always done. Existing subclasses that 
>> override finalize() must continue to work until some point where we 
>> say finalize() is not only deprecated but obsoleted (it no longer does 
>> anything). So until then is there actually any point in doing 
>> anything? Does having a Cleaner and a finalize() method make sense? 
>> Does it aid in the transition?
> As you observe, the alternatives directly using PhantomRefs or the 
> Cleanup do not provide
> as nice a model.? Unfortunately, that model has been recognized to have 
> a number of
> issues [1].? Finalization is a poor substitute for explicit shutdown, it 
> is unpredictable and unreliable,
> and not guaranteed to be executed.

I'm not trying to support/defend finalize(). But it does support the 
very common OO pattern of "override to specialize then call super".

> ThreadPoolExecutor has a responsibility to cleanup any native resources 
> it has allocated (threads)
> and it should be free to use whatever mechanism is appropriate. 
> Currently, the spec for finalize
> does not give it that freedom.

I suppose in hindsight we (JSR-166 EG) could have described automatic 
shutdown without mentioning the word "finalize", but that ship has 
sailed. We did specify it and people can expect it to be usable and they 
can expect it to work. While encouraging people to move away from 
finalization is a good thing you have to give them a workable replacement.

> The initiative is to identify and remediate existing uses of 
> finalization in the JDK.
> The primary concern is about subclasses that reply on the current spec.
> If I'm using grepcode correctly[2], it does not show any subclasses of 
> ThreadPoolExecutor that
> override finalize; so it may be a non-issue.

Pardon my skepticism if I don't consider "grepcode" as a reasonable 
indicator of whether there are subclasses of TPE that override finalize. 
Only a small fraction of source code is in the open.

And I have to agree with Martin that the current documentation for 
finalize() in TPE is somewhat inappropriate. If you deprecate something 
you're supposed to point the user to the preferred way of doing 
something other than the deprecated method - but there is none. 
finalize() in TPE should not have been deprecated until we provided that 
alternative.

I think the way forward here would be to:

1. Change TPE.finalize() to final to force any subclasses to migrate to 
the new mechanism going forward.

2. Implement the new mechanism - presumably Cleaner - and document how 
to achieve the effect of "override to specialize then call super" 
(presumably by overriding shutdown() instead).

then in a few releases we remove TPE.finalize() (at the same time as we 
remove it from Object).

Cheers,
David

> Regards, Roger
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8165641
> 
> [2] 
> http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root at jdk%24openjdk at 8u40-b25@java%24util%24concurrent at ThreadPoolExecutor@finalize%28%29&k=d
> 

From peter.levart at gmail.com  Tue Oct 31 07:36:45 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 31 Oct 2017 08:36:45 +0100
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <81dd2a19-0818-9c1e-7d7f-30132c008f02@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
 <81dd2a19-0818-9c1e-7d7f-30132c008f02@oracle.com>
Message-ID: <c8164676-2d4c-1cf2-9b30-a55e1e9d8ac9@gmail.com>

Hi,

On 10/31/17 05:12, David Holmes wrote:
> On 31/10/2017 1:02 AM, David Lloyd wrote:
>> On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs <Roger.Riggs at oracle.com> 
>> wrote:
>>> ThreadPoolExecutor has a responsibility to cleanup any native 
>>> resources it
>>> has allocated (threads) and it should be free to use whatever 
>>> mechanism is appropriate.
>>
>> I wonder though whether TPE.finalize() is ever actually hit in
>> practice: TPE is (by definition) a thread pool, and every live thread
>> in that pool has (by way of TPE.Worker) a strong reference to the TPE
>> itself via an outer class reference which is passed around in enough
>> places to make me think that it would never actually be collectable in
>> a real-world situation, unless all core threads were allowed to time
>> out.
>
> The docs for TPE cover this in detail: [1]
>
> Finalization
> ??? A pool that is no longer referenced in a program AND has no 
> remaining threads will be shutdown automatically. If you would like to 
> ensure that unreferenced pools are reclaimed even if users forget to 
> call shutdown(), then you must arrange that unused threads eventually 
> die, by setting appropriate keep-alive times, using a lower bound of 
> zero core threads and/or setting allowCoreThreadTimeOut(boolean).

I'm trying to understand the purpose of finalize() in TPE, but can't. 
I'm surely missing something. If the pool is no longer referenced AND 
there are no active threads, what is there left to shutdown() actually? 
All that remains is garbage that will eventually be GCed.

Regards, Peter

>
> David
> -----
>
> [1] 
> https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/ThreadPoolExecutor.html
>


From david.holmes at oracle.com  Tue Oct 31 07:45:31 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Oct 2017 17:45:31 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <c8164676-2d4c-1cf2-9b30-a55e1e9d8ac9@gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
 <81dd2a19-0818-9c1e-7d7f-30132c008f02@oracle.com>
 <c8164676-2d4c-1cf2-9b30-a55e1e9d8ac9@gmail.com>
Message-ID: <e6da131a-2615-7ab6-dbc4-6016db99d317@oracle.com>

On 31/10/2017 5:36 PM, Peter Levart wrote:
> On 10/31/17 05:12, David Holmes wrote:
>> On 31/10/2017 1:02 AM, David Lloyd wrote:
>>> On Mon, Oct 30, 2017 at 9:43 AM, Roger Riggs <Roger.Riggs at oracle.com> 
>>> wrote:
>>>> ThreadPoolExecutor has a responsibility to cleanup any native 
>>>> resources it
>>>> has allocated (threads) and it should be free to use whatever 
>>>> mechanism is appropriate.
>>>
>>> I wonder though whether TPE.finalize() is ever actually hit in
>>> practice: TPE is (by definition) a thread pool, and every live thread
>>> in that pool has (by way of TPE.Worker) a strong reference to the TPE
>>> itself via an outer class reference which is passed around in enough
>>> places to make me think that it would never actually be collectable in
>>> a real-world situation, unless all core threads were allowed to time
>>> out.
>>
>> The docs for TPE cover this in detail: [1]
>>
>> Finalization
>> ??? A pool that is no longer referenced in a program AND has no 
>> remaining threads will be shutdown automatically. If you would like to 
>> ensure that unreferenced pools are reclaimed even if users forget to 
>> call shutdown(), then you must arrange that unused threads eventually 
>> die, by setting appropriate keep-alive times, using a lower bound of 
>> zero core threads and/or setting allowCoreThreadTimeOut(boolean).
> 
> I'm trying to understand the purpose of finalize() in TPE, but can't. 
> I'm surely missing something. If the pool is no longer referenced AND 
> there are no active threads, what is there left to shutdown() actually? 
> All that remains is garbage that will eventually be GCed.

Ummmmm .... I'm going to have to do some archaeology here ...

David

> Regards, Peter
> 
>>
>> David
>> -----
>>
>> [1] 
>> https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/ThreadPoolExecutor.html
>>
> 

From peter.levart at gmail.com  Tue Oct 31 08:25:25 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 31 Oct 2017 09:25:25 +0100
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <e6da131a-2615-7ab6-dbc4-6016db99d317@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
 <81dd2a19-0818-9c1e-7d7f-30132c008f02@oracle.com>
 <c8164676-2d4c-1cf2-9b30-a55e1e9d8ac9@gmail.com>
 <e6da131a-2615-7ab6-dbc4-6016db99d317@oracle.com>
Message-ID: <328ddb3a-e412-67df-c3e0-0574006854e3@gmail.com>

Hi David,

On 10/31/17 08:45, David Holmes wrote:
>>> The docs for TPE cover this in detail: [1]
>>>
>>> Finalization
>>> ??? A pool that is no longer referenced in a program AND has no 
>>> remaining threads will be shutdown automatically. If you would like 
>>> to ensure that unreferenced pools are reclaimed even if users forget 
>>> to call shutdown(), then you must arrange that unused threads 
>>> eventually die, by setting appropriate keep-alive times, using a 
>>> lower bound of zero core threads and/or setting 
>>> allowCoreThreadTimeOut(boolean).
>>
>> I'm trying to understand the purpose of finalize() in TPE, but can't. 
>> I'm surely missing something. If the pool is no longer referenced AND 
>> there are no active threads, what is there left to shutdown() 
>> actually? All that remains is garbage that will eventually be GCed.
>
> Ummmmm .... I'm going to have to do some archaeology here ...
>
> David

I can imagine a thread pool where worker threads, while idling, don't 
have a reference to the pool so the pool can shutdown() itself when:

- the pool is no longer referenced AND
- there is no worker thread executing a task (i.e. all worker threads 
are idle)

In such state, the pool is not reachable and may be shutdown.

But it seems that TPE is not such a pool.

Regards, Peter

>
>> Regards, Peter
>>
>>>
>>> David
>>> -----
>>>
>>> [1] 
>>> https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/ThreadPoolExecutor.html 
>>


From david.holmes at oracle.com  Tue Oct 31 08:55:31 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Oct 2017 18:55:31 +1000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <328ddb3a-e412-67df-c3e0-0574006854e3@gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
 <81dd2a19-0818-9c1e-7d7f-30132c008f02@oracle.com>
 <c8164676-2d4c-1cf2-9b30-a55e1e9d8ac9@gmail.com>
 <e6da131a-2615-7ab6-dbc4-6016db99d317@oracle.com>
 <328ddb3a-e412-67df-c3e0-0574006854e3@gmail.com>
Message-ID: <a14481fc-fa22-18ae-f28e-ad29fdabeb1a@oracle.com>

Hi Peter,

cc'ing Doug Lea

On 31/10/2017 6:25 PM, Peter Levart wrote:
> Hi David,
> 
> On 10/31/17 08:45, David Holmes wrote:
>>>> The docs for TPE cover this in detail: [1]
>>>>
>>>> Finalization
>>>> ??? A pool that is no longer referenced in a program AND has no 
>>>> remaining threads will be shutdown automatically. If you would like 
>>>> to ensure that unreferenced pools are reclaimed even if users forget 
>>>> to call shutdown(), then you must arrange that unused threads 
>>>> eventually die, by setting appropriate keep-alive times, using a 
>>>> lower bound of zero core threads and/or setting 
>>>> allowCoreThreadTimeOut(boolean).
>>>
>>> I'm trying to understand the purpose of finalize() in TPE, but can't. 
>>> I'm surely missing something. If the pool is no longer referenced AND 
>>> there are no active threads, what is there left to shutdown() 
>>> actually? All that remains is garbage that will eventually be GCed.
>>
>> Ummmmm .... I'm going to have to do some archaeology here ...
>>
>> David
> 
> I can imagine a thread pool where worker threads, while idling, don't 
> have a reference to the pool so the pool can shutdown() itself when:
> 
> - the pool is no longer referenced AND
> - there is no worker thread executing a task (i.e. all worker threads 
> are idle)
> 
> In such state, the pool is not reachable and may be shutdown.
> 
> But it seems that TPE is not such a pool.

Right. The TPE has a set of Workers (nested class) and each Worker has a 
Thread. The Thread executes the code of the Worker, so unless we hit the 
classic finalize problem of "this" being elided in a running method 
allowing the current object to get collected, then in theory any live 
worker threads should keep the whole TPE reachable.

In 2006 we added the docs about it being unreferenced and no remaining 
threads - which I guess is a necessary condition for finalization to now 
occur. But as you noted at that point shutdown() is pretty much a no-op.

Maybe Doug (cc'd) can recall the gory details. :)

Cheers,
David

> Regards, Peter
> 
>>
>>> Regards, Peter
>>>
>>>>
>>>> David
>>>> -----
>>>>
>>>> [1] 
>>>> https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/ThreadPoolExecutor.html 
>>>
> 

From peter.levart at gmail.com  Tue Oct 31 09:24:42 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 31 Oct 2017 10:24:42 +0100
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
Message-ID: <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>

Hi,

Here are some of my thoughts...

On 10/31/17 05:37, David Holmes wrote:
> Hi Roger,
>
> On 31/10/2017 12:43 AM, Roger Riggs wrote:
>> Hi David,
>>
>> On 10/30/2017 3:31 AM, David Holmes wrote:
>>> Hi Andrej,
>>>
>>> On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
>>>> Hi David,
>>>>
>>>>> On 30. Oct 2017, at 01:40, David Holmes <david.holmes at oracle.com> 
>>>>> wrote:
>>>>>
>>>>> Hi Roger,
>>>>>
>>>>> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>>>>>> Hi,
>>>>>> With the deprecation of Object.finalize its time to look at its 
>>>>>> uses too see if they can be removed or mitigated.
>>>>>
>>>>> So the nice thing about finalize was that it followed a 
>>>>> nice/clean/simple OO model where a subclass could override, add 
>>>>> their own cleanup and then call super.finalize(). With finalize() 
>>>>> deprecated, and the new mechanism being Cleaners, how do Cleaners 
>>>>> support such usages?
>>>>
>>>> Instead of ThreadPoolExecutor.finalize you can override 
>>>> ThreadPoolExecutor.terminated.
>>>
>>> True. Though overriding shutdown() would be the semantic equivalent 
>>> of overriding finalize(). :)
>>>
>>> In the general case though finalize() might be invoking a final method.

Overriding shutdown() would only work when this method is explicitly 
invoked by user code. Using Cleaner API instead of finalization can not 
employ methods on object that is being tracked as that object is already 
gone when Cleaner invokes the cleanup function.

Migrating TPE to Cleaner API might be particularly painful since the 
state needed to perform the shutdown is currently in the TPE instance 
fields and would have to be moved into the cleanup function. The easiest 
way to do that is to:

- rename class ThreadPoolExecutor to package-private ThreadPoolExecutorImpl
- create new class ThreadPoolExecutor with same public API delegating 
the functionality to the embedded implementation
- registering Cleaner.Cleanable to perform shutdown of embedded executor 
when the public-facing executor becomes phantom reachable

This would have an added benefit of automatically shut(ing)down() the 
pool when it is not reachable any more but still has idle threads.

>>>
>>> Anyway I'm not sure we can actually do something to try to move away 
>>> from use of finalize() in TPE. finalize() is only deprecated - it is 
>>> still expected to work as it has always done. Existing subclasses 
>>> that override finalize() must continue to work until some point 
>>> where we say finalize() is not only deprecated but obsoleted (it no 
>>> longer does anything). So until then is there actually any point in 
>>> doing anything? Does having a Cleaner and a finalize() method make 
>>> sense? Does it aid in the transition?
>> As you observe, the alternatives directly using PhantomRefs or the 
>> Cleanup do not provide
>> as nice a model.? Unfortunately, that model has been recognized to 
>> have a number of
>> issues [1].? Finalization is a poor substitute for explicit shutdown, 
>> it is unpredictable and unreliable,
>> and not guaranteed to be executed.
>
> I'm not trying to support/defend finalize(). But it does support the 
> very common OO pattern of "override to specialize then call super".

I have been thinking about that and I see two approaches to enable 
subclasses to contribute cleanup code:

- one simple approach is for each subclass to use it's own independent 
Cleaner/Cleanable. The benefit is that each subclass is independent of 
its super/sub classes, the drawback is that cleanup functions are called 
in arbitrary order, even in different threads. But for cleaning-up 
independent resources this should work.

- the other approach is more involving as it requires the base class to 
establish an infrastructure for contributing cleanup code. For this 
purpose, the internal low-level Cleaner API is most appropriate thought 
it can be done with public API too. For example (with public API):


public class BaseClass implements AutoCloseable {

 ??? protected static class BaseResource implements Runnable {
 ??????? @Override
 ??????? public void run() {
 ??????????? // cleanup
 ??????? }
 ??? }

 ??? protected final BaseResource resource = createResource();
 ??? private final Cleaner.Cleanable cleanable = 
CleanerFactory.cleaner().register(this, resource);

 ??? protected BaseResource createResource() {
 ??????? return new BaseResource();
 ??? }

 ??? public BaseClass() {
 ??????? // init BaseResource resource...
 ??? }

 ??? @Override
 ??? public final void close() {
 ??????? cleanable.clean();
 ??? }
}


public class DerivedClass extends BaseClass {

 ??? protected static class DerivedResource extends BaseResource {
 ??????? @Override
 ??????? public void run() {
 ??????????? // before-super cleanup
 ??????????? super.run();
 ??????????? // after-super cleanup
 ??????? }
 ??? }

 ??? @Override
 ??? protected DerivedResource createResource() {
 ??????? return new DerivedResource();
 ??? }

 ??? public DerivedClass() {
 ??????? super();
 ??????? DerivedResource resource = (DerivedResource) this.resource;
 ??????? // init DerivedResource resource
 ??? }
}


And alternative with private low-level API:


public class BaseClass implements AutoCloseable {

 ??? protected static class BaseResource extends 
PhantomCleanable<BaseClass> {

 ??????? protected BaseResource(BaseClass referent) {
 ??????????? super(referent, CleanerFactory.cleaner());
 ??????? }

 ??????? @Override
 ??????? protected void performCleanup() {
 ??????????? // cleanup
 ??????? }
 ??? }

 ??? protected final BaseResource resource = createResource();

 ??? protected BaseResource createResource() {
 ??????? return new BaseResource(this);
 ??? }

 ??? public BaseClass() {
 ??????? // init BaseResource resource...
 ??? }

 ??? @Override
 ??? public final void close() {
 ??????? resource.clean();
 ??? }
}


public class DerivedClass extends BaseClass {

 ??? protected static class DerivedResource extends BaseResource {

 ??????? protected DerivedResource(DerivedClass referent) {
 ??????????? super(referent);
 ??????? }

 ??????? @Override
 ??????? protected void performCleanup() {
 ??????????? // before-super cleanup
 ??????????? super.performCleanup();
 ??????????? // after-super cleanup
 ??????? }
 ??? }

 ??? @Override
 ??? protected DerivedResource createResource() {
 ??????? return new DerivedResource(this);
 ??? }

 ??? public DerivedClass() {
 ??????? super();
 ??????? DerivedResource resource = (DerivedResource) this.resource;
 ??????? // init DerivedResource resource
 ??? }
}


Regards, Peter

>
>> ThreadPoolExecutor has a responsibility to cleanup any native 
>> resources it has allocated (threads)
>> and it should be free to use whatever mechanism is appropriate. 
>> Currently, the spec for finalize
>> does not give it that freedom.
>
> I suppose in hindsight we (JSR-166 EG) could have described automatic 
> shutdown without mentioning the word "finalize", but that ship has 
> sailed. We did specify it and people can expect it to be usable and 
> they can expect it to work. While encouraging people to move away from 
> finalization is a good thing you have to give them a workable 
> replacement.
>
>> The initiative is to identify and remediate existing uses of 
>> finalization in the JDK.
>> The primary concern is about subclasses that reply on the current spec.
>> If I'm using grepcode correctly[2], it does not show any subclasses 
>> of ThreadPoolExecutor that
>> override finalize; so it may be a non-issue.
>
> Pardon my skepticism if I don't consider "grepcode" as a reasonable 
> indicator of whether there are subclasses of TPE that override 
> finalize. Only a small fraction of source code is in the open.
>
> And I have to agree with Martin that the current documentation for 
> finalize() in TPE is somewhat inappropriate. If you deprecate 
> something you're supposed to point the user to the preferred way of 
> doing something other than the deprecated method - but there is none. 
> finalize() in TPE should not have been deprecated until we provided 
> that alternative.
>
> I think the way forward here would be to:
>
> 1. Change TPE.finalize() to final to force any subclasses to migrate 
> to the new mechanism going forward.
>
> 2. Implement the new mechanism - presumably Cleaner - and document how 
> to achieve the effect of "override to specialize then call super" 
> (presumably by overriding shutdown() instead).
>
> then in a few releases we remove TPE.finalize() (at the same time as 
> we remove it from Object).
>
> Cheers,
> David
>
>> Regards, Roger
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8165641
>>
>> [2] 
>> http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root at jdk%24openjdk at 8u40-b25@java%24util%24concurrent at ThreadPoolExecutor@finalize%28%29&k=d
>>


From dl at cs.oswego.edu  Tue Oct 31 11:07:55 2017
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 31 Oct 2017 07:07:55 -0400
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <a14481fc-fa22-18ae-f28e-ad29fdabeb1a@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
 <81dd2a19-0818-9c1e-7d7f-30132c008f02@oracle.com>
 <c8164676-2d4c-1cf2-9b30-a55e1e9d8ac9@gmail.com>
 <e6da131a-2615-7ab6-dbc4-6016db99d317@oracle.com>
 <328ddb3a-e412-67df-c3e0-0574006854e3@gmail.com>
 <a14481fc-fa22-18ae-f28e-ad29fdabeb1a@oracle.com>
Message-ID: <2c8418d2-9e66-d465-93fa-1412ad1c72ee@cs.oswego.edu>

On 10/31/2017 04:55 AM, David Holmes wrote:
>  
> In 2006 we added the docs about it being unreferenced and no remaining
> threads - which I guess is a necessary condition for finalization to now
> occur. But as you noted at that point shutdown() is pretty much a no-op.
> 
> Maybe Doug (cc'd) can recall the gory details. :)
> 
We added the wording to deal with complaints that pools were not
being auto-shutdown. But we didn't notice that the conditions for
finalization to trigger were the same as the conditions for
finalization not being necessary! (Just GCing would be fine.)

The best solution seems to be just to remove the method, and
adjust the javadoc wording to refer to GC vs finalization.

I think this would be binary compatible?

-Doug

From Roger.Riggs at Oracle.com  Tue Oct 31 13:43:19 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 31 Oct 2017 09:43:19 -0400
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
Message-ID: <49de9785-ce8c-5384-cd4f-d8dd555b06b1@Oracle.com>

Hi David,

On 10/31/2017 12:37 AM, David Holmes wrote:
> Hi Roger,
>
> On 31/10/2017 12:43 AM, Roger Riggs wrote:
>> Hi David,
>>
>> On 10/30/2017 3:31 AM, David Holmes wrote:
>>> Hi Andrej,
>>>
>>> On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
>>>> Hi David,
>>>>
>>>>> On 30. Oct 2017, at 01:40, David Holmes <david.holmes at oracle.com> 
>>>>> wrote:
>>>>>
>>>>> Hi Roger,
>>>>>
>>>>> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>>>>>> Hi,
>>>>>> With the deprecation of Object.finalize its time to look at its 
>>>>>> uses too see if they can be removed or mitigated.
>>>>>
>>>>> So the nice thing about finalize was that it followed a 
>>>>> nice/clean/simple OO model where a subclass could override, add 
>>>>> their own cleanup and then call super.finalize(). With finalize() 
>>>>> deprecated, and the new mechanism being Cleaners, how do Cleaners 
>>>>> support such usages?
>>>>
>>>> Instead of ThreadPoolExecutor.finalize you can override 
>>>> ThreadPoolExecutor.terminated.
>>>
>>> True. Though overriding shutdown() would be the semantic equivalent 
>>> of overriding finalize(). :)
>>>
>>> In the general case though finalize() might be invoking a final method.
>>>
>>> Anyway I'm not sure we can actually do something to try to move away 
>>> from use of finalize() in TPE. finalize() is only deprecated - it is 
>>> still expected to work as it has always done. Existing subclasses 
>>> that override finalize() must continue to work until some point 
>>> where we say finalize() is not only deprecated but obsoleted (it no 
>>> longer does anything). So until then is there actually any point in 
>>> doing anything? Does having a Cleaner and a finalize() method make 
>>> sense? Does it aid in the transition?
>> As you observe, the alternatives directly using PhantomRefs or the 
>> Cleanup do not provide
>> as nice a model.? Unfortunately, that model has been recognized to 
>> have a number of
>> issues [1].? Finalization is a poor substitute for explicit shutdown, 
>> it is unpredictable and unreliable,
>> and not guaranteed to be executed.
>
> I'm not trying to support/defend finalize(). But it does support the 
> very common OO pattern of "override to specialize then call super".
>
>> ThreadPoolExecutor has a responsibility to cleanup any native 
>> resources it has allocated (threads)
>> and it should be free to use whatever mechanism is appropriate. 
>> Currently, the spec for finalize
>> does not give it that freedom.
>
> I suppose in hindsight we (JSR-166 EG) could have described automatic 
> shutdown without mentioning the word "finalize", but that ship has 
> sailed. We did specify it and people can expect it to be usable and 
> they can expect it to work. While encouraging people to move away from 
> finalization is a good thing you have to give them a workable 
> replacement.
>
>> The initiative is to identify and remediate existing uses of 
>> finalization in the JDK.
>> The primary concern is about subclasses that reply on the current spec.
>> If I'm using grepcode correctly[2], it does not show any subclasses 
>> of ThreadPoolExecutor that
>> override finalize; so it may be a non-issue.
>
> Pardon my skepticism if I don't consider "grepcode" as a reasonable 
> indicator of whether there are subclasses of TPE that override 
> finalize. Only a small fraction of source code is in the open.
Not cited as authoritative, just one data point.
>
> And I have to agree with Martin that the current documentation for 
> finalize() in TPE is somewhat inappropriate. If you deprecate 
> something you're supposed to point the user to the preferred way of 
> doing something other than the deprecated method - but there is none. 
> finalize() in TPE should not have been deprecated until we provided 
> that alternative.
In all the years of hand wringing over finalize no perfect replacement 
has been discovered.
Deprecating and providing some advice, though not perfect for every 
situation is a way
to get people thinking about alternatives that work in various cases.
>
> I think the way forward here would be to:
>
> 1. Change TPE.finalize() to final to force any subclasses to migrate 
> to the new mechanism going forward.
>
> 2. Implement the new mechanism - presumably Cleaner - and document how 
> to achieve the effect of "override to specialize then call super" 
> (presumably by overriding shutdown() instead).
>
> then in a few releases we remove TPE.finalize() (at the same time as 
> we remove it from Object).
The first step is to deal with our own uses with in the JDK and try out 
some workable alternatives
without breaking everything all at once.? It is expected to take a while 
to mitigate all the uses.
In the meantime, reducing the uses and overhead due to finalization 
gives a performance benefit.

Roger

>
> Cheers,
> David
>
>> Regards, Roger
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8165641
>>
>> [2] 
>> http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root at jdk%24openjdk at 8u40-b25@java%24util%24concurrent at ThreadPoolExecutor@finalize%28%29&k=d
>>


From Roger.Riggs at Oracle.com  Tue Oct 31 13:58:05 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 31 Oct 2017 09:58:05 -0400
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <92dfa05b-8d0d-5908-c005-983813f5e8c6@oracle.com>
 <c18540d1-a7bb-1ec5-2be2-ddaaae567e98@gmail.com>
Message-ID: <7a126a10-6e82-63e3-e413-14a134347f89@Oracle.com>

Hi Peter,

Only native resources that do not map to the heap allocation/gc cycle 
need any kind
of cleanup.? I would work toward a model that encapsulates the reference 
to a native resource
with a corresponding allocation/release mechanism as you've described 
here and in the
thread on zip.

For cleanup purposes, the independence of each resource may improve 
robustness
by avoiding dependencies and opportunities for entanglements and bugs 
due to exceptions
and other failures.

In the case of TPE, the native resources are Threads, which keep running 
even if they are
unreferenced and are kept referenced via ThreadGroups.
I don't know the Executor code well enough to do more than speculate, 
but would suggest
that a cleaner (or similar) should be registered for each thread .

For TPE, since Threads do not become unreferenced, the part of the spec 
related to finalize
being called by the finalizer thread is moot.

$.02, Roger

On 10/31/2017 5:24 AM, Peter Levart wrote:
> Hi,
>
> Here are some of my thoughts...
>
> On 10/31/17 05:37, David Holmes wrote:
>> Hi Roger,
>>
>> On 31/10/2017 12:43 AM, Roger Riggs wrote:
>>> Hi David,
>>>
>>> On 10/30/2017 3:31 AM, David Holmes wrote:
>>>> Hi Andrej,
>>>>
>>>> On 30/10/2017 5:02 PM, Andrej Golovnin wrote:
>>>>> Hi David,
>>>>>
>>>>>> On 30. Oct 2017, at 01:40, David Holmes <david.holmes at oracle.com> 
>>>>>> wrote:
>>>>>>
>>>>>> Hi Roger,
>>>>>>
>>>>>> On 30/10/2017 10:24 AM, Roger Riggs wrote:
>>>>>>> Hi,
>>>>>>> With the deprecation of Object.finalize its time to look at its 
>>>>>>> uses too see if they can be removed or mitigated.
>>>>>>
>>>>>> So the nice thing about finalize was that it followed a 
>>>>>> nice/clean/simple OO model where a subclass could override, add 
>>>>>> their own cleanup and then call super.finalize(). With finalize() 
>>>>>> deprecated, and the new mechanism being Cleaners, how do Cleaners 
>>>>>> support such usages?
>>>>>
>>>>> Instead of ThreadPoolExecutor.finalize you can override 
>>>>> ThreadPoolExecutor.terminated.
>>>>
>>>> True. Though overriding shutdown() would be the semantic equivalent 
>>>> of overriding finalize(). :)
>>>>
>>>> In the general case though finalize() might be invoking a final 
>>>> method.
>
> Overriding shutdown() would only work when this method is explicitly 
> invoked by user code. Using Cleaner API instead of finalization can 
> not employ methods on object that is being tracked as that object is 
> already gone when Cleaner invokes the cleanup function.
>
> Migrating TPE to Cleaner API might be particularly painful since the 
> state needed to perform the shutdown is currently in the TPE instance 
> fields and would have to be moved into the cleanup function. The 
> easiest way to do that is to:
>
> - rename class ThreadPoolExecutor to package-private 
> ThreadPoolExecutorImpl
> - create new class ThreadPoolExecutor with same public API delegating 
> the functionality to the embedded implementation
> - registering Cleaner.Cleanable to perform shutdown of embedded 
> executor when the public-facing executor becomes phantom reachable
>
> This would have an added benefit of automatically shut(ing)down() the 
> pool when it is not reachable any more but still has idle threads.
>
>>>>
>>>> Anyway I'm not sure we can actually do something to try to move 
>>>> away from use of finalize() in TPE. finalize() is only deprecated - 
>>>> it is still expected to work as it has always done. Existing 
>>>> subclasses that override finalize() must continue to work until 
>>>> some point where we say finalize() is not only deprecated but 
>>>> obsoleted (it no longer does anything). So until then is there 
>>>> actually any point in doing anything? Does having a Cleaner and a 
>>>> finalize() method make sense? Does it aid in the transition?
>>> As you observe, the alternatives directly using PhantomRefs or the 
>>> Cleanup do not provide
>>> as nice a model.? Unfortunately, that model has been recognized to 
>>> have a number of
>>> issues [1].? Finalization is a poor substitute for explicit 
>>> shutdown, it is unpredictable and unreliable,
>>> and not guaranteed to be executed.
>>
>> I'm not trying to support/defend finalize(). But it does support the 
>> very common OO pattern of "override to specialize then call super".
>
> I have been thinking about that and I see two approaches to enable 
> subclasses to contribute cleanup code:
>
> - one simple approach is for each subclass to use it's own independent 
> Cleaner/Cleanable. The benefit is that each subclass is independent of 
> its super/sub classes, the drawback is that cleanup functions are 
> called in arbitrary order, even in different threads. But for 
> cleaning-up independent resources this should work.
>
> - the other approach is more involving as it requires the base class 
> to establish an infrastructure for contributing cleanup code. For this 
> purpose, the internal low-level Cleaner API is most appropriate 
> thought it can be done with public API too. For example (with public API):
>
>
> public class BaseClass implements AutoCloseable {
>
> ??? protected static class BaseResource implements Runnable {
> ??????? @Override
> ??????? public void run() {
> ??????????? // cleanup
> ??????? }
> ??? }
>
> ??? protected final BaseResource resource = createResource();
> ??? private final Cleaner.Cleanable cleanable = 
> CleanerFactory.cleaner().register(this, resource);
>
> ??? protected BaseResource createResource() {
> ??????? return new BaseResource();
> ??? }
>
> ??? public BaseClass() {
> ??????? // init BaseResource resource...
> ??? }
>
> ??? @Override
> ??? public final void close() {
> ??????? cleanable.clean();
> ??? }
> }
>
>
> public class DerivedClass extends BaseClass {
>
> ??? protected static class DerivedResource extends BaseResource {
> ??????? @Override
> ??????? public void run() {
> ??????????? // before-super cleanup
> ??????????? super.run();
> ??????????? // after-super cleanup
> ??????? }
> ??? }
>
> ??? @Override
> ??? protected DerivedResource createResource() {
> ??????? return new DerivedResource();
> ??? }
>
> ??? public DerivedClass() {
> ??????? super();
> ??????? DerivedResource resource = (DerivedResource) this.resource;
> ??????? // init DerivedResource resource
> ??? }
> }
>
>
> And alternative with private low-level API:
>
>
> public class BaseClass implements AutoCloseable {
>
> ??? protected static class BaseResource extends 
> PhantomCleanable<BaseClass> {
>
> ??????? protected BaseResource(BaseClass referent) {
> ??????????? super(referent, CleanerFactory.cleaner());
> ??????? }
>
> ??????? @Override
> ??????? protected void performCleanup() {
> ??????????? // cleanup
> ??????? }
> ??? }
>
> ??? protected final BaseResource resource = createResource();
>
> ??? protected BaseResource createResource() {
> ??????? return new BaseResource(this);
> ??? }
>
> ??? public BaseClass() {
> ??????? // init BaseResource resource...
> ??? }
>
> ??? @Override
> ??? public final void close() {
> ??????? resource.clean();
> ??? }
> }
>
>
> public class DerivedClass extends BaseClass {
>
> ??? protected static class DerivedResource extends BaseResource {
>
> ??????? protected DerivedResource(DerivedClass referent) {
> ??????????? super(referent);
> ??????? }
>
> ??????? @Override
> ??????? protected void performCleanup() {
> ??????????? // before-super cleanup
> ??????????? super.performCleanup();
> ??????????? // after-super cleanup
> ??????? }
> ??? }
>
> ??? @Override
> ??? protected DerivedResource createResource() {
> ??????? return new DerivedResource(this);
> ??? }
>
> ??? public DerivedClass() {
> ??????? super();
> ??????? DerivedResource resource = (DerivedResource) this.resource;
> ??????? // init DerivedResource resource
> ??? }
> }
>
>
> Regards, Peter
>
>>
>>> ThreadPoolExecutor has a responsibility to cleanup any native 
>>> resources it has allocated (threads)
>>> and it should be free to use whatever mechanism is appropriate. 
>>> Currently, the spec for finalize
>>> does not give it that freedom.
>>
>> I suppose in hindsight we (JSR-166 EG) could have described automatic 
>> shutdown without mentioning the word "finalize", but that ship has 
>> sailed. We did specify it and people can expect it to be usable and 
>> they can expect it to work. While encouraging people to move away 
>> from finalization is a good thing you have to give them a workable 
>> replacement.
>>
>>> The initiative is to identify and remediate existing uses of 
>>> finalization in the JDK.
>>> The primary concern is about subclasses that reply on the current spec.
>>> If I'm using grepcode correctly[2], it does not show any subclasses 
>>> of ThreadPoolExecutor that
>>> override finalize; so it may be a non-issue.
>>
>> Pardon my skepticism if I don't consider "grepcode" as a reasonable 
>> indicator of whether there are subclasses of TPE that override 
>> finalize. Only a small fraction of source code is in the open.
>>
>> And I have to agree with Martin that the current documentation for 
>> finalize() in TPE is somewhat inappropriate. If you deprecate 
>> something you're supposed to point the user to the preferred way of 
>> doing something other than the deprecated method - but there is none. 
>> finalize() in TPE should not have been deprecated until we provided 
>> that alternative.
>>
>> I think the way forward here would be to:
>>
>> 1. Change TPE.finalize() to final to force any subclasses to migrate 
>> to the new mechanism going forward.
>>
>> 2. Implement the new mechanism - presumably Cleaner - and document 
>> how to achieve the effect of "override to specialize then call super" 
>> (presumably by overriding shutdown() instead).
>>
>> then in a few releases we remove TPE.finalize() (at the same time as 
>> we remove it from Object).
>>
>> Cheers,
>> David
>>
>>> Regards, Roger
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8165641
>>>
>>> [2] 
>>> http://grepcode.com/search/usages?type=method&id=repository.grepcode.com%24java%24root at jdk%24openjdk at 8u40-b25@java%24util%24concurrent at ThreadPoolExecutor@finalize%28%29&k=d
>>>
>


From jason_mehrens at hotmail.com  Tue Oct 31 14:13:11 2017
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Tue, 31 Oct 2017 14:13:11 +0000
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <c8164676-2d4c-1cf2-9b30-a55e1e9d8ac9@gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
 <81dd2a19-0818-9c1e-7d7f-30132c008f02@oracle.com>,
 <c8164676-2d4c-1cf2-9b30-a55e1e9d8ac9@gmail.com>
Message-ID: <DM5PR1801MB19453293F34E180D1E6392B0835E0@DM5PR1801MB1945.namprd18.prod.outlook.com>

Hi Peter,

Most of the discussion is in: https://bugs.openjdk.java.net/browse/JDK-6399443.  The linked issue in that report then links to the CI mail thread.

Jason


>I'm trying to understand the purpose of finalize() in TPE, but can't.
>I'm surely missing something. If the pool is no longer referenced AND
>there are no active threads, what is there left to shutdown() actually?
>All that remains is garbage that will eventually be GCed.

>Regards, Peter



From brian.goetz at oracle.com  Tue Oct 31 14:25:09 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 31 Oct 2017 10:25:09 -0400
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
Message-ID: <12dffddd-e11b-6fd2-5f1e-c3d29a93899c@oracle.com>

In "View Collections"

Most collections contain elements themselves. By contrast, <i>view 
collections</i>
112 * themselves do not contain elements, but instead rely on a backing 
collection to
113 * store the actual elements.


This should be: "most collections manage the storage for the elements 
they contain.? By contrast, ...".? (All collections contain their 
elements -- just ask the `contains()` method!)

Similarly, in:

Correspondingly, any changes made to
126 * the view collection are written through to the backing collection.


you might want to make the connection that views might "handle" the 
operation by prohibiting it; view collections need not support changes 
if they don't want to.

In

<b>Unmodifiable view collections.</b>

You might want to say explicitly "such as 
Collections.unmodifiable{List,Set,...}" when describing unmodifiable 
view collections.? THat's of course what you're getting at, but it could 
be said more explicitly.

Returns an <a href="#unmodifiable">unmodifiable List</a> containing the 
elements
1045 * of the given Collection, in iteration order.

In the _given collection's_ iteration order.

Returns an <a href="#unmodifiable">unmodifiable Map</a> containing the 
entries
1664 * of the given Map. the given Map must not be null, and it must not 
contain any
1665 * null keys or values. If the given Map is subsequently modified, 
the returned
1666 * Map will not reflect such modifications.

Second sentence starts with lower case later.

I might quibble with "subsequently modified", as there is some ambiguity 
(what if the map is concurrently modified, subsequent to making the 
copyOf() call, but prior to the return from copyOf()?) But I won't ;)

In

296 Collector<T, ?, List<T>> toUnmodifiableList() {
297 return new CollectorImpl<>((Supplier<List<T>>) ArrayList::new, 
List::add,
298 (left, right) -> { left.addAll(right); return left; },
299 list -> (List<T>)List.of(list.toArray()),
300 CH_NOID);

why the intermediate array, and not just use copyOf()?? (Is it because 
you added copyOf later and didn't go back and update this?)? Same for 
other collectors.








On 10/30/2017 6:50 PM, Stuart Marks wrote:
> (also includes 8184690: add Collectors for collecting into 
> unmodifiable List, Set, and Map)
>
> Hi all,
>
> Here's an updated webrev for this changeset; the previous review 
> thread is here:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html
>
> This webrev includes the following:
>
> * specification revisions to provide clearer definitions of "view" 
> collections, "unmodifiable" collections, and "unmodifiable views"
>
> * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" 
> methods
>
> * new Collectors.toUnmodifiableList, Set, and Map methods
>
> * tests for the new API methods
>
> I've added some assertions that require some independence between the 
> source collection (or map) and the result of the copyOf() method.
>
> I've made a small but significant change to Set.copyOf compared to the 
> previous round. Previously, it specified that the first of any equal 
> elements was preserved. Now, it is explicitly unspecified which of any 
> equals elements is preserved. This is consistent with Set.addAll, 
> Collectors.toSet, and the newly added Collectors.toUnmodifiableSet, 
> none of which specify which of duplicate elements is preserved.
>
> (The outlier here is Stream.distinct, which specifies that the first 
> element of any duplicates is preserved, if the stream is ordered.)
>
> I've also made some minor wording/editorial changes in response to 
> suggestions from David Holmes and Roger Riggs. I've kept the wording 
> changes that give emphasis to "unmodifiable" over "immutable." The 
> term "immutable" is inextricably intertwined with "persistent" when it 
> comes to data structures, and I believe we'll be explaining this 
> forever if Java's "immutable" means something different from everybody 
> else's.
>
> Webrev:
>
> ??? http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/
>
> Bugs:
>
> ??? https://bugs.openjdk.java.net/browse/JDK-8177290
> ??????? add copy factory methods for unmodifiable List, Set, Map
>
> ??? https://bugs.openjdk.java.net/browse/JDK-8184690
> ??????? add Collectors for collecting into unmodifiable List, Set, and 
> Map
>
> Thanks,
>
> s'marks


From dmitry.samersoff at bell-sw.com  Mon Oct 30 18:05:41 2017
From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff)
Date: Mon, 30 Oct 2017 21:05:41 +0300
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
Message-ID: <b8c8d33a-2782-cfba-64df-fc32151ac117@bell-sw.com>

Paul,

templateTable_x86.cpp:

 564   const Register flags = rcx;
 565   const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);

Should we use another register for rarg under NOT_LP64 ?

-Dmitry


On 10/26/2017 08:03 PM, Paul Sandoz wrote:
> Hi,
> 
> Please review the following patch for minimal dynamic constant support:
> 
>   http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
> 
>   https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
>   https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>
> 
> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.
> 
> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.
> 
> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).
> 
> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.
> 
> The CSR for the VM specification is here:
> 
>   https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>
> 
> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).
> 
> Any AoT-related work will be deferred to a future release.
> 
> ?
> 
> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).
> 
> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.
> 
> ?
> 
> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.
> 
> One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.
> 
> ?
> 
> Paul.
> 


From dmitry.samersoff at bell-sw.com  Tue Oct 31 12:58:37 2017
From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff)
Date: Tue, 31 Oct 2017 15:58:37 +0300
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <EBC28788-F65A-42F8-A6AD-7B670FDB74C5@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <b8c8d33a-2782-cfba-64df-fc32151ac117@bell-sw.com>
 <93431280-9CBF-4722-961D-F2D2D0F83B4E@oracle.com>
 <EBC28788-F65A-42F8-A6AD-7B670FDB74C5@oracle.com>
Message-ID: <d3d6c258-4a26-331b-a85c-9e7f23fa8229@bell-sw.com>

Paul and Frederic,

Thank you.

One more question. Do we need to call verify_oop below?

509   { // Check for the null sentinel.
...
517      xorptr(result, result);  // NULL object reference
...

521   if (VerifyOops) {
522      verify_oop(result);
523   }

-Dmitry


On 31.10.2017 00:56, Frederic Parain wrote:
> I?m seeing no issue with rcx being aliased in this code.
> 
> Fred
> 
>> On Oct 30, 2017, at 15:44, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>
>> Hi,
>>
>> Thanks for reviewing.
>>
>>> On 30 Oct 2017, at 11:05, Dmitry Samersoff <dmitry.samersoff at bell-sw.com> wrote:
>>>
>>> Paul,
>>>
>>> templateTable_x86.cpp:
>>>
>>> 564   const Register flags = rcx;
>>> 565   const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
>>>
>>> Should we use another register for rarg under NOT_LP64 ?
>>>
>>
>> I think it should be ok, it i ain?t an expert here on the interpreter and the calling conventions, so please correct me.
>>
>> Some more context:
>>
>> +  const Register flags = rcx;
>> +  const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
>> +  __ movl(rarg, (int)bytecode());
>>
>> The current bytecode code is loaded into ?rarg?
>>
>> +  call_VM(obj, CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_ldc), rarg);
>>
>> Then ?rarg" is the argument to the call to InterpreterRuntime::resolve_ldc, after which it is no longer referred to.
>>
>> +#ifndef _LP64
>> +  // borrow rdi from locals
>> +  __ get_thread(rdi);
>> +  __ get_vm_result_2(flags, rdi);
>> +  __ restore_locals();
>> +#else
>> +  __ get_vm_result_2(flags, r15_thread);
>> +#endif
>>
>> The result from the call is then loaded into flags.
>>
>> So i don?t think it matters in this case if rcx is aliased.
>>
>> Paul.
>>
>>> -Dmitry
>>>
>>>
>>> On 10/26/2017 08:03 PM, Paul Sandoz wrote:
>>>> Hi,
>>>>
>>>> Please review the following patch for minimal dynamic constant support:
>>>>
>>>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
>>>> https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>
>>>>
>>>> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.
>>>>
>>>> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.
>>>>
>>>> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).
>>>>
>>>> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.
>>>>
>>>> The CSR for the VM specification is here:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>
>>>>
>>>> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).
>>>>
>>>> Any AoT-related work will be deferred to a future release.
>>>>
>>>> ?
>>>>
>>>> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).
>>>>
>>>> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.
>>>>
>>>> ?
>>>>
>>>> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.
>>>>
>>>> One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.
>>>>
>>>> ?
>>>>
>>>> Paul.
>>>>
>>>
>>
> 



From kumar.x.srinivasan at oracle.com  Tue Oct 31 16:42:43 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 31 Oct 2017 09:42:43 -0700
Subject: RFR: 8190287: Update JDK's internal ASM to ASMv6
In-Reply-To: <59F3690B.6070309@oracle.com>
References: <59F3690B.6070309@oracle.com>
Message-ID: <59F8A803.9060305@oracle.com>

Hi Remi,

Are you ok with the ASMv6 changes ?

Thanks
Kumar

On 10/27/2017 10:12 AM, Kumar Srinivasan wrote:
> Hello Remi, Sundar and others,
>
> Please review the webrev [1] to update JDK's internal ASM to v6.
>
> To help with review areas, you can use the browser to search for mq 
> patches commented with //
>
> Highlights of changes:
> 1. updated ASMv6 // jdk-new-asmv6.patch
> 2. changes to jlink and jar to add ModuleMainClass and ModulePackages 
> attributes //jdk-new-asm-update.patch
> 3. adjustments to jdk tests  //jdk-new-asm-test.patch
> 4. minor adjustments  to hotspot tests //jdk-new-hotspot-test.patch
>
> Tests:
> jdk_tier1, jdk_tier2, testset hotspot, hotspot_tier1, nashorn ant tests,
> Alan has also run several tests.
>
> Big thanks to Alan for #2 and #3 as part of [3].
>
> Thanks
> Kumar
>
> [1] http://cr.openjdk.java.net/~ksrini/8190287/webrev.00/index.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8190287
> [3] https://bugs.openjdk.java.net/browse/JDK-8186236
>


From peter.levart at gmail.com  Tue Oct 31 17:30:25 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 31 Oct 2017 18:30:25 +0100
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <59F7B6A1.5040303@oracle.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
 <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
 <59F7B6A1.5040303@oracle.com>
Message-ID: <16e98d55-35c0-a039-edf5-95240bed2510@gmail.com>

Hi Sherman,

On 10/31/17 00:32, Xueming Shen wrote:
> On 10/30/2017 01:34 PM, Peter Levart wrote:
>>
>> The Inflater and Deflater now look fine (except you don't have to 
>> check for cleanable != null any more in Inflater.end()).
>>
>> But what shall we do with ZipFile?
>>
>
> Peter,
>
> The fundamental issue here is the gap between the resource allocation
> and the cleaner registration, as far as these two are not an atomic
> operation, it's hard to handle it in the normal use scenario. You might be
> able to workaround it by registering the cleaner first and then send the
> resource reference into the cleaner, as we are going to do for the 
> deflater/
> inflater. 

RIght. Finalization, as designed, usually guides the programmer to not 
mess this order. The finalizable instance is registered as part of 
Object.<init> constructor call. When resource allocation happens in the 
subclass constructor(s), all is well, because code of subclass 
constructors is executed after Object.<init> successfully returns. 
Subclassing PhantomCleanable<T> has this same good property when 
resource allocation is performed in the PhantomCleanable's subclass 
constructor(s).

> But it appears to be a more general issue and in some circumstance
> even the "register-first-allocate-assign-in-later" approach might fail.
> For example, you have N resource to allocate, something goes wrong
> between the first and the Nth resource allocation completed/or simply say
> before you can reach the "register()". 

If you really do "register-first-allocate-assign-in-later" then there is 
no problem as those resources that are assigned are the resources that 
were allocated. The cleanup function should selectively deallocate the 
resources that were assigned (using null or some special default value 
to identify resources that weren't).

> The question then I would like to ask
> again is if this is really something we want to support/cover with the 
> Cleaner
> mechanism. It doesn't appear to be supported under the finalize() 
> mechanism.
> For example, if someone throws out an exception inside the constructor, in
> normal use scenario, regardless you catch or not catch that exception
> (outside the constructor), the finalize() method is probably not going to
> be called by the finalizer for this partially/incompletely constructed 
> object,
> if you don't purposely do something special to publish the object. 


Wrong. Try this example:


public class TestFinalization {

 ??? final int resource;

 ??? public TestFinalization() {
 ??????? if (true) {
 ??????????? // by the time this is thrown, the object is already registered
 ?????????? // for finalization....
 ??????????? throw new RuntimeException();
 ??????? }
 ??????? resource = 42;
 ??? }

 ??? @SuppressWarnings("deprecation")
 ??? @Override
 ??? protected void finalize() {
 ??????? System.out.println("finalize() called: resource=" + resource);
 ??? }

 ??? public static void main(String[] args) throws Exception {
 ??????? try {
 ??????????? new TestFinalization();
 ??????? } catch (RuntimeException e) {
 ??????????? System.out.println("Exception caught");
 ??????? }
 ??????? System.gc();
 ??????? Thread.sleep(1000L);
 ??? }
}


It prints the following:

Exception caught
finalize() called: resource=0

> Sure
> arguably It appears to be out of the scope of Cleaner API and the only 
> thing
> needs to be addressed here is whether or not register(..) operation 
> fails and
> throws an Error. But it might be helpful to see if there is any 
> different opinion
> before going further?

I don't see much difference between finalization and Cleaner mechanism. 
The main difference is that with finalization, the object that is being 
tracked is also the object that contains the state and logic needed for 
cleanup. Cleaner API decouples those two aspects. The low-level 
(extending PhantomCleanable<T>) API also encourages the correct order of 
things: 1st register then allocate. If we either expose the low-level 
API to the public or make some additions to the high-level API to 
encourage the same, all will be well.

Regards, Peter

>
> Sherman
>
>
>
>
>


From paul.sandoz at oracle.com  Tue Oct 31 17:32:25 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 31 Oct 2017 10:32:25 -0700
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <d3d6c258-4a26-331b-a85c-9e7f23fa8229@bell-sw.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <b8c8d33a-2782-cfba-64df-fc32151ac117@bell-sw.com>
 <93431280-9CBF-4722-961D-F2D2D0F83B4E@oracle.com>
 <EBC28788-F65A-42F8-A6AD-7B670FDB74C5@oracle.com>
 <d3d6c258-4a26-331b-a85c-9e7f23fa8229@bell-sw.com>
Message-ID: <58726425-BA16-482B-A02E-3B0613CD5010@oracle.com>


> On 31 Oct 2017, at 05:58, Dmitry Samersoff <dmitry.samersoff at bell-sw.com> wrote:
> 
> Paul and Frederic,
> 
> Thank you.
> 
> One more question. Do we need to call verify_oop below?
> 
> 509   { // Check for the null sentinel.
> ...
> 517      xorptr(result, result);  // NULL object reference
> ...
> 
> 521   if (VerifyOops) {
> 522      verify_oop(result);
> 523   }
> 

I believe it?s harmless.

When the flag is on it eventually results in a call to the stub generated by generate_verify_oop:

http://hg.openjdk.java.net/jdk10/hs/file/tip/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#l1023

    // make sure object is 'reasonable'
    __ testptr(rax, rax);
    __ jcc(Assembler::zero, exit); // if obj is NULL it is OK

If the oop is null the verification will exit safely.

Paul.

> -Dmitry
> 
> 
> On 31.10.2017 00:56, Frederic Parain wrote:
>> I?m seeing no issue with rcx being aliased in this code.
>> 
>> Fred
>> 
>>> On Oct 30, 2017, at 15:44, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Thanks for reviewing.
>>> 
>>>> On 30 Oct 2017, at 11:05, Dmitry Samersoff <dmitry.samersoff at bell-sw.com> wrote:
>>>> 
>>>> Paul,
>>>> 
>>>> templateTable_x86.cpp:
>>>> 
>>>> 564   const Register flags = rcx;
>>>> 565   const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
>>>> 
>>>> Should we use another register for rarg under NOT_LP64 ?
>>>> 
>>> 
>>> I think it should be ok, it i ain?t an expert here on the interpreter and the calling conventions, so please correct me.
>>> 
>>> Some more context:
>>> 
>>> +  const Register flags = rcx;
>>> +  const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1);
>>> +  __ movl(rarg, (int)bytecode());
>>> 
>>> The current bytecode code is loaded into ?rarg?
>>> 
>>> +  call_VM(obj, CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_ldc), rarg);
>>> 
>>> Then ?rarg" is the argument to the call to InterpreterRuntime::resolve_ldc, after which it is no longer referred to.
>>> 
>>> +#ifndef _LP64
>>> +  // borrow rdi from locals
>>> +  __ get_thread(rdi);
>>> +  __ get_vm_result_2(flags, rdi);
>>> +  __ restore_locals();
>>> +#else
>>> +  __ get_vm_result_2(flags, r15_thread);
>>> +#endif
>>> 
>>> The result from the call is then loaded into flags.
>>> 
>>> So i don?t think it matters in this case if rcx is aliased.
>>> 
>>> Paul.
>>> 
>>>> -Dmitry
>>>> 
>>>> 
>>>> On 10/26/2017 08:03 PM, Paul Sandoz wrote:
>>>>> Hi,
>>>>> 
>>>>> Please review the following patch for minimal dynamic constant support:
>>>>> 
>>>>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>
>>>>> 
>>>>> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.
>>>>> 
>>>>> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.
>>>>> 
>>>>> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).
>>>>> 
>>>>> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.
>>>>> 
>>>>> The CSR for the VM specification is here:
>>>>> 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>
>>>>> 
>>>>> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).
>>>>> 
>>>>> Any AoT-related work will be deferred to a future release.
>>>>> 
>>>>> ?
>>>>> 
>>>>> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).
>>>>> 
>>>>> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.
>>>>> 
>>>>> ?
>>>>> 
>>>>> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.
>>>>> 
>>>>> One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.
>>>>> 
>>>>> ?
>>>>> 
>>>>> Paul.
>>>>> 
>>>> 
>>> 
>> 
> 
> 


From Roger.Riggs at Oracle.com  Tue Oct 31 18:24:35 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 31 Oct 2017 14:24:35 -0400
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
Message-ID: <01f8dca4-593e-f3db-d846-3ee5e97b6326@Oracle.com>

Hi Stuart,

Collection.java:

The mix of "should" and "must" in Collection.java can be confusing.
Typically "should" is interpreted as "must" from a conformance point of 
view.
For example,

147 * <p>An <i>unmodifiable collection</i> is a collection, all of whose
148 * mutator methods (as defined above) are specified to throw
149 * {@code UnsupportedOperationException}. Such a collection thus 
cannot be
150 * modified by calling any methods on it. For a collection to be properly
151 * unmodifiable, any view collections derived from it *must *also be 
unmodifiable.
152 * For example, if a List is unmodifiable, the List returned by
153 * {@link List#subList List.subList} *should *also be unmodifiable.

That leaves room for a non-compliant collection which could not 
technically be called "unmodifiable".

138 * does not support the operation. Such methods *should *(but are not 
required
139 * to) throw an {@code UnsupportedOperationException} if the 
invocation would
140 * have no effect on the collection. For example, invoking the
141 * {@link #addAll addAll} method on a collection that does not support
142 * the {@link #add add} operation *should *throw the exception if
143 * the collection passed as an argument is empty.

These two sentences both allow not throwing UOE and requiring UOE. Can 
they be worded to be consistent (or similarly qualified.)

Set.java: 706:? Would using "unique elements" clarify the contents of 
the result?
Saying "Duplicate elements are permitted," may be misleading.
Perhaps "The given Collection may contain duplicate elements"...

Similarly in Collectors.to toUnmodifiableSet:
"Duplicate elements are allowed," can be misleading, especially the word 
allowed.

Collectors.toUnmodifiableMap
 ???? * If the mapped keys
1474????? * might have duplicates, use {@link 
#toUnmodifiableMap(Function, Function, BinaryOperator)}
1475????? * instead.

It would helpful to say why to use the version with the BinaryOperator, 
for example to say"
"To determine which of the duplicate elements to retain".? or similar.

Collectors:1606:? impl note:? With three different NPE throws, it is 
helpful to use the 2-arg
form of requireNonNull to indicate which parameter offends.

Roger

On 10/30/2017 6:50 PM, Stuart Marks wrote:
> (also includes 8184690: add Collectors for collecting into 
> unmodifiable List, Set, and Map)
>
> Hi all,
>
> Here's an updated webrev for this changeset; the previous review 
> thread is here:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html
>
> This webrev includes the following:
>
> * specification revisions to provide clearer definitions of "view" 
> collections, "unmodifiable" collections, and "unmodifiable views"
>
> * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" 
> methods
>
> * new Collectors.toUnmodifiableList, Set, and Map methods
>
> * tests for the new API methods
>
> I've added some assertions that require some independence between the 
> source collection (or map) and the result of the copyOf() method.
>
> I've made a small but significant change to Set.copyOf compared to the 
> previous round. Previously, it specified that the first of any equal 
> elements was preserved. Now, it is explicitly unspecified which of any 
> equals elements is preserved. This is consistent with Set.addAll, 
> Collectors.toSet, and the newly added Collectors.toUnmodifiableSet, 
> none of which specify which of duplicate elements is preserved.
>
> (The outlier here is Stream.distinct, which specifies that the first 
> element of any duplicates is preserved, if the stream is ordered.)
>
> I've also made some minor wording/editorial changes in response to 
> suggestions from David Holmes and Roger Riggs. I've kept the wording 
> changes that give emphasis to "unmodifiable" over "immutable." The 
> term "immutable" is inextricably intertwined with "persistent" when it 
> comes to data structures, and I believe we'll be explaining this 
> forever if Java's "immutable" means something different from everybody 
> else's.
>
> Webrev:
>
> ??? http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/
>
> Bugs:
>
> ??? https://bugs.openjdk.java.net/browse/JDK-8177290
> ??????? add copy factory methods for unmodifiable List, Set, Map
>
> ??? https://bugs.openjdk.java.net/browse/JDK-8184690
> ??????? add Collectors for collecting into unmodifiable List, Set, and 
> Map
>
> Thanks,
>
> s'marks


From brian.goetz at oracle.com  Tue Oct 31 18:24:39 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 31 Oct 2017 14:24:39 -0400
Subject: RFR Re: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
 <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
Message-ID: <ac37386a-5399-c425-5bd0-aed943451186@oracle.com>

While I agree that the overflow-detecting constraint on min/max in the 
early version was too aggressive, you could reasonably choose to enforce 
the constraint that if count == 0, then so should sum, min, and max.

On 10/30/2017 6:49 PM, Paul Sandoz wrote:
> Hi Chris,
>
> After some hiatus here is an updated webrev, i made some tweaks to the JavaDoc:
>
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8178117-summary-constructors/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8178117-summary-constructors/webrev/>
>
> And the CSR:
>
>    https://bugs.openjdk.java.net/browse/JDK-8190381 <https://bugs.openjdk.java.net/browse/JDK-8190381>
>
> The support for a double sum of consisting of an array of double is going beyond my complexity budget for this feature. If that is deemed important later on we can add another constructor.
>
> Paul.
>
>> On 11 Apr 2017, at 17:44, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>>
>> Updated patch with the changed parameter validation, updated javadoc and added test coverage.
>>
>> <8178117.2.patch.txt>
>>
>>> On Apr 11, 2017, at 4:48 PM, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>>>
>>> Color me confused? what would the javadoc on the parameter say? It could I guess have an @implNote documenting the meanings of the parameters? but then what use is it? The proposed API simply limits the precision with which a DoubleSummaryStatistic can be copied to be the same as the precision with which it can be ?accessed?.  That doesn?t seem an enormous problem since I suspect that bulk of usages would be to marshall a ?finished? instance and therefore there is no real loss occuring. If we wanted to support arbitrary precision wouldn?t it be better to have a constructor variant that took a BigDecimal, and a matching getPreciseSum() that returned a BigDecimal?
>>>
>>> Chris
>>>
>>>> On Apr 11, 2017, at 4:16 PM, joe darcy <joe.darcy at oracle.com> wrote:
>>>>
>>>> On an API design note, I would prefer to DoubleSummaryStatistics took a double... argument to pass in the state of the summation. This flexibility is necessary to more fully preserve the computed sum. Also, the we want flexibility to change the amount of internal state DoubleSummaryStats keeps so we don't want to hard-code that into as aspect of the API.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>>
>>>> On 4/11/2017 12:53 PM, Paul Sandoz wrote:
>>>>> Hi Chris,
>>>>>
>>>>> Thanks for looking at this.
>>>>>
>>>>> There is some rudimentary testing using streams in CollectAndSummaryStatisticsTest.java.
>>>>>
>>>>> I think we should enforce constraints where we reliably can:
>>>>>
>>>>> 1) count >= 0
>>>>>
>>>>> 2) count = 0, then min/max/sum are ignored and it?s as if the default constructor was called. (I thought it might be appropriate to reject since a caller might be passing in incorrect information in error, but the defaults for min/max are important and would be a burden for the caller to pass those values.) In this respect having count as the first parameter of the constructor would be useful.
>>>>>
>>>>> 3)  min <= max
>>>>>
>>>>> Since for count > 0 the constraints, count * max >= sum, count * min <= sum, cannot be reliably enforced due to overflow i am inclined to not bother and just document.
>>>>>
>>>>>
>>>>> Note this is gonna be blocked from pushing until the new Compatibility and Specification Review (CSR) process is opened up, which i understand is ?soon"ish :-) but that should not block adding some further tests in the interim and tidying up the javadoc.
>>>>>
>>>>> Paul.
>>>>>
>>>>>
>>>>>> On 6 Apr 2017, at 07:08, Chris Dennis <chris.w.dennis at gmail.com> wrote:
>>>>>>
>>>>>> Hi Paul (et al)
>>>>>>
>>>>>> Like all things API there are wrinkles here when it comes to implementing.
>>>>>>
>>>>>> This patch isn?t final, there appears to be no existing test coverage for these classes beyond testing the compensating summation used in the double implementation, and I left off adding any until it was decided how much parameter validation we want (since that?s the only testing that can really occur here).
>>>>>>
>>>>>> The wrinkles relate to the issues around instances that have suffered overflow in count and/or sum which the existing implementation doesn?t defend against:
>>>>>>
>>>>>> * I chose to ignore all parameters if 'count == 0? and just leave the instance empty. I held off from validating min, max and count however. This obviously 'breaks things? (beyond how broken they would already be) if count == 0 only due to overflow.
>>>>>> * I chose to fail if count is negative.
>>>>>> * I chose to enforce that max and min are logically consistent with count and sum, this can break the moment either one of the overflows as well (I?m also pretty sure that the FPU logic is going to suffer here too - there might be some magic I can do with a pessimistic bit of rounding on the FPU multiplication result).
>>>>>>
>>>>>> I intentionally went with the most aggressive parameter validation here to establish one end of what could be implemented.  There are arguments for this and also arguments for the other extreme (no validation at all).  Personally I?m in favor of the current version where the creation will fail if the inputs are only possible through overflow (modulo fixing the FPU precision issues above) even though it?s at odds with approach of the existing implementation.
>>>>>>
>>>>>> Would appreciate thoughts/feedback.  Thanks.
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>> P.S. I presume tests would be required for the parameter checking (once it is finalized)?
>>>>>>
>>>>>> <8178117.patch>


From lance.andersen at oracle.com  Tue Oct 31 19:28:40 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 31 Oct 2017 15:28:40 -0400
Subject: RFR: JDK-8190439 -  Removal of newrmic
Message-ID: <1C8C2A56-FF26-44B9-844E-C1340FBC7CF0@oracle.com>

Hi all,

Please review the  webrev which removes newrmic as newrmic is not used.

The webrev can be found at  http://cr.openjdk.java.net/~lancea/8190439/webrev.00/

Best
Lance
 <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  Tue Oct 31 19:32:28 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 31 Oct 2017 12:32:28 -0700
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
Message-ID: <A400F3A3-CA5D-441F-B201-10FBA7A07A4A@oracle.com>

Lois identified and fixed a bug found when running the JCK VM tests. I merged the changes below into the current webrev.

Paul.

--- old/src/hotspot/share/interpreter/linkResolver.cpp	2017-10-31 11:56:30.541287505 -0400
+++ new/src/hotspot/share/interpreter/linkResolver.cpp	2017-10-31 11:56:29.215676272 -0400
@@ -301,14 +301,14 @@
   if (vca_result != Reflection::ACCESS_OK) {
     ResourceMark rm(THREAD);
     char* msg = Reflection::verify_class_access_msg(ref_klass,
-                                                    InstanceKlass::cast(sel_klass),
+                                                    InstanceKlass::cast(base_klass),
                                                     vca_result);
     if (msg == NULL) {
       Exceptions::fthrow(
         THREAD_AND_LOCATION,
         vmSymbols::java_lang_IllegalAccessError(),
         "failed to access class %s from class %s",
-        sel_klass->external_name(),
+        base_klass->external_name(),
         ref_klass->external_name());
     } else {
       // Use module specific message returned by verify_class_access_msg().


 
> On 26 Oct 2017, at 10:03, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Please review the following patch for minimal dynamic constant support:
> 
>  http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
> 
>  https://bugs.openjdk.java.net/browse/JDK-8186046 <https://bugs.openjdk.java.net/browse/JDK-8186046>
>  https://bugs.openjdk.java.net/browse/JDK-8186209 <https://bugs.openjdk.java.net/browse/JDK-8186209>
> 
> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good.
> 
> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex.
> 
> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository).
> 
> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments.
> 
> The CSR for the VM specification is here:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8189199 <https://bugs.openjdk.java.net/browse/JDK-8189199>
> 
> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles).
> 
> Any AoT-related work will be deferred to a future release.
> 
> ?
> 
> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte).
> 
> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches.
> 
> ?
> 
> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants.
> 
> One test uses class file bytes produced from a modified version of asmtools.  The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test.
> 
> ?
> 
> Paul.


From Roger.Riggs at oracle.com  Tue Oct 31 20:05:46 2017
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 31 Oct 2017 16:05:46 -0400
Subject: RFR 8190441: ProblemList some intermittent CORBA tests
Message-ID: <bef24a44-5676-0d59-919c-4b73418fb4a6@oracle.com>

Please review some additions to the ProblemList.txt for intermittent 
CORBA tests.

diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -315,8 +315,12 @@ sun/tools/jhsdb/heapconfig/JMapHeapConfi

 ?com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 
linux-i586,macosx-all,windows-x64

-javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 
8169737 linux-all
-
+javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 
8169737 generic-all
+
 ?org/omg/CORBA/OrbPropertiesTest.java 8175177 generic-all

+javax/rmi/PortableRemoteObject/ConcurrentHashmapTest.java 8080643 
generic-all
+
+javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all
+
 ?############################################################################

Issue: https://bugs.openjdk.java.net/browse/JDK-8190441

Thanks, Roger

p.s. trying out some attachments to check the mail filters


-------------- next part --------------
A non-text attachment was scrubbed...
Name: prob-8190441.patch
Type: text/x-patch
Size: 924 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20171031/51d22dc8/prob-8190441.patch>
-------------- next part --------------
# HG changeset patch
# Parent 3937719e63717e09e293bdec81e44d9214ce5578
8190441: ProblemList some intermittent CORBA tests

diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt
+++ b/test/jdk/ProblemList.txt
@@ -315,8 +315,12 @@ sun/tools/jhsdb/heapconfig/JMapHeapConfi
 
 com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java                   8169942 linux-i586,macosx-all,windows-x64
 
-javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 linux-all
-
+javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 generic-all
+ 
 org/omg/CORBA/OrbPropertiesTest.java			        8175177 generic-all
 
+javax/rmi/PortableRemoteObject/ConcurrentHashmapTest.java       8080643 generic-all
+
+javax/rmi/ssl/SSLSocketParametersTest.sh                        8162906 generic-all
+
 ############################################################################

From mandy.chung at oracle.com  Tue Oct 31 20:06:52 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 31 Oct 2017 13:06:52 -0700
Subject: RFR: JDK-8190439 - Removal of newrmic
In-Reply-To: <1C8C2A56-FF26-44B9-844E-C1340FBC7CF0@oracle.com>
References: <1C8C2A56-FF26-44B9-844E-C1340FBC7CF0@oracle.com>
Message-ID: <77ea564d-47fd-e0a5-4e96-71cecd2ce6c3@oracle.com>



On 10/31/17 12:28 PM, Lance Andersen wrote:
> Hi all,
>
> Please review the  webrev which removes newrmic as newrmic is not used.
>
> The webrev can be found at  http://cr.openjdk.java.net/~lancea/8190439/webrev.00/
>
+1

Mandy

From lance.andersen at oracle.com  Tue Oct 31 20:07:17 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 31 Oct 2017 16:07:17 -0400
Subject: RFR 8190441: ProblemList some intermittent CORBA tests
In-Reply-To: <bef24a44-5676-0d59-919c-4b73418fb4a6@oracle.com>
References: <bef24a44-5676-0d59-919c-4b73418fb4a6@oracle.com>
Message-ID: <7C7298A0-3C26-4595-A625-72FCDE4DC803@oracle.com>

Looks good roger

> On Oct 31, 2017, at 4:05 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Please review some additions to the ProblemList.txt for intermittent CORBA tests.
> 
> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt
> +++ b/test/jdk/ProblemList.txt
> @@ -315,8 +315,12 @@ sun/tools/jhsdb/heapconfig/JMapHeapConfi
> 
>  com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 linux-i586,macosx-all,windows-x64
> 
> -javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 linux-all
> -
> +javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 generic-all
> +
>  org/omg/CORBA/OrbPropertiesTest.java 8175177 generic-all
> 
> +javax/rmi/PortableRemoteObject/ConcurrentHashmapTest.java 8080643 generic-all
> +
> +javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all
> +
>  ############################################################################
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8190441
> 
> Thanks, Roger
> 
> p.s. trying out some attachments to check the mail filters
> 
> 
> <prob-8190441.patch><prob-8190441.txt>

 <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 joe.darcy at oracle.com  Tue Oct 31 20:08:27 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 31 Oct 2017 13:08:27 -0700
Subject: RFR 8190441: ProblemList some intermittent CORBA tests
In-Reply-To: <7C7298A0-3C26-4595-A625-72FCDE4DC803@oracle.com>
References: <bef24a44-5676-0d59-919c-4b73418fb4a6@oracle.com>
 <7C7298A0-3C26-4595-A625-72FCDE4DC803@oracle.com>
Message-ID: <59F8D83B.9080004@oracle.com>

+1

-Joe

On 10/31/2017 1:07 PM, Lance Andersen wrote:
> Looks good roger
>
>> On Oct 31, 2017, at 4:05 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>
>> Please review some additions to the ProblemList.txt for intermittent CORBA tests.
>>
>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
>> --- a/test/jdk/ProblemList.txt
>> +++ b/test/jdk/ProblemList.txt
>> @@ -315,8 +315,12 @@ sun/tools/jhsdb/heapconfig/JMapHeapConfi
>>
>>   com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 linux-i586,macosx-all,windows-x64
>>
>> -javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 linux-all
>> -
>> +javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 generic-all
>> +
>>   org/omg/CORBA/OrbPropertiesTest.java 8175177 generic-all
>>
>> +javax/rmi/PortableRemoteObject/ConcurrentHashmapTest.java 8080643 generic-all
>> +
>> +javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all
>> +
>>   ############################################################################
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8190441
>>
>> Thanks, Roger
>>
>> p.s. trying out some attachments to check the mail filters
>>
>>
>> <prob-8190441.patch><prob-8190441.txt>
>   <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 Roger.Riggs at Oracle.com  Tue Oct 31 20:11:11 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 31 Oct 2017 16:11:11 -0400
Subject: RFR: JDK-8190439 - Removal of newrmic
In-Reply-To: <77ea564d-47fd-e0a5-4e96-71cecd2ce6c3@oracle.com>
References: <1C8C2A56-FF26-44B9-844E-C1340FBC7CF0@oracle.com>
 <77ea564d-47fd-e0a5-4e96-71cecd2ce6c3@oracle.com>
Message-ID: <8f3029d1-46ce-c2c7-6238-68da047fa915@Oracle.com>

Ditto:? +1

On 10/31/2017 4:06 PM, mandy chung wrote:
>
>
> On 10/31/17 12:28 PM, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the? webrev which removes newrmic as newrmic is not used.
>>
>> The webrev can be found at 
>> http://cr.openjdk.java.net/~lancea/8190439/webrev.00/
>>
> +1
>
> Mandy


From stuart.marks at oracle.com  Tue Oct 31 20:37:42 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 31 Oct 2017 13:37:42 -0700
Subject: ThreadPoolExecutor and finalization
In-Reply-To: <CA+kOe08vE5hXJRot0t8p==VnsY6DEaD0ipqcrMYPkhMOW=rzDg@mail.gmail.com>
References: <cface258-82b8-f5eb-5746-4ce69ddd7c24@oracle.com>
 <459cf96f-de06-0183-d661-03506d1a01a1@oracle.com>
 <C620AB47-84BC-4906-9CD8-86DAF4E07F8E@gmail.com>
 <e24e25fd-40a6-69b4-801e-46e5ecd27ac3@oracle.com>
 <81a7c918-239b-c205-a946-672e894576be@Oracle.com>
 <CANghgrRPdbtRsh0n41nX9Q7b8DYcENzDXpUM5HLBT8Mp0HfaGg@mail.gmail.com>
 <bfd6c977-df4d-53ba-a59c-8e2a6c04f2eb@Oracle.com>
 <CA+kOe08vE5hXJRot0t8p==VnsY6DEaD0ipqcrMYPkhMOW=rzDg@mail.gmail.com>
Message-ID: <305aa1b0-ee40-b2fd-d1bd-4aeedad55a56@oracle.com>



On 10/30/17 10:21 AM, Martin Buchholz wrote:
>> The initiative is to identify and remediate existing uses of finalization
>> in the JDK.
> 
> I've been skeptical about this initiative as stated.  I would not have
> deprecated finalize(). We will never remove finalize() from the JDK, and I
> don't see how switching TPE from finalize to some other mechanism such as
> Cleaner has real benefits for users.  There aren't enough instances of TPE
> created for finalization to be a real user performance problem.

Interesting that you say "we will never remove finalize()" ... it is exactly the 
goal of this initiative to remove finalize() eventually. Or at least to remove 
the finalization mechanism. It's been a thorn in the side of GC implementors 
since forever. As Roger stated, the early part of this effort is to remove uses 
from within the JDK, and to warn external users to start migrating to other 
facilities. Hence, we've deprecated it and are having this discussion.

I don't know what the later parts of the transition will look like. Perhaps at 
some point we deprecate Object.finalize() for removal; perhaps at some point the 
VM stops calling Object.finalize() even though the method is declared; perhaps 
at some point we actually remove the Object.finalize() method. All of this will 
require further discussion, and it will be based on our experience working 
through these early remediation steps.

> TPE's spec currently has a finalize deprecation warning, but this is not
> helpful for users.
> (a documentation readability regression!)
> https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/ThreadPoolExecutor.html#finalize--

I'm not sure why you say this isn't helpful. It's clearly not helpful to 
*clients* of TPE; but since finalize() is protected, the warning is clearly 
directed at subclasses, and it provides information about migrating away from 
finalization. Should say something different?

s'marks

From Alan.Bateman at oracle.com  Tue Oct 31 21:04:32 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 31 Oct 2017 21:04:32 +0000
Subject: RFR: JDK-8190439 - Removal of newrmic
In-Reply-To: <1C8C2A56-FF26-44B9-844E-C1340FBC7CF0@oracle.com>
References: <1C8C2A56-FF26-44B9-844E-C1340FBC7CF0@oracle.com>
Message-ID: <13006fbe-202f-d7b8-1fcf-e9df0420bfa0@oracle.com>



On 31/10/2017 19:28, Lance Andersen wrote:
> Hi all,
>
> Please review the  webrev which removes newrmic as newrmic is not used.
>
> The webrev can be found at  http://cr.openjdk.java.net/~lancea/8190439/webrev.00/
>
Looks fine. As you found, it was disabled in JDK 9 and probably should 
have been removed at the time.

-Alan

From mandy.chung at oracle.com  Tue Oct 31 21:43:59 2017
From: mandy.chung at oracle.com (mandy chung)
Date: Tue, 31 Oct 2017 14:43:59 -0700
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
Message-ID: <230aad0f-8649-baf2-71e8-8efc75d0cb16@oracle.com>



On 10/26/17 10:03 AM, Paul Sandoz wrote:
> Hi,
>
> Please review the following patch for minimal dynamic constant support:
>
>    http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>


I reviewed the non-hotspot change as a learning exercise (I am not close 
to j.l.invoke implementation).? I assume DynamicConstant intends to be 
non-public in this patch, right?

   30 public final class DynamicConstant

Mandy


From stuart.marks at oracle.com  Tue Oct 31 22:46:25 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 31 Oct 2017 15:46:25 -0700
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <12dffddd-e11b-6fd2-5f1e-c3d29a93899c@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <12dffddd-e11b-6fd2-5f1e-c3d29a93899c@oracle.com>
Message-ID: <e6d39f4a-e510-4ef0-4a82-3b84945f0718@oracle.com>

Thanks for the review. Editorial comments accepted. Discussion and responses to some items below.


On 10/31/17 7:25 AM, Brian Goetz wrote:
>
> Returns an <a href="#unmodifiable">unmodifiable Map</a> containing the entries
> 1664 * of the given Map. the given Map must not be null, and it must not 
> contain any
> 1665 * null keys or values. If the given Map is subsequently modified, the 
> returned
> 1666 * Map will not reflect such modifications.
>
> I might quibble with "subsequently modified", as there is some ambiguity (what 
> if the map is concurrently modified, subsequent to making the copyOf() call, 
> but prior to the return from copyOf()?)? But I won't ;)
>
Well I actually did think about this, but I couldn't think of anything better to 
say. If concurrent modification is permitted, it's conceivable that a 
modification made any time during the copy might end up in the returned map. It 
depends on the source map's implementation and concurrent modification policy. 
So I think the only statement that can be made is about the state of the 
returned map after copyOf() returns. That's what "subsequent" means to me, but I 
could clarify this if you think it's worth it.

(Similar reasoning for List and Set.)
>
> 296 Collector<T, ?, List<T>> toUnmodifiableList() {
> 297 return new CollectorImpl<>((Supplier<List<T>>) ArrayList::new, List::add,
> 298 (left, right) -> { left.addAll(right); return left; },
> 299 list -> (List<T>)List.of(list.toArray()),
> 300 CH_NOID);
> why the intermediate array, and not just use copyOf()?? (Is it because you 
> added copyOf later and didn't go back and update this?)? Same for other 
> collectors.
The copyOf method is mostly forced to make a defensive copy, so it's no better.

I think what should happen here eventually is that the elements should be 
collected into something like a SpinedBuffer, and then a private interface 
should be plumbed into the unmodifiable list implementation that can copy 
elements directly from the buffer. This avoids the extra copy. But I'll take 
care of that later.

For toUnmodifiableSet and toUnmodifiableMap, I can imagine similar private 
interfaces to avoid excess copies, but I think they each still need to build up 
full intermediate HashSet/HashMap in order to get rid of duplicates.

s'marks
>
>
>
>
>
>
>
>
> On 10/30/2017 6:50 PM, Stuart Marks wrote:
>> (also includes 8184690: add Collectors for collecting into unmodifiable List, 
>> Set, and Map)
>>
>> Hi all,
>>
>> Here's an updated webrev for this changeset; the previous review thread is here:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html
>>
>> This webrev includes the following:
>>
>> * specification revisions to provide clearer definitions of "view" 
>> collections, "unmodifiable" collections, and "unmodifiable views"
>>
>> * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" methods
>>
>> * new Collectors.toUnmodifiableList, Set, and Map methods
>>
>> * tests for the new API methods
>>
>> I've added some assertions that require some independence between the source 
>> collection (or map) and the result of the copyOf() method.
>>
>> I've made a small but significant change to Set.copyOf compared to the 
>> previous round. Previously, it specified that the first of any equal elements 
>> was preserved. Now, it is explicitly unspecified which of any equals elements 
>> is preserved. This is consistent with Set.addAll, Collectors.toSet, and the 
>> newly added Collectors.toUnmodifiableSet, none of which specify which of 
>> duplicate elements is preserved.
>>
>> (The outlier here is Stream.distinct, which specifies that the first element 
>> of any duplicates is preserved, if the stream is ordered.)
>>
>> I've also made some minor wording/editorial changes in response to 
>> suggestions from David Holmes and Roger Riggs. I've kept the wording changes 
>> that give emphasis to "unmodifiable" over "immutable." The term "immutable" 
>> is inextricably intertwined with "persistent" when it comes to data 
>> structures, and I believe we'll be explaining this forever if Java's 
>> "immutable" means something different from everybody else's.
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/
>>
>> Bugs:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8177290
>> ??????? add copy factory methods for unmodifiable List, Set, Map
>>
>> https://bugs.openjdk.java.net/browse/JDK-8184690
>> ??????? add Collectors for collecting into unmodifiable List, Set, and Map
>>
>> Thanks,
>>
>> s'marks
>


From paul.sandoz at oracle.com  Tue Oct 31 22:53:30 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 31 Oct 2017 15:53:30 -0700
Subject: [10] RFR 8186046 Minimal ConstantDynamic support
In-Reply-To: <230aad0f-8649-baf2-71e8-8efc75d0cb16@oracle.com>
References: <A3420FD7-0556-4865-9CE7-2E5252DD1381@oracle.com>
 <230aad0f-8649-baf2-71e8-8efc75d0cb16@oracle.com>
Message-ID: <05E86643-EE91-49BB-9A57-B291AA087211@oracle.com>


> On 31 Oct 2017, at 14:43, mandy chung <mandy.chung at oracle.com> wrote:
> 
> 
> 
> On 10/26/17 10:03 AM, Paul Sandoz wrote:
>> Hi,
>> 
>> Please review the following patch for minimal dynamic constant support:
>> 
>>   
>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
> 
> 
> I reviewed the non-hotspot change as a learning exercise (I am not close to j.l.invoke implementation).  I assume DynamicConstant intends to be non-public in this patch, right?
>   30 public final class DynamicConstant 
> 

Well spotted.

More likely to be renamed to ConstantBootstraps when a minimal set of dynamic constant bootstraps will be proposed (likely this week) as a follow on patch.

I?ll made it non-public in the updated webrev so as to keep this patch self-contained.

Paul.



From peter.levart at gmail.com  Tue Oct 31 23:07:13 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 1 Nov 2017 00:07:13 +0100
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <64f46e40-b641-b280-eed3-99606e9ad1d5@oracle.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
 <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
 <0ec13ca6-d542-ba81-c804-bfd524564f6a@gmail.com>
 <64f46e40-b641-b280-eed3-99606e9ad1d5@oracle.com>
Message-ID: <55ff486d-2b09-6463-734e-c769603cdae7@gmail.com>

Hi Mandy, Sherman, Roger,

On 10/31/17 00:25, mandy chung wrote:
>
>
> On 10/30/17 1:49 PM, Peter Levart wrote:
>>
>> ...above example lends itself as a use case for the following 
>> equivalent alternative using internal low-level API where ZStreamRef 
>> becomes the Cleanable itself:
>>
>> class ZStreamRef extends PhantomCleanable<Object> {
>>
>> ??? private final LongConsumer end;
>> ??? private volatile long address;
>>
>> ??? ZStreamRef (Object referent, LongSupplier init, LongConsumer end) {
>> ??? ??? // here the registration MUST happen as 1st thing - enforced 
>> by javac
>> ??????? super(referent, CleanerFactory.cleaner());
>> ??????? this.end = end;
>> ??????? this.address = init.getAsLong();
>> ??? }
>>
>> ??? long address() {
>> ??????? return address;
>> ??? }
>>
>> ??? @Override
>> ??? protected void performCleanup() {
>> ??????? long addr = address;
>> ??????? address = 0;
>> ??????? if (addr != 0) {
>> ??????????? end.accept(addr);
>> ??????? }
>> ??? }
>> }
>>
>
> I was thinking something along this line what could ensure the 
> "cleanable" object is allocated before allocating the resources that 
> the cleanable is responsible for clean up.?? I think it'd be a good 
> RFE to improve the Cleaner API to address the OOM case.
>
> Mandy

I played a little with an idea of how such additional Cleaner API might 
look like. Here's what I came up with, together with how this would 
apply to ZipFile/Inflater/Deflater:

http://cr.openjdk.java.net/~plevart/jdk10-dev/8185582_ZIP.cleaner/webrev.02/

@Sherman:

While looking at how to apply this to ZipFile Cleaner(s), I noticed that 
Releaser, as proposed, does not have to include opened streams or cached 
inflaters. Why?

- opened streams keep a reference to the ZipFile, so ZipFile's Cleaner 
will not fire automatically until all opened streams and ZipFile become 
phantom-reachable. Even more than that, ZipFileInflaterInputStream's 
Cleaner keeps a reference to ZipFile in order to call 
ZipFile.releaseInflater. So all ZipFileInflaterInputStream(s) have to be 
closed 1st (either cleaned automatically or explicitly) so that their 
inflaters are released back to cache and ZipFileInflaterInputStream's 
cleanup functions are released. Only then may ZipFile become 
phantom-reachable. When Releaser is finally triggered automatically, 
there are no more open ZipFileInflaterInputStream(s) only 
ZipFileInputStream(s) may be still open, but already phantom-reachable. 
PhantomReference specification says:

 ?* <p> Suppose the garbage collector determines at a certain point in time
 ?* that an object is <a href="package-summary.html#reachability">
 ?* phantom reachable</a>.? At that time it will atomically clear
 ?* all phantom references to that object and all phantom references to
 ?* any other phantom-reachable objects from which that object is reachable.
 ?* At the same time or at some later time it will enqueue those 
newly-cleared
 ?* phantom references that are registered with reference queues.

...which means that when ZipFile's Cleaner finally fires automatically, 
all opened stream's Cleaners have already fired or are going to fire 
together in same "batch" with the ZipFile's Cleaner. No need for ZipFile 
to include opened streams in its automatic cleanup. It only has to do 
that in explicit close().

The same reasoning goes for cached inflaters. They are only reachable 
from ZipFile. So when ZipFile becomes phantom-reachable, so do cached 
Inflaters at the same time and are therefore cleaned in the same "batch".

The only resource that ZipFile needs to clean in its automatic cleanup 
function is the shared, globally cached, reference counted Source (zsrc) 
object. And this is what I did with this new proposed Cleaner API in 
above webrev.02.


So, what do you think of this new Cleaner API extension?

Regards, Peter



From stuart.marks at oracle.com  Tue Oct 31 23:21:01 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 31 Oct 2017 16:21:01 -0700
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <01f8dca4-593e-f3db-d846-3ee5e97b6326@Oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
 <01f8dca4-593e-f3db-d846-3ee5e97b6326@Oracle.com>
Message-ID: <d7558a3e-fe47-9e38-b062-5ebd617f40e5@oracle.com>



On 10/31/17 11:24 AM, Roger Riggs wrote:
> Hi Stuart,
> 
> Collection.java:
> 
> The mix of "should" and "must" in Collection.java can be confusing.
> Typically "should" is interpreted as "must" from a conformance point of view.

"Must" is a requirement, and "should" is a recommendation to implementors, and 
advice to clients that some property often but doesn't necessarily hold.

> For example,
> 
> 147 * <p>An <i>unmodifiable collection</i> is a collection, all of whose
> 148 * mutator methods (as defined above) are specified to throw
> 149 * {@code UnsupportedOperationException}. Such a collection thus cannot be
> 150 * modified by calling any methods on it. For a collection to be properly
> 151 * unmodifiable, any view collections derived from it *must *also be 
> unmodifiable.
> 152 * For example, if a List is unmodifiable, the List returned by
> 153 * {@link List#subList List.subList} *should *also be unmodifiable.
> 
> That leaves room for a non-compliant collection which could not technically be 
> called "unmodifiable".

I agree that "should" is poor here; I'll reword this to say that the returned 
list "is also unmodifiable."

> 138 * does not support the operation. Such methods *should *(but are not required
> 139 * to) throw an {@code UnsupportedOperationException} if the invocation would
> 140 * have no effect on the collection. For example, invoking the
> 141 * {@link #addAll addAll} method on a collection that does not support
> 142 * the {@link #add add} operation *should *throw the exception if
> 143 * the collection passed as an argument is empty.
> 
> These two sentences both allow not throwing UOE and requiring UOE. Can they be 
> worded to be consistent (or similarly qualified.)

For this case, implementations are recommended to throw UOE, but they are not 
required to do so. Some implementations will throw, while others will not throw. 
There are examples of both in the JDK. I'll clarify the example, but I really do 
mean "should" here.

> Set.java: 706:? Would using "unique elements" clarify the contents of the result?
> Saying "Duplicate elements are permitted," may be misleading.
> Perhaps "The given Collection may contain duplicate elements"...

I'll clarify this to say that if the given Collection contains duplicate 
elements, an arbitrary element of the duplicates is preserved.

> Similarly in Collectors.to toUnmodifiableSet:
> "Duplicate elements are allowed," can be misleading, especially the word allowed.

Will update similarly.

> Collectors.toUnmodifiableMap
>  ???? * If the mapped keys
> 1474????? * might have duplicates, use {@link #toUnmodifiableMap(Function, 
> Function, BinaryOperator)}
> 1475????? * instead.
> 
> It would helpful to say why to use the version with the BinaryOperator, for 
> example to say"
> "To determine which of the duplicate elements to retain".? or similar.

Will add words about handling the merging of values.

> Collectors:1606:? impl note:? With three different NPE throws, it is helpful to 
> use the 2-arg
> form of requireNonNull to indicate which parameter offends.

Will update.

Thanks,

s'marks

> 
> Roger
> 
> On 10/30/2017 6:50 PM, Stuart Marks wrote:
>> (also includes 8184690: add Collectors for collecting into unmodifiable List, 
>> Set, and Map)
>>
>> Hi all,
>>
>> Here's an updated webrev for this changeset; the previous review thread is here:
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html
>>
>> This webrev includes the following:
>>
>> * specification revisions to provide clearer definitions of "view" 
>> collections, "unmodifiable" collections, and "unmodifiable views"
>>
>> * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" methods
>>
>> * new Collectors.toUnmodifiableList, Set, and Map methods
>>
>> * tests for the new API methods
>>
>> I've added some assertions that require some independence between the source 
>> collection (or map) and the result of the copyOf() method.
>>
>> I've made a small but significant change to Set.copyOf compared to the 
>> previous round. Previously, it specified that the first of any equal elements 
>> was preserved. Now, it is explicitly unspecified which of any equals elements 
>> is preserved. This is consistent with Set.addAll, Collectors.toSet, and the 
>> newly added Collectors.toUnmodifiableSet, none of which specify which of 
>> duplicate elements is preserved.
>>
>> (The outlier here is Stream.distinct, which specifies that the first element 
>> of any duplicates is preserved, if the stream is ordered.)
>>
>> I've also made some minor wording/editorial changes in response to suggestions 
>> from David Holmes and Roger Riggs. I've kept the wording changes that give 
>> emphasis to "unmodifiable" over "immutable." The term "immutable" is 
>> inextricably intertwined with "persistent" when it comes to data structures, 
>> and I believe we'll be explaining this forever if Java's "immutable" means 
>> something different from everybody else's.
>>
>> Webrev:
>>
>> ??? http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/
>>
>> Bugs:
>>
>> ??? https://bugs.openjdk.java.net/browse/JDK-8177290
>> ??????? add copy factory methods for unmodifiable List, Set, Map
>>
>> ??? https://bugs.openjdk.java.net/browse/JDK-8184690
>> ??????? add Collectors for collecting into unmodifiable List, Set, and Map
>>
>> Thanks,
>>
>> s'marks
> 

From xueming.shen at oracle.com  Tue Oct 31 23:25:24 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 31 Oct 2017 16:25:24 -0700
Subject: RFR JDK-8185582, Update Zip implementation to use Cleaner, not
 finalizers
In-Reply-To: <16e98d55-35c0-a039-edf5-95240bed2510@gmail.com>
References: <59CB46AE.2000701@oracle.com>
 <b5198f40-73d3-be02-47b5-10901a3e013a@oracle.com>
 <59CC3725.7080505@oracle.com> <871slnwe5p.fsf@mid.deneb.enyo.de>
 <516a953c-5a16-7049-8602-8aece2c34745@gmail.com>
 <59F4D419.8070201@oracle.com>
 <2eb8621e-5ebe-b464-f298-7ed63bad638f@gmail.com>
 <59F7735A.3000501@oracle.com>
 <57ebed04-0b53-a5b9-7c6d-71e0098327d8@gmail.com>
 <59F7B6A1.5040303@oracle.com>
 <16e98d55-35c0-a039-edf5-95240bed2510@gmail.com>
Message-ID: <59F90664.9050403@oracle.com>

Hi Peter,

After tried couple implementations it seems the most reasonable approach 
is to
use the coding pattern you suggested to move all pieces into ZSStream 
Ref. Given
we are already using the internal API CleanerFactory it is attractive to 
go a little
further to subclass PhantomCleanable directly (in which I would assume 
we can
save one extra object), but I think I'd better to follow the "suggested" 
clean usage
(to register a runnable into the cleaner) for now.

   39 class ZStreamRef implements Runnable {
   40
   41     private LongConsumer end;
   42     private volatile long address;
   43     private final Cleanable cleanable;
   44
   45     ZStreamRef (Object owner, LongSupplier addr, LongConsumer end) {
   46         this.cleanable = CleanerFactory.cleaner().register(owner, 
this);
   47         this.end = end;
   48         this.address = addr.getAsLong();
   49     }
   50

Similar change has been made for the ZipFile cleaner to follow the same 
coding
pattern. The "cleaner" is now renamed from Releaser to CleanableResource.

http://cr.openjdk.java.net/~sherman/8185582/webrev/

Thanks,
Sherman

From joe.darcy at oracle.com  Tue Oct 31 23:46:12 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 31 Oct 2017 16:46:12 -0700
Subject: RFR Re: [PATCH] 8178117: Add public state constructors for
 Int/Long/DoubleSummaryStatistics
In-Reply-To: <11BAC038-0D59-467C-AE0B-212049E5E46B@oracle.com>
References: <595F8B9A-8AB0-4C13-8ECE-FD822C15FF3F@gmail.com>
 <9E35282E-793B-411A-9A21-0B5762B68A28@oracle.com>
 <961938eb-8bde-a88c-ea05-de940c954ddd@oracle.com>
 <FCC8E8FF-3222-421A-ADF7-5542E911F2F8@gmail.com>
 <DF5459F9-D1F9-4E54-8543-43FFB2BF4341@gmail.com>
 <287F85F8-340A-4D74-B03F-6F9BBDE15011@oracle.com>
 <59F7C175.7010705@oracle.com>
 <11BAC038-0D59-467C-AE0B-212049E5E46B@oracle.com>
Message-ID: <f09eee75-39f2-b8cc-a95e-29e5be9c3b7e@oracle.com>

Hi Paul,


On 10/30/2017 9:33 PM, Paul Sandoz wrote:
> Hi,
>
>> On 30 Oct 2017, at 17:19, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
>>
>> Hello,
>>
>> Is it intentional that "DoubleSummaryStatistics" is used in a sentence like
>>
>>    91      * @apiNote
>>    92      * The enforcement of argument correctness means that the retrieved set of
>>    93      * recorded values obtained from a {@code DoubleSummaryStatistics} source
>>
>> in all three types being updated?
>>
> No, copy?n?paste error. Fixed.
>
>
>> For the code in the constructor, if you don't want to have something like an explicit switch on Long.signum(count), I'd prefer to see at least a comment like
>>
>> // Use default field values if count == 0
>>
> Done.
>
>
>> For the double case, I'd recommend future work change the new constructor to
>>
>>      DoubleSummaryStatistics(long count, double min, double max, double sum, double... additionalSum)
>>
>> where the final argument could be used to convey additional state.
>>
> Ok.
>
>
>> For the double case, if a NaN is used than max and min will be NaN. Therefore, I'd recommend change the correctness constraint for that type to
>>
>>      <li>{@code min} &le; {@code max} || (isNaN(min) && isNaN(max)) </li>
>>
>> with an analogous update to the code.
>>
> In that case we need to double (sorry) down on the NaNs and include sum as well:
>
> *   <li>{@code (min <= max && !isNaN(sum)) || (isNaN(min) && isNaN(max) && isNaN(sum))}

A more complete test for the numerical consistency conditions would be 
something like

     min <= sum/count  <= max

However, that would require a bit of thought due to potential round-off 
so this might not be worth the complexity trade-off. (If any of min, 
sum, and max were NaN, the comparisons would be false.)

Cheers,

-Joe



From stuart.marks at oracle.com  Tue Oct 31 23:49:56 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 31 Oct 2017 16:49:56 -0700
Subject: RFR(m): 8177290 add copy factory methods for unmodifiable List,
 Set, Map
In-Reply-To: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
References: <73e99ba6-508f-9334-3814-7af6e67e99f4@oracle.com>
Message-ID: <dce7e6d1-baaa-0c2e-5029-cb0f107a8a97@oracle.com>

Updated webrev, based on comments from Brian and Roger:

     http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.2/

s'marks


On 10/30/17 3:50 PM, Stuart Marks wrote:
> (also includes 8184690: add Collectors for collecting into unmodifiable List, 
> Set, and Map)
> 
> Hi all,
> 
> Here's an updated webrev for this changeset; the previous review thread is here:
> 
>      
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-September/049261.html
> 
> This webrev includes the following:
> 
> * specification revisions to provide clearer definitions of "view" collections, 
> "unmodifiable" collections, and "unmodifiable views"
> 
> * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" methods
> 
> * new Collectors.toUnmodifiableList, Set, and Map methods
> 
> * tests for the new API methods
> 
> I've added some assertions that require some independence between the source 
> collection (or map) and the result of the copyOf() method.
> 
> I've made a small but significant change to Set.copyOf compared to the previous 
> round. Previously, it specified that the first of any equal elements was 
> preserved. Now, it is explicitly unspecified which of any equals elements is 
> preserved. This is consistent with Set.addAll, Collectors.toSet, and the newly 
> added Collectors.toUnmodifiableSet, none of which specify which of duplicate 
> elements is preserved.
> 
> (The outlier here is Stream.distinct, which specifies that the first element of 
> any duplicates is preserved, if the stream is ordered.)
> 
> I've also made some minor wording/editorial changes in response to suggestions 
> from David Holmes and Roger Riggs. I've kept the wording changes that give 
> emphasis to "unmodifiable" over "immutable." The term "immutable" is 
> inextricably intertwined with "persistent" when it comes to data structures, and 
> I believe we'll be explaining this forever if Java's "immutable" means something 
> different from everybody else's.
> 
> Webrev:
> 
>  ??? http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.1/
> 
> Bugs:
> 
>  ??? https://bugs.openjdk.java.net/browse/JDK-8177290
>  ??????? add copy factory methods for unmodifiable List, Set, Map
> 
>  ??? https://bugs.openjdk.java.net/browse/JDK-8184690
>  ??????? add Collectors for collecting into unmodifiable List, Set, and Map
> 
> Thanks,
> 
> s'marks