From withoutpointk at gmail.com  Tue Sep  1 08:00:31 2015
From: withoutpointk at gmail.com (Adrian)
Date: Tue, 1 Sep 2015 04:00:31 -0400
Subject: Cache which java classes are in a jar when opening jar the first
	time during classloading
In-Reply-To: <55E42760.3090109@oracle.com>
References: <CAL_yH3itTEOSHXOFH4KVBNz9hd16_i-SfWp5PTiOK31gbRvyLw@mail.gmail.com>
	<CAMDxSEjX9YtVKKGjoj+FJ93chG2V1iRziFkjJqKFAgWAgf00dA@mail.gmail.com>
	<55E42760.3090109@oracle.com>
Message-ID: <CAL_yH3j=htDdnmOOQZzwNRTHxWcjhsg6zROAPqvC_mvhegaKgg@mail.gmail.com>

I took a closer look at the
URLClassLoader/URLClassPath/JarFile/ZipFile code, and it doesn't seem
to handle the jars being modified from an external source; even though
URLClassPath iterates through all the jars in order each time
searching for a resource, the JarFile objects never get updated if the
file is modified from an external source (and these objects are not
accessible publicly)

Every JarLoader has a private JarFile, and JarLoader#getResource calls
JarFile#getJarEntry, which ends up calling ZipFile#getEntry
This ends up calling ZIP_GetEntry implemented in C
(jdk/src/share/native/java/util/zip/zip_util.c), which iterates
through a jzfile->entries, which is an array of jzcells (these are
defined in zip_util.h)
There's nothing that updates this structure if the file has been
modified externally; it will always contain the original data when it
opened the file, unless modified through the same object

So as Alan said, modifying a JAR file in use leads to unpredictable behaviour
I believe implementing a cache is possible without affecting the
semantics of URLClassPath
It would even be possible to cache the JarEntry/ZipEntry so it doesn't
need to iterate through jzfile->entries for every JarFile
The motivation is to
1. Remove linear checking all the JarLoaders to get a resource
2. Remove linear checking all the entries in a JarFile to see if it
contains a resource

I noticed a couple other complications:
1. We can cache entries in jar files, but resources may still show up
in URLClassPath$Loaders and URLClassPath$FileLoaders "earlier" on the
classpath, which have precedence
2. Not all JarLoaders open the JarFile in the constructor - depends on
the meta index
I noticed a couple other caveats though, which I'll talk about

For the first problem, suppose these are the items in
URLClassPath#loaders (an ArrayList<Loader>):
0. FileLoader
1. JarLoader
2. JarLoader

And we call URLClassPath#getResource for the first time for "abc".
It creates the FileLoader, calls FileLoader#getResource, and doesn't find "abc".
It creates the JarLoader, calls JarLoader#getResource, and finds "abc".
It also caches "def" and "ghi" which this jar contains, so
URLClassPath has a map which points these resources to this loader.
The loader keeps its own map of resources -> JarEntries.
When we call URLClassPath#getResource for "def" or "ghi", we'll find
entries in our cache/map, but it's important to check the first
FileLoader as it comes before the JarLoader

For the second problem, I found the meta index best documented in its
source  (online link:
http://www.docjar.com/html/api/sun/misc/MetaIndex.java.html).
To my understanding, the meta index provides information on which
classes a jar file may contain (typically system jar files? the file
is auto generated)
When a meta index is present, the JarLoader doesn't open the JarFile
eagerly because the meta index can say if a jar definitely doesn't
contain a resource (it delays opening the jar until it has to)

The workaround is to keep track of which Loaders have cached entries.
There's no caching for Loader and FileLoader, and for JarLoaders where
the meta index is present.
With the cache, we can ignore all the JarLoaders with cached entries
(i.e. your average jar files)

I don't think the overhead for reading all the jar entries to build
the cache is a problem because as it is JarFile already needs to do a
linear search through all its entries when calling getJarEntry

I implemented changes based on what I described above to test its
performance/see if it would work.
I'm running a basic HDFS client which reads data from a datanode.
It loads ~1600 classes from ~100 jar library files.
Normally, URLClassPath#getResource in total takes ~850ms.
With the change, it takes ~550ms

I included a patch below to show what I mean (in case the code is
clearer than my description), and in case someone wants to try the
changes themselves (my apologies if there's a better way to do this -
I'm still new to the mailing list)

Hopefully I explained my thoughts well, and I tried to explain the
"why" in my comments in the code

Any insight on why this would/wouldn't work or wouldn't be ideal would
be greatly appreciated
I'm just trying to get a better understand of how JVM (classloading)
works, why it works that way, and how it could be improved

Best regards,
Adrian

Patch to URLClassPath.java (also attached, but I'm not sure if attachments work)
diff --git a/src/share/classes/sun/misc/URLClassPath.java
b/src/share/classes/sun/misc/URLClassPath.java
--- a/src/share/classes/sun/misc/URLClassPath.java
+++ b/src/share/classes/sun/misc/URLClassPath.java
@@ -86,6 +86,7 @@

     /* Map of each URL opened to its corresponding Loader */
     HashMap<String, Loader> lmap = new HashMap<String, Loader>();
+    HashMap<String, Loader> cmap = new HashMap<String, Loader>();

     /* The jar protocol handler to use when creating new URLs */
     private URLStreamHandler jarHandler;
@@ -195,6 +196,37 @@
         }

         Loader loader;
+        Loader cachedLoader = cmap.get(name);
+        if (cachedLoader != null) {
+            // only loop through already initialized loaders
+            // if we have a cache entry for this resource, it means
it exists in one of the already initialized JarLoaders
+            // we only have to check Loaders and FileLoaders that
come before it
+            for (int i = 0; i < loaders.size(); i++) {
+                loader = getLoader(i);
+                // we checked all loaders prior to the cached loader
we know contains this resource
+                if (loader == cachedLoader) {
+                    break;
+                }
+                // the cache maps a resource to the first JarLoader
that contains it*
+                // if the current loader is a JarLoader and it is not
the cached hit, it doesn't contain the resource
+                // * based on the meta index, a JarLoader may not
open a JarFile when constructed
+                //   so some JarLoaders don't have cached entries; we
still need to check them
+                //   because they are before the cached loader
+                //   Each JarLoader keeps track of whether it has
cached its entries or not
+                //   getAreEntriesCached will always be false for
Loaders and FileLoaders
+                if (loader.getAreEntriesCached()) {
+                    continue;
+                }
+                Resource res = loader.getResource(name, check);
+                if (res != null) {
+                    return res;
+                }
+            }
+            // we tested all the prior loaders that could possibly
contain the resource
+            // the resource was not found there, so we know our
cached loader is the first loader that contains the resource
+            return cachedLoader.getResource(name, check);
+        }
+
         for (int i = 0; (loader = getLoader(i)) != null; i++) {
             Resource res = loader.getResource(name, check);
             if (res != null) {
@@ -363,7 +395,7 @@
                             return new Loader(url);
                         }
                     } else {
-                        return new JarLoader(url, jarHandler, lmap);
+                        return new JarLoader(url, jarHandler, lmap, cmap);
                     }
                 }
             });
@@ -471,12 +503,16 @@
     private static class Loader implements Closeable {
         private final URL base;
         private JarFile jarfile; // if this points to a jar file
+        // whether or not this Loader has added its entries to
URLClassPath's cache
+        // only set to true by JarLoader
+        protected boolean areEntriesCached;

         /*
          * Creates a new Loader for the specified URL.
          */
         Loader(URL url) {
             base = url;
+            areEntriesCached = false;
         }

         /*
@@ -583,6 +619,10 @@
         URL[] getClassPath() throws IOException {
             return null;
         }
+
+        public boolean getAreEntriesCached() {
+            return areEntriesCached;
+        }
     }

     /*
@@ -595,6 +635,8 @@
         private MetaIndex metaIndex;
         private URLStreamHandler handler;
         private HashMap<String, Loader> lmap;
+        private HashMap<String, Loader> cmap;
+        private HashMap<String, JarEntry> jemap;
         private boolean closed = false;
         private static final sun.misc.JavaUtilZipFileAccess zipAccess =
                 sun.misc.SharedSecrets.getJavaUtilZipFileAccess();
@@ -604,13 +646,15 @@
          * a JAR file.
          */
         JarLoader(URL url, URLStreamHandler jarHandler,
-                  HashMap<String, Loader> loaderMap)
+                  HashMap<String, Loader> loaderMap, HashMap<String,
Loader> classMap)
             throws IOException
         {
             super(new URL("jar", "", -1, url + "!/", jarHandler));
             csu = url;
             handler = jarHandler;
             lmap = loaderMap;
+            cmap = classMap;
+            jemap = new HashMap<String, JarEntry>();

             if (!isOptimizable(url)) {
                 ensureOpen();
@@ -638,6 +682,23 @@
                     ensureOpen();
                 }
             }
+
+            if (jar != null) {
+                // if the metaIndex is not null, it can be used to
check if a jar definitely doesn't contain a resource
+                // in that case, the jar is not necessarily opened yet
+                Enumeration<JarEntry> entries = jar.entries();
+                while (entries.hasMoreElements()) {
+                    JarEntry je = entries.nextElement();
+                    String name = je.getName();
+                    if (!cmap.containsKey(name)) {
+                        // URLClassPath's cmap keeps track of
resource -> JarLoader
+                        cmap.put(name, this);
+                        // local jemap keeps track of resource -> JarEntry
+                        jemap.put(name, je);
+                    }
+                }
+                areEntriesCached = true;
+            }
         }

         @Override
@@ -837,7 +898,9 @@
             } catch (IOException e) {
                 throw (InternalError) new InternalError().initCause(e);
             }
-            final JarEntry entry = jar.getJarEntry(name);
+            // no need to call JarFile#getJarEntry(name),
+            // which does a linear search of an internal data
structure containing all zip file entries
+            final JarEntry entry = jemap.get(name);
             if (entry != null)
                 return checkResource(name, check, entry);

@@ -890,7 +953,7 @@
                                 new PrivilegedExceptionAction<JarLoader>() {
                                     public JarLoader run() throws IOException {
                                         return new JarLoader(url, handler,
-                                            lmap);
+                                            lmap, cmap);
                                     }
                                 });

On Mon, Aug 31, 2015 at 6:07 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
>
> On 31/08/2015 04:02, Jonathan Yu wrote:
>>
>> Hi Adrian,
>>
>> It's possible for jar files to be modified while the JVM is running - is
>> there some facility for detecting that an archive was modified and thus
>> invalidating the cache?
>>
> Modifying a JAR file that is in use leads to unpredictable behavior and can
> even cause crashes too (when JAR/zip files are memory mapped). That said,
> the class path can extend over time, the most obvious being when JAR files
> have the Class-Path attribute. It is possible to construct a cache at
> run-time that is package name -> the first JAR file containing that package
> but at the cost of scanning the contents of JAR files (probably on open).
> There was a lot of experiments and prototypes in the past along these lines.
>
> -Alan.
-------------- next part --------------
diff --git a/src/share/classes/sun/misc/URLClassPath.java b/src/share/classes/sun/misc/URLClassPath.java
--- a/src/share/classes/sun/misc/URLClassPath.java
+++ b/src/share/classes/sun/misc/URLClassPath.java
@@ -86,6 +86,7 @@
 
     /* Map of each URL opened to its corresponding Loader */
     HashMap<String, Loader> lmap = new HashMap<String, Loader>();
+    HashMap<String, Loader> cmap = new HashMap<String, Loader>();
 
     /* The jar protocol handler to use when creating new URLs */
     private URLStreamHandler jarHandler;
@@ -195,6 +196,37 @@
         }
 
         Loader loader;
+        Loader cachedLoader = cmap.get(name);
+        if (cachedLoader != null) {
+            // only loop through already initialized loaders
+            // if we have a cache entry for this resource, it means it exists in one of the already initialized JarLoaders
+            // we only have to check Loaders and FileLoaders that come before it
+            for (int i = 0; i < loaders.size(); i++) {
+                loader = getLoader(i);
+                // we checked all loaders prior to the cached loader we know contains this resource
+                if (loader == cachedLoader) {
+                    break;
+                }
+                // the cache maps a resource to the first JarLoader that contains it*
+                // if the current loader is a JarLoader and it is not the cached hit, it doesn't contain the resource
+                // * based on the meta index, a JarLoader may not open a JarFile when constructed
+                //   so some JarLoaders don't have cached entries; we still need to check them
+                //   because they are before the cached loader
+                //   Each JarLoader keeps track of whether it has cached its entries or not
+                //   getAreEntriesCached will always be false for Loaders and FileLoaders
+                if (loader.getAreEntriesCached()) {
+                    continue;
+                }
+                Resource res = loader.getResource(name, check);
+                if (res != null) {
+                    return res;
+                }
+            }
+            // we tested all the prior loaders that could possibly contain the resource
+            // the resource was not found there, so we know our cached loader is the first loader that contains the resource
+            return cachedLoader.getResource(name, check);
+        }
+
         for (int i = 0; (loader = getLoader(i)) != null; i++) {
             Resource res = loader.getResource(name, check);
             if (res != null) {
@@ -363,7 +395,7 @@
                             return new Loader(url);
                         }
                     } else {
-                        return new JarLoader(url, jarHandler, lmap);
+                        return new JarLoader(url, jarHandler, lmap, cmap);
                     }
                 }
             });
@@ -471,12 +503,16 @@
     private static class Loader implements Closeable {
         private final URL base;
         private JarFile jarfile; // if this points to a jar file
+        // whether or not this Loader has added its entries to URLClassPath's cache
+        // only set to true by JarLoader
+        protected boolean areEntriesCached;
 
         /*
          * Creates a new Loader for the specified URL.
          */
         Loader(URL url) {
             base = url;
+            areEntriesCached = false;
         }
 
         /*
@@ -583,6 +619,10 @@
         URL[] getClassPath() throws IOException {
             return null;
         }
+
+        public boolean getAreEntriesCached() {
+            return areEntriesCached;
+        }
     }
 
     /*
@@ -595,6 +635,8 @@
         private MetaIndex metaIndex;
         private URLStreamHandler handler;
         private HashMap<String, Loader> lmap;
+        private HashMap<String, Loader> cmap;
+        private HashMap<String, JarEntry> jemap;
         private boolean closed = false;
         private static final sun.misc.JavaUtilZipFileAccess zipAccess =
                 sun.misc.SharedSecrets.getJavaUtilZipFileAccess();
@@ -604,13 +646,15 @@
          * a JAR file.
          */
         JarLoader(URL url, URLStreamHandler jarHandler,
-                  HashMap<String, Loader> loaderMap)
+                  HashMap<String, Loader> loaderMap, HashMap<String, Loader> classMap)
             throws IOException
         {
             super(new URL("jar", "", -1, url + "!/", jarHandler));
             csu = url;
             handler = jarHandler;
             lmap = loaderMap;
+            cmap = classMap;
+            jemap = new HashMap<String, JarEntry>();
 
             if (!isOptimizable(url)) {
                 ensureOpen();
@@ -638,6 +682,23 @@
                     ensureOpen();
                 }
             }
+
+            if (jar != null) {
+                // if the metaIndex is not null, it can be used to check if a jar definitely doesn't contain a resource
+                // in that case, the jar is not necessarily opened yet
+                Enumeration<JarEntry> entries = jar.entries();
+                while (entries.hasMoreElements()) {
+                    JarEntry je = entries.nextElement();
+                    String name = je.getName();
+                    if (!cmap.containsKey(name)) {
+                        // URLClassPath's cmap keeps track of resource -> JarLoader
+                        cmap.put(name, this);
+                        // local jemap keeps track of resource -> JarEntry
+                        jemap.put(name, je);
+                    }
+                }
+                areEntriesCached = true;
+            }
         }
 
         @Override
@@ -837,7 +898,9 @@
             } catch (IOException e) {
                 throw (InternalError) new InternalError().initCause(e);
             }
-            final JarEntry entry = jar.getJarEntry(name);
+            // no need to call JarFile#getJarEntry(name),
+            // which does a linear search of an internal data structure containing all zip file entries
+            final JarEntry entry = jemap.get(name);
             if (entry != null)
                 return checkResource(name, check, entry);
 
@@ -890,7 +953,7 @@
                                 new PrivilegedExceptionAction<JarLoader>() {
                                     public JarLoader run() throws IOException {
                                         return new JarLoader(url, handler,
-                                            lmap);
+                                            lmap, cmap);
                                     }
                                 });
 

From vyom.tewari at oracle.com  Tue Sep  1 08:38:57 2015
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Tue, 1 Sep 2015 14:08:57 +0530
Subject: RFR <8064470 > JNI exception pending in
	jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c
Message-ID: <55E56421.8090406@oracle.com>

Hi everyone,

Can you please review my changes for below bug.

Bug:
     JDK-8064470 : JNI exception pending in 
jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c

Webrev:
http://cr.openjdk.java.net/~dfuchs/vyom/8064470/webrev.01/

This change ensure that we immediately return if an exception has been 
raised (result == NULL) by GetMethodId() or proceed to the next
line if there is no JNI pending exception.

if result is NULL, there is a pending exception, and we return. if 
result is not NULL, there is no pending exception, and we proceed to the 
next line...

Thanks,
Vyom


From Alan.Bateman at oracle.com  Tue Sep  1 08:49:41 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 01 Sep 2015 09:49:41 +0100
Subject: RFR <8064470 > JNI exception pending in
	jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c
In-Reply-To: <55E56421.8090406@oracle.com>
References: <55E56421.8090406@oracle.com>
Message-ID: <55E566A5.8050203@oracle.com>

On 01/09/2015 09:38, Vyom Tewari wrote:
> Hi everyone,
>
> Can you please review my changes for below bug.
>
> Bug:
>     JDK-8064470 : JNI exception pending in 
> jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c
>
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/vyom/8064470/webrev.01/
>
> This change ensure that we immediately return if an exception has been 
> raised (result == NULL) by GetMethodId() or proceed to the next
> line if there is no JNI pending exception.
>
> if result is NULL, there is a pending exception, and we return. if 
> result is not NULL, there is no pending exception, and we proceed to 
> the next line...
This looks okay although if we run out of resources here then it means 
there aren't sufficient resources to even start the VM fully.

The reordering of the includes makes me wonder if jvm.h is needed, it 
doesn't appear to be.

-Alan.


From chris.hegarty at oracle.com  Tue Sep  1 09:12:53 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 1 Sep 2015 10:12:53 +0100
Subject: RFR <8064470 > JNI exception pending in
	jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c
In-Reply-To: <55E56421.8090406@oracle.com>
References: <55E56421.8090406@oracle.com>
Message-ID: <02E2D052-F4B2-41FD-A04C-76CFFE82E926@oracle.com>

Hi Vyom,

On 1 Sep 2015, at 09:38, Vyom Tewari <vyom.tewari at oracle.com> wrote:

> Hi everyone,
> 
> Can you please review my changes for below bug.
> 
> Bug:
>    JDK-8064470 : JNI exception pending in jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c
> 
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/vyom/8064470/webrev.01/

The changes look ok to me, and consistent with the Windows variant. Note that the final CHECK_NULL is not strictly necessary, but we seem to have adopted this style to avoid potential future mistakes if additional code is added.

-Chris.


> This change ensure that we immediately return if an exception has been raised (result == NULL) by GetMethodId() or proceed to the next
> line if there is no JNI pending exception.
> 
> if result is NULL, there is a pending exception, and we return. if result is not NULL, there is no pending exception, and we proceed to the next line...
> 
> Thanks,
> Vyom



From daniel.fuchs at oracle.com  Tue Sep  1 09:59:32 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 1 Sep 2015 11:59:32 +0200
Subject: RFR <8064470 > JNI exception pending in
	jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c
In-Reply-To: <55E56421.8090406@oracle.com>
References: <55E56421.8090406@oracle.com>
Message-ID: <55E57704.7080307@oracle.com>

Hi Vyom,

Thanks for taking care of this issue.
This looks good to me as well.

I can sponsor this change for you.

best regards,

-- daniel

On 01/09/15 10:38, Vyom Tewari wrote:
> Hi everyone,
>
> Can you please review my changes for below bug.
>
> Bug:
>      JDK-8064470 : JNI exception pending in
> jdk/src/java/base/unix/native/libjava/FileDescriptor_md.c
>
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/vyom/8064470/webrev.01/
>
> This change ensure that we immediately return if an exception has been
> raised (result == NULL) by GetMethodId() or proceed to the next
> line if there is no JNI pending exception.
>
> if result is NULL, there is a pending exception, and we return. if
> result is not NULL, there is no pending exception, and we proceed to the
> next line...
>
> Thanks,
> Vyom



From tbuktu at hotmail.com  Tue Sep  1 17:48:09 2015
From: tbuktu at hotmail.com (Tim Buktu)
Date: Tue, 1 Sep 2015 19:48:09 +0200
Subject: Note on #8014320
Message-ID: <BLU436-SMTP1932909817379316469056BC66A0@phx.gbl>

Hi,

there is a variant of SSA described by Zimmermann and Brent (http://www.loria.fr/~zimmerma/mca) whose running time increases more smoothly than this implementation, although time complexity is the same. It would require rewriting major parts of the code, though.
Just an FYI for the record.

Tim



From brian.burkhalter at oracle.com  Tue Sep  1 18:12:24 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 1 Sep 2015 11:12:24 -0700
Subject: Note on #8014320
In-Reply-To: <BLU436-SMTP1932909817379316469056BC66A0@phx.gbl>
References: <BLU436-SMTP1932909817379316469056BC66A0@phx.gbl>
Message-ID: <693EE555-45F8-46A0-A982-F6DA167BB1AD@oracle.com>

On Sep 1, 2015, at 10:48 AM, Tim Buktu <tbuktu at hotmail.com> wrote:

> there is a variant of SSA described by Zimmermann and Brent (http://www.loria.fr/~zimmerma/mca)

Thanks for the pointer but the link above gives me:

"L'acc?s ? cette page est interdit !"

A pre-release version of their book is however available here

http://www.loria.fr/~zimmerma/mca/mca-cup-0.5.9.pdf

via

http://www.loria.fr/~zimmerma/mca/pub226.html

> whose running time increases more smoothly than this implementation, although time complexity is the same. It would require rewriting major parts of the code, though.
> Just an FYI for the record.

Thanks for the suggestion.

Brian

From vyom.tewari at oracle.com  Wed Sep  2 13:22:16 2015
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Wed, 2 Sep 2015 18:52:16 +0530
Subject: RFR 8080486: JNI exception pending in
	jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c
Message-ID: <55E6F808.9080902@oracle.com>

Hi everyone,

Can you please review my changes for below bug.

Bug:
      JDK-8080486 : JNI exception pending in 
jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c

Webrev:
http://cr.openjdk.java.net/~dfuchs/vyom/8080486/webrev.01

This change ensure that we immediately return if an exception has been 
raised (result == NULL) by GetMethodId/NewGlobalRef or proceed to the 
next statement if there is no JNI pending exception.

Thanks,
Vyom


From ivan.gerasimov at oracle.com  Wed Sep  2 13:55:11 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 2 Sep 2015 16:55:11 +0300
Subject: RFR 8080486: JNI exception pending in
	jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c
In-Reply-To: <55E6F808.9080902@oracle.com>
References: <55E6F808.9080902@oracle.com>
Message-ID: <55E6FFBF.5010905@oracle.com>

This looks good.

In general, it might be more appropriate to review this on 
net-dev at openjdk.java.net alias.

Sincerely yours,
Ivan


On 02.09.2015 16:22, Vyom Tewari wrote:
> Hi everyone,
>
> Can you please review my changes for below bug.
>
> Bug:
>      JDK-8080486 : JNI exception pending in 
> jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c
>
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/vyom/8080486/webrev.01
>
> This change ensure that we immediately return if an exception has been 
> raised (result == NULL) by GetMethodId/NewGlobalRef or proceed to the 
> next statement if there is no JNI pending exception.
>
> Thanks,
> Vyom
>



From joe.darcy at oracle.com  Wed Sep  2 19:27:04 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 02 Sep 2015 12:27:04 -0700
Subject: JDK 9 RFR of JDK-8134982: Problem list TCKJapaneseChronology.java
Message-ID: <55E74D88.5070800@oracle.com>

Hello,

Until the HotSpot issue in JDK-8134979 is addressed, the test

     java/time/tck/java/time/chrono/TCKJapaneseChronology.java

should be placed on the problem list to avoid repeated uninformative 
test failures.

Please review the patch below.

Thanks,

-Joe

diff -r d9bd64884486 test/ProblemList.txt
--- a/test/ProblemList.txt    Wed Sep 02 13:24:14 2015 -0500
+++ b/test/ProblemList.txt    Wed Sep 02 12:26:33 2015 -0700
@@ -319,6 +319,9 @@

  # jdk_time

+# 8134979
+java/time/tck/java/time/chrono/TCKJapaneseChronology.java generic-all
+
  ############################################################################

  # jdk_tools



From lance.andersen at oracle.com  Wed Sep  2 19:53:00 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 2 Sep 2015 15:53:00 -0400
Subject: JDK 9 RFR of JDK-8134982: Problem list TCKJapaneseChronology.java
In-Reply-To: <55E74D88.5070800@oracle.com>
References: <55E74D88.5070800@oracle.com>
Message-ID: <02599357-79D9-479F-9B69-19963F7652B0@oracle.com>

ok by me

On Sep 2, 2015, at 3:27 PM, "Joseph D. Darcy" <joe.darcy at oracle.com> wrote:

> Hello,
> 
> Until the HotSpot issue in JDK-8134979 is addressed, the test
> 
>    java/time/tck/java/time/chrono/TCKJapaneseChronology.java
> 
> should be placed on the problem list to avoid repeated uninformative test failures.
> 
> Please review the patch below.
> 
> Thanks,
> 
> -Joe
> 
> diff -r d9bd64884486 test/ProblemList.txt
> --- a/test/ProblemList.txt    Wed Sep 02 13:24:14 2015 -0500
> +++ b/test/ProblemList.txt    Wed Sep 02 12:26:33 2015 -0700
> @@ -319,6 +319,9 @@
> 
> # jdk_time
> 
> +# 8134979
> +java/time/tck/java/time/chrono/TCKJapaneseChronology.java generic-all
> +
> ############################################################################
> 
> # jdk_tools
> 



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 martinrb at google.com  Wed Sep  2 20:05:11 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 2 Sep 2015 13:05:11 -0700
Subject: RFR: 8134984: Text files should end in exactly one newline
Message-ID: <CA+kOe0-81E4r_Mv+j84icxaa8+YnSjg+smR2J+d-7ZxVtcmJkQ@mail.gmail.com>

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/one-newline/one-newline.patch
https://bugs.openjdk.java.net/browse/JDK-8134984

Sherman, what's up with repeated A1A4 in IBM1381.c2b?


From chris.hegarty at oracle.com  Wed Sep  2 20:14:28 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 2 Sep 2015 21:14:28 +0100
Subject: RFR: 8134984: Text files should end in exactly one newline
In-Reply-To: <CA+kOe0-81E4r_Mv+j84icxaa8+YnSjg+smR2J+d-7ZxVtcmJkQ@mail.gmail.com>
References: <CA+kOe0-81E4r_Mv+j84icxaa8+YnSjg+smR2J+d-7ZxVtcmJkQ@mail.gmail.com>
Message-ID: <AA87FFFF-110B-4FB7-A620-53101C0457C6@oracle.com>

There was a thread a while back, over on the tools mailing list about the enforcement of this [1].

-Chris.

[1] http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-May/thread.html <http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-May/thread.html>


> On 2 Sep 2015, at 21:05, Martin Buchholz <martinrb at google.com> wrote:
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/one-newline/one-newline.patch
> https://bugs.openjdk.java.net/browse/JDK-8134984
> 
> Sherman, what's up with repeated A1A4 in IBM1381.c2b?



From martinrb at google.com  Wed Sep  2 20:22:23 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 2 Sep 2015 13:22:23 -0700
Subject: RFR: 8134984: Text files should end in exactly one newline
In-Reply-To: <AA87FFFF-110B-4FB7-A620-53101C0457C6@oracle.com>
References: <CA+kOe0-81E4r_Mv+j84icxaa8+YnSjg+smR2J+d-7ZxVtcmJkQ@mail.gmail.com>
	<AA87FFFF-110B-4FB7-A620-53101C0457C6@oracle.com>
Message-ID: <CA+kOe0-8YxaYkNavh2eTASKWQmXmAo6qj6tEg4w5x2hD5Q5+=w@mail.gmail.com>

On Wed, Sep 2, 2015 at 1:14 PM, Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> There was a thread a while back, over on the tools mailing list about the
> enforcement of this [1].
>

I support enforcement of one-newline via jcheck or other mechanism, and
this change would be a pre-requisite for that, but we can fix things even
without a change to jcheck.


From chris.hegarty at oracle.com  Wed Sep  2 20:27:43 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 2 Sep 2015 21:27:43 +0100
Subject: RFR: 8134984: Text files should end in exactly one newline
In-Reply-To: <CA+kOe0-8YxaYkNavh2eTASKWQmXmAo6qj6tEg4w5x2hD5Q5+=w@mail.gmail.com>
References: <CA+kOe0-81E4r_Mv+j84icxaa8+YnSjg+smR2J+d-7ZxVtcmJkQ@mail.gmail.com>
	<AA87FFFF-110B-4FB7-A620-53101C0457C6@oracle.com>
	<CA+kOe0-8YxaYkNavh2eTASKWQmXmAo6qj6tEg4w5x2hD5Q5+=w@mail.gmail.com>
Message-ID: <E21779D5-8E7A-4F09-A620-B11253599AC5@oracle.com>


> On 2 Sep 2015, at 21:22, Martin Buchholz <martinrb at google.com> wrote:
> 
> 
> On Wed, Sep 2, 2015 at 1:14 PM, Chris Hegarty <chris.hegarty at oracle.com <mailto:chris.hegarty at oracle.com>> wrote:
> There was a thread a while back, over on the tools mailing list about the enforcement of this [1].
> 
> I support enforcement of one-newline via jcheck or other mechanism, and this change would be a pre-requisite for that, but we can fix things even without a change to jcheck.  

Right. The change looks ok to me.

-Chris.



From xueming.shen at oracle.com  Wed Sep  2 20:56:45 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 02 Sep 2015 13:56:45 -0700
Subject: RFR: 8134984: Text files should end in exactly one newline
In-Reply-To: <CA+kOe0-81E4r_Mv+j84icxaa8+YnSjg+smR2J+d-7ZxVtcmJkQ@mail.gmail.com>
References: <CA+kOe0-81E4r_Mv+j84icxaa8+YnSjg+smR2J+d-7ZxVtcmJkQ@mail.gmail.com>
Message-ID: <55E7628D.6040903@oracle.com>

On 09/02/2015 01:05 PM, Martin Buchholz wrote:
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/one-newline/one-newline.patch <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/one-newline/one-newline.patch>
> https://bugs.openjdk.java.net/browse/JDK-8134984
>
> Sherman, what's up with repeated A1A4 in IBM1381.c2b?

That's a c2b table, the content means both u00b7 and u7ac2 should be mapped
to A1A4 (1:m mapping)...but the u7ac2 is strange, my unicode book suggests it's
a CJK. The comment suggests it was a fix for

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

back to 1.2.2. I need to pull out the original IBM1381 to verify the mapping ...




From volker.simonis at gmail.com  Thu Sep  3 15:12:59 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 3 Sep 2015 17:12:59 +0200
Subject: RFR: 8134984: Text files should end in exactly one newline
In-Reply-To: <AA87FFFF-110B-4FB7-A620-53101C0457C6@oracle.com>
References: <CA+kOe0-81E4r_Mv+j84icxaa8+YnSjg+smR2J+d-7ZxVtcmJkQ@mail.gmail.com>
	<AA87FFFF-110B-4FB7-A620-53101C0457C6@oracle.com>
Message-ID: <CA+3eh110TbOOdi=GJLEBAsWvcZtU8p8RaOpgekSzJDEttV2KeA@mail.gmail.com>

Hi,

I think I proposed a pretty good solution for the "jcheck" problem
back then in May (see the mailing list thread posted by Chris and the
quote below) and I got two positive reviews from Chris and Magnus.
Unfortunately neither are they "code-tools" reviewers nor am I a
"code-tools" comitter and it seems to be notoriously hard to get a
sponsor from that group :)

Quoting from my previous mail:

I've introduced a new attribute 'check_eof' in .jcheck/conf which
controls the behavior of the new feature:

# Test if we should check for a correct EOF (i.e. files end with
exatly one '\n')
# This behaviour is controlled by the 'check_eof' attribute in the conf file.
# -1 means to not check for EOF at all.
#  0 means to potentially check all the changes for a correct EOF.
#    any other positive number is interpreted as the revision number or change-
#    set ID from which on jcheck should start checking for a correct EOF.
# If the 'check_eof' attribute is missing, '-1' (i.e. no EOF check)
will be assumed.

This way we can change jcheck and add the new EOF checking without
changing its behaviour on any existing, jcheck-enabled repositories.
Afterwards, any single repository can enable the EOF-checking from an
arbitrary changeset on-wards.

Here's the webrev:

http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298.v2/

Is anybody willing to assist sponsoring this change?

Volker





On Wed, Sep 2, 2015 at 10:14 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> There was a thread a while back, over on the tools mailing list about the enforcement of this [1].
>
> -Chris.
>
> [1] http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-May/thread.html <http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-May/thread.html>
>
>
>> On 2 Sep 2015, at 21:05, Martin Buchholz <martinrb at google.com> wrote:
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/one-newline/one-newline.patch
>> https://bugs.openjdk.java.net/browse/JDK-8134984
>>
>> Sherman, what's up with repeated A1A4 in IBM1381.c2b?
>


From martinrb at google.com  Fri Sep  4 03:23:31 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 3 Sep 2015 20:23:31 -0700
Subject: RFR: 8134984: Text files should end in exactly one newline
In-Reply-To: <CA+3eh110TbOOdi=GJLEBAsWvcZtU8p8RaOpgekSzJDEttV2KeA@mail.gmail.com>
References: <CA+kOe0-81E4r_Mv+j84icxaa8+YnSjg+smR2J+d-7ZxVtcmJkQ@mail.gmail.com>
	<AA87FFFF-110B-4FB7-A620-53101C0457C6@oracle.com>
	<CA+3eh110TbOOdi=GJLEBAsWvcZtU8p8RaOpgekSzJDEttV2KeA@mail.gmail.com>
Message-ID: <CA+kOe080XM7wUo95bPbe+dFrb84GyBeC5VafMjDOrd09kT0bOw@mail.gmail.com>

[+hg-tools-dev]

hg-tools-dev seems to be the mailing list for jcheck.

I support adding new checks to jcheck, but I also have no code-tools
superpowers and I have not looked at Volker's proposed change for jcheck.

(I wish it were easier to change openjdk.  Current access control is too
fine grained and enabling contributors requires too much paperwork.)

(I've committed my one-newline change for the jdk repo; I encourage others
to do the same for other repos)

On Thu, Sep 3, 2015 at 8:12 AM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi,
>
> I think I proposed a pretty good solution for the "jcheck" problem
> back then in May (see the mailing list thread posted by Chris and the
> quote below) and I got two positive reviews from Chris and Magnus.
> Unfortunately neither are they "code-tools" reviewers nor am I a
> "code-tools" comitter and it seems to be notoriously hard to get a
> sponsor from that group :)
>
> Quoting from my previous mail:
>
> I've introduced a new attribute 'check_eof' in .jcheck/conf which
> controls the behavior of the new feature:
>
> # Test if we should check for a correct EOF (i.e. files end with
> exatly one '\n')
> # This behaviour is controlled by the 'check_eof' attribute in the conf
> file.
> # -1 means to not check for EOF at all.
> #  0 means to potentially check all the changes for a correct EOF.
> #    any other positive number is interpreted as the revision number or
> change-
> #    set ID from which on jcheck should start checking for a correct EOF.
> # If the 'check_eof' attribute is missing, '-1' (i.e. no EOF check)
> will be assumed.
>
> This way we can change jcheck and add the new EOF checking without
> changing its behaviour on any existing, jcheck-enabled repositories.
> Afterwards, any single repository can enable the EOF-checking from an
> arbitrary changeset on-wards.
>
> Here's the webrev:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/7901298.v2/
>
> Is anybody willing to assist sponsoring this change?
>
> Volker
>
>
>
>
>
> On Wed, Sep 2, 2015 at 10:14 PM, Chris Hegarty <chris.hegarty at oracle.com>
> wrote:
> > There was a thread a while back, over on the tools mailing list about
> the enforcement of this [1].
> >
> > -Chris.
> >
> > [1]
> http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-May/thread.html <
> http://mail.openjdk.java.net/pipermail/hg-tools-dev/2015-May/thread.html>
> >
> >
> >> On 2 Sep 2015, at 21:05, Martin Buchholz <martinrb at google.com> wrote:
> >>
> >>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/one-newline/one-newline.patch
> >> https://bugs.openjdk.java.net/browse/JDK-8134984
> >>
> >> Sherman, what's up with repeated A1A4 in IBM1381.c2b?
> >
>


From stuart.marks at oracle.com  Fri Sep  4 06:17:59 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 3 Sep 2015 23:17:59 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
Message-ID: <55E93797.8020408@oracle.com>

Please review this update to the Scanner enhancement I proposed a while back. [1]

I've updated based on some discussions with Paul Sandoz. The updates since the 
previous posting are 1) coordination of spec wording from Matcher; 2) addition 
of ConcurrentModificationException; 3) updating tests to use the streams testing 
framework; 4) some javadoc cleanups.

Bug:

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

Webrev:

	http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.2/

Specdiff:

	http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.2/overview-summary.html


For convenience, I've appended below the description from my earlier post. [1]

s'marks

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034821.html


-------


Scanner is essentially a regular expression matcher that matches over arbitrary 
input (e.g., from a file) instead of a fixed string like Matcher. Scanner will 
read and buffer additional input as necessary when looking for matches.

This change proposes to add two streams methods:

1. tokens(), which returns a stream of tokens delimited by the Scanner's 
delimiter. Scanner's default delimiter is whitespace, so the following will 
collect a list of whitespace-separated words from a file:

     try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
         List<String> words = sc.tokens().collect(toList());
     }

2. findAll(pattern), which returns a stream of match results generated by 
searching the input for the given pattern (either a Pattern or a String). For 
example, the following will extract from a file all words that are surrounded by 
"_" characters, such as _foo_ :

     try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
         return sc.findAll("_([\\w]+)_")
                  .map(mr -> mr.group(1))
                  .collect(toList());
     }

Implementation notes. A Scanner is essentially already an iterator of tokens, so 
tokens() pretty much just wraps "this" into a stream. The findAll() methods are 
a wrapper around repeated calls to findWithinHorizon(pattern, 0) with a bit of 
refactoring to avoid converting the MatchResult to a String prematurely.

The tests are pretty straightforward, with some additional cleanups, such as 
using try-with-resources.

-------


From amaembo at gmail.com  Fri Sep  4 06:57:15 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Fri, 4 Sep 2015 12:57:15 +0600
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55E93797.8020408@oracle.com>
References: <55E93797.8020408@oracle.com>
Message-ID: <1762778776.20150904125715@gmail.com>

Hello!

In tokens() JavaDoc:

     * <pre>{@code
     * List<String> result = new Scanner("abc,def,,ghi").useDelimiter(",").
     *     .tokens().collect(Collectors.toList());
     * }</pre>

Here the dot is duplicated after "useDelimiter()" and before
"tokens()" on the next line.

Everything else looks good to me.

With best regards,
Tagir Valeev.

SM> Please review this update to the Scanner enhancement I proposed a while back. [1]

SM> I've updated based on some discussions with Paul Sandoz. The updates since the
SM> previous posting are 1) coordination of spec wording from Matcher; 2) addition
SM> of ConcurrentModificationException; 3) updating tests to use the streams testing
SM> framework; 4) some javadoc cleanups.

SM> Bug:

SM>         https://bugs.openjdk.java.net/browse/JDK-8072722

SM> Webrev:

SM>         http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.2/

SM> Specdiff:

SM>        
SM> http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.2/overview-summary.html


SM> For convenience, I've appended below the description from my earlier post. [1]

SM> s'marks

SM> [1]
SM> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034821.html


SM> -------


SM> Scanner is essentially a regular expression matcher that matches over arbitrary
SM> input (e.g., from a file) instead of a fixed string like Matcher. Scanner will
SM> read and buffer additional input as necessary when looking for matches.

SM> This change proposes to add two streams methods:

SM> 1. tokens(), which returns a stream of tokens delimited by the Scanner's
SM> delimiter. Scanner's default delimiter is whitespace, so the following will
SM> collect a list of whitespace-separated words from a file:

SM>      try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
SM>          List<String> words = sc.tokens().collect(toList());
SM>      }

SM> 2. findAll(pattern), which returns a stream of match results generated by
SM> searching the input for the given pattern (either a Pattern or a String). For
SM> example, the following will extract from a file all words that are surrounded by
SM> "_" characters, such as _foo_ :

SM>      try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
SM>          return sc.findAll("_([\\w]+)_")
SM>                   .map(mr -> mr.group(1))
SM>                   .collect(toList());
SM>      }

SM> Implementation notes. A Scanner is essentially already an iterator of tokens, so
SM> tokens() pretty much just wraps "this" into a stream. The findAll() methods are
SM> a wrapper around repeated calls to findWithinHorizon(pattern, 0) with a bit of
SM> refactoring to avoid converting the MatchResult to a String prematurely.

SM> The tests are pretty straightforward, with some additional cleanups, such as
SM> using try-with-resources.

SM> -------



From paul.sandoz at oracle.com  Fri Sep  4 08:35:01 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 4 Sep 2015 10:35:01 +0200
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55E93797.8020408@oracle.com>
References: <55E93797.8020408@oracle.com>
Message-ID: <C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>

Hi Stuart,

This is looking very good.

Just some comments on the tricky aspect related to late-binding of the Stream to the scanner state:

2652      * <p>This scanner's state should not be modified during execution of the returned
2653      * stream's pipeline. Subsequent calls to any methods on this scanner other than
2654      * {@link #close} and {@link #ioException} may return undefined results or may cause
2655      * undefined effects on the returned stream. The returned stream's source
2656      * {@code Spliterator} is <em>fail-fast</em> and will, on a best-effort
2657      * basis, throw a {@link java.util.ConcurrentModificationException} if such
2658      * modification is detected.

?Subsequent? is a little vague here, does it mean before, during or after stream pipeline execution?


Before:

Most methods on scanner may be called before stream pipeline execution, they just adjust the scanner state from which to start from. If close is called it should result in an ISE on pipeline execution.

During:

Either a CME on a best-effort basis if scanner state is modified by a behavioural parameter, or an ISE if close is called.

After:

The scanner is in an indeterminate state. For further operations it needs to be reset, and if the scanner was closed during execution an ISE will result on further operations.

We should try and succinctly talk about all three cases in the specification.


You might need to double check FindSpliterator for the before and during cases as i don?t think findPatternInBuffer checks if the scanner is closed, i think it needs an ensureOpen call in tryAdvance.

Paul.

On 4 Sep 2015, at 08:17, Stuart Marks <stuart.marks at oracle.com> wrote:

> Please review this update to the Scanner enhancement I proposed a while back. [1]
> 
> I've updated based on some discussions with Paul Sandoz. The updates since the previous posting are 1) coordination of spec wording from Matcher; 2) addition of ConcurrentModificationException; 3) updating tests to use the streams testing framework; 4) some javadoc cleanups.
> 
> Bug:
> 
> 	https://bugs.openjdk.java.net/browse/JDK-8072722
> 
> Webrev:
> 
> 	http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.2/
> 
> Specdiff:
> 
> 	http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.2/overview-summary.html
> 
> 
> For convenience, I've appended below the description from my earlier post. [1]
> 
> s'marks
> 
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034821.html
> 
> 
> -------
> 
> 
> Scanner is essentially a regular expression matcher that matches over arbitrary input (e.g., from a file) instead of a fixed string like Matcher. Scanner will read and buffer additional input as necessary when looking for matches.
> 
> This change proposes to add two streams methods:
> 
> 1. tokens(), which returns a stream of tokens delimited by the Scanner's delimiter. Scanner's default delimiter is whitespace, so the following will collect a list of whitespace-separated words from a file:
> 
>    try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
>        List<String> words = sc.tokens().collect(toList());
>    }
> 
> 2. findAll(pattern), which returns a stream of match results generated by searching the input for the given pattern (either a Pattern or a String). For example, the following will extract from a file all words that are surrounded by "_" characters, such as _foo_ :
> 
>    try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
>        return sc.findAll("_([\\w]+)_")
>                 .map(mr -> mr.group(1))
>                 .collect(toList());
>    }
> 
> Implementation notes. A Scanner is essentially already an iterator of tokens, so tokens() pretty much just wraps "this" into a stream. The findAll() methods are a wrapper around repeated calls to findWithinHorizon(pattern, 0) with a bit of refactoring to avoid converting the MatchResult to a String prematurely.
> 
> The tests are pretty straightforward, with some additional cleanups, such as using try-with-resources.
> 
> -------



From daniel.fuchs at oracle.com  Fri Sep  4 15:04:18 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 4 Sep 2015 17:04:18 +0200
Subject: RFR 8080486: JNI exception pending in
	jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c
In-Reply-To: <55E6FFBF.5010905@oracle.com>
References: <55E6F808.9080902@oracle.com> <55E6FFBF.5010905@oracle.com>
Message-ID: <55E9B2F2.6030106@oracle.com>

Hi Vyom,

I'm not a net/JNI expert but what you are proposing
looks good to me too. Ivan has already given his assent.

Unless I hear objections - or comments from other reviewers,
I will sponsor this change and push it for you (I'll wait
for Monday).

best regards,

-- daniel

On 02/09/15 15:55, Ivan Gerasimov wrote:
> This looks good.
>
> In general, it might be more appropriate to review this on
> net-dev at openjdk.java.net alias.
>
> Sincerely yours,
> Ivan
>
>
> On 02.09.2015 16:22, Vyom Tewari wrote:
>> Hi everyone,
>>
>> Can you please review my changes for below bug.
>>
>> Bug:
>>      JDK-8080486 : JNI exception pending in
>> jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c
>>
>> Webrev:
>> http://cr.openjdk.java.net/~dfuchs/vyom/8080486/webrev.01
>>
>> This change ensure that we immediately return if an exception has been
>> raised (result == NULL) by GetMethodId/NewGlobalRef or proceed to the
>> next statement if there is no JNI pending exception.
>>
>> Thanks,
>> Vyom
>>
>



From Alan.Bateman at oracle.com  Fri Sep  4 15:09:31 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 04 Sep 2015 16:09:31 +0100
Subject: RFR 8080486: JNI exception pending in
	jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c
In-Reply-To: <55E9B2F2.6030106@oracle.com>
References: <55E6F808.9080902@oracle.com> <55E6FFBF.5010905@oracle.com>
	<55E9B2F2.6030106@oracle.com>
Message-ID: <55E9B42B.2050404@oracle.com>



On 04/09/2015 16:04, Daniel Fuchs wrote:
> Hi Vyom,
>
> I'm not a net/JNI expert but what you are proposing
> looks good to me too. Ivan has already given his assent.
>
> Unless I hear objections - or comments from other reviewers,
> I will sponsor this change and push it for you (I'll wait
> for Monday).
I think it looks fine. I had actually thought we had addressed all of 
these issues some day okay but maybe a few escaped.

-Alan


From chris.hegarty at oracle.com  Fri Sep  4 15:10:46 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 04 Sep 2015 16:10:46 +0100
Subject: RFR 8080486: JNI exception pending in
	jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c
In-Reply-To: <55E9B2F2.6030106@oracle.com>
References: <55E6F808.9080902@oracle.com> <55E6FFBF.5010905@oracle.com>
	<55E9B2F2.6030106@oracle.com>
Message-ID: <55E9B476.9060504@oracle.com>

The changes look fine to me too.

-Chris.

On 04/09/15 16:04, Daniel Fuchs wrote:
> Hi Vyom,
>
> I'm not a net/JNI expert but what you are proposing
> looks good to me too. Ivan has already given his assent.
>
> Unless I hear objections - or comments from other reviewers,
> I will sponsor this change and push it for you (I'll wait
> for Monday).
>
> best regards,
>
> -- daniel
>
> On 02/09/15 15:55, Ivan Gerasimov wrote:
>> This looks good.
>>
>> In general, it might be more appropriate to review this on
>> net-dev at openjdk.java.net alias.
>>
>> Sincerely yours,
>> Ivan
>>
>>
>> On 02.09.2015 16:22, Vyom Tewari wrote:
>>> Hi everyone,
>>>
>>> Can you please review my changes for below bug.
>>>
>>> Bug:
>>>      JDK-8080486 : JNI exception pending in
>>> jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080486/webrev.01
>>>
>>> This change ensure that we immediately return if an exception has been
>>> raised (result == NULL) by GetMethodId/NewGlobalRef or proceed to the
>>> next statement if there is no JNI pending exception.
>>>
>>> Thanks,
>>> Vyom
>>>
>>
>


From stuart.marks at oracle.com  Fri Sep  4 21:38:46 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 4 Sep 2015 14:38:46 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <1762778776.20150904125715@gmail.com>
References: <55E93797.8020408@oracle.com> <1762778776.20150904125715@gmail.com>
Message-ID: <55EA0F66.8010702@oracle.com>

Hi Tagir,

Well spotted! I'll fix this.

Thanks,

s'marks

On 9/3/15 11:57 PM, Tagir F. Valeev wrote:
> Hello!
>
> In tokens() JavaDoc:
>
>       * <pre>{@code
>       * List<String> result = new Scanner("abc,def,,ghi").useDelimiter(",").
>       *     .tokens().collect(Collectors.toList());
>       * }</pre>
>
> Here the dot is duplicated after "useDelimiter()" and before
> "tokens()" on the next line.
>
> Everything else looks good to me.
>
> With best regards,
> Tagir Valeev.
>
> SM> Please review this update to the Scanner enhancement I proposed a while back. [1]
>
> SM> I've updated based on some discussions with Paul Sandoz. The updates since the
> SM> previous posting are 1) coordination of spec wording from Matcher; 2) addition
> SM> of ConcurrentModificationException; 3) updating tests to use the streams testing
> SM> framework; 4) some javadoc cleanups.
>
> SM> Bug:
>
> SM>         https://bugs.openjdk.java.net/browse/JDK-8072722
>
> SM> Webrev:
>
> SM>         http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.2/
>
> SM> Specdiff:
>
> SM>
> SM> http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.2/overview-summary.html
>
>
> SM> For convenience, I've appended below the description from my earlier post. [1]
>
> SM> s'marks
>
> SM> [1]
> SM> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034821.html
>
>
> SM> -------
>
>
> SM> Scanner is essentially a regular expression matcher that matches over arbitrary
> SM> input (e.g., from a file) instead of a fixed string like Matcher. Scanner will
> SM> read and buffer additional input as necessary when looking for matches.
>
> SM> This change proposes to add two streams methods:
>
> SM> 1. tokens(), which returns a stream of tokens delimited by the Scanner's
> SM> delimiter. Scanner's default delimiter is whitespace, so the following will
> SM> collect a list of whitespace-separated words from a file:
>
> SM>      try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
> SM>          List<String> words = sc.tokens().collect(toList());
> SM>      }
>
> SM> 2. findAll(pattern), which returns a stream of match results generated by
> SM> searching the input for the given pattern (either a Pattern or a String). For
> SM> example, the following will extract from a file all words that are surrounded by
> SM> "_" characters, such as _foo_ :
>
> SM>      try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
> SM>          return sc.findAll("_([\\w]+)_")
> SM>                   .map(mr -> mr.group(1))
> SM>                   .collect(toList());
> SM>      }
>
> SM> Implementation notes. A Scanner is essentially already an iterator of tokens, so
> SM> tokens() pretty much just wraps "this" into a stream. The findAll() methods are
> SM> a wrapper around repeated calls to findWithinHorizon(pattern, 0) with a bit of
> SM> refactoring to avoid converting the MatchResult to a String prematurely.
>
> SM> The tests are pretty straightforward, with some additional cleanups, such as
> SM> using try-with-resources.
>
> SM> -------
>


From ivan.gerasimov at oracle.com  Sat Sep  5 14:25:18 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sat, 5 Sep 2015 17:25:18 +0300
Subject: RFR 8072466: Deadlock when starting MulticastSocket and
	DatagramSocket
In-Reply-To: <54E2E5BF.3080304@oracle.com>
References: <54D4FE63.5090108@oracle.com> <54E2E5BF.3080304@oracle.com>
Message-ID: <55EAFB4E.5050506@oracle.com>

Hi everyone!

The fix didn't bring enough attention back in February for some reason.
So, I'd like to re-request a review.

I've added a regression test, which reliably reproduces a deadlock on my 
local Windows 7 machine.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072466
WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/00/webrev/

Sincerely yours,
Ivan

On 17.02.2015 9:54, Ivan Gerasimov wrote:
> Can someone help review this fix please?
>
> Comments/suggestions are welcome!
>
> Sincerely yours,
> Ivan
>
> On 06.02.2015 20:48, Ivan Gerasimov wrote:
>> Hello!
>>
>> There has been a deadlock in jdk-net code noticed on Windows.
>>
>> In the bug description there's a stack snippet showing that one of 
>> the deadlocked threads stuck in the native initialization code of 
>> DualStackPlainDatagramSocketImpl and the other -- in initializing of 
>> TwoStacksPlainDatagramSocketImpl.
>>
>> I suspect that the reason might be due to unordered initialization:
>> AbstractPlainDatagramSocketImpl, the parent of both classes above, 
>> explicitly loads TwoStacksPlainDatagramSocketImpl from the native 
>> init().
>> Thus, when both classes are being initialized concurrently, it may 
>> end with a clash.
>>
>>
>> Another issue noticed by Mark Sheppard is that the Windows version of 
>> DefaultDatagramSocketImplFactory.createDatagramSocketImpl() isn't 
>> synchronized, but reads/modifies shared data.
>> Thus, I removed modification and declared all the accessed fields final.
>>
>> Would you please help review the proposed fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072466
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/0/webrev/
>>
>> The build went fine on all the platforms, all the tests from 
>> (net|nio|io) passed Okay.
>>
>> Sincerely yours,
>> Ivan
>>
>>
>>
>
>
>



From amaembo at gmail.com  Sun Sep  6 10:21:11 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Sun, 6 Sep 2015 16:21:11 +0600
Subject: Collections.emptyList().spliterator() is not ORDERED
Message-ID: <726458471.20150906162111@gmail.com>

Hello!

As Paul Sandoz pointed out in the "Custom spliterator for
Collections.nCopies(n, obj).stream()" discussion, the
List.spliterator() is specified to be ORDERED. However
Collections.emptyList().spliterator() violates this specification:

System.out.println(Collections.emptyList()
  .spliterator().hasCharacteristics(Spliterator.ORDERED));
// prints false

This becomes critical if I want to concatenate streams from the two
lists returned from two different methods (one of which returned
emptyList) and process the result in parallel. For example:

List<Integer> list1 = IntStream.range(0, 100).boxed().collect(Collectors.toList());
List<Integer> list2 = Collections.emptyList();
System.out.println(Stream
      .concat(list1.stream(), list2.stream()).parallel()
      .filter(x -> x >= 0).limit(10).collect(Collectors.toList()));

This code unexpectedly prints some random subset. This can be fixed by
replacing list2 with

List<Integer> list2 = Arrays.asList();

As Arrays.asList().spliterator() is ordered, the resulting stream is
ordered as well, so we see [0, ..., 9] as expected.

Looks like a bug in emptyList() implementation.

With best regards,
Tagir Valeev.



From claes.redestad at oracle.com  Sun Sep  6 19:37:53 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sun, 06 Sep 2015 21:37:53 +0200
Subject: JDK-7198513
In-Reply-To: <55EC8A33.8030904@gmx.de>
References: <55EC8A33.8030904@gmx.de>
Message-ID: <55EC9611.4080508@oracle.com>

[+core-libs-dev]

Hi,

bug database cleanup workflow: I guess raising the issue on the
appropriate mailing list (which for j.u.Formatter happens to be
core-libs-dev) and getting someone on that list with write access to
JBS to review and update the bug is as good as any.

Knowing which mailing list to post to surely isn't obvious, and there's
plenty to choose from[1]. You should also read the guide on how to
contribute[2] and make sure you or your company have signed the
OCA (see [2]) so that we can accept code contributions from you.

As you say, this looks pretty clear-cut: the empty Object[] gets passed
in as the varargs array, which then throws a
MissingFormatArgumentException since fewer arguments then
the specifier is provided, all according to the Formatter javadoc spec.
I'll update and close the bug. Thanks!

/Claes

[1] http://mail.openjdk.java.net
[2] http://openjdk.java.net/contribute/

On 09/06/2015 08:47 PM, Sebastian Sickelmann wrote:
> Hi,
>
> i am looking through same bug-reports for some low hanging fruits and I
> found JDK-7198513[1] ,
> which seems to be a reporting failure. The Formatter works as excepted.
> The reported made a
> small mistake and used the empty ObjectArray without any case, so it is
> used as the var-arg
> parameter (with zero elements).
>
> I think this bug can be closed.
>
> I tested the following on 1.6.0_35, 1.7.0_79 and 1.8.0_45 and it always
> produces the same
> expected result.
>
>
> public class FormatterTest {
>
>      public static void main(String[] args) {
>          System.out.println(String.format("%d,%b", 42, new Object[] {}));
>          System.out.println(String.format("%b", (Object) new Object[] {}));
>          try {
>              System.out.println(String.format("%b", new Object[] {}));
>              System.out.println("There is something rotten in state of
> Denmark");
>          } catch (MissingFormatArgumentException e) {
>              System.out.println("Works as expected");
>          }
>      }
> }
>
> Result:
> 42,true
> true
> Works as expected
>
> What is the preferred workflow for such a bug-database cleanup? Is it
> through the mailing list?
>
> -- Sebastian
>
> [1] https://bugs.openjdk.java.net/browse/JDK-7198513
>
>



From paul.sandoz at oracle.com  Mon Sep  7 08:45:50 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 7 Sep 2015 10:45:50 +0200
Subject: Collections.emptyList().spliterator() is not ORDERED
In-Reply-To: <726458471.20150906162111@gmail.com>
References: <726458471.20150906162111@gmail.com>
Message-ID: <4B4AA2BA-DA81-486A-ACFA-8CBF2FB57DDE@oracle.com>

Hi Tagir,

Well spotted. We made an exception when the spliterator covers no elements:

  https://bugs.openjdk.java.net/browse/JDK-8022797
  http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/737b6c298d81

I thought i could get away solely with a specification change to allow reuse of an empty spliterator implementation. But, as you show it pops up in certain cases that aggregate two or more streams. In hindsight i somewhat regret this decision as it makes general processing more difficult :-(

In this case we should fix Stream.concat to check if a spliterator reporting SIZED is empty, which will allow us to optimize the concatenation [1].

Paul.

P.S. I still have a bunch of your stuff in my queue to process, sorry it?s taking so long,i will get to them in the next couple of weeks, but i need to process some other stuff first.

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

On 6 Sep 2015, at 12:21, Tagir F. Valeev <amaembo at gmail.com> wrote:

> Hello!
> 
> As Paul Sandoz pointed out in the "Custom spliterator for
> Collections.nCopies(n, obj).stream()" discussion, the
> List.spliterator() is specified to be ORDERED. However
> Collections.emptyList().spliterator() violates this specification:
> 
> System.out.println(Collections.emptyList()
>  .spliterator().hasCharacteristics(Spliterator.ORDERED));
> // prints false
> 
> This becomes critical if I want to concatenate streams from the two
> lists returned from two different methods (one of which returned
> emptyList) and process the result in parallel. For example:
> 
> List<Integer> list1 = IntStream.range(0, 100).boxed().collect(Collectors.toList());
> List<Integer> list2 = Collections.emptyList();
> System.out.println(Stream
>      .concat(list1.stream(), list2.stream()).parallel()
>      .filter(x -> x >= 0).limit(10).collect(Collectors.toList()));
> 
> This code unexpectedly prints some random subset. This can be fixed by
> replacing list2 with
> 
> List<Integer> list2 = Arrays.asList();
> 
> As Arrays.asList().spliterator() is ordered, the resulting stream is
> ordered as well, so we see [0, ..., 9] as expected.
> 
> Looks like a bug in emptyList() implementation.
> 
> With best regards,
> Tagir Valeev.
> 



From amaembo at gmail.com  Mon Sep  7 09:20:32 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Mon, 7 Sep 2015 15:20:32 +0600
Subject: Collections.emptyList().spliterator() is not ORDERED
In-Reply-To: <4B4AA2BA-DA81-486A-ACFA-8CBF2FB57DDE@oracle.com>
References: <726458471.20150906162111@gmail.com>
	<4B4AA2BA-DA81-486A-ACFA-8CBF2FB57DDE@oracle.com>
Message-ID: <792598028.20150907152032@gmail.com>

Hello!

PS> Well spotted. We made an exception when the spliterator covers no elements:

PS>   https://bugs.openjdk.java.net/browse/JDK-8022797
PS>   http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/737b6c298d81

Thanks for the information, I did not know about that.

PS> In this case we should fix Stream.concat to check if a
PS> spliterator reporting SIZED is empty, which will allow us to optimize the concatenation [1].
PS> [1] https://bugs.openjdk.java.net/browse/JDK-8022805

That would be even better from performance point of view. Thanks.

By the way, probably it's reasonable then for Arrays.asList to check
the array length like:

    public static <T> List<T> asList(T... a) {
        if(a.length == 0)
          return Collections.emptyList();
        return new ArrayList<>(a);
    }

This would make Arrays.asList() (without arguments) and
Collections.emptyList() perfectly consistent (now their spliterators
report different characteristics) and reduce the number of heap
objects. Probably there are some caveats I'm not aware of. Sorry if it
was already discussed.

PS> P.S. I still have a bunch of your stuff in my queue to process,
PS> sorry it?s taking so long,i will get to them in the next couple of
PS> weeks, but i need to process some other stuff first.

No problems, I'm not in a hurry.

With best regards,
Tagir Valeev.

PS> On 6 Sep 2015, at 12:21, Tagir F. Valeev <amaembo at gmail.com> wrote:

>> Hello!
>> 
>> As Paul Sandoz pointed out in the "Custom spliterator for
>> Collections.nCopies(n, obj).stream()" discussion, the
>> List.spliterator() is specified to be ORDERED. However
>> Collections.emptyList().spliterator() violates this specification:
>> 
>> System.out.println(Collections.emptyList()
>>  .spliterator().hasCharacteristics(Spliterator.ORDERED));
>> // prints false
>> 
>> This becomes critical if I want to concatenate streams from the two
>> lists returned from two different methods (one of which returned
>> emptyList) and process the result in parallel. For example:
>> 
>> List<Integer> list1 = IntStream.range(0, 100).boxed().collect(Collectors.toList());
>> List<Integer> list2 = Collections.emptyList();
>> System.out.println(Stream
>>      .concat(list1.stream(), list2.stream()).parallel()
>>      .filter(x -> x >= 0).limit(10).collect(Collectors.toList()));
>> 
>> This code unexpectedly prints some random subset. This can be fixed by
>> replacing list2 with
>> 
>> List<Integer> list2 = Arrays.asList();
>> 
>> As Arrays.asList().spliterator() is ordered, the resulting stream is
>> ordered as well, so we see [0, ..., 9] as expected.
>> 
>> Looks like a bug in emptyList() implementation.
>> 
>> With best regards,
>> Tagir Valeev.
>> 



From vyom.tewari at oracle.com  Mon Sep  7 09:26:55 2015
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Mon, 7 Sep 2015 14:56:55 +0530
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
Message-ID: <55ED585F.9060005@oracle.com>

Hi everyone,
Can you please review my changes for below bug.

Bug:
      JDK-8080402 : File Leak in 
jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
Webrev:
http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/

This change ensure that if close() fails we throw correct io exception 
and there is no file leak.

Thanks,
Vyom


From chris.hegarty at oracle.com  Mon Sep  7 09:32:14 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 7 Sep 2015 10:32:14 +0100
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55ED585F.9060005@oracle.com>
References: <55ED585F.9060005@oracle.com>
Message-ID: <55ED599E.9050301@oracle.com>

Hi Vyom,

On 07/09/15 10:26, Vyom Tewari wrote:
> Hi everyone,
> Can you please review my changes for below bug.
>
> Bug:
>       JDK-8080402 : File Leak in
> jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/
>
> This change ensure that if close() fails we throw correct io exception
> and there is no file leak.

However unlikely to happen, I think your changes are correct. Reviewed.

-Chris.


From ivan.gerasimov at oracle.com  Mon Sep  7 09:40:49 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 7 Sep 2015 12:40:49 +0300
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55ED585F.9060005@oracle.com>
References: <55ED585F.9060005@oracle.com>
Message-ID: <55ED5BA1.8010102@oracle.com>

Hi!

The close() function isn't really restartable.

So, I think, it's more correct to replace
     RESTARTABLE(close(s), res);
with
     res = close(s);

Sincerely yours,
Ivan

On 07.09.2015 12:26, Vyom Tewari wrote:
> Hi everyone,
> Can you please review my changes for below bug.
>
> Bug:
>      JDK-8080402 : File Leak in 
> jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/
>
> This change ensure that if close() fails we throw correct io exception 
> and there is no file leak.
>
> Thanks,
> Vyom
>



From Alan.Bateman at oracle.com  Mon Sep  7 10:18:23 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 07 Sep 2015 11:18:23 +0100
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55ED585F.9060005@oracle.com>
References: <55ED585F.9060005@oracle.com>
Message-ID: <55ED646F.7020607@oracle.com>

On 07/09/2015 10:26, Vyom Tewari wrote:
> Hi everyone,
> Can you please review my changes for below bug.
>
> Bug:
>      JDK-8080402 : File Leak in 
> jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/
>
> This change ensure that if close() fails we throw correct io exception 
> and there is no file leak.
close isn't restartable so I think we need to look at that while we are 
here.

-Alan.


From vyom.tewari at oracle.com  Mon Sep  7 13:08:05 2015
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Mon, 7 Sep 2015 18:38:05 +0530
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55ED646F.7020607@oracle.com>
References: <55ED585F.9060005@oracle.com> <55ED646F.7020607@oracle.com>
Message-ID: <55ED8C35.9000208@oracle.com>

Hi All,

Please find the latest diff, which contains the  latest fix.
http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/

Thanks,
Vyom


On 9/7/2015 3:48 PM, Alan Bateman wrote:
> On 07/09/2015 10:26, Vyom Tewari wrote:
>> Hi everyone,
>> Can you please review my changes for below bug.
>>
>> Bug:
>>      JDK-8080402 : File Leak in 
>> jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
>> Webrev:
>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/
>>
>> This change ensure that if close() fails we throw correct io 
>> exception and there is no file leak.
> close isn't restartable so I think we need to look at that while we 
> are here.
>
> -Alan.



From paul.sandoz at oracle.com  Mon Sep  7 13:23:33 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 7 Sep 2015 15:23:33 +0200
Subject: Collections.emptyList().spliterator() is not ORDERED
In-Reply-To: <792598028.20150907152032@gmail.com>
References: <726458471.20150906162111@gmail.com>
	<4B4AA2BA-DA81-486A-ACFA-8CBF2FB57DDE@oracle.com>
	<792598028.20150907152032@gmail.com>
Message-ID: <3D197E7F-CF35-44C1-B0B7-DC9C9DAE513E@oracle.com>

On 7 Sep 2015, at 11:20, Tagir F. Valeev <amaembo at gmail.com> wrote:
> PS> In this case we should fix Stream.concat to check if a
> PS> spliterator reporting SIZED is empty, which will allow us to optimize the concatenation [1].
> PS> [1] https://bugs.openjdk.java.net/browse/JDK-8022805
> 
> That would be even better from performance point of view. Thanks.
> 

Yes, there is a happy side to this :-)


> By the way, probably it's reasonable then for Arrays.asList to check
> the array length like:
> 
>    public static <T> List<T> asList(T... a) {
>        if(a.length == 0)
>          return Collections.emptyList();
>        return new ArrayList<>(a);
>    }
> 
> This would make Arrays.asList() (without arguments) and
> Collections.emptyList() perfectly consistent (now their spliterators
> report different characteristics) and reduce the number of heap
> objects. Probably there are some caveats I'm not aware of. Sorry if it
> was already discussed.
> 

This has not been discussed, it?s an edge case micro-optimisation but seems reasonable.


> PS> P.S. I still have a bunch of your stuff in my queue to process,
> PS> sorry it?s taking so long,i will get to them in the next couple of
> PS> weeks, but i need to process some other stuff first.
> 
> No problems, I'm not in a hurry.
> 

Ok, thanks,
Paul.


From ivan.gerasimov at oracle.com  Mon Sep  7 13:29:37 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 7 Sep 2015 16:29:37 +0300
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55ED8C35.9000208@oracle.com>
References: <55ED585F.9060005@oracle.com> <55ED646F.7020607@oracle.com>
	<55ED8C35.9000208@oracle.com>
Message-ID: <55ED9141.9090703@oracle.com>

Thanks!

It looks good to me now.

Sincerely yours,
Ivan

On 07.09.2015 16:08, Vyom Tewari wrote:
> Hi All,
>
> Please find the latest diff, which contains the  latest fix.
> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/
>
> Thanks,
> Vyom
>
>
> On 9/7/2015 3:48 PM, Alan Bateman wrote:
>> On 07/09/2015 10:26, Vyom Tewari wrote:
>>> Hi everyone,
>>> Can you please review my changes for below bug.
>>>
>>> Bug:
>>>      JDK-8080402 : File Leak in 
>>> jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
>>> Webrev:
>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/
>>>
>>> This change ensure that if close() fails we throw correct io 
>>> exception and there is no file leak.
>> close isn't restartable so I think we need to look at that while we 
>> are here.
>>
>> -Alan.
>
>



From chris.hegarty at oracle.com  Mon Sep  7 14:39:37 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 7 Sep 2015 15:39:37 +0100
Subject: RFR 8072466: Deadlock when starting MulticastSocket and
	DatagramSocket
In-Reply-To: <55EAFB4E.5050506@oracle.com>
References: <54D4FE63.5090108@oracle.com> <54E2E5BF.3080304@oracle.com>
	<55EAFB4E.5050506@oracle.com>
Message-ID: <55EDA1A9.5070506@oracle.com>

This looks like a nice cleanup, and fix. Thanks Ivan.

-Chris.

On 05/09/15 15:25, Ivan Gerasimov wrote:
> Hi everyone!
>
> The fix didn't bring enough attention back in February for some reason.
> So, I'd like to re-request a review.
>
> I've added a regression test, which reliably reproduces a deadlock on my
> local Windows 7 machine.
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072466
> WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/00/webrev/
>
> Sincerely yours,
> Ivan
>
> On 17.02.2015 9:54, Ivan Gerasimov wrote:
>> Can someone help review this fix please?
>>
>> Comments/suggestions are welcome!
>>
>> Sincerely yours,
>> Ivan
>>
>> On 06.02.2015 20:48, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> There has been a deadlock in jdk-net code noticed on Windows.
>>>
>>> In the bug description there's a stack snippet showing that one of
>>> the deadlocked threads stuck in the native initialization code of
>>> DualStackPlainDatagramSocketImpl and the other -- in initializing of
>>> TwoStacksPlainDatagramSocketImpl.
>>>
>>> I suspect that the reason might be due to unordered initialization:
>>> AbstractPlainDatagramSocketImpl, the parent of both classes above,
>>> explicitly loads TwoStacksPlainDatagramSocketImpl from the native
>>> init().
>>> Thus, when both classes are being initialized concurrently, it may
>>> end with a clash.
>>>
>>>
>>> Another issue noticed by Mark Sheppard is that the Windows version of
>>> DefaultDatagramSocketImplFactory.createDatagramSocketImpl() isn't
>>> synchronized, but reads/modifies shared data.
>>> Thus, I removed modification and declared all the accessed fields final.
>>>
>>> Would you please help review the proposed fix?
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072466
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/0/webrev/
>>>
>>> The build went fine on all the platforms, all the tests from
>>> (net|nio|io) passed Okay.
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>>
>>>
>>
>>
>>
>


From ivan.gerasimov at oracle.com  Mon Sep  7 15:06:53 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 7 Sep 2015 18:06:53 +0300
Subject: RFR 8072466: Deadlock when starting MulticastSocket and
	DatagramSocket
In-Reply-To: <55EDA1A9.5070506@oracle.com>
References: <54D4FE63.5090108@oracle.com> <54E2E5BF.3080304@oracle.com>
	<55EAFB4E.5050506@oracle.com> <55EDA1A9.5070506@oracle.com>
Message-ID: <55EDA80D.1040600@oracle.com>

Thank you Chris for the review!

Sincerely yours,
Ivan

On 07.09.2015 17:39, Chris Hegarty wrote:
> This looks like a nice cleanup, and fix. Thanks Ivan.
>
> -Chris.
>
> On 05/09/15 15:25, Ivan Gerasimov wrote:
>> Hi everyone!
>>
>> The fix didn't bring enough attention back in February for some reason.
>> So, I'd like to re-request a review.
>>
>> I've added a regression test, which reliably reproduces a deadlock on my
>> local Windows 7 machine.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072466
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/00/webrev/
>>
>> Sincerely yours,
>> Ivan
>>
>> On 17.02.2015 9:54, Ivan Gerasimov wrote:
>>> Can someone help review this fix please?
>>>
>>> Comments/suggestions are welcome!
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>> On 06.02.2015 20:48, Ivan Gerasimov wrote:
>>>> Hello!
>>>>
>>>> There has been a deadlock in jdk-net code noticed on Windows.
>>>>
>>>> In the bug description there's a stack snippet showing that one of
>>>> the deadlocked threads stuck in the native initialization code of
>>>> DualStackPlainDatagramSocketImpl and the other -- in initializing of
>>>> TwoStacksPlainDatagramSocketImpl.
>>>>
>>>> I suspect that the reason might be due to unordered initialization:
>>>> AbstractPlainDatagramSocketImpl, the parent of both classes above,
>>>> explicitly loads TwoStacksPlainDatagramSocketImpl from the native
>>>> init().
>>>> Thus, when both classes are being initialized concurrently, it may
>>>> end with a clash.
>>>>
>>>>
>>>> Another issue noticed by Mark Sheppard is that the Windows version of
>>>> DefaultDatagramSocketImplFactory.createDatagramSocketImpl() isn't
>>>> synchronized, but reads/modifies shared data.
>>>> Thus, I removed modification and declared all the accessed fields 
>>>> final.
>>>>
>>>> Would you please help review the proposed fix?
>>>>
>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8072466
>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8072466/0/webrev/
>>>>
>>>> The build went fine on all the platforms, all the tests from
>>>> (net|nio|io) passed Okay.
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>



From hearn at vinumeris.com  Mon Sep  7 16:41:18 2015
From: hearn at vinumeris.com (Mike Hearn)
Date: Mon, 7 Sep 2015 18:41:18 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)
Message-ID: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>

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

This bug (really: lack of feature) filed in 2002 can be worked around by
using internal APIs. However, post jigsaw, that won't be so easy any more.
I have a bit of code that uses the workaround, so, I'd rather it didn't
break.

I don't have an OpenJDK bug tracker account so I'll comment here
instead. Mark Reinhold said:

"We'd be thrilled if someone could come up with a workable solution, so
we'll leave this bug open in the hope that it will attract attention from
someone more clever than we are."

The underlying issue is that if you can unmap a file mapping, a racing
thread could remap something else into the same place, confusing secure
code that still has access to the MappedByteBuffer object. A simple if()
check could avoid this, but at the cost of slowing down access.

I have two suggested fixes:

1. Have an unmap method that throws if a SecurityManager is present.
Non-secure code that owns its own JVM (i.e. nearly all of it) would then be
able to unmap files and delete them on Windows. Sandboxed code would still
suffer, but OK, so be it.

2. Have an internal subclass or wrapper object around MappedByteBuffer that
is only used when a SecurityManager is present, which does the check
against the volatile field. The JVM should optimise out the virtual method
call or inline the wrapper code, thus ensuring only sandboxed code pays the
cost.

In both cases, an unmap method could be added in such a way that the race
condition Mark describes should not be an issue.

Thoughts?


From mark.sheppard at oracle.com  Mon Sep  7 16:41:57 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Mon, 7 Sep 2015 17:41:57 +0100
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55ED9141.9090703@oracle.com>
References: <55ED585F.9060005@oracle.com> <55ED646F.7020607@oracle.com>
	<55ED8C35.9000208@oracle.com> <55ED9141.9090703@oracle.com>
Message-ID: <55EDBE55.5020606@oracle.com>


a couple of other considerations in the context of this issue perhaps?

in this s is being duped onto fd, and part of the dup2 operation is the 
closing of fd, but
what's is the expected state of file descriptor fd in the event of a 
dup2 failure?

s is closed in any case, but what about fd, should it be attended to if 
dup2 < 0
and closed ? is it still considered a valid fd?

what can be said about the state of the encapsulating FileDescriptor 
associated with fd?
at this stage can it still be considered valid?
should valid() return false?

regards
Mark

On 07/09/2015 14:29, Ivan Gerasimov wrote:
> Thanks!
>
> It looks good to me now.
>
> Sincerely yours,
> Ivan
>
> On 07.09.2015 16:08, Vyom Tewari wrote:
>> Hi All,
>>
>> Please find the latest diff, which contains the  latest fix.
>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/
>>
>> Thanks,
>> Vyom
>>
>>
>> On 9/7/2015 3:48 PM, Alan Bateman wrote:
>>> On 07/09/2015 10:26, Vyom Tewari wrote:
>>>> Hi everyone,
>>>> Can you please review my changes for below bug.
>>>>
>>>> Bug:
>>>>      JDK-8080402 : File Leak in 
>>>> jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/
>>>>
>>>> This change ensure that if close() fails we throw correct io 
>>>> exception and there is no file leak.
>>> close isn't restartable so I think we need to look at that while we 
>>> are here.
>>>
>>> -Alan.
>>
>>
>



From Alan.Bateman at oracle.com  Mon Sep  7 16:52:19 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 07 Sep 2015 17:52:19 +0100
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55ED8C35.9000208@oracle.com>
References: <55ED585F.9060005@oracle.com> <55ED646F.7020607@oracle.com>
	<55ED8C35.9000208@oracle.com>
Message-ID: <55EDC0C3.5010306@oracle.com>



On 07/09/2015 14:08, Vyom Tewari wrote:
> Hi All,
>
> Please find the latest diff, which contains the  latest fix.
> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/
I think this looks okay now.

-Alan


From daniel.fuchs at oracle.com  Mon Sep  7 17:24:46 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 7 Sep 2015 19:24:46 +0200
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55EDC0C3.5010306@oracle.com>
References: <55ED585F.9060005@oracle.com> <55ED646F.7020607@oracle.com>
	<55ED8C35.9000208@oracle.com> <55EDC0C3.5010306@oracle.com>
Message-ID: <55EDC85E.7080602@oracle.com>

Hi Vyom,

I will sponsor that and push it for you.

best regards,

-- daniel


On 07/09/15 18:52, Alan Bateman wrote:
>
>
> On 07/09/2015 14:08, Vyom Tewari wrote:
>> Hi All,
>>
>> Please find the latest diff, which contains the  latest fix.
>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/
> I think this looks okay now.
>
> -Alan



From daniel.fuchs at oracle.com  Mon Sep  7 17:26:26 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 7 Sep 2015 19:26:26 +0200
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55EDC85E.7080602@oracle.com>
References: <55ED585F.9060005@oracle.com> <55ED646F.7020607@oracle.com>
	<55ED8C35.9000208@oracle.com> <55EDC0C3.5010306@oracle.com>
	<55EDC85E.7080602@oracle.com>
Message-ID: <55EDC8C2.8050908@oracle.com>

Oh - sorry - I hadn't seen Mark question.
I will wait until those are resolved...


On 07/09/15 19:24, Daniel Fuchs wrote:
> Hi Vyom,
>
> I will sponsor that and push it for you.
>
> best regards,
>
> -- daniel
>
>
> On 07/09/15 18:52, Alan Bateman wrote:
>>
>>
>> On 07/09/2015 14:08, Vyom Tewari wrote:
>>> Hi All,
>>>
>>> Please find the latest diff, which contains the  latest fix.
>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/
>> I think this looks okay now.
>>
>> -Alan
>



From chris.hegarty at oracle.com  Tue Sep  8 08:28:04 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 8 Sep 2015 09:28:04 +0100
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55EDBE55.5020606@oracle.com>
References: <55ED585F.9060005@oracle.com> <55ED646F.7020607@oracle.com>
	<55ED8C35.9000208@oracle.com> <55ED9141.9090703@oracle.com>
	<55EDBE55.5020606@oracle.com>
Message-ID: <DEBDFEEA-FA3C-4C10-8868-D9244D4D4803@oracle.com>


On 7 Sep 2015, at 17:41, Mark Sheppard <mark.sheppard at oracle.com> wrote:

> a couple of other considerations in the context of this issue perhaps?
> 
> in this s is being duped onto fd, and part of the dup2 operation is the closing of fd, but
> what's is the expected state of file descriptor fd in the event of a dup2 failure?

I?m not sure that the documentation for dup2 gives us enough detail here. The only situation I can see where fd would not be closed is when EBADF is returned. Should not be an issue here.

> s is closed in any case, but what about fd, should it be attended to if dup2 < 0
> and closed ? is it still considered a valid fd?
> 
> what can be said about the state of the encapsulating FileDescriptor associated with fd?
> at this stage can it still be considered valid?
> should valid() return false?

Probably, but may not be worth bothering with unless there are operations that can access it after this method throws.

-Chris.

> regards
> Mark
> 
> On 07/09/2015 14:29, Ivan Gerasimov wrote:
>> Thanks!
>> 
>> It looks good to me now.
>> 
>> Sincerely yours,
>> Ivan
>> 
>> On 07.09.2015 16:08, Vyom Tewari wrote:
>>> Hi All,
>>> 
>>> Please find the latest diff, which contains the  latest fix.
>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/
>>> 
>>> Thanks,
>>> Vyom
>>> 
>>> 
>>> On 9/7/2015 3:48 PM, Alan Bateman wrote:
>>>> On 07/09/2015 10:26, Vyom Tewari wrote:
>>>>> Hi everyone,
>>>>> Can you please review my changes for below bug.
>>>>> 
>>>>> Bug:
>>>>>     JDK-8080402 : File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/
>>>>> 
>>>>> This change ensure that if close() fails we throw correct io exception and there is no file leak.
>>>> close isn't restartable so I think we need to look at that while we are here.
>>>> 
>>>> -Alan.
>>> 
>>> 
>> 
> 



From paul.sandoz at oracle.com  Tue Sep  8 08:58:27 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 8 Sep 2015 10:58:27 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
Message-ID: <8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>

HI Mike,

This is fundamentally about *integrity* of the runtime. It follows there are security implications, but it?s still fundamentally an integrity issue and guarding an unsafe operation with a Security Manager is unfortunately an insufficient solution.

Paul.

On 7 Sep 2015, at 18:41, Mike Hearn <hearn at vinumeris.com> wrote:

> https://bugs.openjdk.java.net/browse/JDK-4724038
> 
> This bug (really: lack of feature) filed in 2002 can be worked around by
> using internal APIs. However, post jigsaw, that won't be so easy any more.
> I have a bit of code that uses the workaround, so, I'd rather it didn't
> break.
> 
> I don't have an OpenJDK bug tracker account so I'll comment here
> instead. Mark Reinhold said:
> 
> "We'd be thrilled if someone could come up with a workable solution, so
> we'll leave this bug open in the hope that it will attract attention from
> someone more clever than we are."
> 
> The underlying issue is that if you can unmap a file mapping, a racing
> thread could remap something else into the same place, confusing secure
> code that still has access to the MappedByteBuffer object. A simple if()
> check could avoid this, but at the cost of slowing down access.
> 
> I have two suggested fixes:
> 
> 1. Have an unmap method that throws if a SecurityManager is present.
> Non-secure code that owns its own JVM (i.e. nearly all of it) would then be
> able to unmap files and delete them on Windows. Sandboxed code would still
> suffer, but OK, so be it.
> 
> 2. Have an internal subclass or wrapper object around MappedByteBuffer that
> is only used when a SecurityManager is present, which does the check
> against the volatile field. The JVM should optimise out the virtual method
> call or inline the wrapper code, thus ensuring only sandboxed code pays the
> cost.
> 
> In both cases, an unmap method could be added in such a way that the race
> condition Mark describes should not be an issue.
> 
> Thoughts?



From aph at redhat.com  Tue Sep  8 09:30:32 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 8 Sep 2015 10:30:32 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
Message-ID: <55EEAAB8.1000004@redhat.com>

On 09/08/2015 09:58 AM, Paul Sandoz wrote:

> This is fundamentally about *integrity* of the runtime. It follows
> there are security implications, but it?s still fundamentally an
> integrity issue and guarding an unsafe operation with a Security
> Manager is unfortunately an insufficient solution.

That's an interesting distinction.  I'm not sure we're all that
consistent about it elsewhere.

But never mind that; how about this idea?  Create a
MappedByteBufferForwardingObject whose only job is to forward requests
to a MappedByteBuffer.  That MappedByteBuffer does not escape from the
forwarding object.  When the forwarding object is closed (or unmapped)
its MappedByteBuffer field is nulled.  The file can then be unmapped
because we know it is not reachable.  There would be some overhead for
the indirection, and that MappedByteBuffer field would have to be
volatile, so this would not be entirely free of cost.  It's very easy
to prototype this idea to see if it would be reasonably cheap.

However, I think that some cleverness in HotSpot could make that cost
go away.  For example, we could associate with every
MappedByteBufferForwardingObject a protection page in memory.  When
the forwarding object is unmapped that page is write-protected.  Every
access to the mapped file is preceded by a write to the page; there
don't have to be any memory fence instructions.  The protection page
would stay until the forwarding object was unmapped.

Andrew.


From paul.sandoz at oracle.com  Tue Sep  8 10:42:14 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 8 Sep 2015 12:42:14 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EEAAB8.1000004@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com>
Message-ID: <73CB5B94-B817-4333-87E8-89E9A2110199@oracle.com>


On 8 Sep 2015, at 11:30, Andrew Haley <aph at redhat.com> wrote:

> On 09/08/2015 09:58 AM, Paul Sandoz wrote:
> 
>> This is fundamentally about *integrity* of the runtime. It follows
>> there are security implications, but it?s still fundamentally an
>> integrity issue and guarding an unsafe operation with a Security
>> Manager is unfortunately an insufficient solution.
> 
> That's an interesting distinction.  I'm not sure we're all that
> consistent about it elsewhere.
> 

True, in the sense that using Java reflection one could change the contents of an ArrayList but one still requires a reference, and that of course is even more unsafe to do on a String, which might be interned and where special optimisations are applied. Personally, i wish we could strengthen the integrity of the platform in such cases (without which it makes it much harder to apply certain optimisations).

I would argue the case of an unsafe unmap is more severe since there is no intent to break the integrity.


> But never mind that; how about this idea?  Create a
> MappedByteBufferForwardingObject whose only job is to forward requests
> to a MappedByteBuffer.  That MappedByteBuffer does not escape from the
> forwarding object.  When the forwarding object is closed (or unmapped)
> its MappedByteBuffer field is nulled.  The file can then be unmapped
> because we know it is not reachable.  There would be some overhead for
> the indirection, and that MappedByteBuffer field would have to be
> volatile, so this would not be entirely free of cost.  It's very easy
> to prototype this idea to see if it would be reasonably cheap.
> 

It?s not entirely clear to me if bulk operations would be safe under such circumstances. What if an unmap/remap concurrently occurs during an Unsafe.copyMemory when performing a Buffer.get/put with an array?


> However, I think that some cleverness in HotSpot could make that cost
> go away.  For example, we could associate with every
> MappedByteBufferForwardingObject a protection page in memory.  When
> the forwarding object is unmapped that page is write-protected.  Every
> access to the mapped file is preceded by a write to the page; there
> don't have to be any memory fence instructions.  The protection page
> would stay until the forwarding object was unmapped.
> 

So basically the overhead would be a ?plain" write and the indirection. Does that solve all cases Mark describes in the issue, specifically race conditions within the VM?s process?

Paul.


From david.lloyd at redhat.com  Tue Sep  8 11:37:03 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 08 Sep 2015 06:37:03 -0500
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EEAAB8.1000004@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com>
Message-ID: <55EEC85F.7010800@redhat.com>

On 09/08/2015 04:30 AM, Andrew Haley wrote:
> On 09/08/2015 09:58 AM, Paul Sandoz wrote:
>
>> This is fundamentally about *integrity* of the runtime. It follows
>> there are security implications, but it?s still fundamentally an
>> integrity issue and guarding an unsafe operation with a Security
>> Manager is unfortunately an insufficient solution.
>
> That's an interesting distinction.  I'm not sure we're all that
> consistent about it elsewhere.
>
> But never mind that; how about this idea?  Create a
> MappedByteBufferForwardingObject whose only job is to forward requests
> to a MappedByteBuffer.  That MappedByteBuffer does not escape from the
> forwarding object.  When the forwarding object is closed (or unmapped)
> its MappedByteBuffer field is nulled.  The file can then be unmapped
> because we know it is not reachable.  There would be some overhead for
> the indirection, and that MappedByteBuffer field would have to be
> volatile, so this would not be entirely free of cost.  It's very easy
> to prototype this idea to see if it would be reasonably cheap.

I think the real MappedByteBuffer would have to be cleaned up via 
PhantomReference in this case, and extra care would have to be taken to 
ensure that a premature GC does not occur (I guess that's the thrust of 
Paul Sandoz's reply).

> However, I think that some cleverness in HotSpot could make that cost
> go away.  For example, we could associate with every
> MappedByteBufferForwardingObject a protection page in memory.  When
> the forwarding object is unmapped that page is write-protected.  Every
> access to the mapped file is preceded by a write to the page; there
> don't have to be any memory fence instructions.  The protection page
> would stay until the forwarding object was unmapped.

If you're already doing this, why not skip the level of indirection and 
mprotect the entire mapped region to PROT_NONE when the user unmaps? 
The JVM could trap on that memory area and convert the signal to an 
UnmappedBufferException or some such.  Then you do the real unmap when 
the buffer is GC'd (maybe via Cleaner).  This is very akin to how file 
descriptors are cleaned up, AFAICT.

-- 
- DML


From Alan.Bateman at oracle.com  Tue Sep  8 12:07:29 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 08 Sep 2015 13:07:29 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
Message-ID: <55EECF81.3050508@oracle.com>



On 08/09/2015 09:58, Paul Sandoz wrote:
> HI Mike,
>
> This is fundamentally about *integrity* of the runtime. It follows there are security implications, but it?s still fundamentally an integrity issue and guarding an unsafe operation with a Security Manager is unfortunately an insufficient solution.
>
> Paul.
>
Right, and just to add that there has been many attempts over the years 
to find solutions to this issue. I think the closest was atomimcally 
remapping but that wasn't feasible on all platforms and also didn't free 
up the address space in a timely manner.

On the security manager suggestion then one of the concerns from a few 
years ago is that trusted code might unmap while untrusted code has a 
reference to the buffer.

There have been attempts using redirection too but there was always 
performance concerns. It also gets complicated with view buffers.

-Alan




From hearn at vinumeris.com  Tue Sep  8 13:03:05 2015
From: hearn at vinumeris.com (Mike Hearn)
Date: Tue, 8 Sep 2015 15:03:05 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EEC85F.7010800@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com> <55EEC85F.7010800@redhat.com>
Message-ID: <CA+w+GKQJR-n6JmwDXj_Y3DWakOb3CbpT2VV3=OqjC9pxPkN96A@mail.gmail.com>

>
> If you're already doing this, why not skip the level of indirection and
> mprotect the entire mapped region to PROT_NONE when the user unmaps?
> ....... Then you do the real unmap when the buffer is GC'd (maybe via
> Cleaner).


Because the reason users are working around this is Windows, where they
need the ability to do:

buffer.unmap();
file.delete();

If the unmap is still asynchronous it doesn't solve the problem.

Wait, or does it?

The primary place this matters is Windows. I must say that a
*significant* amount
of the time that I find or write Java that doesn't run across platforms
properly, it's due to differences between the platforms file locking
behaviours and in particular because Java does not open files with a
reasonable share mode on Windows.

The bug to change this is here:

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

The comment (from 2007) says that there's a new file IO API (presumably
this meant NIO) that uses the right share mode, but that it still doesn't
help for deleting a mapped file because Windows doesn't allow that.

But MSDN is a little contradictory:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa366532(v=vs.85).aspx

These *calls to CloseHandle succeed even when there are file views that are
> still open*. However, leaving file views mapped causes memory leaks.


https://msdn.microsoft.com/en-us/library/windows/desktop/aa363915(v=vs.85).aspx

The *DeleteFile* function fails if an application attempts to delete a file
> that has other handles open for normal I/O or as a memory-mapped file (
> *FILE_SHARE_DELETE* must have been specified when other handles were
> opened).


So it suggests that you CAN delete an mmapped buffer as long as the handles
were all opened correctly. If true then this would allow the following
implementation:

- Java always opens files with FILE_SHARE_DELETE. As any app that is not
expecting this behaviour is not portable anyway (would fail on UNIX), the
compatibility issues would hopefully not be too extreme.

- An attempt to close, delete or rename a file firstly remaps any mappings
of it to trigger access violations, then closes all underlying Win32
HANDLEs owned by the JVM, then returns. The actual unmap can be done
asynchronously as today once the GC comes along but it wouldn't matter
anymore because it's no longer stopping other file operations from working.


From aph at redhat.com  Tue Sep  8 13:05:17 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 8 Sep 2015 14:05:17 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <73CB5B94-B817-4333-87E8-89E9A2110199@oracle.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com>
	<73CB5B94-B817-4333-87E8-89E9A2110199@oracle.com>
Message-ID: <55EEDD0D.6070302@redhat.com>

On 09/08/2015 11:42 AM, Paul Sandoz wrote:
> 
> On 8 Sep 2015, at 11:30, Andrew Haley <aph at redhat.com> wrote:

>> But never mind that; how about this idea?  Create a
>> MappedByteBufferForwardingObject whose only job is to forward requests
>> to a MappedByteBuffer.  That MappedByteBuffer does not escape from the
>> forwarding object.  When the forwarding object is closed (or unmapped)
>> its MappedByteBuffer field is nulled.  The file can then be unmapped
>> because we know it is not reachable.  There would be some overhead for
>> the indirection, and that MappedByteBuffer field would have to be
>> volatile, so this would not be entirely free of cost.  It's very easy
>> to prototype this idea to see if it would be reasonably cheap.
>>
> 
> It?s not entirely clear to me if bulk operations would be safe under
> such circumstances. What if an unmap/remap concurrently occurs
> during an Unsafe.copyMemory when performing a Buffer.get/put with an
> array?

I don't think you'd actually need to unmap anything until a safepoint.
I don't think that the speed of unmapping is critical as long as it
happens "soon".

>> However, I think that some cleverness in HotSpot could make that cost
>> go away.  For example, we could associate with every
>> MappedByteBufferForwardingObject a protection page in memory.  When
>> the forwarding object is unmapped that page is write-protected.  Every
>> access to the mapped file is preceded by a write to the page; there
>> don't have to be any memory fence instructions.  The protection page
>> would stay until the forwarding object was unmapped.
> 
> So basically the overhead would be a ?plain" write and the
> indirection. Does that solve all cases Mark describes in the issue,
> specifically race conditions within the VM?s process?

As far as I can see, yes.

Andrew.


From mark.sheppard at oracle.com  Tue Sep  8 13:05:26 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Tue, 8 Sep 2015 14:05:26 +0100
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <DEBDFEEA-FA3C-4C10-8868-D9244D4D4803@oracle.com>
References: <55ED585F.9060005@oracle.com> <55ED646F.7020607@oracle.com>
	<55ED8C35.9000208@oracle.com> <55ED9141.9090703@oracle.com>
	<55EDBE55.5020606@oracle.com>
	<DEBDFEEA-FA3C-4C10-8868-D9244D4D4803@oracle.com>
Message-ID: <55EEDD16.7010805@oracle.com>

that's true, the documentation is a bit nebulous on this issue.
but the inference is that the file descriptors are indeterminate state.
some older man pages allude to this

as per solaris man pages, close will
" If close() is interrupted by a signal that is to be caught,
it  will return  -1  with errno set to EINTR and the state of fildes is 
unspecified"

if dup2(s, fd) is viewed as a combination of close(fd) and fcntl (s, 
F_DUP2FD, fd), and close is not restartable
then similar semantics could be inferred for dup2 in a EINTR scenario?
presume that subsequent call in the RESTARTABLE loop  will return 
another error.




On 08/09/2015 09:28, Chris Hegarty wrote:
> On 7 Sep 2015, at 17:41, Mark Sheppard <mark.sheppard at oracle.com> wrote:
>
>> a couple of other considerations in the context of this issue perhaps?
>>
>> in this s is being duped onto fd, and part of the dup2 operation is the closing of fd, but
>> what's is the expected state of file descriptor fd in the event of a dup2 failure?
> I?m not sure that the documentation for dup2 gives us enough detail here. The only situation I can see where fd would not be closed is when EBADF is returned. Should not be an issue here.
>
>> s is closed in any case, but what about fd, should it be attended to if dup2 < 0
>> and closed ? is it still considered a valid fd?
>>
>> what can be said about the state of the encapsulating FileDescriptor associated with fd?
>> at this stage can it still be considered valid?
>> should valid() return false?
> Probably, but may not be worth bothering with unless there are operations that can access it after this method throws.
>
> -Chris.
>
>> regards
>> Mark
>>
>> On 07/09/2015 14:29, Ivan Gerasimov wrote:
>>> Thanks!
>>>
>>> It looks good to me now.
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>> On 07.09.2015 16:08, Vyom Tewari wrote:
>>>> Hi All,
>>>>
>>>> Please find the latest diff, which contains the  latest fix.
>>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/
>>>>
>>>> Thanks,
>>>> Vyom
>>>>
>>>>
>>>> On 9/7/2015 3:48 PM, Alan Bateman wrote:
>>>>> On 07/09/2015 10:26, Vyom Tewari wrote:
>>>>>> Hi everyone,
>>>>>> Can you please review my changes for below bug.
>>>>>>
>>>>>> Bug:
>>>>>>      JDK-8080402 : File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/
>>>>>>
>>>>>> This change ensure that if close() fails we throw correct io exception and there is no file leak.
>>>>> close isn't restartable so I think we need to look at that while we are here.
>>>>>
>>>>> -Alan.
>>>>



From aph at redhat.com  Tue Sep  8 13:10:20 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 8 Sep 2015 14:10:20 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EEC85F.7010800@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com> <55EEC85F.7010800@redhat.com>
Message-ID: <55EEDE3C.7000509@redhat.com>

On 09/08/2015 12:37 PM, David M. Lloyd wrote:
> On 09/08/2015 04:30 AM, Andrew Haley wrote:
>> On 09/08/2015 09:58 AM, Paul Sandoz wrote:
> 
>> However, I think that some cleverness in HotSpot could make that cost
>> go away.  For example, we could associate with every
>> MappedByteBufferForwardingObject a protection page in memory.  When
>> the forwarding object is unmapped that page is write-protected.  Every
>> access to the mapped file is preceded by a write to the page; there
>> don't have to be any memory fence instructions.  The protection page
>> would stay until the forwarding object was unmapped.

Sorry, I meant "until the forwarding object was collected".

> If you're already doing this, why not skip the level of indirection and 
> mprotect the entire mapped region to PROT_NONE when the user unmaps?

Because one page has to hang around until the forwarding object is
garbage collected.  The entire mapping doesn't.

Andrew.



From aph at redhat.com  Tue Sep  8 13:11:51 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 8 Sep 2015 14:11:51 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EEC85F.7010800@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com> <55EEC85F.7010800@redhat.com>
Message-ID: <55EEDE97.9060904@redhat.com>

On 09/08/2015 12:37 PM, David M. Lloyd wrote:
> Then you do the real unmap when 
> the buffer is GC'd (maybe via Cleaner).  This is very akin to how file 
> descriptors are cleaned up, AFAICT.

Indeed it is, and it's no better than the status quo.  This is an attempt
to do better.

Andrew.



From dawid.weiss at gmail.com  Tue Sep  8 13:13:09 2015
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Tue, 8 Sep 2015 15:13:09 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CA+w+GKQJR-n6JmwDXj_Y3DWakOb3CbpT2VV3=OqjC9pxPkN96A@mail.gmail.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com> <55EEC85F.7010800@redhat.com>
	<CA+w+GKQJR-n6JmwDXj_Y3DWakOb3CbpT2VV3=OqjC9pxPkN96A@mail.gmail.com>
Message-ID: <CAM21Rt9+LSwkfzBbwRpKfiQRrnbYdKMVCFYze88T_Jzvo==6wg@mail.gmail.com>

> Because the reason users are working around this is Windows, where they
> need the ability to do:
>
> buffer.unmap();
> file.delete();

This is exactly the case in Lucene, for example. Which currently
resorts to ugly hacks (the entire documentation of this class is
interesting -- concerns memory fragmentation on 32-bit VMs, file
locking and other quirks).

https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java#L162-L177

Dawid


From aph at redhat.com  Tue Sep  8 13:29:25 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 8 Sep 2015 14:29:25 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EEDD0D.6070302@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com>
	<73CB5B94-B817-4333-87E8-89E9A2110199@oracle.com>
	<55EEDD0D.6070302@redhat.com>
Message-ID: <55EEE2B5.5070800@redhat.com>

On 09/08/2015 02:05 PM, Andrew Haley wrote:
> I don't think you'd actually need to unmap anything until a safepoint.
> I don't think that the speed of unmapping is critical as long as it
> happens "soon".

Although given the desire to do

  buffer.unmap();
  file.delete();

that belief may be misplaced.  We could just block for a safepoint;
we already do that in other cases, and there's no guarantee about how
long unmap() would take to execute.

Andrew.



From david.lloyd at redhat.com  Tue Sep  8 16:58:15 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 08 Sep 2015 11:58:15 -0500
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CA+w+GKQJR-n6JmwDXj_Y3DWakOb3CbpT2VV3=OqjC9pxPkN96A@mail.gmail.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>	<55EEAAB8.1000004@redhat.com>	<55EEC85F.7010800@redhat.com>
	<CA+w+GKQJR-n6JmwDXj_Y3DWakOb3CbpT2VV3=OqjC9pxPkN96A@mail.gmail.com>
Message-ID: <55EF13A7.2030103@redhat.com>

On 09/08/2015 08:03 AM, Mike Hearn wrote:
>     If you're already doing this, why not skip the level of indirection
>     and mprotect the entire mapped region to PROT_NONE when the user
>     unmaps? ....... Then you do the real unmap when the buffer is GC'd
>     (maybe via Cleaner).
>
>
> Because the reason users are working around this is Windows, where they
> need the ability to do:
>
> buffer.unmap();
> file.delete();
>
> If the unmap is still asynchronous it doesn't solve the problem.

So Windows has no operation which can remap a previously mapped section 
of memory to something else? (say, just a block of non-access memory)

Note that such an operation has to be atomic with respect to all other 
operations which affect the address space of the process (or at least, 
which may randomly choose an address in memory at which to create new 
mappings), but not with respect to anything else really.  The point of 
the remapping is to continue to reserve the address space, without 
actually referencing what was there before (thus dodging file lock 
issues).  No physical or virtual memory need actually be reserved for 
such a mapping.

-- 
- DML


From david.lloyd at redhat.com  Tue Sep  8 17:03:11 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 08 Sep 2015 12:03:11 -0500
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EEDE97.9060904@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>	<55EEAAB8.1000004@redhat.com>
	<55EEC85F.7010800@redhat.com> <55EEDE97.9060904@redhat.com>
Message-ID: <55EF14CF.9030201@redhat.com>

On 09/08/2015 08:11 AM, Andrew Haley wrote:
> On 09/08/2015 12:37 PM, David M. Lloyd wrote:
>> Then you do the real unmap when
>> the buffer is GC'd (maybe via Cleaner).  This is very akin to how file
>> descriptors are cleaned up, AFAICT.
>
> Indeed it is, and it's no better than the status quo.  This is an attempt
> to do better.

Actually it *is* better, as it releases the mapping to the underlying 
file, and does not require any resources (outside of the page table 
itself and any associated kernel bookkeeping) to maintain a valid state 
during the time window between user-driven unmap and automatic GC.  The 
underlying file can (for example) immediately relinquish reserved disk 
storage or RAM at unmap time (the desired effect), rather than waiting 
for GC to come around (status quo).

I believe that reclaiming the reserved address space is of much less 
importance than freeing the backing resources (especially for 64-bit 
systems), which is why I suggest this approach.

-- 
- DML


From aph at redhat.com  Tue Sep  8 17:40:55 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 8 Sep 2015 18:40:55 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EF14CF.9030201@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com> <55EEC85F.7010800@redhat.com>
	<55EEDE97.9060904@redhat.com> <55EF14CF.9030201@redhat.com>
Message-ID: <55EF1DA7.3010405@redhat.com>

On 09/08/2015 06:03 PM, David M. Lloyd wrote:
> On 09/08/2015 08:11 AM, Andrew Haley wrote:
>> On 09/08/2015 12:37 PM, David M. Lloyd wrote:
>>> Then you do the real unmap when
>>> the buffer is GC'd (maybe via Cleaner).  This is very akin to how file
>>> descriptors are cleaned up, AFAICT.
>>
>> Indeed it is, and it's no better than the status quo.  This is an attempt
>> to do better.
> 
> Actually it *is* better, as it releases the mapping to the underlying 
> file, and does not require any resources (outside of the page table 
> itself and any associated kernel bookkeeping) to maintain a valid state 
> during the time window between user-driven unmap and automatic GC.  The 
> underlying file can (for example) immediately relinquish reserved disk 
> storage or RAM at unmap time (the desired effect), rather than waiting 
> for GC to come around (status quo).
> 
> I believe that reclaiming the reserved address space is of much less 
> importance than freeing the backing resources (especially for 64-bit 
> systems), which is why I suggest this approach.

I think you may be assuming rather a lot about the way that the
underlying OS actually works.  The bug report mentions race conditions
when remapping, and not every OS has nice UNIXy semantics.  Hence my
proposal, which might be portable to other OSs.

Andrew.


From david.lloyd at redhat.com  Tue Sep  8 17:54:42 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 08 Sep 2015 12:54:42 -0500
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EF1DA7.3010405@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>	<55EEAAB8.1000004@redhat.com>
	<55EEC85F.7010800@redhat.com>	<55EEDE97.9060904@redhat.com>
	<55EF14CF.9030201@redhat.com> <55EF1DA7.3010405@redhat.com>
Message-ID: <55EF20E2.2070009@redhat.com>

On 09/08/2015 12:40 PM, Andrew Haley wrote:
> On 09/08/2015 06:03 PM, David M. Lloyd wrote:
>> On 09/08/2015 08:11 AM, Andrew Haley wrote:
>>> On 09/08/2015 12:37 PM, David M. Lloyd wrote:
>>>> Then you do the real unmap when
>>>> the buffer is GC'd (maybe via Cleaner).  This is very akin to how file
>>>> descriptors are cleaned up, AFAICT.
>>>
>>> Indeed it is, and it's no better than the status quo.  This is an attempt
>>> to do better.
>>
>> Actually it *is* better, as it releases the mapping to the underlying
>> file, and does not require any resources (outside of the page table
>> itself and any associated kernel bookkeeping) to maintain a valid state
>> during the time window between user-driven unmap and automatic GC.  The
>> underlying file can (for example) immediately relinquish reserved disk
>> storage or RAM at unmap time (the desired effect), rather than waiting
>> for GC to come around (status quo).
>>
>> I believe that reclaiming the reserved address space is of much less
>> importance than freeing the backing resources (especially for 64-bit
>> systems), which is why I suggest this approach.
>
> I think you may be assuming rather a lot about the way that the
> underlying OS actually works.  The bug report mentions race conditions
> when remapping, and not every OS has nice UNIXy semantics.  Hence my
> proposal, which might be portable to other OSs.

It's at least been in POSIX since 2008: "This volume of POSIX.1?2008 
specifies that [..] new [MAP_FIXED] mappings replace any existing 
mappings, following existing practice in this regard."  Linux agrees: 
"If the memory region specified by addr and len overlaps pages of any 
existing mapping(s), then the overlapped part of the existing mapping(s) 
will be discarded."  BSD seems to agree as well, as does Solaris, and I 
can't seem to find any public reference to known race conditions with 
this kind of operation.

I think the only questionable platform at this point is Windows (to me 
at least, given that I do not have much experience on it).
-- 
- DML


From aph at redhat.com  Tue Sep  8 18:37:34 2015
From: aph at redhat.com (Andrew Haley)
Date: Tue, 8 Sep 2015 19:37:34 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EF20E2.2070009@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com> <55EEC85F.7010800@redhat.com>
	<55EEDE97.9060904@redhat.com> <55EF14CF.9030201@redhat.com>
	<55EF1DA7.3010405@redhat.com> <55EF20E2.2070009@redhat.com>
Message-ID: <55EF2AEE.9030100@redhat.com>

On 09/08/2015 06:54 PM, David M. Lloyd wrote:
> I think the only questionable platform at this point is Windows (to me 
> at least, given that I do not have much experience on it).

That's right, and it's Windows which has the worst problem: on UNIX
you can delete a file which is mapped, on Windows AFAIK you can't.  I
think that MR is referring to Windows when he talks about race
conditions.

Andrew.


From david.lloyd at redhat.com  Tue Sep  8 18:49:20 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 08 Sep 2015 13:49:20 -0500
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EF2AEE.9030100@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>	<55EEAAB8.1000004@redhat.com>
	<55EEC85F.7010800@redhat.com>	<55EEDE97.9060904@redhat.com>
	<55EF14CF.9030201@redhat.com>	<55EF1DA7.3010405@redhat.com>
	<55EF20E2.2070009@redhat.com> <55EF2AEE.9030100@redhat.com>
Message-ID: <55EF2DB0.8090403@redhat.com>

On 09/08/2015 01:37 PM, Andrew Haley wrote:
> On 09/08/2015 06:54 PM, David M. Lloyd wrote:
>> I think the only questionable platform at this point is Windows (to me
>> at least, given that I do not have much experience on it).
>
> That's right, and it's Windows which has the worst problem: on UNIX
> you can delete a file which is mapped, on Windows AFAIK you can't.  I
> think that MR is referring to Windows when he talks about race
> conditions.

Possibly, but again, if Windows can somehow allow pages to be remapped 
without first unmapping them the way other OSes can, then the file lock 
issue is no longer an issue, which is the entire point of the approach. 
  Researching Windows' behavior seems to be the key; I haven't been able 
to discover anything definitive online though, and I do not have 
immediate access to any Windows-based machines for testing, so I 
couldn't really guess beyond that.

-- 
- DML


From forax at univ-mlv.fr  Tue Sep  8 19:15:42 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 8 Sep 2015 21:15:42 +0200 (CEST)
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EEE2B5.5070800@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com>
	<73CB5B94-B817-4333-87E8-89E9A2110199@oracle.com>
	<55EEDD0D.6070302@redhat.com> <55EEE2B5.5070800@redhat.com>
Message-ID: <1661851856.943842.1441739742409.JavaMail.zimbra@u-pem.fr>

On 09/08/2015 03:29 PM, Andrew Haley wrote:
> On 09/08/2015 02:05 PM, Andrew Haley wrote:
>> I don't think you'd actually need to unmap anything until a safepoint.
>> I don't think that the speed of unmapping is critical as long as it
>> happens "soon".
>
> Although given the desire to do
>
>   buffer.unmap();
>   file.delete();
>
> that belief may be misplaced.  We could just block for a safepoint;
> we already do that in other cases, and there's no guarantee about how
> long unmap() would take to execute.
>
> Andrew.
>

I think a simple way to solve that is to ask for a safepoint explicitly,

  buffer.unmap();
  waitUntilUnmapped();
  file.delete();

R?mi

----- Mail original -----
> De: "Andrew Haley" <aph at redhat.com>
> ?: core-libs-dev at openjdk.java.net
> Envoy?: Mardi 8 Septembre 2015 15:29:25
> Objet: Re: Suggested fix for JDK-4724038 (Add unmap method to	MappedByteBuffer)
> 
> On 09/08/2015 02:05 PM, Andrew Haley wrote:
> > I don't think you'd actually need to unmap anything until a safepoint.
> > I don't think that the speed of unmapping is critical as long as it
> > happens "soon".
> 
> Although given the desire to do
> 
>   buffer.unmap();
>   file.delete();
> 
> that belief may be misplaced.  We could just block for a safepoint;
> we already do that in other cases, and there's no guarantee about how
> long unmap() would take to execute.
> 
> Andrew.
> 
> 


From hearn at vinumeris.com  Tue Sep  8 19:39:49 2015
From: hearn at vinumeris.com (Mike Hearn)
Date: Tue, 8 Sep 2015 21:39:49 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EF13A7.2030103@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com> <55EEC85F.7010800@redhat.com>
	<CA+w+GKQJR-n6JmwDXj_Y3DWakOb3CbpT2VV3=OqjC9pxPkN96A@mail.gmail.com>
	<55EF13A7.2030103@redhat.com>
Message-ID: <CA+w+GKTNUjuNv6w3Wr41+7jDLbkUSnOYkZKu0rDNp4FjoktDyg@mail.gmail.com>

>
> So Windows has no operation which can remap a previously mapped section of
> memory to something else? (say, just a block of non-access memory)
>
> Note that such an operation has to be atomic with respect to all other
> operations which affect the address space of the process (or at least,
> which may randomly choose an address in memory at which to create new
> mappings), but not with respect to anything else really.  The point of the
> remapping is to continue to reserve the address space, without actually
> referencing what was there before (thus dodging file lock issues).  No
> physical or virtual memory need actually be reserved for such a mapping.
>
> --
> - DML
>


From hearn at vinumeris.com  Tue Sep  8 19:41:25 2015
From: hearn at vinumeris.com (Mike Hearn)
Date: Tue, 8 Sep 2015 21:41:25 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CA+w+GKTNUjuNv6w3Wr41+7jDLbkUSnOYkZKu0rDNp4FjoktDyg@mail.gmail.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com> <55EEC85F.7010800@redhat.com>
	<CA+w+GKQJR-n6JmwDXj_Y3DWakOb3CbpT2VV3=OqjC9pxPkN96A@mail.gmail.com>
	<55EF13A7.2030103@redhat.com>
	<CA+w+GKTNUjuNv6w3Wr41+7jDLbkUSnOYkZKu0rDNp4FjoktDyg@mail.gmail.com>
Message-ID: <CA+w+GKSssAUpLpYEWBKiOzvQGt1K8dDEU4Z9WwAa6JJG_oqGtA@mail.gmail.com>

Sorry, seems I must have hit send without noticing.

Windows has this:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa366890(v=vs.85).aspx

However the question is, what happens if you remap a range and then unmap
the file from that same range?

I'm assuming the file unmap operation deletes the mappings entirely.


From vitalyd at gmail.com  Tue Sep  8 19:47:57 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 8 Sep 2015 15:47:57 -0400
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CA+w+GKSssAUpLpYEWBKiOzvQGt1K8dDEU4Z9WwAa6JJG_oqGtA@mail.gmail.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com> <55EEC85F.7010800@redhat.com>
	<CA+w+GKQJR-n6JmwDXj_Y3DWakOb3CbpT2VV3=OqjC9pxPkN96A@mail.gmail.com>
	<55EF13A7.2030103@redhat.com>
	<CA+w+GKTNUjuNv6w3Wr41+7jDLbkUSnOYkZKu0rDNp4FjoktDyg@mail.gmail.com>
	<CA+w+GKSssAUpLpYEWBKiOzvQGt1K8dDEU4Z9WwAa6JJG_oqGtA@mail.gmail.com>
Message-ID: <CAHjP37FFpyFry68_LxV3+4D13NbKS1JAOtrZ=LcSWg7+aQRr5A@mail.gmail.com>

You'd want to then MapViewOfFileEx later using VirtualAllocEx reservation
(to change the mapping), but I don't think MapViewOfFileEx allows
specifying a base address that is reserved via VirtualAllocEx.

On Tue, Sep 8, 2015 at 3:41 PM, Mike Hearn <hearn at vinumeris.com> wrote:

> Sorry, seems I must have hit send without noticing.
>
> Windows has this:
>
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa366890(v=vs.85).aspx
>
> However the question is, what happens if you remap a range and then unmap
> the file from that same range?
>
> I'm assuming the file unmap operation deletes the mappings entirely.
>


From hearn at vinumeris.com  Tue Sep  8 20:13:12 2015
From: hearn at vinumeris.com (Mike Hearn)
Date: Tue, 8 Sep 2015 22:13:12 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EF2AEE.9030100@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com> <55EEC85F.7010800@redhat.com>
	<55EEDE97.9060904@redhat.com> <55EF14CF.9030201@redhat.com>
	<55EF1DA7.3010405@redhat.com> <55EF20E2.2070009@redhat.com>
	<55EF2AEE.9030100@redhat.com>
Message-ID: <CA+w+GKQbT2jP90rQakbaa3HYdGRaNZkWH5vR0u3e3pAL0ZhEEg@mail.gmail.com>

>
> I think that MR is referring to Windows when he talks about
> race conditions.


The race can happen on any platform if you can't do an atomic unmap of a
file and remap to some kind of guard page. I guess on Linux you can, maybe?
I've never tried it.

It may be that on Windows if you remap a file mapping with VirtualAllocEx,
and then close the underlying handle, the guard mapping sticks around and
you can then delete/rename the underlying file.

If not then this appears to be one of those unfortunate sun.misc.Unsafe
equivalents, where the safe way doesn't exist, and the unsafe way that
developers are currently using successfully is going to vanish :(

If there isn't a clever ordering on Windows that works I'd be A-OK with
just trading off a bit of safety when there's no SecurityManager present.
The proposed race is likely to be exceptionally rare on 64 bit systems and
it seems the alternative is either don't use MappedByteBuffer, or override
Jigsaw and get access to the internal Cleaner API back again.


From jodastephen at gmail.com  Tue Sep  8 18:53:16 2015
From: jodastephen at gmail.com (Stephen Colebourne)
Date: Tue, 8 Sep 2015 19:53:16 +0100
Subject: RFR JDK-8133079 LocalDate/LocalTime ofInstant()
In-Reply-To: <CACzrW9DiN5DPG1d1W=gT8NZTJnNwTH5fHe4bpRNHs94tPVatxQ@mail.gmail.com>
References: <CACzrW9DiN5DPG1d1W=gT8NZTJnNwTH5fHe4bpRNHs94tPVatxQ@mail.gmail.com>
Message-ID: <CACzrW9Dsap9AA83yVi1uESP_6O7cYSy9sC9NWe1uoosCQ6PEvA@mail.gmail.com>

Anyone like to take this on please?
Stephen
On 28 Aug 2015 00:07, "Stephen Colebourne" <scolebourne at joda.org> wrote:

> External question sites indicate that users have difficulty converting
> between java.util.Date and LocalDate, and also between Instant and
> LocalDate/LocalTime. This user difficulty can be resolved with some
> additional methods.
>
> Currently, the following methods exist:
>
>  ZonedDateTime.ofInstant(Instant, ZoneId);
>  OffsetDateTime.ofInstant(Instant, ZoneId);
>  LocalDateTime.ofInstant(Instant, ZoneId);
>  OffsetTime.ofInstant(Instant, ZoneId);
>
> This enhancement proposes to add the same method to LocalDate and
> LocalTime. It can reasonably be argued this was a simple oversight in
> the original development.
>
> Diff attached to the JIRA:
>
> https://bugs.openjdk.java.net/browse/JDK-8133079
>
> Would also appreciate a reviewer to ensure that the code and tests
> pass OK (as opposed to my best efforts on a very dubious
> Windows/Eclipse/JDK8 setup)
>
> Stephen
>


From Ulf.Zibis at CoSoCo.de  Tue Sep  8 20:39:37 2015
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Tue, 8 Sep 2015 22:39:37 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EF2AEE.9030100@redhat.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com> <55EEC85F.7010800@redhat.com>
	<55EEDE97.9060904@redhat.com> <55EF14CF.9030201@redhat.com>
	<55EF1DA7.3010405@redhat.com> <55EF20E2.2070009@redhat.com>
	<55EF2AEE.9030100@redhat.com>
Message-ID: <55EF4789.8040004@CoSoCo.de>

Am 08.09.2015 um 20:37 schrieb Andrew Haley:
> I think that MR is referring to Windows when he talks about race conditions. Andrew. 

Couldn't we introduce a unmap() method which throws an UnsupportedOperationException if the 
underlying OS isn't able to unmap the the buffer safely in the mean time?

-Ulf



From Roger.Riggs at Oracle.com  Tue Sep  8 21:08:33 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 8 Sep 2015 17:08:33 -0400
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
Message-ID: <55EF4E51.2030506@Oracle.com>

Please review an intermittent test bug fix.
The test setup time is very short and the user may be returned as 0 
which is reported as root.
The correction lengthens the time allowed for the process to start.

The test is removed from the ProblemList.

Webrev:
http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-info-8133552/

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

Thanks, Roger



From Roger.Riggs at Oracle.com  Tue Sep  8 21:10:42 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 8 Sep 2015 17:10:42 -0400
Subject: RFR 9: 8135094 : (process) java/lang/ProcessHandle/InfoTest fails
	testing commandLine()
Message-ID: <55EF4ED2.2040209@Oracle.com>

Please review this test fix.
The test assumes that the pathname of the command is literally the same as
the executable path provides to ProcessBuilder. However, if the path 
contains
a symbolic link, it is resolved and the real path is reported as the 
command.

Webrev:
http://bussund0416.us.oracle.com/~rriggs/webrev/webrev-info-8135094/

Issue:
    https://bugs.openjdk.java.net/browse/JDK-8135094

Thanks, Roger



From Roger.Riggs at Oracle.com  Tue Sep  8 21:34:31 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 8 Sep 2015 17:34:31 -0400
Subject: RFR 9: 8135094 : (process) java/lang/ProcessHandle/InfoTest fails
	testing commandLine()
In-Reply-To: <55EF4ED2.2040209@Oracle.com>
References: <55EF4ED2.2040209@Oracle.com>
Message-ID: <55EF5467.4070509@Oracle.com>

Oops, Corrected links to webrev:

On 9/8/2015 5:10 PM, Roger Riggs wrote:
> Please review this test fix.
> The test assumes that the pathname of the command is literally the 
> same as
> the executable path provides to ProcessBuilder. However, if the path 
> contains
> a symbolic link, it is resolved and the real path is reported as the 
> command.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs//webrev-info-8135094
>
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8135094
>
> Thanks, Roger
>



From Roger.Riggs at Oracle.com  Tue Sep  8 21:35:10 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 8 Sep 2015 17:35:10 -0400
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
In-Reply-To: <55EF4E51.2030506@Oracle.com>
References: <55EF4E51.2030506@Oracle.com>
Message-ID: <55EF548E.2060601@Oracle.com>

With link to webrev corrected:

On 9/8/2015 5:08 PM, Roger Riggs wrote:
> Please review an intermittent test bug fix.
> The test setup time is very short and the user may be returned as 0 
> which is reported as root.
> The correction lengthens the time allowed for the process to start.
>
> The test is removed from the ProblemList.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs//webrev-info-8133552
>
> Bug:
>   https://bugs.openjdk.java.net/browse/JDK-8133552
>
> Thanks, Roger
>



From chris.hegarty at oracle.com  Tue Sep  8 21:42:12 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 8 Sep 2015 22:42:12 +0100
Subject: RFR 9: 8135094 : (process) java/lang/ProcessHandle/InfoTest fails
	testing commandLine()
In-Reply-To: <55EF5467.4070509@Oracle.com>
References: <55EF4ED2.2040209@Oracle.com> <55EF5467.4070509@Oracle.com>
Message-ID: <87AC031D-0C99-4D1A-B5CC-3B3D98DD99BD@oracle.com>


> On 8 Sep 2015, at 22:34, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Oops, Corrected links to webrev:
> 
> On 9/8/2015 5:10 PM, Roger Riggs wrote:
>> Please review this test fix.
>> The test assumes that the pathname of the command is literally the same as
>> the executable path provides to ProcessBuilder. However, if the path contains
>> a symbolic link, it is resolved and the real path is reported as the command.
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs//webrev-info-8135094
>> 
>> Issue:
>>   https://bugs.openjdk.java.net/browse/JDK-8135094 <https://bugs.openjdk.java.net/browse/JDK-8135094>

Looks ok to me Roger.

-Chris.




From peter.levart at gmail.com  Tue Sep  8 22:37:13 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 9 Sep 2015 00:37:13 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <1661851856.943842.1441739742409.JavaMail.zimbra@u-pem.fr>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com>
	<73CB5B94-B817-4333-87E8-89E9A2110199@oracle.com>
	<55EEDD0D.6070302@redhat.com> <55EEE2B5.5070800@redhat.com>
	<1661851856.943842.1441739742409.JavaMail.zimbra@u-pem.fr>
Message-ID: <55EF6319.6080609@gmail.com>



On 09/08/2015 09:15 PM, Remi Forax wrote:
> On 09/08/2015 03:29 PM, Andrew Haley wrote:
>> On 09/08/2015 02:05 PM, Andrew Haley wrote:
>>> I don't think you'd actually need to unmap anything until a safepoint.
>>> I don't think that the speed of unmapping is critical as long as it
>>> happens "soon".
>> Although given the desire to do
>>
>>    buffer.unmap();
>>    file.delete();
>>
>> that belief may be misplaced.  We could just block for a safepoint;
>> we already do that in other cases, and there's no guarantee about how
>> long unmap() would take to execute.
>>
>> Andrew.
>>
> I think a simple way to solve that is to ask for a safepoint explicitly,
>
>    buffer.unmap();
>    waitUntilUnmapped();
>    file.delete();
>
> R?mi

Hi,

The following can already be performed today:

buffer = null;
waitUntilUnmapped();
file.delete();


The tricky part is how to do waitUntilUnmapped() and maybe even help 
ReferenceHandler thread and/or trigger reference processing while 
waiting. Here's an example that executes an asynchronous callback after 
the memory has been unmapped:

http://cr.openjdk.java.net/~plevart/jdk9-dev/4724038_MappedByteBuffer_afterRelease/webrev.01/

The test shows how one could delete the file after it has been unmapped 
(if the byte buffer was the only mapping).

Would such notification be enough to cover the use cases? What are the 
use cases one would like to cover with hypothetical unmap() was it 
available?


Regards, Peter

> ----- Mail original -----
>> De: "Andrew Haley" <aph at redhat.com>
>> ?: core-libs-dev at openjdk.java.net
>> Envoy?: Mardi 8 Septembre 2015 15:29:25
>> Objet: Re: Suggested fix for JDK-4724038 (Add unmap method to	MappedByteBuffer)
>>
>> On 09/08/2015 02:05 PM, Andrew Haley wrote:
>>> I don't think you'd actually need to unmap anything until a safepoint.
>>> I don't think that the speed of unmapping is critical as long as it
>>> happens "soon".
>> Although given the desire to do
>>
>>    buffer.unmap();
>>    file.delete();
>>
>> that belief may be misplaced.  We could just block for a safepoint;
>> we already do that in other cases, and there's no guarantee about how
>> long unmap() would take to execute.
>>
>> Andrew.
>>
>>



From stuart.marks at oracle.com  Wed Sep  9 00:53:53 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 8 Sep 2015 17:53:53 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
Message-ID: <55EF8321.8040203@oracle.com>



On 9/4/15 1:35 AM, Paul Sandoz wrote:
> Hi Stuart,
>
> This is looking very good.
>
> Just some comments on the tricky aspect related to late-binding of the Stream to the scanner state:
>
> 2652      * <p>This scanner's state should not be modified during execution of the returned
> 2653      * stream's pipeline. Subsequent calls to any methods on this scanner other than
> 2654      * {@link #close} and {@link #ioException} may return undefined results or may cause
> 2655      * undefined effects on the returned stream. The returned stream's source
> 2656      * {@code Spliterator} is <em>fail-fast</em> and will, on a best-effort
> 2657      * basis, throw a {@link java.util.ConcurrentModificationException} if such
> 2658      * modification is detected.
>
> ?Subsequent? is a little vague here, does it mean before, during or after stream pipeline execution?

> Before:
>
> Most methods on scanner may be called before stream pipeline execution, they just adjust the scanner state from which to start from. If close is called it should result in an ISE on pipeline execution.
>
> During:
>
> Either a CME on a best-effort basis if scanner state is modified by a behavioural parameter, or an ISE if close is called.
>
> After:
>
> The scanner is in an indeterminate state. For further operations it needs to be reset, and if the scanner was closed during execution an ISE will result on further operations.
>
> We should try and succinctly talk about all three cases in the specification.

Mmm, yes, can't get anything vague past you. :-) "Subsequent" should mean 
anytime after initiation of the pipeline execution. But it would be better to be 
a bit more explicit. Note that effects go both ways; during pipeline execution, 
calls to scanner methods might cause the stream to throw CME, and stream 
operations might cause scanner methods to return unspecified results.

I think the following covers all of the before, during, and after cases.

<< Scanning starts upon initiation of the terminal stream operation, using the 
current state of this scanner. Subsequent calls to any methods on this scanner 
other than {@link #close} and {@link #ioException} may return undefined results 
or may cause undefined effects on the returned stream. The returned stream's 
source {@code Spliterator} is <em>fail-fast</em> and will, on a best-effort 
basis, throw a {@link java.util.ConcurrentModificationException} if any such 
calls are detected during pipeline execution. >>

The reset() method will reset the delimiter, locale, and radix, but it can't 
reset the position in the input, so the scanner effectively cannot be reused 
after any stream operation has been initiated.

I'll add the following:

<< After stream execution completes, this scanner is left in an indeterminate 
state and cannot be reused. >>

The closed behavior is separate from CME, so I'll add the following to the text 
that covers the closing behavior.

<< IllegalStateException is thrown if the scanner has been closed when this 
method is called, or if this scanner is closed during pipeline execution. >>

All of the above apply to both the tokens() method and the main findAll() method.

> You might need to double check FindSpliterator for the before and during cases as i don?t think findPatternInBuffer checks if the scanner is closed, i think it needs an ensureOpen call in tryAdvance.

Good catch! I've added an ensureOpen() call here and I've also add tests to 
cover this case.

Updated webrev:

   http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.3/

Updated specdiff:

 
http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.3/overview-summary.html

s'marks



> Paul.
>
> On 4 Sep 2015, at 08:17, Stuart Marks <stuart.marks at oracle.com> wrote:
>
>> Please review this update to the Scanner enhancement I proposed a while back. [1]
>>
>> I've updated based on some discussions with Paul Sandoz. The updates since the previous posting are 1) coordination of spec wording from Matcher; 2) addition of ConcurrentModificationException; 3) updating tests to use the streams testing framework; 4) some javadoc cleanups.
>>
>> Bug:
>>
>> 	https://bugs.openjdk.java.net/browse/JDK-8072722
>>
>> Webrev:
>>
>> 	http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.2/
>>
>> Specdiff:
>>
>> 	http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.2/overview-summary.html
>>
>>
>> For convenience, I've appended below the description from my earlier post. [1]
>>
>> s'marks
>>
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034821.html
>>
>>
>> -------
>>
>>
>> Scanner is essentially a regular expression matcher that matches over arbitrary input (e.g., from a file) instead of a fixed string like Matcher. Scanner will read and buffer additional input as necessary when looking for matches.
>>
>> This change proposes to add two streams methods:
>>
>> 1. tokens(), which returns a stream of tokens delimited by the Scanner's delimiter. Scanner's default delimiter is whitespace, so the following will collect a list of whitespace-separated words from a file:
>>
>>     try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
>>         List<String> words = sc.tokens().collect(toList());
>>     }
>>
>> 2. findAll(pattern), which returns a stream of match results generated by searching the input for the given pattern (either a Pattern or a String). For example, the following will extract from a file all words that are surrounded by "_" characters, such as _foo_ :
>>
>>     try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
>>         return sc.findAll("_([\\w]+)_")
>>                  .map(mr -> mr.group(1))
>>                  .collect(toList());
>>     }
>>
>> Implementation notes. A Scanner is essentially already an iterator of tokens, so tokens() pretty much just wraps "this" into a stream. The findAll() methods are a wrapper around repeated calls to findWithinHorizon(pattern, 0) with a bit of refactoring to avoid converting the MatchResult to a String prematurely.
>>
>> The tests are pretty straightforward, with some additional cleanups, such as using try-with-resources.
>>
>> -------
>


From david.holmes at oracle.com  Wed Sep  9 04:38:05 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 9 Sep 2015 14:38:05 +1000
Subject: RFR: 8133611: Remove
	java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java from
	problem list
Message-ID: <55EFB7AD.40401@oracle.com>

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

Webrev: http://cr.openjdk.java.net/~dholmes/8133611/webrev/

Patch inline below.

Now the hotspot fix is in place the test can be removed from the problem 
list and need not be marked "intermittent".

Thanks,
David
-----

--- old/test/ProblemList.txt	2015-09-09 00:34:56.091794570 -0400
+++ new/test/ProblemList.txt	2015-09-09 00:34:54.719717019 -0400
@@ -363,10 +363,6 @@
  # 8062512
 
java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java 
generic-all

-# 8029453
-java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java linux-all
-
-
 
############################################################################

  # jdk_instrument
--- 
old/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 
2015-09-09 00:35:00.104021348 -0400
+++ 
new/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 
2015-09-09 00:34:58.715942891 -0400
@@ -35,7 +35,6 @@
   * @test
   * @bug 4486658 5031862
   * @run main TimeoutLockLoops
- * @key intermittent
   * @summary Checks for responsiveness of locks to timeouts.
   * Runs under the assumption that ITERS computations require more than
   * TIMEOUT msecs to complete, which seems to be a safe assumption for


From joe.darcy at oracle.com  Wed Sep  9 04:42:33 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 8 Sep 2015 21:42:33 -0700
Subject: RFR: 8133611: Remove
	java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java from
	problem list
In-Reply-To: <55EFB7AD.40401@oracle.com>
References: <55EFB7AD.40401@oracle.com>
Message-ID: <55EFB8B9.8090206@oracle.com>

Approved; thanks David,

-Joe

On 9/8/2015 9:38 PM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8133611
>
> Webrev: http://cr.openjdk.java.net/~dholmes/8133611/webrev/
>
> Patch inline below.
>
> Now the hotspot fix is in place the test can be removed from the 
> problem list and need not be marked "intermittent".
>
> Thanks,
> David
> -----
>
> --- old/test/ProblemList.txt    2015-09-09 00:34:56.091794570 -0400
> +++ new/test/ProblemList.txt    2015-09-09 00:34:54.719717019 -0400
> @@ -363,10 +363,6 @@
>  # 8062512
>
> java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java generic-all 
>
>
> -# 8029453
> -java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java linux-all
> -
> -
>
> ############################################################################ 
>
>
>  # jdk_instrument
> --- 
> old/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 2015-09-09 
> 00:35:00.104021348 -0400
> +++ 
> new/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 2015-09-09 
> 00:34:58.715942891 -0400
> @@ -35,7 +35,6 @@
>   * @test
>   * @bug 4486658 5031862
>   * @run main TimeoutLockLoops
> - * @key intermittent
>   * @summary Checks for responsiveness of locks to timeouts.
>   * Runs under the assumption that ITERS computations require more than
>   * TIMEOUT msecs to complete, which seems to be a safe assumption for



From paul.sandoz at oracle.com  Wed Sep  9 07:50:11 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 9 Sep 2015 09:50:11 +0200
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55EF8321.8040203@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
Message-ID: <E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>


On 9 Sep 2015, at 02:53, Stuart Marks <stuart.marks at oracle.com> wrote:
> I think the following covers all of the before, during, and after cases.
> 
> << Scanning starts upon initiation of the terminal stream operation, using the current state of this scanner. Subsequent calls to any methods on this scanner other than {@link #close} and {@link #ioException} may return undefined results or may cause undefined effects on the returned stream. The returned stream's source {@code Spliterator} is <em>fail-fast</em> and will, on a best-effort basis, throw a {@link java.util.ConcurrentModificationException} if any such calls are detected during pipeline execution. >>
> 
> The reset() method will reset the delimiter, locale, and radix, but it can't reset the position in the input, so the scanner effectively cannot be reused after any stream operation has been initiated.
> 
> I'll add the following:
> 
> << After stream execution completes, this scanner is left in an indeterminate state and cannot be reused. >>
> 

Ah, shame, which strongly suggests advising that the stream/scanner should always be closed afterwards, regardless of whether it contains a resource to be released. Not sure we need to say anything, up to you.


> The closed behavior is separate from CME, so I'll add the following to the text that covers the closing behavior.
> 
> << IllegalStateException is thrown if the scanner has been closed when this method is called, or if this scanner is closed during pipeline execution. >>
> 
> All of the above apply to both the tokens() method and the main findAll() method.
> 
>> You might need to double check FindSpliterator for the before and during cases as i don?t think findPatternInBuffer checks if the scanner is closed, i think it needs an ensureOpen call in tryAdvance.
> 
> Good catch! I've added an ensureOpen() call here and I've also add tests to cover this case.
> 
> Updated webrev:
> 
>  http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.3/
> 

+1.

Paul.

> Updated specdiff:
> 
> http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.3/overview-summary.html
> 
> s'marks
> 


From david.holmes at oracle.com  Wed Sep  9 08:03:34 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 9 Sep 2015 18:03:34 +1000
Subject: RFR: 8133611: Remove
	java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java from
	problem list
In-Reply-To: <55EFB8B9.8090206@oracle.com>
References: <55EFB7AD.40401@oracle.com> <55EFB8B9.8090206@oracle.com>
Message-ID: <55EFE7D6.2060309@oracle.com>

Thanks Joe - pushed.

David

On 9/09/2015 2:42 PM, joe darcy wrote:
> Approved; thanks David,
>
> -Joe
>
> On 9/8/2015 9:38 PM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8133611
>>
>> Webrev: http://cr.openjdk.java.net/~dholmes/8133611/webrev/
>>
>> Patch inline below.
>>
>> Now the hotspot fix is in place the test can be removed from the
>> problem list and need not be marked "intermittent".
>>
>> Thanks,
>> David
>> -----
>>
>> --- old/test/ProblemList.txt    2015-09-09 00:34:56.091794570 -0400
>> +++ new/test/ProblemList.txt    2015-09-09 00:34:54.719717019 -0400
>> @@ -363,10 +363,6 @@
>>  # 8062512
>>
>> java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java generic-all
>>
>>
>> -# 8029453
>> -java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java linux-all
>> -
>> -
>>
>> ############################################################################
>>
>>
>>  # jdk_instrument
>> ---
>> old/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 2015-09-09
>> 00:35:00.104021348 -0400
>> +++
>> new/test/java/util/concurrent/locks/ReentrantLock/TimeoutLockLoops.java 2015-09-09
>> 00:34:58.715942891 -0400
>> @@ -35,7 +35,6 @@
>>   * @test
>>   * @bug 4486658 5031862
>>   * @run main TimeoutLockLoops
>> - * @key intermittent
>>   * @summary Checks for responsiveness of locks to timeouts.
>>   * Runs under the assumption that ITERS computations require more than
>>   * TIMEOUT msecs to complete, which seems to be a safe assumption for
>


From chris.hegarty at oracle.com  Wed Sep  9 08:04:15 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 9 Sep 2015 09:04:15 +0100
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55EF8321.8040203@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
Message-ID: <625461DA-2656-4CAD-84FB-87A9A866A389@oracle.com>

This looks very nice, just a minor spec comment..

> On 9 Sep 2015, at 01:53, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> 
> 
> On 9/4/15 1:35 AM, Paul Sandoz wrote:
>> Hi Stuart,
>> 
>> This is looking very good.
>> 
>> Just some comments on the tricky aspect related to late-binding of the Stream to the scanner state:
>> 
>> 2652      * <p>This scanner's state should not be modified during execution of the returned
>> 2653      * stream's pipeline. Subsequent calls to any methods on this scanner other than
>> 2654      * {@link #close} and {@link #ioException} may return undefined results or may cause
>> 2655      * undefined effects on the returned stream. The returned stream's source
>> 2656      * {@code Spliterator} is <em>fail-fast</em> and will, on a best-effort
>> 2657      * basis, throw a {@link java.util.ConcurrentModificationException} if such
>> 2658      * modification is detected.
>> 
>> ?Subsequent? is a little vague here, does it mean before, during or after stream pipeline execution?
> 
>> Before:
>> 
>> Most methods on scanner may be called before stream pipeline execution, they just adjust the scanner state from which to start from. If close is called it should result in an ISE on pipeline execution.
>> 
>> During:
>> 
>> Either a CME on a best-effort basis if scanner state is modified by a behavioural parameter, or an ISE if close is called.
>> 
>> After:
>> 
>> The scanner is in an indeterminate state. For further operations it needs to be reset, and if the scanner was closed during execution an ISE will result on further operations.
>> 
>> We should try and succinctly talk about all three cases in the specification.
> 
> Mmm, yes, can't get anything vague past you. :-) "Subsequent" should mean anytime after initiation of the pipeline execution. But it would be better to be a bit more explicit. Note that effects go both ways; during pipeline execution, calls to scanner methods might cause the stream to throw CME, and stream operations might cause scanner methods to return unspecified results.
> 
> I think the following covers all of the before, during, and after cases.
> 
> << Scanning starts upon initiation of the terminal stream operation, using the current state of this scanner. Subsequent calls to any methods on this scanner other than {@link #close} and {@link #ioException} may return undefined results or may cause undefined effects on the returned stream. The returned stream's source {@code Spliterator} is <em>fail-fast</em> and will, on a best-effort basis, throw a {@link java.util.ConcurrentModificationException} if any such calls are detected during pipeline execution. >>
> 
> The reset() method will reset the delimiter, locale, and radix, but it can't reset the position in the input, so the scanner effectively cannot be reused after any stream operation has been initiated.
> 
> I'll add the following:
> 
> << After stream execution completes, this scanner is left in an indeterminate state and cannot be reused. >>

I think this note is good, but the webrev/specdiff uses the term ?pipeline execution?. I think ?stream execution? is less likely to cause confusion.

-Chris.


> The closed behavior is separate from CME, so I'll add the following to the text that covers the closing behavior.
> 
> << IllegalStateException is thrown if the scanner has been closed when this method is called, or if this scanner is closed during pipeline execution. >>
> 
> All of the above apply to both the tokens() method and the main findAll() method.
> 
>> You might need to double check FindSpliterator for the before and during cases as i don?t think findPatternInBuffer checks if the scanner is closed, i think it needs an ensureOpen call in tryAdvance.
> 
> Good catch! I've added an ensureOpen() call here and I've also add tests to cover this case.
> 
> Updated webrev:
> 
>  http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.3/ <http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.3/>
> 
> Updated specdiff:
> 
> http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.3/overview-summary.html <http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.3/overview-summary.html>
> 
> s'marks
> 
> 
> 
>> Paul.
>> 
>> On 4 Sep 2015, at 08:17, Stuart Marks <stuart.marks at oracle.com> wrote:
>> 
>>> Please review this update to the Scanner enhancement I proposed a while back. [1]
>>> 
>>> I've updated based on some discussions with Paul Sandoz. The updates since the previous posting are 1) coordination of spec wording from Matcher; 2) addition of ConcurrentModificationException; 3) updating tests to use the streams testing framework; 4) some javadoc cleanups.
>>> 
>>> Bug:
>>> 
>>> 	https://bugs.openjdk.java.net/browse/JDK-8072722
>>> 
>>> Webrev:
>>> 
>>> 	http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.2/
>>> 
>>> Specdiff:
>>> 
>>> 	http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.2/overview-summary.html
>>> 
>>> 
>>> For convenience, I've appended below the description from my earlier post. [1]
>>> 
>>> s'marks
>>> 
>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/034821.html
>>> 
>>> 
>>> -------
>>> 
>>> 
>>> Scanner is essentially a regular expression matcher that matches over arbitrary input (e.g., from a file) instead of a fixed string like Matcher. Scanner will read and buffer additional input as necessary when looking for matches.
>>> 
>>> This change proposes to add two streams methods:
>>> 
>>> 1. tokens(), which returns a stream of tokens delimited by the Scanner's delimiter. Scanner's default delimiter is whitespace, so the following will collect a list of whitespace-separated words from a file:
>>> 
>>>    try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
>>>        List<String> words = sc.tokens().collect(toList());
>>>    }
>>> 
>>> 2. findAll(pattern), which returns a stream of match results generated by searching the input for the given pattern (either a Pattern or a String). For example, the following will extract from a file all words that are surrounded by "_" characters, such as _foo_ :
>>> 
>>>    try (Scanner sc = new Scanner(Paths.get(FILENAME))) {
>>>        return sc.findAll("_([\\w]+)_")
>>>                 .map(mr -> mr.group(1))
>>>                 .collect(toList());
>>>    }
>>> 
>>> Implementation notes. A Scanner is essentially already an iterator of tokens, so tokens() pretty much just wraps "this" into a stream. The findAll() methods are a wrapper around repeated calls to findWithinHorizon(pattern, 0) with a bit of refactoring to avoid converting the MatchResult to a String prematurely.
>>> 
>>> The tests are pretty straightforward, with some additional cleanups, such as using try-with-resources.
>>> 
>>> -------



From aph at redhat.com  Wed Sep  9 08:32:34 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 9 Sep 2015 09:32:34 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <1661851856.943842.1441739742409.JavaMail.zimbra@u-pem.fr>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com>
	<73CB5B94-B817-4333-87E8-89E9A2110199@oracle.com>
	<55EEDD0D.6070302@redhat.com> <55EEE2B5.5070800@redhat.com>
	<1661851856.943842.1441739742409.JavaMail.zimbra@u-pem.fr>
Message-ID: <55EFEEA2.8020405@redhat.com>

On 09/08/2015 08:15 PM, Remi Forax wrote:
> On 09/08/2015 03:29 PM, Andrew Haley wrote:
>> On 09/08/2015 02:05 PM, Andrew Haley wrote:
>>> I don't think you'd actually need to unmap anything until a safepoint.
>>> I don't think that the speed of unmapping is critical as long as it
>>> happens "soon".
>>
>> Although given the desire to do
>>
>>   buffer.unmap();
>>   file.delete();
>>
>> that belief may be misplaced.  We could just block for a safepoint;
>> we already do that in other cases, and there's no guarantee about how
>> long unmap() would take to execute.
> 
> I think a simple way to solve that is to ask for a safepoint explicitly,
> 
>   buffer.unmap();
>   waitUntilUnmapped();
>   file.delete();

Umm, why?  Java methods usually don't return until they've finished.  I
can't think of any application requirement for asynchronous operation in
this particular case.

Andrew.



From paul.sandoz at oracle.com  Wed Sep  9 08:37:48 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 9 Sep 2015 10:37:48 +0200
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <625461DA-2656-4CAD-84FB-87A9A866A389@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<625461DA-2656-4CAD-84FB-87A9A866A389@oracle.com>
Message-ID: <E7CF8420-F28F-412B-A439-73A2D7CF4E16@oracle.com>

On 9 Sep 2015, at 10:04, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> << After stream execution completes, this scanner is left in an indeterminate state and cannot be reused. >>
> 
> I think this note is good, but the webrev/specdiff uses the term ?pipeline execution?. I think ?stream execution? is less likely to cause confusion.
> 

I usually try and refer to "stream pipeline execution".

Paul.


From aph at redhat.com  Wed Sep  9 08:42:29 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 9 Sep 2015 09:42:29 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EF4789.8040004@CoSoCo.de>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com> <55EEC85F.7010800@redhat.com>
	<55EEDE97.9060904@redhat.com> <55EF14CF.9030201@redhat.com>
	<55EF1DA7.3010405@redhat.com> <55EF20E2.2070009@redhat.com>
	<55EF2AEE.9030100@redhat.com> <55EF4789.8040004@CoSoCo.de>
Message-ID: <55EFF0F5.8050308@redhat.com>

On 09/08/2015 09:39 PM, Ulf Zibis wrote:
> Am 08.09.2015 um 20:37 schrieb Andrew Haley:
>> I think that MR is referring to Windows when he talks about race conditions. Andrew. 
> 
> Couldn't we introduce a unmap() method which throws an UnsupportedOperationException if the 
> underlying OS isn't able to unmap the the buffer safely in the mean time?

How would that help Windows people?  And how would it aid portability?

Andrew.




From chris.hegarty at oracle.com  Wed Sep  9 09:51:49 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 9 Sep 2015 10:51:49 +0100
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <E7CF8420-F28F-412B-A439-73A2D7CF4E16@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<625461DA-2656-4CAD-84FB-87A9A866A389@oracle.com>
	<E7CF8420-F28F-412B-A439-73A2D7CF4E16@oracle.com>
Message-ID: <55F00135.1040809@oracle.com>

On 09/09/15 09:37, Paul Sandoz wrote:
> On 9 Sep 2015, at 10:04, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>>
>>> << After stream execution completes, this scanner is left in an indeterminate state and cannot be reused. >>
>>
>> I think this note is good, but the webrev/specdiff uses the term ?pipeline execution?. I think ?stream execution? is less likely to cause confusion.
>>
>
> I usually try and refer to "stream pipeline execution".

Yes, that is better. It links 'pipeline' to the stream.

-Chris.


From uschindler at apache.org  Wed Sep  9 10:51:31 2015
From: uschindler at apache.org (Uwe Schindler)
Date: Wed, 9 Sep 2015 12:51:31 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
Message-ID: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>

Hi,

Dawid Weiss and I are both involved in the Apache Lucene project and we know the problems with MappedByteBuffer and unmapping. Dawid already responded with a source code link to our impl (which needs to use the hacky cleaner() approach; also look at the heavy documentation in this class): https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java

So we would be very happy to get this issue resolved! The cleaner() hack is enabled by default in Lucene if the JVM supports it (so we won't break if JIGSAW prevents this, but our *large* users would heavily complain).

>> This is fundamentally about *integrity* of the runtime. It follows there
>> are security implications, but it?s still fundamentally an integrity issue
>> and guarding an unsafe operation with a Security Manager is
>> unfortunately an insufficient solution.
>
> Right, and just to add that there has been many attempts over the years 
> to find solutions to this issue. I think the closest was atomimcally 
> remapping but that wasn't feasible on all platforms and also didn't free 
> up the address space in a timely manner.

So we should really find a solution here. I was talking with several people on various conferences (Rory O'Donnel or Mark Reinhold) and we had some ideas how to solve this. My idea how to solve this is explained below (I am not a JVM internals or Hotspot guy, so excuse some obviously "wrong" assumptions):

Actually there are 2 issues, not only one. The first issue is, as mentioned before: you cannot unmap via API. This is needed for many apps, including Apache Lucene, for a reason which comes more from "another" bug, and this is my issue #2 (see below).

First, unmapping for Lucene is very important at the moment, because we operate on the Lucene indexes purely using mmap (see [1]), which may be several hundreds of Gigabytes easily. On highly dynamic systems, Lucene often maps new files (also very largeones ) and relies on the fact, that older, deleted files are unmapped in time (this does not need to be ASAP, just "in time"). So we have those 2 "bugs", which force us to unmap:

(1) disk space issues / delete after last close (POSIX) vs. No delete at all (Windows)

- disk space: we have seen customers running out of disk space on Lucene, because unmapping wasn?t done in time and therefore POSIX with delete on last close cannot free the disk space, although the file was already deleted. The problem you are seeing on Windows that you cannot delete, is therefore worse on Linux, because it is hidden to the user - you cannot free the disk space of the deleted file! Lucene creates and deletes files all the time while indexing realtime data (e.g. think of Github's very dynamic code search index, which is backed by Lucene/Elasticsearch).
- virtual memory: If you map huge files (several hundreds of Gigabytes) and they are not unmapped in time, you may run out of virtual address space. This especially affects Windows, because it does not use the full 46 bits (or like that) of addresses. So effectively you can only map like 4 Terabytes on Windows. If you have fragmentation of address space this gets worse (In Lucene, we map in chunks of 1 GiB because of the signed 32 bit integer limit of ByteBuffer, so fragmentation is not our biggest issue).

(2) It takes veeeeeeeeeeeeeeeery long time until the unmapping actually occurs!

This is the real bug! If the garbage collector would clean up the buffers asap, we would not need to unmap from user code. In Lucene we just delay the file delete on Windows, so we are not really affected by the file deletion inability (but that would be nice if it could be fixed).

If you look at the usage pattern of those huge, mapped files, you will see why they are in most cases *never ever* unmapped automatically: Lucene maps very large files and uses them for longer time. So the MappedByteBuffer object gets migrated to older generations on the heap. Garbage collection there happens, of course, very delayed. That would not be the most problematic part, but there is a second issue: The MappedByteBuffer object is just a very small object (in heap size measurement: just an object header and a few pointers), so the garbage collector does not see it as heavy! It's just a very small like 30 bytes object instance. Why should the Garbage collector clean it up? And in fact it will almost never do this! The garbage collector cannot see that our 30 bytes object instance "sits" on something like 300 Gigabytes of virtual memory and disk space!

One proposal to fix this would be to add something like an internal OpenJDK Java Annotation or similar where you can "mark" heavy objects, so Garbage collector could free them by preference (similar to sun.misc.Contended).

For the Apache Lucene team,
Uwe

[1] http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/




From david.lloyd at redhat.com  Wed Sep  9 12:41:53 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 09 Sep 2015 07:41:53 -0500
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
Message-ID: <55F02911.9030504@redhat.com>

If you have access to a Windows development environment, it seems to me 
that you could help directly with the testing required to determine a 
solution.

I think my proposed remapping approach will work, but it is contingent 
on testing the following on Windows:

* Determine if it is possible to remap the pages previously mapped to a 
file view without first unmapping them.  Preferably, the pages would be 
remapped as inaccessible (equivalent to POSIX PROT_NONE).

* Determine if such remapping releases the file to be deleted, or, if 
not, determine if the previously mapped file view can be unmapped 
without affecting the remapped pages.

If the answer to both of these can be shown to be affirmative, then I 
think there is a real viable solution which allows immediate release of 
backing resources, with the address space being reclaimed by GC.

On 09/09/2015 05:51 AM, Uwe Schindler wrote:
> Hi,
>
> Dawid Weiss and I are both involved in the Apache Lucene project and we know the problems with MappedByteBuffer and unmapping. Dawid already responded with a source code link to our impl (which needs to use the hacky cleaner() approach; also look at the heavy documentation in this class): https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
>
> So we would be very happy to get this issue resolved! The cleaner() hack is enabled by default in Lucene if the JVM supports it (so we won't break if JIGSAW prevents this, but our *large* users would heavily complain).
>
>>> This is fundamentally about *integrity* of the runtime. It follows there
>>> are security implications, but it?s still fundamentally an integrity issue
>>> and guarding an unsafe operation with a Security Manager is
>>> unfortunately an insufficient solution.
>>
>> Right, and just to add that there has been many attempts over the years
>> to find solutions to this issue. I think the closest was atomimcally
>> remapping but that wasn't feasible on all platforms and also didn't free
>> up the address space in a timely manner.
>
> So we should really find a solution here. I was talking with several people on various conferences (Rory O'Donnel or Mark Reinhold) and we had some ideas how to solve this. My idea how to solve this is explained below (I am not a JVM internals or Hotspot guy, so excuse some obviously "wrong" assumptions):
>
> Actually there are 2 issues, not only one. The first issue is, as mentioned before: you cannot unmap via API. This is needed for many apps, including Apache Lucene, for a reason which comes more from "another" bug, and this is my issue #2 (see below).
>
> First, unmapping for Lucene is very important at the moment, because we operate on the Lucene indexes purely using mmap (see [1]), which may be several hundreds of Gigabytes easily. On highly dynamic systems, Lucene often maps new files (also very largeones ) and relies on the fact, that older, deleted files are unmapped in time (this does not need to be ASAP, just "in time"). So we have those 2 "bugs", which force us to unmap:
>
> (1) disk space issues / delete after last close (POSIX) vs. No delete at all (Windows)
>
> - disk space: we have seen customers running out of disk space on Lucene, because unmapping wasn?t done in time and therefore POSIX with delete on last close cannot free the disk space, although the file was already deleted. The problem you are seeing on Windows that you cannot delete, is therefore worse on Linux, because it is hidden to the user - you cannot free the disk space of the deleted file! Lucene creates and deletes files all the time while indexing realtime data (e.g. think of Github's very dynamic code search index, which is backed by Lucene/Elasticsearch).
> - virtual memory: If you map huge files (several hundreds of Gigabytes) and they are not unmapped in time, you may run out of virtual address space. This especially affects Windows, because it does not use the full 46 bits (or like that) of addresses. So effectively you can only map like 4 Terabytes on Windows. If you have fragmentation of address space this gets worse (In Lucene, we map in chunks of 1 GiB because of the signed 32 bit integer limit of ByteBuffer, so fragmentation is not our biggest issue).
>
> (2) It takes veeeeeeeeeeeeeeeery long time until the unmapping actually occurs!
>
> This is the real bug! If the garbage collector would clean up the buffers asap, we would not need to unmap from user code. In Lucene we just delay the file delete on Windows, so we are not really affected by the file deletion inability (but that would be nice if it could be fixed).
>
> If you look at the usage pattern of those huge, mapped files, you will see why they are in most cases *never ever* unmapped automatically: Lucene maps very large files and uses them for longer time. So the MappedByteBuffer object gets migrated to older generations on the heap. Garbage collection there happens, of course, very delayed. That would not be the most problematic part, but there is a second issue: The MappedByteBuffer object is just a very small object (in heap size measurement: just an object header and a few pointers), so the garbage collector does not see it as heavy! It's just a very small like 30 bytes object instance. Why should the Garbage collector clean it up? And in fact it will almost never do this! The garbage collector cannot see that our 30 bytes object instance "sits" on something like 300 Gigabytes of virtual memory and disk space!
>
> One proposal to fix this would be to add something like an internal OpenJDK Java Annotation or similar where you can "mark" heavy objects, so Garbage collector could free them by preference (similar to sun.misc.Contended).
>
> For the Apache Lucene team,
> Uwe
>
> [1] http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html
>
> -----
> Uwe Schindler
> uschindler at apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
>

-- 
- DML


From Alan.Bateman at oracle.com  Wed Sep  9 12:44:53 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 09 Sep 2015 13:44:53 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F02911.9030504@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com>
Message-ID: <55F029C5.7040403@oracle.com>



On 09/09/2015 13:41, David M. Lloyd wrote:
> If you have access to a Windows development environment, it seems to 
> me that you could help directly with the testing required to determine 
> a solution.
>
> I think my proposed remapping approach will work, but it is contingent 
> on testing the following on Windows:
>
> * Determine if it is possible to remap the pages previously mapped to 
> a file view without first unmapping them.  Preferably, the pages would 
> be remapped as inaccessible (equivalent to POSIX PROT_NONE).
>
> * Determine if such remapping releases the file to be deleted, or, if 
> not, determine if the previously mapped file view can be unmapped 
> without affecting the remapped pages.
>
> If the answer to both of these can be shown to be affirmative, then I 
> think there is a real viable solution which allows immediate release 
> of backing resources, with the address space being reclaimed by GC.
There are a few contributions from Microsoft on this mailing list and 
they might be able to jump in on this discussion. When we last explored 
the remapping approach (about 5 years ago) then we didn't find a way to 
do it atomically so we gave up. It's good to explore this again with 
fresh eyes.

-Alan


From hearn at vinumeris.com  Wed Sep  9 12:46:41 2015
From: hearn at vinumeris.com (Mike Hearn)
Date: Wed, 9 Sep 2015 14:46:41 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
Message-ID: <CA+w+GKTq2qo4kLdV_L1JE1=KD7zNEcEtuoC316TvvzbgQBY46w@mail.gmail.com>

Thanks for the contribution, Uwe.

So far I think I like Andrew's suggestion of a guard page the most.
Unmapping the guard page boils down to a kind of thread-local variable
without the actual cost of reading anything (in theory). So by
write-protecting the guard page and then unmapping the file, and letting
the GC clean up the guard page later, the same semantics as today are
preserved and there's no race.

I guess, although it's ugly, a system property could control whether the
NIO implementation returns an ordinary MappedByteBuffer or a new subclass,
the UnmappableMappedByteBuffer. HotSpot would then be responsible for
removing the overhead of the virtual calls, as normal. If a customer finds
that the guard page write is causing performance issues for them, they
could use the system property to get the hold behaviour back and the unmap
call would throw.

But it sounds like users with extreme VMM needs, like Lucene, would find
this a performance win rather than a loss.

I admit that I'm not a JDK dev. Writing such a patch would be possible for
me but I don't have any kind of performance testing rigs, and this tweak
seems to be mostly dominated by performance concerns. Also I'm kind of busy
with other things right now.

On Wed, Sep 9, 2015 at 12:51 PM, Uwe Schindler <uschindler at apache.org>
wrote:

> Hi,
>
> Dawid Weiss and I are both involved in the Apache Lucene project and we
> know the problems with MappedByteBuffer and unmapping. Dawid already
> responded with a source code link to our impl (which needs to use the hacky
> cleaner() approach; also look at the heavy documentation in this class):
> https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
>
> So we would be very happy to get this issue resolved! The cleaner() hack
> is enabled by default in Lucene if the JVM supports it (so we won't break
> if JIGSAW prevents this, but our *large* users would heavily complain).
>
> >> This is fundamentally about *integrity* of the runtime. It follows there
> >> are security implications, but it?s still fundamentally an integrity
> issue
> >> and guarding an unsafe operation with a Security Manager is
> >> unfortunately an insufficient solution.
> >
> > Right, and just to add that there has been many attempts over the years
> > to find solutions to this issue. I think the closest was atomimcally
> > remapping but that wasn't feasible on all platforms and also didn't free
> > up the address space in a timely manner.
>
> So we should really find a solution here. I was talking with several
> people on various conferences (Rory O'Donnel or Mark Reinhold) and we had
> some ideas how to solve this. My idea how to solve this is explained below
> (I am not a JVM internals or Hotspot guy, so excuse some obviously "wrong"
> assumptions):
>
> Actually there are 2 issues, not only one. The first issue is, as
> mentioned before: you cannot unmap via API. This is needed for many apps,
> including Apache Lucene, for a reason which comes more from "another" bug,
> and this is my issue #2 (see below).
>
> First, unmapping for Lucene is very important at the moment, because we
> operate on the Lucene indexes purely using mmap (see [1]), which may be
> several hundreds of Gigabytes easily. On highly dynamic systems, Lucene
> often maps new files (also very largeones ) and relies on the fact, that
> older, deleted files are unmapped in time (this does not need to be ASAP,
> just "in time"). So we have those 2 "bugs", which force us to unmap:
>
> (1) disk space issues / delete after last close (POSIX) vs. No delete at
> all (Windows)
>
> - disk space: we have seen customers running out of disk space on Lucene,
> because unmapping wasn?t done in time and therefore POSIX with delete on
> last close cannot free the disk space, although the file was already
> deleted. The problem you are seeing on Windows that you cannot delete, is
> therefore worse on Linux, because it is hidden to the user - you cannot
> free the disk space of the deleted file! Lucene creates and deletes files
> all the time while indexing realtime data (e.g. think of Github's very
> dynamic code search index, which is backed by Lucene/Elasticsearch).
> - virtual memory: If you map huge files (several hundreds of Gigabytes)
> and they are not unmapped in time, you may run out of virtual address
> space. This especially affects Windows, because it does not use the full 46
> bits (or like that) of addresses. So effectively you can only map like 4
> Terabytes on Windows. If you have fragmentation of address space this gets
> worse (In Lucene, we map in chunks of 1 GiB because of the signed 32 bit
> integer limit of ByteBuffer, so fragmentation is not our biggest issue).
>
> (2) It takes veeeeeeeeeeeeeeeery long time until the unmapping actually
> occurs!
>
> This is the real bug! If the garbage collector would clean up the buffers
> asap, we would not need to unmap from user code. In Lucene we just delay
> the file delete on Windows, so we are not really affected by the file
> deletion inability (but that would be nice if it could be fixed).
>
> If you look at the usage pattern of those huge, mapped files, you will see
> why they are in most cases *never ever* unmapped automatically: Lucene maps
> very large files and uses them for longer time. So the MappedByteBuffer
> object gets migrated to older generations on the heap. Garbage collection
> there happens, of course, very delayed. That would not be the most
> problematic part, but there is a second issue: The MappedByteBuffer object
> is just a very small object (in heap size measurement: just an object
> header and a few pointers), so the garbage collector does not see it as
> heavy! It's just a very small like 30 bytes object instance. Why should the
> Garbage collector clean it up? And in fact it will almost never do this!
> The garbage collector cannot see that our 30 bytes object instance "sits"
> on something like 300 Gigabytes of virtual memory and disk space!
>
> One proposal to fix this would be to add something like an internal
> OpenJDK Java Annotation or similar where you can "mark" heavy objects, so
> Garbage collector could free them by preference (similar to
> sun.misc.Contended).
>
> For the Apache Lucene team,
> Uwe
>
> [1]
> http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html
>
> -----
> Uwe Schindler
> uschindler at apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
>
>


From aph at redhat.com  Wed Sep  9 12:49:47 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 9 Sep 2015 13:49:47 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F02911.9030504@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com>
Message-ID: <55F02AEB.80101@redhat.com>

On 09/09/2015 01:41 PM, David M. Lloyd wrote:
> If the answer to both of these can be shown to be affirmative, then I 
> think there is a real viable solution which allows immediate release of 
> backing resources, with the address space being reclaimed by GC.

GC delays can be days if an object is in the old generation, and the
Lucene people say this is a real problem for them.  I don't understand
why you want a solution which does not meet one of the requirements.

GC is great for managing heap.  For everything else it's not a
solution.

Andrew.


From aph at redhat.com  Wed Sep  9 12:52:16 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 9 Sep 2015 13:52:16 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CA+w+GKTq2qo4kLdV_L1JE1=KD7zNEcEtuoC316TvvzbgQBY46w@mail.gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<CA+w+GKTq2qo4kLdV_L1JE1=KD7zNEcEtuoC316TvvzbgQBY46w@mail.gmail.com>
Message-ID: <55F02B80.6070506@redhat.com>

On 09/09/2015 01:46 PM, Mike Hearn wrote:
> I guess, although it's ugly, a system property could control whether the
> NIO implementation returns an ordinary MappedByteBuffer or a new subclass,
> the UnmappableMappedByteBuffer. HotSpot would then be responsible for
> removing the overhead of the virtual calls, as normal. If a customer finds
> that the guard page write is causing performance issues for them, they
> could use the system property to get the hold behaviour back and the unmap
> call would throw.
> 
> But it sounds like users with extreme VMM needs, like Lucene, would find
> this a performance win rather than a loss.

I don't like that much: I'd much rather have a wrapper around a
MappedByteBuffer: a closeable MappedByteBuffer, if you like.  But
really, that's just a quibble about details, and is a little
premature.

Andrew.



From david.lloyd at redhat.com  Wed Sep  9 12:58:45 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 09 Sep 2015 07:58:45 -0500
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F02AEB.80101@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>	<55F02911.9030504@redhat.com>
	<55F02AEB.80101@redhat.com>
Message-ID: <55F02D05.2050509@redhat.com>

On 09/09/2015 07:49 AM, Andrew Haley wrote:
> On 09/09/2015 01:41 PM, David M. Lloyd wrote:
>> If the answer to both of these can be shown to be affirmative, then I
>> think there is a real viable solution which allows immediate release of
>> backing resources, with the address space being reclaimed by GC.
>
> GC delays can be days if an object is in the old generation, and the
> Lucene people say this is a real problem for them.  I don't understand
> why you want a solution which does not meet one of the requirements.

It's a real problem for them (as stated) when the GC delay prevents 
release of the backing resources.  With my proposal it would not!  It 
would only prevent release of the address space.

> GC is great for managing heap.  For everything else it's not a
> solution.

Yet it's the only effective way to ensure that the address space is 
unused before releasing it.

The problem with an indirection approach is that it is inherently racy:

Thread 1: read indirection field
Thread 2: clear indirection field
Thread 2: release buffer
Thread 2: create new buffer with same address
Thread 1: access different buffer than expected

Even with the guard page it fails:

Thread 1: access guard page
Thread 2: protect guard page
Thread 2: release buffer
Thread 2: create new buffer with same address
Thread 1: access different buffer than expected

This is identical to the file descriptor problem:

Thread 1: read file descriptor #
Thread 2: close file
Thread 2: open new file
Thread 1: perform syscall against wrong file

You have to find a way to reserve the resource until we can be certain 
that not only is it not reachable, but also no threads have cached a 
reference to it.  For file descriptors, dup2 is used to clone a "dead" 
FD into the original number, until GC can come around and close it.

You can use a dedicated object (e.g. FileDescriptor) to make GC happen 
as quickly as it can (by nulling the sole reference and making it 
unreachable), but unless you start hooking into GC itself I don't see 
how you can ensure that something is not cached in a thread (that's what 
GC *does*).
-- 
- DML


From aph at redhat.com  Wed Sep  9 13:06:40 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 9 Sep 2015 14:06:40 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F02D05.2050509@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com>
Message-ID: <55F02EE0.4040901@redhat.com>

On 09/09/2015 01:58 PM, David M. Lloyd wrote:
> On 09/09/2015 07:49 AM, Andrew Haley wrote:
>> On 09/09/2015 01:41 PM, David M. Lloyd wrote:
>>> If the answer to both of these can be shown to be affirmative, then I
>>> think there is a real viable solution which allows immediate release of
>>> backing resources, with the address space being reclaimed by GC.
>>
>> GC delays can be days if an object is in the old generation, and the
>> Lucene people say this is a real problem for them.  I don't understand
>> why you want a solution which does not meet one of the requirements.
> 
> It's a real problem for them (as stated) when the GC delay prevents 
> release of the backing resources.  With my proposal it would not!  It 
> would only prevent release of the address space.

The release of the address space is a requirement.

>> GC is great for managing heap.  For everything else it's not a
>> solution.
> 
> Yet it's the only effective way to ensure that the address space is 
> unused before releasing it.
> 
> The problem with an indirection approach is that it is inherently racy:
> 
> Thread 1: read indirection field
> Thread 2: clear indirection field
> Thread 2: release buffer
> Thread 2: create new buffer with same address
> Thread 1: access different buffer than expected
> 
> Even with the guard page it fails:
> 
> Thread 1: access guard page
> Thread 2: protect guard page
> Thread 2: release buffer
> Thread 2: create new buffer with same address
> Thread 1: access different buffer than expected

No, that's wrong.  We can't release the buffer until we clear the
references which point to it.  Then thread 1 has no way to reach it.

> You have to find a way to reserve the resource until we can be certain 
> that not only is it not reachable, but also no threads have cached a 
> reference to it.

That's already done: we can't unmap the mapping until the next safepoint.

Andrew.



From david.lloyd at redhat.com  Wed Sep  9 13:13:43 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 09 Sep 2015 08:13:43 -0500
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F02EE0.4040901@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>	<55F02911.9030504@redhat.com>
	<55F02AEB.80101@redhat.com>	<55F02D05.2050509@redhat.com>
	<55F02EE0.4040901@redhat.com>
Message-ID: <55F03087.1010604@redhat.com>

On 09/09/2015 08:06 AM, Andrew Haley wrote:
> On 09/09/2015 01:58 PM, David M. Lloyd wrote:
>> On 09/09/2015 07:49 AM, Andrew Haley wrote:
>>> On 09/09/2015 01:41 PM, David M. Lloyd wrote:
>>>> If the answer to both of these can be shown to be affirmative, then I
>>>> think there is a real viable solution which allows immediate release of
>>>> backing resources, with the address space being reclaimed by GC.
>>>
>>> GC delays can be days if an object is in the old generation, and the
>>> Lucene people say this is a real problem for them.  I don't understand
>>> why you want a solution which does not meet one of the requirements.
>>
>> It's a real problem for them (as stated) when the GC delay prevents
>> release of the backing resources.  With my proposal it would not!  It
>> would only prevent release of the address space.
>
> The release of the address space is a requirement.
>
>>> GC is great for managing heap.  For everything else it's not a
>>> solution.
>>
>> Yet it's the only effective way to ensure that the address space is
>> unused before releasing it.
>>
>> The problem with an indirection approach is that it is inherently racy:
>>
>> Thread 1: read indirection field
>> Thread 2: clear indirection field
>> Thread 2: release buffer
>> Thread 2: create new buffer with same address
>> Thread 1: access different buffer than expected
>>
>> Even with the guard page it fails:
>>
>> Thread 1: access guard page
>> Thread 2: protect guard page
>> Thread 2: release buffer
>> Thread 2: create new buffer with same address
>> Thread 1: access different buffer than expected
>
> No, that's wrong.  We can't release the buffer until we clear the
> references which point to it.  Then thread 1 has no way to reach it.
>
>> You have to find a way to reserve the resource until we can be certain
>> that not only is it not reachable, but also no threads have cached a
>> reference to it.
>
> That's already done: we can't unmap the mapping until the next safepoint.

How would you hook into the safepoint to perform the unmapping?  You'd 
have to wait for all threads to arrive at safepoints, wouldn't you?

-- 
- DML


From aph at redhat.com  Wed Sep  9 13:17:31 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 9 Sep 2015 14:17:31 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F03087.1010604@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com>
Message-ID: <55F0316B.7010303@redhat.com>

On 09/09/2015 02:13 PM, David M. Lloyd wrote:
> How would you hook into the safepoint to perform the unmapping?  You'd 
> have to wait for all threads to arrive at safepoints, wouldn't you?

Yes.  That happens in the VM already, e.g. when we need to revoke the
bias of a lock.  It's a well-established mechanism.

Andrew.



From david.lloyd at redhat.com  Wed Sep  9 13:55:04 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 09 Sep 2015 08:55:04 -0500
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F0316B.7010303@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>	<55F02911.9030504@redhat.com>
	<55F02AEB.80101@redhat.com>	<55F02D05.2050509@redhat.com>
	<55F02EE0.4040901@redhat.com>	<55F03087.1010604@redhat.com>
	<55F0316B.7010303@redhat.com>
Message-ID: <55F03A38.1070604@redhat.com>

On 09/09/2015 08:17 AM, Andrew Haley wrote:
> On 09/09/2015 02:13 PM, David M. Lloyd wrote:
>> How would you hook into the safepoint to perform the unmapping?  You'd
>> have to wait for all threads to arrive at safepoints, wouldn't you?
>
> Yes.  That happens in the VM already, e.g. when we need to revoke the
> bias of a lock.  It's a well-established mechanism.

Could you extend the technique to other native resources as well?
-- 
- DML


From aph at redhat.com  Wed Sep  9 14:01:13 2015
From: aph at redhat.com (Andrew Haley)
Date: Wed, 9 Sep 2015 15:01:13 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F03A38.1070604@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com>
Message-ID: <55F03BA9.20304@redhat.com>

On 09/09/2015 02:55 PM, David M. Lloyd wrote:
> On 09/09/2015 08:17 AM, Andrew Haley wrote:
>> On 09/09/2015 02:13 PM, David M. Lloyd wrote:
>>> How would you hook into the safepoint to perform the unmapping?  You'd
>>> have to wait for all threads to arrive at safepoints, wouldn't you?
>>
>> Yes.  That happens in the VM already, e.g. when we need to revoke the
>> bias of a lock.  It's a well-established mechanism.
> 
> Could you extend the technique to other native resources as well?

Yes, but of course there will be some back-pressure from HotSpot
developers: it requires changes to the VM, and you have to be
extremely careful not to cause a deadlock.

Andrew.


From peter.levart at gmail.com  Wed Sep  9 14:21:36 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 9 Sep 2015 16:21:36 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
Message-ID: <55F04070.1030006@gmail.com>

Hi Uwe,

As I thought, the problem for some seems to be non-prompt unmapping of 
mapped address space held by otherwise unreachable mapped byte buffers. 
The mapped address space doesn't live in the Java heap and doesn't 
represent a heap memory pressure, so GC doesn't kick-in automatically 
when one would like. One could help by manually triggering GC with 
System.gc() in such situations. The problem is how to detect such 
situations. Direct byte buffers (ByteBuffer.allocateDirect) maintain a 
count of bytes currently allocated and don't allow allocation of native 
memory beyond certain configured limit (-XX:MaxDirectMemorySize=<size>). 
Before throwing OutOfMemoryError, the  ByteBuffer.allocateDirect() 
request tries it's best to free direct memory allocated by otherwise 
unreachable direct ByteBuffers (using System.gc() to trigger GC and 
helping process references).

Would similar approach - configured limit for FileChannel.map()ped 
address space be of any help to Lucene applications? Is it possible to 
estimate the max. amount of address space a particular Lucene 
application may need at any one time so that mapping over such limit 
could be considered an application error?

Regards, Peter

On 09/09/2015 12:51 PM, Uwe Schindler wrote:
> Hi,
>
> Dawid Weiss and I are both involved in the Apache Lucene project and we know the problems with MappedByteBuffer and unmapping. Dawid already responded with a source code link to our impl (which needs to use the hacky cleaner() approach; also look at the heavy documentation in this class): https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
>
> So we would be very happy to get this issue resolved! The cleaner() hack is enabled by default in Lucene if the JVM supports it (so we won't break if JIGSAW prevents this, but our *large* users would heavily complain).
>
>>> This is fundamentally about *integrity* of the runtime. It follows there
>>> are security implications, but it?s still fundamentally an integrity issue
>>> and guarding an unsafe operation with a Security Manager is
>>> unfortunately an insufficient solution.
>> Right, and just to add that there has been many attempts over the years
>> to find solutions to this issue. I think the closest was atomimcally
>> remapping but that wasn't feasible on all platforms and also didn't free
>> up the address space in a timely manner.
> So we should really find a solution here. I was talking with several people on various conferences (Rory O'Donnel or Mark Reinhold) and we had some ideas how to solve this. My idea how to solve this is explained below (I am not a JVM internals or Hotspot guy, so excuse some obviously "wrong" assumptions):
>
> Actually there are 2 issues, not only one. The first issue is, as mentioned before: you cannot unmap via API. This is needed for many apps, including Apache Lucene, for a reason which comes more from "another" bug, and this is my issue #2 (see below).
>
> First, unmapping for Lucene is very important at the moment, because we operate on the Lucene indexes purely using mmap (see [1]), which may be several hundreds of Gigabytes easily. On highly dynamic systems, Lucene often maps new files (also very largeones ) and relies on the fact, that older, deleted files are unmapped in time (this does not need to be ASAP, just "in time"). So we have those 2 "bugs", which force us to unmap:
>
> (1) disk space issues / delete after last close (POSIX) vs. No delete at all (Windows)
>
> - disk space: we have seen customers running out of disk space on Lucene, because unmapping wasn?t done in time and therefore POSIX with delete on last close cannot free the disk space, although the file was already deleted. The problem you are seeing on Windows that you cannot delete, is therefore worse on Linux, because it is hidden to the user - you cannot free the disk space of the deleted file! Lucene creates and deletes files all the time while indexing realtime data (e.g. think of Github's very dynamic code search index, which is backed by Lucene/Elasticsearch).
> - virtual memory: If you map huge files (several hundreds of Gigabytes) and they are not unmapped in time, you may run out of virtual address space. This especially affects Windows, because it does not use the full 46 bits (or like that) of addresses. So effectively you can only map like 4 Terabytes on Windows. If you have fragmentation of address space this gets worse (In Lucene, we map in chunks of 1 GiB because of the signed 32 bit integer limit of ByteBuffer, so fragmentation is not our biggest issue).
>
> (2) It takes veeeeeeeeeeeeeeeery long time until the unmapping actually occurs!
>
> This is the real bug! If the garbage collector would clean up the buffers asap, we would not need to unmap from user code. In Lucene we just delay the file delete on Windows, so we are not really affected by the file deletion inability (but that would be nice if it could be fixed).
>
> If you look at the usage pattern of those huge, mapped files, you will see why they are in most cases *never ever* unmapped automatically: Lucene maps very large files and uses them for longer time. So the MappedByteBuffer object gets migrated to older generations on the heap. Garbage collection there happens, of course, very delayed. That would not be the most problematic part, but there is a second issue: The MappedByteBuffer object is just a very small object (in heap size measurement: just an object header and a few pointers), so the garbage collector does not see it as heavy! It's just a very small like 30 bytes object instance. Why should the Garbage collector clean it up? And in fact it will almost never do this! The garbage collector cannot see that our 30 bytes object instance "sits" on something like 300 Gigabytes of virtual memory and disk space!
>
> One proposal to fix this would be to add something like an internal OpenJDK Java Annotation or similar where you can "mark" heavy objects, so Garbage collector could free them by preference (similar to sun.misc.Contended).
>
> For the Apache Lucene team,
> Uwe
>
> [1] http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html
>
> -----
> Uwe Schindler
> uschindler at apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
>



From volker.simonis at gmail.com  Wed Sep  9 14:24:48 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 9 Sep 2015 16:24:48 +0200
Subject: RFR 9: 8135094 : (process) java/lang/ProcessHandle/InfoTest fails
	testing commandLine()
In-Reply-To: <55EF5467.4070509@Oracle.com>
References: <55EF4ED2.2040209@Oracle.com>
	<55EF5467.4070509@Oracle.com>
Message-ID: <CA+3eh102tm=zeKJKc0Xsacrk5XSqA2cOYJ38AbDQxs4TRkxrtA@mail.gmail.com>

Hi Roger,

the change looks good.
Thanks for fixing this issue.

Regards,
Volker


On Tue, Sep 8, 2015 at 11:34 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Oops, Corrected links to webrev:
>
> On 9/8/2015 5:10 PM, Roger Riggs wrote:
>>
>> Please review this test fix.
>> The test assumes that the pathname of the command is literally the same as
>> the executable path provides to ProcessBuilder. However, if the path
>> contains
>> a symbolic link, it is resolved and the real path is reported as the
>> command.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs//webrev-info-8135094
>>
>> Issue:
>>    https://bugs.openjdk.java.net/browse/JDK-8135094
>>
>> Thanks, Roger
>>
>


From peter.levart at gmail.com  Wed Sep  9 14:45:46 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 9 Sep 2015 16:45:46 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F04070.1030006@gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F04070.1030006@gmail.com>
Message-ID: <55F0461A.2070005@gmail.com>



On 09/09/2015 04:21 PM, Peter Levart wrote:
> Hi Uwe,
>
> As I thought, the problem for some seems to be non-prompt unmapping of 
> mapped address space held by otherwise unreachable mapped byte 
> buffers. The mapped address space doesn't live in the Java heap and 
> doesn't represent a heap memory pressure, so GC doesn't kick-in 
> automatically when one would like. One could help by manually 
> triggering GC with System.gc() in such situations. The problem is how 
> to detect such situations. Direct byte buffers 
> (ByteBuffer.allocateDirect) maintain a count of bytes currently 
> allocated and don't allow allocation of native memory beyond certain 
> configured limit (-XX:MaxDirectMemorySize=<size>). Before throwing 
> OutOfMemoryError, the  ByteBuffer.allocateDirect() request tries it's 
> best to free direct memory allocated by otherwise unreachable direct 
> ByteBuffers (using System.gc() to trigger GC and helping process 
> references).
>
> Would similar approach - configured limit for FileChannel.map()ped 
> address space be of any help to Lucene applications? Is it possible to 
> estimate the max. amount of address space a particular Lucene 
> application may need at any one time so that mapping over such limit 
> could be considered an application error?

Perhaps the number of bytes mapped is not always a correct quantity to 
track. Maybe Lucene needs tracking the number of mapped regions or 
something else? I think it would be best to leave to the application to 
decide and implement the tracking and also triggering GC at times when 
it approaches the limit. All that is missing currently from 
MappedByteBuffer API for that purpose is a notification to the 
application after it has been unmapped.

Regards, Peter

>
> Regards, Peter
>
> On 09/09/2015 12:51 PM, Uwe Schindler wrote:
>> Hi,
>>
>> Dawid Weiss and I are both involved in the Apache Lucene project and 
>> we know the problems with MappedByteBuffer and unmapping. Dawid 
>> already responded with a source code link to our impl (which needs to 
>> use the hacky cleaner() approach; also look at the heavy 
>> documentation in this class): 
>> https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
>>
>> So we would be very happy to get this issue resolved! The cleaner() 
>> hack is enabled by default in Lucene if the JVM supports it (so we 
>> won't break if JIGSAW prevents this, but our *large* users would 
>> heavily complain).
>>
>>>> This is fundamentally about *integrity* of the runtime. It follows 
>>>> there
>>>> are security implications, but it?s still fundamentally an 
>>>> integrity issue
>>>> and guarding an unsafe operation with a Security Manager is
>>>> unfortunately an insufficient solution.
>>> Right, and just to add that there has been many attempts over the years
>>> to find solutions to this issue. I think the closest was atomimcally
>>> remapping but that wasn't feasible on all platforms and also didn't 
>>> free
>>> up the address space in a timely manner.
>> So we should really find a solution here. I was talking with several 
>> people on various conferences (Rory O'Donnel or Mark Reinhold) and we 
>> had some ideas how to solve this. My idea how to solve this is 
>> explained below (I am not a JVM internals or Hotspot guy, so excuse 
>> some obviously "wrong" assumptions):
>>
>> Actually there are 2 issues, not only one. The first issue is, as 
>> mentioned before: you cannot unmap via API. This is needed for many 
>> apps, including Apache Lucene, for a reason which comes more from 
>> "another" bug, and this is my issue #2 (see below).
>>
>> First, unmapping for Lucene is very important at the moment, because 
>> we operate on the Lucene indexes purely using mmap (see [1]), which 
>> may be several hundreds of Gigabytes easily. On highly dynamic 
>> systems, Lucene often maps new files (also very largeones ) and 
>> relies on the fact, that older, deleted files are unmapped in time 
>> (this does not need to be ASAP, just "in time"). So we have those 2 
>> "bugs", which force us to unmap:
>>
>> (1) disk space issues / delete after last close (POSIX) vs. No delete 
>> at all (Windows)
>>
>> - disk space: we have seen customers running out of disk space on 
>> Lucene, because unmapping wasn?t done in time and therefore POSIX 
>> with delete on last close cannot free the disk space, although the 
>> file was already deleted. The problem you are seeing on Windows that 
>> you cannot delete, is therefore worse on Linux, because it is hidden 
>> to the user - you cannot free the disk space of the deleted file! 
>> Lucene creates and deletes files all the time while indexing realtime 
>> data (e.g. think of Github's very dynamic code search index, which is 
>> backed by Lucene/Elasticsearch).
>> - virtual memory: If you map huge files (several hundreds of 
>> Gigabytes) and they are not unmapped in time, you may run out of 
>> virtual address space. This especially affects Windows, because it 
>> does not use the full 46 bits (or like that) of addresses. So 
>> effectively you can only map like 4 Terabytes on Windows. If you have 
>> fragmentation of address space this gets worse (In Lucene, we map in 
>> chunks of 1 GiB because of the signed 32 bit integer limit of 
>> ByteBuffer, so fragmentation is not our biggest issue).
>>
>> (2) It takes veeeeeeeeeeeeeeeery long time until the unmapping 
>> actually occurs!
>>
>> This is the real bug! If the garbage collector would clean up the 
>> buffers asap, we would not need to unmap from user code. In Lucene we 
>> just delay the file delete on Windows, so we are not really affected 
>> by the file deletion inability (but that would be nice if it could be 
>> fixed).
>>
>> If you look at the usage pattern of those huge, mapped files, you 
>> will see why they are in most cases *never ever* unmapped 
>> automatically: Lucene maps very large files and uses them for longer 
>> time. So the MappedByteBuffer object gets migrated to older 
>> generations on the heap. Garbage collection there happens, of course, 
>> very delayed. That would not be the most problematic part, but there 
>> is a second issue: The MappedByteBuffer object is just a very small 
>> object (in heap size measurement: just an object header and a few 
>> pointers), so the garbage collector does not see it as heavy! It's 
>> just a very small like 30 bytes object instance. Why should the 
>> Garbage collector clean it up? And in fact it will almost never do 
>> this! The garbage collector cannot see that our 30 bytes object 
>> instance "sits" on something like 300 Gigabytes of virtual memory and 
>> disk space!
>>
>> One proposal to fix this would be to add something like an internal 
>> OpenJDK Java Annotation or similar where you can "mark" heavy 
>> objects, so Garbage collector could free them by preference (similar 
>> to sun.misc.Contended).
>>
>> For the Apache Lucene team,
>> Uwe
>>
>> [1] 
>> http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html
>>
>> -----
>> Uwe Schindler
>> uschindler at apache.org
>> ASF Member, Apache Lucene PMC / Committer
>> Bremen, Germany
>> http://lucene.apache.org/
>>
>>
>



From dawid.weiss at gmail.com  Wed Sep  9 14:56:07 2015
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Wed, 9 Sep 2015 16:56:07 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F0461A.2070005@gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F04070.1030006@gmail.com> <55F0461A.2070005@gmail.com>
Message-ID: <CAM21Rt9gFwZFxwRiAP16AR7gakc4_rDcZUNmdHr98uVYFwJJ1Q@mail.gmail.com>

> I think it would be best to leave to the application to decide and
> implement the tracking and also triggering GC at times when it approaches
> the limit.

I disagree. The GC -- when and how it is triggered -- should be
transparent to the application. We don't want to manage GC, we want to
(truly) release the resources we allocated (and we know when they are
no longer needed).

What you suggest is essentially managing GC from application level. I
don't think it's the right approach to solve the problem.

Dawid


From vyom.tewari at oracle.com  Wed Sep  9 15:23:27 2015
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Wed, 9 Sep 2015 20:53:27 +0530
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55EEDD16.7010805@oracle.com>
References: <55ED585F.9060005@oracle.com> <55ED646F.7020607@oracle.com>
	<55ED8C35.9000208@oracle.com> <55ED9141.9090703@oracle.com>
	<55EDBE55.5020606@oracle.com>
	<DEBDFEEA-FA3C-4C10-8868-D9244D4D4803@oracle.com>
	<55EEDD16.7010805@oracle.com>
Message-ID: <55F04EEF.5020309@oracle.com>

Hi Mark,

Is it OK to go ahead with the patch as it is, or you are expecting any 
additional modification is required ?.

Thanks,
Vyom


On 9/8/2015 6:35 PM, Mark Sheppard wrote:
> that's true, the documentation is a bit nebulous on this issue.
> but the inference is that the file descriptors are indeterminate state.
> some older man pages allude to this
>
> as per solaris man pages, close will
> " If close() is interrupted by a signal that is to be caught,
> it  will return  -1  with errno set to EINTR and the state of fildes 
> is unspecified"
>
> if dup2(s, fd) is viewed as a combination of close(fd) and fcntl (s, 
> F_DUP2FD, fd), and close is not restartable
> then similar semantics could be inferred for dup2 in a EINTR scenario?
> presume that subsequent call in the RESTARTABLE loop  will return 
> another error.
>
>
>
>
> On 08/09/2015 09:28, Chris Hegarty wrote:
>> On 7 Sep 2015, at 17:41, Mark Sheppard <mark.sheppard at oracle.com> wrote:
>>
>>> a couple of other considerations in the context of this issue perhaps?
>>>
>>> in this s is being duped onto fd, and part of the dup2 operation is 
>>> the closing of fd, but
>>> what's is the expected state of file descriptor fd in the event of a 
>>> dup2 failure?
>> I?m not sure that the documentation for dup2 gives us enough detail 
>> here. The only situation I can see where fd would not be closed is 
>> when EBADF is returned. Should not be an issue here.
>>
>>> s is closed in any case, but what about fd, should it be attended to 
>>> if dup2 < 0
>>> and closed ? is it still considered a valid fd?
>>>
>>> what can be said about the state of the encapsulating FileDescriptor 
>>> associated with fd?
>>> at this stage can it still be considered valid?
>>> should valid() return false?
>> Probably, but may not be worth bothering with unless there are 
>> operations that can access it after this method throws.
>>
>> -Chris.
>>
>>> regards
>>> Mark
>>>
>>> On 07/09/2015 14:29, Ivan Gerasimov wrote:
>>>> Thanks!
>>>>
>>>> It looks good to me now.
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>> On 07.09.2015 16:08, Vyom Tewari wrote:
>>>>> Hi All,
>>>>>
>>>>> Please find the latest diff, which contains the  latest fix.
>>>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/
>>>>>
>>>>> Thanks,
>>>>> Vyom
>>>>>
>>>>>
>>>>> On 9/7/2015 3:48 PM, Alan Bateman wrote:
>>>>>> On 07/09/2015 10:26, Vyom Tewari wrote:
>>>>>>> Hi everyone,
>>>>>>> Can you please review my changes for below bug.
>>>>>>>
>>>>>>> Bug:
>>>>>>>      JDK-8080402 : File Leak in 
>>>>>>> jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/
>>>>>>>
>>>>>>> This change ensure that if close() fails we throw correct io 
>>>>>>> exception and there is no file leak.
>>>>>> close isn't restartable so I think we need to look at that while 
>>>>>> we are here.
>>>>>>
>>>>>> -Alan.
>>>>>
>



From peter.levart at gmail.com  Wed Sep  9 15:46:15 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 9 Sep 2015 17:46:15 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CAM21Rt9gFwZFxwRiAP16AR7gakc4_rDcZUNmdHr98uVYFwJJ1Q@mail.gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F04070.1030006@gmail.com> <55F0461A.2070005@gmail.com>
	<CAM21Rt9gFwZFxwRiAP16AR7gakc4_rDcZUNmdHr98uVYFwJJ1Q@mail.gmail.com>
Message-ID: <55F05447.1040107@gmail.com>



On 09/09/2015 04:56 PM, Dawid Weiss wrote:
>> I think it would be best to leave to the application to decide and
>> implement the tracking and also triggering GC at times when it approaches
>> the limit.
> I disagree. The GC -- when and how it is triggered -- should be
> transparent to the application. We don't want to manage GC, we want to
> (truly) release the resources we allocated (and we know when they are
> no longer needed).
>
> What you suggest is essentially managing GC from application level. I
> don't think it's the right approach to solve the problem.
>
> Dawid

Hi Dawid,

By wanting to truly release the resources you allocated, you are 
essentially wanting to manage the resources yourself. If you are willing 
to track the active mapped byte buffers manually yourself, then what 
about the following idea:

- you track the number of mapped buffers (or mapped address space) that 
you "know" is active in the application manually.
- you track the number of mapped buffers (or mapped address space) that 
is actually mapped at a particular time (by utilizing an after-unmap 
call-back that would have to be added to MappedByteBuffer API)
- when the difference of those two tracked quantities reaches certain 
amount or percentage, you give a kick to GC to do it's job, as it is 
lagging behind.

I would not call this managing GC, but just hinting GC at the right 
time. The most burden in this approach would be the manual tracking of 
active buffers, but you are willing to do that anyway by wanting to 
manually release the resources. Everything else can be made automatic.


Regards, Peter



From volker.simonis at gmail.com  Wed Sep  9 15:46:35 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 9 Sep 2015 17:46:35 +0200
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
In-Reply-To: <55EF548E.2060601@Oracle.com>
References: <55EF4E51.2030506@Oracle.com>
	<55EF548E.2060601@Oracle.com>
Message-ID: <CA+3eh13kWTrmwoOpt3gQgV8iqkOqMirn0o6hJp+pgWGGD_K-Cg@mail.gmail.com>

Hi Roger,

I think your change looks good and it surely improves the test
stability but I don't think it solves the problem in all cases.

I think this problem is caused by a <defunct> (i.e. "zombie") process
(the spawned process lived too short and was already a zombie when the
info object was created). If you look at the proc-file system entry of
a <defunct> process you can see that its 'cmdline' file has zero size
and the file is owned by root. This is exactly what is reported by the
corresponding info object in the bug report (user=root and no cmd
field).

We may need to improve the way how we get the uid of a pid on Linux.
The current way of querying the owner of /proc/<pid>/cmdline seems to
be unreliable. We may instead take the owner of /proc/<pid> which
seems to be still the initial user of the process.

Regards,
Volker


On Tue, Sep 8, 2015 at 11:35 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> With link to webrev corrected:
>
> On 9/8/2015 5:08 PM, Roger Riggs wrote:
>>
>> Please review an intermittent test bug fix.
>> The test setup time is very short and the user may be returned as 0 which
>> is reported as root.
>> The correction lengthens the time allowed for the process to start.
>>
>> The test is removed from the ProblemList.
>>
>> Webrev:
>>    http://cr.openjdk.java.net/~rriggs//webrev-info-8133552
>>
>> Bug:
>>   https://bugs.openjdk.java.net/browse/JDK-8133552
>>
>> Thanks, Roger
>>
>


From mark.sheppard at oracle.com  Wed Sep  9 15:54:13 2015
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 9 Sep 2015 16:54:13 +0100
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55F04EEF.5020309@oracle.com>
References: <55ED585F.9060005@oracle.com> <55ED646F.7020607@oracle.com>
	<55ED8C35.9000208@oracle.com> <55ED9141.9090703@oracle.com>
	<55EDBE55.5020606@oracle.com>
	<DEBDFEEA-FA3C-4C10-8868-D9244D4D4803@oracle.com>
	<55EEDD16.7010805@oracle.com> <55F04EEF.5020309@oracle.com>
Message-ID: <55F05625.703@oracle.com>

Hi Vyom,
     yes, I believe the consensus is to proceed with the changes.

regards
Mark

On 09/09/2015 16:23, Vyom Tewari wrote:
> Hi Mark,
>
> Is it OK to go ahead with the patch as it is, or you are expecting any 
> additional modification is required ?.
>
> Thanks,
> Vyom
>
>
> On 9/8/2015 6:35 PM, Mark Sheppard wrote:
>> that's true, the documentation is a bit nebulous on this issue.
>> but the inference is that the file descriptors are indeterminate state.
>> some older man pages allude to this
>>
>> as per solaris man pages, close will
>> " If close() is interrupted by a signal that is to be caught,
>> it  will return  -1  with errno set to EINTR and the state of fildes 
>> is unspecified"
>>
>> if dup2(s, fd) is viewed as a combination of close(fd) and fcntl (s, 
>> F_DUP2FD, fd), and close is not restartable
>> then similar semantics could be inferred for dup2 in a EINTR scenario?
>> presume that subsequent call in the RESTARTABLE loop  will return 
>> another error.
>>
>>
>>
>>
>> On 08/09/2015 09:28, Chris Hegarty wrote:
>>> On 7 Sep 2015, at 17:41, Mark Sheppard <mark.sheppard at oracle.com> 
>>> wrote:
>>>
>>>> a couple of other considerations in the context of this issue perhaps?
>>>>
>>>> in this s is being duped onto fd, and part of the dup2 operation is 
>>>> the closing of fd, but
>>>> what's is the expected state of file descriptor fd in the event of 
>>>> a dup2 failure?
>>> I?m not sure that the documentation for dup2 gives us enough detail 
>>> here. The only situation I can see where fd would not be closed is 
>>> when EBADF is returned. Should not be an issue here.
>>>
>>>> s is closed in any case, but what about fd, should it be attended 
>>>> to if dup2 < 0
>>>> and closed ? is it still considered a valid fd?
>>>>
>>>> what can be said about the state of the encapsulating 
>>>> FileDescriptor associated with fd?
>>>> at this stage can it still be considered valid?
>>>> should valid() return false?
>>> Probably, but may not be worth bothering with unless there are 
>>> operations that can access it after this method throws.
>>>
>>> -Chris.
>>>
>>>> regards
>>>> Mark
>>>>
>>>> On 07/09/2015 14:29, Ivan Gerasimov wrote:
>>>>> Thanks!
>>>>>
>>>>> It looks good to me now.
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>> On 07.09.2015 16:08, Vyom Tewari wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Please find the latest diff, which contains the  latest fix.
>>>>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/
>>>>>>
>>>>>> Thanks,
>>>>>> Vyom
>>>>>>
>>>>>>
>>>>>> On 9/7/2015 3:48 PM, Alan Bateman wrote:
>>>>>>> On 07/09/2015 10:26, Vyom Tewari wrote:
>>>>>>>> Hi everyone,
>>>>>>>> Can you please review my changes for below bug.
>>>>>>>>
>>>>>>>> Bug:
>>>>>>>>      JDK-8080402 : File Leak in 
>>>>>>>> jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/
>>>>>>>>
>>>>>>>> This change ensure that if close() fails we throw correct io 
>>>>>>>> exception and there is no file leak.
>>>>>>> close isn't restartable so I think we need to look at that while 
>>>>>>> we are here.
>>>>>>>
>>>>>>> -Alan.
>>>>>>
>>
>



From uschindler at apache.org  Wed Sep  9 15:58:06 2015
From: uschindler at apache.org (Uwe Schindler)
Date: Wed, 9 Sep 2015 17:58:06 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F04070.1030006@gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F04070.1030006@gmail.com>
Message-ID: <03f101d0eb18$53740800$fa5c1800$@apache.org>

Hi,

> As I thought, the problem for some seems to be non-prompt unmapping of
> mapped address space held by otherwise unreachable mapped byte buffers.
> The mapped address space doesn't live in the Java heap and doesn't
> represent a heap memory pressure, so GC doesn't kick-in automatically
> when one would like. One could help by manually triggering GC with
> System.gc() in such situations. The problem is how to detect such situations.

Unfortunately, System#gc() is explicitely disallowed in most environments (because it performs a full GC): You should not use explicit GCs, because this hurts low-latency applications like search engines. So disabling explicit GCs should be done for such installations, e.g. external libraries tend to call System#gc() for no reason...

> Direct byte buffers (ByteBuffer.allocateDirect) maintain a count of bytes
> currently allocated and don't allow allocation of native memory beyond
> certain configured limit (-XX:MaxDirectMemorySize=<size>).
> Before throwing OutOfMemoryError, the  ByteBuffer.allocateDirect()
> request tries it's best to free direct memory allocated by otherwise
> unreachable direct ByteBuffers (using System.gc() to trigger GC and helping
> process references).

This code breaks if you disallow explicit GC. As Dawid says, I don't think the application should take care about GC.

> Would similar approach - configured limit for FileChannel.map()ped address
> space be of any help to Lucene applications? Is it possible to estimate the
> max. amount of address space a particular Lucene application may need at
> any one time so that mapping over such limit could be considered an
> application error?

This does not scale with index sizes going into the hundreds of Gigabytes. We cannot force the users to calculate their index size before using it and set corresponding JVM settings.

Uwe

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/





From dawid.weiss at gmail.com  Wed Sep  9 16:03:34 2015
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Wed, 9 Sep 2015 18:03:34 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F05447.1040107@gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F04070.1030006@gmail.com> <55F0461A.2070005@gmail.com>
	<CAM21Rt9gFwZFxwRiAP16AR7gakc4_rDcZUNmdHr98uVYFwJJ1Q@mail.gmail.com>
	<55F05447.1040107@gmail.com>
Message-ID: <CAM21Rt-JJn=LpKC4hyq-yhoY7tWOHKbL=HONqnvu9Nq1CdnT_g@mail.gmail.com>

> - you track the number of mapped buffers (or mapped address space) that you
> "know" is active in the application manually.

The problem is you really can't do it on a global, JVM-scale, Peter.
It's enough that the same JVM process starts two isolated class
loaders with Lucene in each and such accounting is no longer
correct... There are also other valid reasons (the ones Uwe mentioned)
which make explicit System.gc() a non-viable option.

Dawid


From uschindler at apache.org  Wed Sep  9 16:22:04 2015
From: uschindler at apache.org (Uwe Schindler)
Date: Wed, 9 Sep 2015 18:22:04 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F04070.1030006@gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F04070.1030006@gmail.com>
Message-ID: <03f801d0eb1b$ac3149a0$0493dce0$@apache.org>

Hi,

> As I thought, the problem for some seems to be non-prompt unmapping of
> mapped address space held by otherwise unreachable mapped byte buffers.
> The mapped address space doesn't live in the Java heap and doesn't
> represent a heap memory pressure, so GC doesn't kick-in automatically
> when one would like. One could help by manually triggering GC with
> System.gc() in such situations. The problem is how to detect such situations.
> Direct byte buffers (ByteBuffer.allocateDirect) maintain a count of bytes
> currently allocated and don't allow allocation of native memory beyond
> certain configured limit (-XX:MaxDirectMemorySize=<size>).
> Before throwing OutOfMemoryError, the  ByteBuffer.allocateDirect()
> request tries it's best to free direct memory allocated by otherwise
> unreachable direct ByteBuffers (using System.gc() to trigger GC and helping
> process references).

FileChannel#map does the same (it tries to map, catches OOM, waits a second and tries again). But as described in my earlier mail this does not work as expected in newer GC implementations - this is why we see the issues like a JVM running for a week or longer without any full GC and then sitting on a Terabyte of address/diskspace space before getting unuseable. System#gc() is ignored in most environments, because it causes more havoc (full pauses) - especially if a full GC is otherwise rarely needed. I think this crazy try-catch-sleep-retry code should better be removed from FileChannel#map once the GC algorithms are fixed to take care of the heaviness of MappedByteBuffer (my proposal, the Annotation @sun.misc.Heavy...) and free it earlier.

In addition, I think Andrew Haley made some good comments about opportunities how to solve the problem.

Uwe



From volker.simonis at gmail.com  Wed Sep  9 16:36:53 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 9 Sep 2015 18:36:53 +0200
Subject: RFR(XXS): 8135271: Add missing "-client IGNORE" to jvm.cfg file for
	ppc64
Message-ID: <CA+3eh12yuow+GzDMCvVbjAZ+8ZjYpKzXkxW30TcR-zxkJxn5bg@mail.gmail.com>

Hi,

can somebody please review this trivial fix which simply adds the
missing "-client IGNORE" to jvm.cfg file for ppc64 to avoid test
failures when running the regression tests:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8135271/
https://bugs.openjdk.java.net/browse/JDK-8135271

Thank you and best regards,
Volker


From forax at univ-mlv.fr  Wed Sep  9 16:46:13 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 9 Sep 2015 18:46:13 +0200 (CEST)
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F0316B.7010303@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
Message-ID: <1399854042.1293842.1441817173796.JavaMail.zimbra@u-pem.fr>

MutableCallSite.setTarget() also works that way in Hotspot, it goes to a safe point to trash all assembly codes generated from methods that use an invokedynamic that uses the target of the callsite.

R?mi

----- Mail original -----
> De: "Andrew Haley" <aph at redhat.com>
> ?: core-libs-dev at openjdk.java.net
> Envoy?: Mercredi 9 Septembre 2015 15:17:31
> Objet: Re: Suggested fix for JDK-4724038 (Add unmap method to	MappedByteBuffer)
> 
> On 09/09/2015 02:13 PM, David M. Lloyd wrote:
> > How would you hook into the safepoint to perform the unmapping?  You'd
> > have to wait for all threads to arrive at safepoints, wouldn't you?
> 
> Yes.  That happens in the VM already, e.g. when we need to revoke the
> bias of a lock.  It's a well-established mechanism.
> 
> Andrew.
> 
> 


From daniel.fuchs at oracle.com  Wed Sep  9 16:49:41 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 9 Sep 2015 18:49:41 +0200
Subject: RFR 8080402: File Leak in
	jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
In-Reply-To: <55F05625.703@oracle.com>
References: <55ED585F.9060005@oracle.com> <55ED646F.7020607@oracle.com>
	<55ED8C35.9000208@oracle.com> <55ED9141.9090703@oracle.com>
	<55EDBE55.5020606@oracle.com>
	<DEBDFEEA-FA3C-4C10-8868-D9244D4D4803@oracle.com>
	<55EEDD16.7010805@oracle.com> <55F04EEF.5020309@oracle.com>
	<55F05625.703@oracle.com>
Message-ID: <55F06325.7010609@oracle.com>

On 09/09/15 17:54, Mark Sheppard wrote:
> Hi Vyom,
>      yes, I believe the consensus is to proceed with the changes.

OK - I will be pushing them then.

best regards,

-- daniel

>
> regards
> Mark
>
> On 09/09/2015 16:23, Vyom Tewari wrote:
>> Hi Mark,
>>
>> Is it OK to go ahead with the patch as it is, or you are expecting any
>> additional modification is required ?.
>>
>> Thanks,
>> Vyom
>>
>>
>> On 9/8/2015 6:35 PM, Mark Sheppard wrote:
>>> that's true, the documentation is a bit nebulous on this issue.
>>> but the inference is that the file descriptors are indeterminate state.
>>> some older man pages allude to this
>>>
>>> as per solaris man pages, close will
>>> " If close() is interrupted by a signal that is to be caught,
>>> it  will return  -1  with errno set to EINTR and the state of fildes
>>> is unspecified"
>>>
>>> if dup2(s, fd) is viewed as a combination of close(fd) and fcntl (s,
>>> F_DUP2FD, fd), and close is not restartable
>>> then similar semantics could be inferred for dup2 in a EINTR scenario?
>>> presume that subsequent call in the RESTARTABLE loop  will return
>>> another error.
>>>
>>>
>>>
>>>
>>> On 08/09/2015 09:28, Chris Hegarty wrote:
>>>> On 7 Sep 2015, at 17:41, Mark Sheppard <mark.sheppard at oracle.com>
>>>> wrote:
>>>>
>>>>> a couple of other considerations in the context of this issue perhaps?
>>>>>
>>>>> in this s is being duped onto fd, and part of the dup2 operation is
>>>>> the closing of fd, but
>>>>> what's is the expected state of file descriptor fd in the event of
>>>>> a dup2 failure?
>>>> I?m not sure that the documentation for dup2 gives us enough detail
>>>> here. The only situation I can see where fd would not be closed is
>>>> when EBADF is returned. Should not be an issue here.
>>>>
>>>>> s is closed in any case, but what about fd, should it be attended
>>>>> to if dup2 < 0
>>>>> and closed ? is it still considered a valid fd?
>>>>>
>>>>> what can be said about the state of the encapsulating
>>>>> FileDescriptor associated with fd?
>>>>> at this stage can it still be considered valid?
>>>>> should valid() return false?
>>>> Probably, but may not be worth bothering with unless there are
>>>> operations that can access it after this method throws.
>>>>
>>>> -Chris.
>>>>
>>>>> regards
>>>>> Mark
>>>>>
>>>>> On 07/09/2015 14:29, Ivan Gerasimov wrote:
>>>>>> Thanks!
>>>>>>
>>>>>> It looks good to me now.
>>>>>>
>>>>>> Sincerely yours,
>>>>>> Ivan
>>>>>>
>>>>>> On 07.09.2015 16:08, Vyom Tewari wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Please find the latest diff, which contains the  latest fix.
>>>>>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vyom
>>>>>>>
>>>>>>>
>>>>>>> On 9/7/2015 3:48 PM, Alan Bateman wrote:
>>>>>>>> On 07/09/2015 10:26, Vyom Tewari wrote:
>>>>>>>>> Hi everyone,
>>>>>>>>> Can you please review my changes for below bug.
>>>>>>>>>
>>>>>>>>> Bug:
>>>>>>>>>      JDK-8080402 : File Leak in
>>>>>>>>> jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/
>>>>>>>>>
>>>>>>>>> This change ensure that if close() fails we throw correct io
>>>>>>>>> exception and there is no file leak.
>>>>>>>> close isn't restartable so I think we need to look at that while
>>>>>>>> we are here.
>>>>>>>>
>>>>>>>> -Alan.
>>>>>>>
>>>
>>
>



From forax at univ-mlv.fr  Wed Sep  9 16:54:47 2015
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 9 Sep 2015 18:54:47 +0200 (CEST)
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55EF6319.6080609@gmail.com>
References: <CA+w+GKQSkijaJfApMwRTXRtHf+4b+=bshmFvHx6YpoR+xL-W+w@mail.gmail.com>
	<8BAB6B4F-ACD6-492A-983F-953EDB03DDD9@oracle.com>
	<55EEAAB8.1000004@redhat.com>
	<73CB5B94-B817-4333-87E8-89E9A2110199@oracle.com>
	<55EEDD0D.6070302@redhat.com> <55EEE2B5.5070800@redhat.com>
	<1661851856.943842.1441739742409.JavaMail.zimbra@u-pem.fr>
	<55EF6319.6080609@gmail.com>
Message-ID: <2025857678.1295620.1441817687693.JavaMail.zimbra@u-pem.fr>

Hi Peter, 
the problem of your approach is that you rely on the GC and as the others have said, 
usually a MappedByteBuffer is used a long time so it goes to a region that is not clean frequently by the GC (if cleaned at all) 
so it requires a FullGC, and there is no real way to ask for a FullGC in Java. 

so either as Andew has suggested, unmap asks the VM to go to a safepoint or 
unmap is asynchronous and ask the VM to do the unmapping/page protect trick at the next safepoint and we need a special call to be able 
to wait for the ummaping to happen in the thread that want to do a file.delete(). 

R?mi 

----- Mail original -----

> De: "Peter Levart" <peter.levart at gmail.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>, "Andrew Haley" <aph at redhat.com>
> Cc: core-libs-dev at openjdk.java.net
> Envoy?: Mercredi 9 Septembre 2015 00:37:13
> Objet: Re: Suggested fix for JDK-4724038 (Add unmap method to
> MappedByteBuffer)

> On 09/08/2015 09:15 PM, Remi Forax wrote:

> > On 09/08/2015 03:29 PM, Andrew Haley wrote:
> 

> > > On 09/08/2015 02:05 PM, Andrew Haley wrote:
> > 
> 

> > > > I don't think you'd actually need to unmap anything until a safepoint.
> > > 
> > 
> 
> > > > I don't think that the speed of unmapping is critical as long as it
> > > 
> > 
> 
> > > > happens "soon".
> > > 
> > 
> 

> > > Although given the desire to do
> > 
> 

> > > buffer.unmap();
> > 
> 
> > > file.delete();
> > 
> 

> > > that belief may be misplaced.  We could just block for a safepoint;
> > 
> 
> > > we already do that in other cases, and there's no guarantee about how
> > 
> 
> > > long unmap() would take to execute.
> > 
> 

> > > Andrew.
> > 
> 

> > I think a simple way to solve that is to ask for a safepoint explicitly,
> 

> > buffer.unmap();
> 
> > waitUntilUnmapped();
> 
> > file.delete();
> 

> > R?mi
> 

> Hi,

> The following can already be performed today:

> buffer = null;
> waitUntilUnmapped();
> file.delete();

> The tricky part is how to do waitUntilUnmapped() and maybe even help
> ReferenceHandler thread and/or trigger reference processing while waiting.
> Here's an example that executes an asynchronous callback after the memory
> has been unmapped:

> http://cr.openjdk.java.net/~plevart/jdk9-dev/4724038_MappedByteBuffer_afterRelease/webrev.01/

> The test shows how one could delete the file after it has been unmapped (if
> the byte buffer was the only mapping).

> Would such notification be enough to cover the use cases? What are the use
> cases one would like to cover with hypothetical unmap() was it available?

> Regards, Peter

> > ----- Mail original -----
> 

> > > De: "Andrew Haley" <aph at redhat.com> ?: core-libs-dev at openjdk.java.net
> > > Envoy?:
> > > Mardi 8 Septembre 2015 15:29:25
> > 
> 
> > > Objet: Re: Suggested fix for JDK-4724038 (Add unmap method to
> > > 	MappedByteBuffer)
> > 
> 

> > > On 09/08/2015 02:05 PM, Andrew Haley wrote:
> > 
> 

> > > > I don't think you'd actually need to unmap anything until a safepoint.
> > > 
> > 
> 
> > > > I don't think that the speed of unmapping is critical as long as it
> > > 
> > 
> 
> > > > happens "soon".
> > > 
> > 
> 

> > > Although given the desire to do
> > 
> 

> > > buffer.unmap();
> > 
> 
> > > file.delete();
> > 
> 

> > > that belief may be misplaced.  We could just block for a safepoint;
> > 
> 
> > > we already do that in other cases, and there's no guarantee about how
> > 
> 
> > > long unmap() would take to execute.
> > 
> 

> > > Andrew.
> > 
> 


From daniel.fuchs at oracle.com  Wed Sep  9 16:55:51 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 9 Sep 2015 18:55:51 +0200
Subject: RFR: 8033661: readConfiguration does not cleanly reinitialize the
	logging system
Message-ID: <55F06497.5010300@oracle.com>

Hi,

Please find below a candidate fix for:

8033661: readConfiguration does not cleanly reinitialize the
          logging system
https://bugs.openjdk.java.net/browse/JDK-8033661

http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.00/

LogManager.readConfiguration() presents a number of flaws that may not
be fixable without endangering backward compatibility, or stability.
Some of them have been quite aptly summed up in JDK-8033661.

One of the main issue with readConfiguration() is that it calls reset().
This means that there's no way we can look at the previous
configuration and next configuration and close only those handlers
that the new configuration does not keep, leaving the others
unchanged.

I have tried experimenting with adding a per-logger
'handlersInitialized' flag, so that handlers could be created on-demand
when a logger first accesses them - as the root logger does, but rapidly
abandoned this idea due to the complexity of avoiding race conditions
and potential deadlocks.

There are also more complex cases that the current
readConfiguration() doen't take into account: when a new logger
is created by user/library code, the configuration is looked up and
any intermediate logger for which there is a configuration (level,
handler, useParentHandler) is created: this is done by
processParentHandler()).
However, readConfiguration() does not ensure that this also
happens for existing loggers: if a configuration (e.g a level,
or a handler) appears in the new configuration, for the parent of
an existing logger, but that parent does not exist yet - then this
piece of configuration will be ignored until the parent is created
explicitly by application/library code, which might be never.
This leaves the logger tree in an inconsistent state with regard to
the configuration loaded.

It seems that to fix that - we should call processParentHandler() on
all existing loggers.

I have the feeling that trying to fix all of this in
readConfiguration() could be dangerous WRT to the assumptions
that already existing code that calls readConfiguration()
may have on what readConfiguration() actually does.
If we wanted to fix readConfiguration() we therefore might need to
introduce yet another opt-in/opt-out flag for the new behavior.

All this leads to propose a more prudent approach.
I'm proposing to leave readConfiguration() unchanged, and instead
introduce a new updateConfiguration() method that would make it
possible to give more control to the caller on how the old and
new configuration should be merged.
The new updateConfiguration() method would take a
remapper function, allowing the caller to control how the old and
new configuration are going to be merged into a resulting configuration.
The method would ensure that loggers are properly initialized, given
the difference between their old & resulting configuration, calling
processParentHandlers when necessary.

The new method has the advantage that it would not call reset(), as
readConfiguration() did.
So if a logger has an identical configuration in the old & new conf,
it doesn't need to be changed at all. Its handlers don't need to be
closed and reopened - they can just be left alone.

The problems exhibited by JDK-8033661 could then be solved by
calling updateConfiguration() with a remapper function that,
for a given property 'p' with old value 'o' and new value 'n'
always return the new value 'n':

    manager.updateConfiguration((p) -> ((o,n) -> n));

comments welcomed,

-- daniel



From Roger.Riggs at Oracle.com  Wed Sep  9 16:56:30 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 9 Sep 2015 12:56:30 -0400
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
In-Reply-To: <CA+3eh13kWTrmwoOpt3gQgV8iqkOqMirn0o6hJp+pgWGGD_K-Cg@mail.gmail.com>
References: <55EF4E51.2030506@Oracle.com> <55EF548E.2060601@Oracle.com>
	<CA+3eh13kWTrmwoOpt3gQgV8iqkOqMirn0o6hJp+pgWGGD_K-Cg@mail.gmail.com>
Message-ID: <55F064BE.1050401@Oracle.com>

Hi Volker,

Thanks for the review and diagnosis.

Can opening /proc/pid be used as a fallback if the st_uid is zero or
is it worth the overhead of stat'ing /proc/pid always?

Thanks, Roger


On 9/9/2015 11:46 AM, Volker Simonis wrote:
> Hi Roger,
>
> I think your change looks good and it surely improves the test
> stability but I don't think it solves the problem in all cases.
>
> I think this problem is caused by a <defunct> (i.e. "zombie") process
> (the spawned process lived too short and was already a zombie when the
> info object was created). If you look at the proc-file system entry of
> a <defunct> process you can see that its 'cmdline' file has zero size
> and the file is owned by root. This is exactly what is reported by the
> corresponding info object in the bug report (user=root and no cmd
> field).
>
> We may need to improve the way how we get the uid of a pid on Linux.
> The current way of querying the owner of /proc/<pid>/cmdline seems to
> be unreliable. We may instead take the owner of /proc/<pid> which
> seems to be still the initial user of the process.
>
> Regards,
> Volker
>
>
> On Tue, Sep 8, 2015 at 11:35 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> With link to webrev corrected:
>>
>> On 9/8/2015 5:08 PM, Roger Riggs wrote:
>>> Please review an intermittent test bug fix.
>>> The test setup time is very short and the user may be returned as 0 which
>>> is reported as root.
>>> The correction lengthens the time allowed for the process to start.
>>>
>>> The test is removed from the ProblemList.
>>>
>>> Webrev:
>>>     http://cr.openjdk.java.net/~rriggs//webrev-info-8133552
>>>
>>> Bug:
>>>    https://bugs.openjdk.java.net/browse/JDK-8133552
>>>
>>> Thanks, Roger
>>>



From david.lloyd at redhat.com  Wed Sep  9 17:12:17 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Wed, 09 Sep 2015 12:12:17 -0500
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F02911.9030504@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com>
Message-ID: <55F06871.6090101@redhat.com>

I think I've managed to reasonably firmly establish that atomically 
remapping memory is impossible on Windows based on various anecdotal 
evidence found from searching around (particularly on Cygwin mailing 
list archives).

Another possible option is to use other Windows memory management APIs 
to prevent a region of memory from being used by the automatic address 
selection mechanism - perhaps a VirtualAlloc with MEM_RESERVE would 
still allow a file mapping to be loaded there later via MapViewOfFileEx? 
  In this way, you could non-atomically unmap and remap the pages with 
some degree of assurance that they won't be reused.

Assuming that it is impossible to delete the mapping in any of these 
ways though, an unmap worst case implementation on Windows is not worse 
than the current status quo: it could just VirtualProtect the memory 
mapping to PAGE_NOACCESS and wait for GC to do its thing.  Perhaps such 
an implementation could suffice until such time that a specialized 
HotSpot-based solution (like what Andrew described) or other better 
option could be achieved.

On 09/09/2015 07:41 AM, David M. Lloyd wrote:
> If you have access to a Windows development environment, it seems to me
> that you could help directly with the testing required to determine a
> solution.
>
> I think my proposed remapping approach will work, but it is contingent
> on testing the following on Windows:
>
> * Determine if it is possible to remap the pages previously mapped to a
> file view without first unmapping them.  Preferably, the pages would be
> remapped as inaccessible (equivalent to POSIX PROT_NONE).
>
> * Determine if such remapping releases the file to be deleted, or, if
> not, determine if the previously mapped file view can be unmapped
> without affecting the remapped pages.
>
> If the answer to both of these can be shown to be affirmative, then I
> think there is a real viable solution which allows immediate release of
> backing resources, with the address space being reclaimed by GC.
>
> On 09/09/2015 05:51 AM, Uwe Schindler wrote:
>> Hi,
>>
>> Dawid Weiss and I are both involved in the Apache Lucene project and
>> we know the problems with MappedByteBuffer and unmapping. Dawid
>> already responded with a source code link to our impl (which needs to
>> use the hacky cleaner() approach; also look at the heavy documentation
>> in this class):
>> https://github.com/apache/lucene-solr/blob/trunk/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java
>>
>>
>> So we would be very happy to get this issue resolved! The cleaner()
>> hack is enabled by default in Lucene if the JVM supports it (so we
>> won't break if JIGSAW prevents this, but our *large* users would
>> heavily complain).
>>
>>>> This is fundamentally about *integrity* of the runtime. It follows
>>>> there
>>>> are security implications, but it?s still fundamentally an integrity
>>>> issue
>>>> and guarding an unsafe operation with a Security Manager is
>>>> unfortunately an insufficient solution.
>>>
>>> Right, and just to add that there has been many attempts over the years
>>> to find solutions to this issue. I think the closest was atomimcally
>>> remapping but that wasn't feasible on all platforms and also didn't free
>>> up the address space in a timely manner.
>>
>> So we should really find a solution here. I was talking with several
>> people on various conferences (Rory O'Donnel or Mark Reinhold) and we
>> had some ideas how to solve this. My idea how to solve this is
>> explained below (I am not a JVM internals or Hotspot guy, so excuse
>> some obviously "wrong" assumptions):
>>
>> Actually there are 2 issues, not only one. The first issue is, as
>> mentioned before: you cannot unmap via API. This is needed for many
>> apps, including Apache Lucene, for a reason which comes more from
>> "another" bug, and this is my issue #2 (see below).
>>
>> First, unmapping for Lucene is very important at the moment, because
>> we operate on the Lucene indexes purely using mmap (see [1]), which
>> may be several hundreds of Gigabytes easily. On highly dynamic
>> systems, Lucene often maps new files (also very largeones ) and relies
>> on the fact, that older, deleted files are unmapped in time (this does
>> not need to be ASAP, just "in time"). So we have those 2 "bugs", which
>> force us to unmap:
>>
>> (1) disk space issues / delete after last close (POSIX) vs. No delete
>> at all (Windows)
>>
>> - disk space: we have seen customers running out of disk space on
>> Lucene, because unmapping wasn?t done in time and therefore POSIX with
>> delete on last close cannot free the disk space, although the file was
>> already deleted. The problem you are seeing on Windows that you cannot
>> delete, is therefore worse on Linux, because it is hidden to the user
>> - you cannot free the disk space of the deleted file! Lucene creates
>> and deletes files all the time while indexing realtime data (e.g.
>> think of Github's very dynamic code search index, which is backed by
>> Lucene/Elasticsearch).
>> - virtual memory: If you map huge files (several hundreds of
>> Gigabytes) and they are not unmapped in time, you may run out of
>> virtual address space. This especially affects Windows, because it
>> does not use the full 46 bits (or like that) of addresses. So
>> effectively you can only map like 4 Terabytes on Windows. If you have
>> fragmentation of address space this gets worse (In Lucene, we map in
>> chunks of 1 GiB because of the signed 32 bit integer limit of
>> ByteBuffer, so fragmentation is not our biggest issue).
>>
>> (2) It takes veeeeeeeeeeeeeeeery long time until the unmapping
>> actually occurs!
>>
>> This is the real bug! If the garbage collector would clean up the
>> buffers asap, we would not need to unmap from user code. In Lucene we
>> just delay the file delete on Windows, so we are not really affected
>> by the file deletion inability (but that would be nice if it could be
>> fixed).
>>
>> If you look at the usage pattern of those huge, mapped files, you will
>> see why they are in most cases *never ever* unmapped automatically:
>> Lucene maps very large files and uses them for longer time. So the
>> MappedByteBuffer object gets migrated to older generations on the
>> heap. Garbage collection there happens, of course, very delayed. That
>> would not be the most problematic part, but there is a second issue:
>> The MappedByteBuffer object is just a very small object (in heap size
>> measurement: just an object header and a few pointers), so the garbage
>> collector does not see it as heavy! It's just a very small like 30
>> bytes object instance. Why should the Garbage collector clean it up?
>> And in fact it will almost never do this! The garbage collector cannot
>> see that our 30 bytes object instance "sits" on something like 300
>> Gigabytes of virtual memory and disk space!
>>
>> One proposal to fix this would be to add something like an internal
>> OpenJDK Java Annotation or similar where you can "mark" heavy objects,
>> so Garbage collector could free them by preference (similar to
>> sun.misc.Contended).
>>
>> For the Apache Lucene team,
>> Uwe
>>
>> [1]
>> http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html
>>
>> -----
>> Uwe Schindler
>> uschindler at apache.org
>> ASF Member, Apache Lucene PMC / Committer
>> Bremen, Germany
>> http://lucene.apache.org/
>>
>>
>

-- 
- DML


From Roger.Riggs at Oracle.com  Wed Sep  9 17:24:10 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 9 Sep 2015 13:24:10 -0400
Subject: RFR(XXS): 8135271: Add missing "-client IGNORE" to jvm.cfg file
	for ppc64
In-Reply-To: <CA+3eh12yuow+GzDMCvVbjAZ+8ZjYpKzXkxW30TcR-zxkJxn5bg@mail.gmail.com>
References: <CA+3eh12yuow+GzDMCvVbjAZ+8ZjYpKzXkxW30TcR-zxkJxn5bg@mail.gmail.com>
Message-ID: <55F06B3A.3090602@Oracle.com>

Hi Volker,

Looks good.

Roger


On 9/9/2015 12:36 PM, Volker Simonis wrote:
> Hi,
>
> can somebody please review this trivial fix which simply adds the
> missing "-client IGNORE" to jvm.cfg file for ppc64 to avoid test
> failures when running the regression tests:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8135271/
> https://bugs.openjdk.java.net/browse/JDK-8135271
>
> Thank you and best regards,
> Volker



From stuart.marks at oracle.com  Wed Sep  9 21:32:08 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 9 Sep 2015 14:32:08 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
Message-ID: <55F0A558.9010304@oracle.com>



On 9/9/15 12:50 AM, Paul Sandoz wrote:
>> << After stream execution completes, this scanner is left in an indeterminate state and cannot be reused. >>
>
> Ah, shame, which strongly suggests advising that the stream/scanner should always be closed afterwards, regardless of whether it contains a resource to be released. Not sure we need to say anything, up to you.

Sure, closing the Scanner (or a Stream derived from it) will prevent inadvertent 
reuse.

But I think this is similar to a Stream, which need only be closed if it 
contains a resource. If it doesn't contain a resource, the fluent API makes it 
easy to just throw it away. For example,

     String text = ... ;
     long wordCount = new Scanner(text).findAll("\\w+").count();

I'm thus leaning against recommending that the Scanner or its derived Stream be 
closed in all cases.

On 9/9/15 1:04 AM, Chris Hegarty wrote:
> the webrev/specdiff uses the term ?pipeline execution?. I think ?stream execution? is less likely to cause confusion.

I'll change the occurrences of "pipeline execution" to "stream pipeline 
execution" per your exchange with Paul. Looks like there are two such 
occurrences in each of the tokens() and findAll() methods.

Thanks for the reviews!

s'marks



From Roger.Riggs at Oracle.com  Wed Sep  9 21:49:35 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 9 Sep 2015 17:49:35 -0400
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
In-Reply-To: <55F064BE.1050401@Oracle.com>
References: <55EF4E51.2030506@Oracle.com> <55EF548E.2060601@Oracle.com>
	<CA+3eh13kWTrmwoOpt3gQgV8iqkOqMirn0o6hJp+pgWGGD_K-Cg@mail.gmail.com>
	<55F064BE.1050401@Oracle.com>
Message-ID: <55F0A96F.8020602@Oracle.com>

Hi,

Please review this update to extract the uid on from the owner of the 
/proc/<pid> file.
It should be more reliable than using the owner of the 
/proc/<pid>/cmdline file.

Webrev:
     http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/

Thanks, Roger


On 9/9/2015 12:56 PM, Roger Riggs wrote:
> Hi Volker,
>
> Thanks for the review and diagnosis.
>
> Can opening /proc/pid be used as a fallback if the st_uid is zero or
> is it worth the overhead of stat'ing /proc/pid always?
>
> Thanks, Roger
>
>
> On 9/9/2015 11:46 AM, Volker Simonis wrote:
>> Hi Roger,
>>
>> I think your change looks good and it surely improves the test
>> stability but I don't think it solves the problem in all cases.
>>
>> I think this problem is caused by a <defunct> (i.e. "zombie") process
>> (the spawned process lived too short and was already a zombie when the
>> info object was created). If you look at the proc-file system entry of
>> a <defunct> process you can see that its 'cmdline' file has zero size
>> and the file is owned by root. This is exactly what is reported by the
>> corresponding info object in the bug report (user=root and no cmd
>> field).
>>
>> We may need to improve the way how we get the uid of a pid on Linux.
>> The current way of querying the owner of /proc/<pid>/cmdline seems to
>> be unreliable. We may instead take the owner of /proc/<pid> which
>> seems to be still the initial user of the process.
>>
>> Regards,
>> Volker
>>
>>
>> On Tue, Sep 8, 2015 at 11:35 PM, Roger Riggs <Roger.Riggs at oracle.com> 
>> wrote:
>>> With link to webrev corrected:
>>>
>>> On 9/8/2015 5:08 PM, Roger Riggs wrote:
>>>> Please review an intermittent test bug fix.
>>>> The test setup time is very short and the user may be returned as 0 
>>>> which
>>>> is reported as root.
>>>> The correction lengthens the time allowed for the process to start.
>>>>
>>>> The test is removed from the ProblemList.
>>>>
>>>> Webrev:
>>>>     http://cr.openjdk.java.net/~rriggs//webrev-info-8133552
>>>>
>>>> Bug:
>>>>    https://bugs.openjdk.java.net/browse/JDK-8133552
>>>>
>>>> Thanks, Roger
>>>>
>



From stuart.marks at oracle.com  Wed Sep  9 22:07:17 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 9 Sep 2015 15:07:17 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F0A558.9010304@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com>
Message-ID: <55F0AD95.8060909@oracle.com>



On 9/9/15 2:32 PM, Stuart Marks wrote:
> I'll change the occurrences of "pipeline execution" to "stream pipeline
> execution" per your exchange with Paul. Looks like there are two such
> occurrences in each of the tokens() and findAll() methods.

Er, three such occurrences.

Webrev: (final, I hope)

   http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.4/

Specdiff:

 
http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.4/overview-summary.html

s'marks


From xueming.shen at oracle.com  Wed Sep  9 22:35:40 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 09 Sep 2015 15:35:40 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F0AD95.8060909@oracle.com>
References: <55E93797.8020408@oracle.com>	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>	<55EF8321.8040203@oracle.com>	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>	<55F0A558.9010304@oracle.com>
	<55F0AD95.8060909@oracle.com>
Message-ID: <55F0B43C.2030205@oracle.com>

Hi Stuart,

Can't modCount be increased to negative in extreme case?

2705             if (expectedCount>= 0&&  expectedCount != modCount) {
2706                 throw new ConcurrentModificationException();
2707             }

It'd be better to initialize expectedCount to modCount in constrocutor?

Sherman

On 09/09/2015 03:07 PM, Stuart Marks wrote:
>
>
> On 9/9/15 2:32 PM, Stuart Marks wrote:
>> I'll change the occurrences of "pipeline execution" to "stream pipeline
>> execution" per your exchange with Paul. Looks like there are two such
>> occurrences in each of the tokens() and findAll() methods.
>
> Er, three such occurrences.
>
> Webrev: (final, I hope)
>
>   http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.4/
>
> Specdiff:
>
>
> http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.4/overview-summary.html
>
> s'marks



From xueming.shen at oracle.com  Wed Sep  9 22:51:29 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 09 Sep 2015 15:51:29 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F0B43C.2030205@oracle.com>
References: <55E93797.8020408@oracle.com>	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>	<55EF8321.8040203@oracle.com>	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>	<55F0A558.9010304@oracle.com>	<55F0AD95.8060909@oracle.com>
	<55F0B43C.2030205@oracle.com>
Message-ID: <55F0B7F1.8010200@oracle.com>

One more comment regarding the CME check.

2829                     if (expectedCount != modCount) {
2830                         throw new ConcurrentModificationException();
2831                     }


While it definitely serves the purpose of "fail-fast", but given it's a ordered/sequential
stream, this condition is always checked in the immediate next round of tryAdvance().
Just doubt it really benefits anyone. It's true that it almost costs nothing though.

-Sherman

On 09/09/2015 03:35 PM, Xueming Shen wrote:
> Hi Stuart,
>
> Can't modCount be increased to negative in extreme case?
>
> 2705             if (expectedCount>= 0&&  expectedCount != modCount) {
> 2706                 throw new ConcurrentModificationException();
> 2707             }
>
> It'd be better to initialize expectedCount to modCount in constrocutor?
>
> Sherman
>
> On 09/09/2015 03:07 PM, Stuart Marks wrote:
>>
>>
>> On 9/9/15 2:32 PM, Stuart Marks wrote:
>>> I'll change the occurrences of "pipeline execution" to "stream pipeline
>>> execution" per your exchange with Paul. Looks like there are two such
>>> occurrences in each of the tokens() and findAll() methods.
>>
>> Er, three such occurrences.
>>
>> Webrev: (final, I hope)
>>
>>   http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.4/
>>
>> Specdiff:
>>
>>
>> http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.4/overview-summary.html
>>
>> s'marks
>



From joe.darcy at oracle.com  Thu Sep 10 00:08:33 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 09 Sep 2015 17:08:33 -0700
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
In-Reply-To: <55F0A96F.8020602@Oracle.com>
References: <55EF4E51.2030506@Oracle.com>
	<55EF548E.2060601@Oracle.com>	<CA+3eh13kWTrmwoOpt3gQgV8iqkOqMirn0o6hJp+pgWGGD_K-Cg@mail.gmail.com>	<55F064BE.1050401@Oracle.com>
	<55F0A96F.8020602@Oracle.com>
Message-ID: <55F0CA01.5090508@oracle.com>

Hi Roger,

If timeouts need to be used, I suggest rather than fixed values they be 
adjusted according to the timeout factor being used in the test run.

Can some sort of repeated testing with exponential backout to a longer 
timeout be used ? If the system is actually ready is a fraction of a 
second, it is preferable for the test to be able to complete without 
waiting the full timeout value. (Perhaps that is already encapsulated in 
the existing code.)

Thanks,

-Joe

On 9/9/2015 2:49 PM, Roger Riggs wrote:
> Hi,
>
> Please review this update to extract the uid on from the owner of the 
> /proc/<pid> file.
> It should be more reliable than using the owner of the 
> /proc/<pid>/cmdline file.
>
> Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/
>
> Thanks, Roger
>
>
> On 9/9/2015 12:56 PM, Roger Riggs wrote:
>> Hi Volker,
>>
>> Thanks for the review and diagnosis.
>>
>> Can opening /proc/pid be used as a fallback if the st_uid is zero or
>> is it worth the overhead of stat'ing /proc/pid always?
>>
>> Thanks, Roger
>>
>>
>> On 9/9/2015 11:46 AM, Volker Simonis wrote:
>>> Hi Roger,
>>>
>>> I think your change looks good and it surely improves the test
>>> stability but I don't think it solves the problem in all cases.
>>>
>>> I think this problem is caused by a <defunct> (i.e. "zombie") process
>>> (the spawned process lived too short and was already a zombie when the
>>> info object was created). If you look at the proc-file system entry of
>>> a <defunct> process you can see that its 'cmdline' file has zero size
>>> and the file is owned by root. This is exactly what is reported by the
>>> corresponding info object in the bug report (user=root and no cmd
>>> field).
>>>
>>> We may need to improve the way how we get the uid of a pid on Linux.
>>> The current way of querying the owner of /proc/<pid>/cmdline seems to
>>> be unreliable. We may instead take the owner of /proc/<pid> which
>>> seems to be still the initial user of the process.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Tue, Sep 8, 2015 at 11:35 PM, Roger Riggs 
>>> <Roger.Riggs at oracle.com> wrote:
>>>> With link to webrev corrected:
>>>>
>>>> On 9/8/2015 5:08 PM, Roger Riggs wrote:
>>>>> Please review an intermittent test bug fix.
>>>>> The test setup time is very short and the user may be returned as 
>>>>> 0 which
>>>>> is reported as root.
>>>>> The correction lengthens the time allowed for the process to start.
>>>>>
>>>>> The test is removed from the ProblemList.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~rriggs//webrev-info-8133552
>>>>>
>>>>> Bug:
>>>>>    https://bugs.openjdk.java.net/browse/JDK-8133552
>>>>>
>>>>> Thanks, Roger
>>>>>
>>
>



From david.holmes at oracle.com  Thu Sep 10 01:17:02 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 10 Sep 2015 11:17:02 +1000
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F03BA9.20304@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
Message-ID: <55F0DA0E.70506@oracle.com>

On 10/09/2015 12:01 AM, Andrew Haley wrote:
> On 09/09/2015 02:55 PM, David M. Lloyd wrote:
>> On 09/09/2015 08:17 AM, Andrew Haley wrote:
>>> On 09/09/2015 02:13 PM, David M. Lloyd wrote:
>>>> How would you hook into the safepoint to perform the unmapping?  You'd
>>>> have to wait for all threads to arrive at safepoints, wouldn't you?
>>>
>>> Yes.  That happens in the VM already, e.g. when we need to revoke the
>>> bias of a lock.  It's a well-established mechanism.
>>
>> Could you extend the technique to other native resources as well?
>
> Yes, but of course there will be some back-pressure from HotSpot
> developers: it requires changes to the VM, and you have to be
> extremely careful not to cause a deadlock.

Adding a new JVM_* function that requests a safepoint VM operation be 
executed is not a major concern in my opinion**. Of more of a concern is 
the cost of doing a stop-the-world safepoint in the kinds of 
environments being described. How frequently are these unmap operations 
needed?

** Note the VM operation can only operate on native data structures - no 
Java code execution is allowed.

David H.

> Andrew.
>


From aph at redhat.com  Thu Sep 10 07:59:47 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 10 Sep 2015 08:59:47 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F0DA0E.70506@oracle.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com>
Message-ID: <55F13873.8090204@redhat.com>

Ha
On 09/10/2015 02:17 AM, David Holmes wrote:
> On 10/09/2015 12:01 AM, Andrew Haley wrote:
>> On 09/09/2015 02:55 PM, David M. Lloyd wrote:
>>> On 09/09/2015 08:17 AM, Andrew Haley wrote:
>>>> On 09/09/2015 02:13 PM, David M. Lloyd wrote:
>>>>> How would you hook into the safepoint to perform the unmapping?  You'd
>>>>> have to wait for all threads to arrive at safepoints, wouldn't you?
>>>>
>>>> Yes.  That happens in the VM already, e.g. when we need to revoke the
>>>> bias of a lock.  It's a well-established mechanism.
>>>
>>> Could you extend the technique to other native resources as well?
>>
>> Yes, but of course there will be some back-pressure from HotSpot
>> developers: it requires changes to the VM, and you have to be
>> extremely careful not to cause a deadlock.
> 
> Adding a new JVM_* function that requests a safepoint VM operation be 
> executed is not a major concern in my opinion**. Of more of a concern is 
> the cost of doing a stop-the-world safepoint in the kinds of 
> environments being described. How frequently are these unmap operations 
> needed?

That's an interesting point.  I wonder if it might make sense to piggyback
on a safepoint which would have happened anyway.  But having said that, we
seem to be quite happy to safepoint for biased lock revocation and all
manner of other things.

Andrew.



From paul.sandoz at oracle.com  Thu Sep 10 09:04:55 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 10 Sep 2015 11:04:55 +0200
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F0AD95.8060909@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com> <55F0AD95.8060909@oracle.com>
Message-ID: <97D9E02D-E0D3-46BF-89A5-B106BDCD259E@oracle.com>


On 10 Sep 2015, at 00:07, Stuart Marks <stuart.marks at oracle.com> wrote:

> 
> 
> On 9/9/15 2:32 PM, Stuart Marks wrote:
>> I'll change the occurrences of "pipeline execution" to "stream pipeline
>> execution" per your exchange with Paul. Looks like there are two such
>> occurrences in each of the tokens() and findAll() methods.
> 
> Er, three such occurrences.
> 
> Webrev: (final, I hope)
> 
>  http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.4/
> 

+1.

Paul.

> Specdiff:
> 
> http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.4/overview-summary.html
> 
> s'marks



From vitalyd at gmail.com  Thu Sep 10 11:25:02 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 10 Sep 2015 07:25:02 -0400
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F13873.8090204@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
Message-ID: <CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>

The safepoint happiness is unfortunately a separate issue in Hotspot, and
it's definitely not happy times :).  Part of the problem is the
piggybacking of various operations on a safepoint - the safepoint time
alone (not counting GC, say) keeps growing.  You probably could piggyback
this on GuaranteedSafepointInterval safepoints, but those are currently
predicated on IC buffers needing to be cleaned.

As for biased locking, you'll find many deployments that care about latency
turn it off entirely (it's not a very useful feature on modern hardware, at
least X86/64) precisely to avoid revocation induced global pauses.

Would we exceed the complexity budget if posix systems would use memory
remapping and windows safepoints?

sent from my phone
On Sep 10, 2015 4:00 AM, "Andrew Haley" <aph at redhat.com> wrote:

> Ha
> On 09/10/2015 02:17 AM, David Holmes wrote:
> > On 10/09/2015 12:01 AM, Andrew Haley wrote:
> >> On 09/09/2015 02:55 PM, David M. Lloyd wrote:
> >>> On 09/09/2015 08:17 AM, Andrew Haley wrote:
> >>>> On 09/09/2015 02:13 PM, David M. Lloyd wrote:
> >>>>> How would you hook into the safepoint to perform the unmapping?
> You'd
> >>>>> have to wait for all threads to arrive at safepoints, wouldn't you?
> >>>>
> >>>> Yes.  That happens in the VM already, e.g. when we need to revoke the
> >>>> bias of a lock.  It's a well-established mechanism.
> >>>
> >>> Could you extend the technique to other native resources as well?
> >>
> >> Yes, but of course there will be some back-pressure from HotSpot
> >> developers: it requires changes to the VM, and you have to be
> >> extremely careful not to cause a deadlock.
> >
> > Adding a new JVM_* function that requests a safepoint VM operation be
> > executed is not a major concern in my opinion**. Of more of a concern is
> > the cost of doing a stop-the-world safepoint in the kinds of
> > environments being described. How frequently are these unmap operations
> > needed?
>
> That's an interesting point.  I wonder if it might make sense to piggyback
> on a safepoint which would have happened anyway.  But having said that, we
> seem to be quite happy to safepoint for biased lock revocation and all
> manner of other things.
>
> Andrew.
>
>


From aph at redhat.com  Thu Sep 10 13:22:27 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 10 Sep 2015 14:22:27 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
Message-ID: <55F18413.2010700@redhat.com>

On 09/10/2015 12:25 PM, Vitaly Davidovich wrote:

> The safepoint happiness is unfortunately a separate issue in
> Hotspot, and it's definitely not happy times :).  Part of the
> problem is the piggybacking of various operations on a safepoint -
> the safepoint time alone (not counting GC, say) keeps growing.  You
> probably could piggyback this on GuaranteedSafepointInterval
> safepoints, but those are currently predicated on IC buffers needing
> to be cleaned.

OK.  I see that there is a conflict here.

> As for biased locking, you'll find many deployments that care about
> latency turn it off entirely (it's not a very useful feature on
> modern hardware, at least X86/64) precisely to avoid revocation
> induced global pauses.

Indeed so, yes.  (But biased locking seems to be the default.  Is that
a good thing?)

> Would we exceed the complexity budget if posix systems would use
> memory remapping and windows safepoints?

I can still see address space exhaustion happening on unices.

On AArch64 we use either 3 or or 4 levels of translation tables with
4k pages, which gets us 512GB or 256TB of space.  With 64k pages 2
levels of translation tables are used, and that gets us 4TB of address
space.  If you map a few big databases it's really not going to take
very long to run out of space.

I guess it could be a runtime switch, like everything else.  :-)

Andrew.


From Roger.Riggs at Oracle.com  Thu Sep 10 13:30:58 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 10 Sep 2015 09:30:58 -0400
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
In-Reply-To: <55F0CA01.5090508@oracle.com>
References: <55EF4E51.2030506@Oracle.com> <55EF548E.2060601@Oracle.com>
	<CA+3eh13kWTrmwoOpt3gQgV8iqkOqMirn0o6hJp+pgWGGD_K-Cg@mail.gmail.com>
	<55F064BE.1050401@Oracle.com> <55F0A96F.8020602@Oracle.com>
	<55F0CA01.5090508@oracle.com>
Message-ID: <55F18612.1090409@Oracle.com>

Hi Joe,

I think adjusting the timeouts is already covered.
The test uses Process.waitFor(timeout) to wait for the process to exit, 
but only up to the timeout value.
The "Utils.adjustTimeout(5)", performs the desired adjustment based on 
the jtreg timeoutFactor.
Utils is in the testlibrary.

Roger


On 9/9/2015 8:08 PM, Joseph D. Darcy wrote:
> Hi Roger,
>
> If timeouts need to be used, I suggest rather than fixed values they 
> be adjusted according to the timeout factor being used in the test run.
>
> Can some sort of repeated testing with exponential backout to a longer 
> timeout be used ? If the system is actually ready is a fraction of a 
> second, it is preferable for the test to be able to complete without 
> waiting the full timeout value. (Perhaps that is already encapsulated 
> in the existing code.)
>
> Thanks,
>
> -Joe
>
> On 9/9/2015 2:49 PM, Roger Riggs wrote:
>> Hi,
>>
>> Please review this update to extract the uid on from the owner of the 
>> /proc/<pid> file.
>> It should be more reliable than using the owner of the 
>> /proc/<pid>/cmdline file.
>>
>> Webrev:
>>     http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/
>>
>> Thanks, Roger
>>
>>
>> On 9/9/2015 12:56 PM, Roger Riggs wrote:
>>> Hi Volker,
>>>
>>> Thanks for the review and diagnosis.
>>>
>>> Can opening /proc/pid be used as a fallback if the st_uid is zero or
>>> is it worth the overhead of stat'ing /proc/pid always?
>>>
>>> Thanks, Roger
>>>
>>>
>>> On 9/9/2015 11:46 AM, Volker Simonis wrote:
>>>> Hi Roger,
>>>>
>>>> I think your change looks good and it surely improves the test
>>>> stability but I don't think it solves the problem in all cases.
>>>>
>>>> I think this problem is caused by a <defunct> (i.e. "zombie") process
>>>> (the spawned process lived too short and was already a zombie when the
>>>> info object was created). If you look at the proc-file system entry of
>>>> a <defunct> process you can see that its 'cmdline' file has zero size
>>>> and the file is owned by root. This is exactly what is reported by the
>>>> corresponding info object in the bug report (user=root and no cmd
>>>> field).
>>>>
>>>> We may need to improve the way how we get the uid of a pid on Linux.
>>>> The current way of querying the owner of /proc/<pid>/cmdline seems to
>>>> be unreliable. We may instead take the owner of /proc/<pid> which
>>>> seems to be still the initial user of the process.
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>> On Tue, Sep 8, 2015 at 11:35 PM, Roger Riggs 
>>>> <Roger.Riggs at oracle.com> wrote:
>>>>> With link to webrev corrected:
>>>>>
>>>>> On 9/8/2015 5:08 PM, Roger Riggs wrote:
>>>>>> Please review an intermittent test bug fix.
>>>>>> The test setup time is very short and the user may be returned as 
>>>>>> 0 which
>>>>>> is reported as root.
>>>>>> The correction lengthens the time allowed for the process to start.
>>>>>>
>>>>>> The test is removed from the ProblemList.
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~rriggs//webrev-info-8133552
>>>>>>
>>>>>> Bug:
>>>>>>    https://bugs.openjdk.java.net/browse/JDK-8133552
>>>>>>
>>>>>> Thanks, Roger
>>>>>>
>>>
>>
>



From Roger.Riggs at Oracle.com  Thu Sep 10 13:42:43 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 10 Sep 2015 09:42:43 -0400
Subject: RFR JDK-8133079 LocalDate/LocalTime ofInstant()
In-Reply-To: <CACzrW9Dsap9AA83yVi1uESP_6O7cYSy9sC9NWe1uoosCQ6PEvA@mail.gmail.com>
References: <CACzrW9DiN5DPG1d1W=gT8NZTJnNwTH5fHe4bpRNHs94tPVatxQ@mail.gmail.com>
	<CACzrW9Dsap9AA83yVi1uESP_6O7cYSy9sC9NWe1uoosCQ6PEvA@mail.gmail.com>
Message-ID: <55F188D3.9000804@Oracle.com>

Hi Stephen,

I can take it up but probably won't get to it until after JavaOne. 
(Early Nov)

Roger


On 9/8/2015 2:53 PM, Stephen Colebourne wrote:
> Anyone like to take this on please?
> Stephen
> On 28 Aug 2015 00:07, "Stephen Colebourne" <scolebourne at joda.org> wrote:
>
>> External question sites indicate that users have difficulty converting
>> between java.util.Date and LocalDate, and also between Instant and
>> LocalDate/LocalTime. This user difficulty can be resolved with some
>> additional methods.
>>
>> Currently, the following methods exist:
>>
>>   ZonedDateTime.ofInstant(Instant, ZoneId);
>>   OffsetDateTime.ofInstant(Instant, ZoneId);
>>   LocalDateTime.ofInstant(Instant, ZoneId);
>>   OffsetTime.ofInstant(Instant, ZoneId);
>>
>> This enhancement proposes to add the same method to LocalDate and
>> LocalTime. It can reasonably be argued this was a simple oversight in
>> the original development.
>>
>> Diff attached to the JIRA:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8133079
>>
>> Would also appreciate a reviewer to ensure that the code and tests
>> pass OK (as opposed to my best efforts on a very dubious
>> Windows/Eclipse/JDK8 setup)
>>
>> Stephen
>>



From chris.hegarty at oracle.com  Thu Sep 10 13:43:01 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 10 Sep 2015 14:43:01 +0100
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
In-Reply-To: <55F18612.1090409@Oracle.com>
References: <55EF4E51.2030506@Oracle.com> <55EF548E.2060601@Oracle.com>
	<CA+3eh13kWTrmwoOpt3gQgV8iqkOqMirn0o6hJp+pgWGGD_K-Cg@mail.gmail.com>
	<55F064BE.1050401@Oracle.com> <55F0A96F.8020602@Oracle.com>
	<55F0CA01.5090508@oracle.com> <55F18612.1090409@Oracle.com>
Message-ID: <59018F23-A1FF-4443-B209-799FAF95C869@oracle.com>

Roger,

The timeouts, in this test, are just to ensure that the test does not block indefinitely, if it encounters a bug in the JDK, right?  If a timeout is ever triggered then there is a bug, right?

If this is the case then, we have used larger timeouts in other areas ( net, concurrency ) to cover running on slooooow, or busy, machines. Typically 30 secs.   To ensure no false failures.  The large value doesn?t really matter because it is never expected to actually wait that long. If it does timeout, then there is definitely a JDK bug.  Does it make sense to bump these to 30 secs also?

-Chris.

On 10 Sep 2015, at 14:30, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Joe,
> 
> I think adjusting the timeouts is already covered.
> The test uses Process.waitFor(timeout) to wait for the process to exit, but only up to the timeout value.
> The "Utils.adjustTimeout(5)", performs the desired adjustment based on the jtreg timeoutFactor.
> Utils is in the testlibrary.
> 
> Roger
> 
> 
> On 9/9/2015 8:08 PM, Joseph D. Darcy wrote:
>> Hi Roger,
>> 
>> If timeouts need to be used, I suggest rather than fixed values they be adjusted according to the timeout factor being used in the test run.
>> 
>> Can some sort of repeated testing with exponential backout to a longer timeout be used ? If the system is actually ready is a fraction of a second, it is preferable for the test to be able to complete without waiting the full timeout value. (Perhaps that is already encapsulated in the existing code.)
>> 
>> Thanks,
>> 
>> -Joe
>> 
>> On 9/9/2015 2:49 PM, Roger Riggs wrote:
>>> Hi,
>>> 
>>> Please review this update to extract the uid on from the owner of the /proc/<pid> file.
>>> It should be more reliable than using the owner of the /proc/<pid>/cmdline file.
>>> 
>>> Webrev:
>>>    http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/
>>> 
>>> Thanks, Roger
>>> 
>>> 
>>> On 9/9/2015 12:56 PM, Roger Riggs wrote:
>>>> Hi Volker,
>>>> 
>>>> Thanks for the review and diagnosis.
>>>> 
>>>> Can opening /proc/pid be used as a fallback if the st_uid is zero or
>>>> is it worth the overhead of stat'ing /proc/pid always?
>>>> 
>>>> Thanks, Roger
>>>> 
>>>> 
>>>> On 9/9/2015 11:46 AM, Volker Simonis wrote:
>>>>> Hi Roger,
>>>>> 
>>>>> I think your change looks good and it surely improves the test
>>>>> stability but I don't think it solves the problem in all cases.
>>>>> 
>>>>> I think this problem is caused by a <defunct> (i.e. "zombie") process
>>>>> (the spawned process lived too short and was already a zombie when the
>>>>> info object was created). If you look at the proc-file system entry of
>>>>> a <defunct> process you can see that its 'cmdline' file has zero size
>>>>> and the file is owned by root. This is exactly what is reported by the
>>>>> corresponding info object in the bug report (user=root and no cmd
>>>>> field).
>>>>> 
>>>>> We may need to improve the way how we get the uid of a pid on Linux.
>>>>> The current way of querying the owner of /proc/<pid>/cmdline seems to
>>>>> be unreliable. We may instead take the owner of /proc/<pid> which
>>>>> seems to be still the initial user of the process.
>>>>> 
>>>>> Regards,
>>>>> Volker
>>>>> 
>>>>> 
>>>>> On Tue, Sep 8, 2015 at 11:35 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>>> With link to webrev corrected:
>>>>>> 
>>>>>> On 9/8/2015 5:08 PM, Roger Riggs wrote:
>>>>>>> Please review an intermittent test bug fix.
>>>>>>> The test setup time is very short and the user may be returned as 0 which
>>>>>>> is reported as root.
>>>>>>> The correction lengthens the time allowed for the process to start.
>>>>>>> 
>>>>>>> The test is removed from the ProblemList.
>>>>>>> 
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~rriggs//webrev-info-8133552
>>>>>>> 
>>>>>>> Bug:
>>>>>>>   https://bugs.openjdk.java.net/browse/JDK-8133552
>>>>>>> 
>>>>>>> Thanks, Roger
>>>>>>> 
>>>> 
>>> 
>> 
> 



From david.lloyd at redhat.com  Thu Sep 10 13:48:40 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 10 Sep 2015 08:48:40 -0500
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F18413.2010700@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>	<55F02911.9030504@redhat.com>
	<55F02AEB.80101@redhat.com>	<55F02D05.2050509@redhat.com>
	<55F02EE0.4040901@redhat.com>	<55F03087.1010604@redhat.com>
	<55F0316B.7010303@redhat.com>	<55F03A38.1070604@redhat.com>
	<55F03BA9.20304@redhat.com>	<55F0DA0E.70506@oracle.com>
	<55F13873.8090204@redhat.com>	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com>
Message-ID: <55F18A38.4090004@redhat.com>

On 09/10/2015 08:22 AM, Andrew Haley wrote:
> On 09/10/2015 12:25 PM, Vitaly Davidovich wrote:
>
>> The safepoint happiness is unfortunately a separate issue in
>> Hotspot, and it's definitely not happy times :).  Part of the
>> problem is the piggybacking of various operations on a safepoint -
>> the safepoint time alone (not counting GC, say) keeps growing.  You
>> probably could piggyback this on GuaranteedSafepointInterval
>> safepoints, but those are currently predicated on IC buffers needing
>> to be cleaned.
>
> OK.  I see that there is a conflict here.

Is it possible that the operation could be simplified - down to setting 
a flag maybe - so that the expensive/potentially dangerous stuff (the 
actual unmap) can be done in a proper thread?

>> As for biased locking, you'll find many deployments that care about
>> latency turn it off entirely (it's not a very useful feature on
>> modern hardware, at least X86/64) precisely to avoid revocation
>> induced global pauses.
>
> Indeed so, yes.  (But biased locking seems to be the default.  Is that
> a good thing?)
>
>> Would we exceed the complexity budget if posix systems would use
>> memory remapping and windows safepoints?
>
> I can still see address space exhaustion happening on unices.

Still, it's important to remember that the status quo currently exhausts 
address space *and* actual backing resources, so anything is really an 
improvement at this point...

> On AArch64 we use either 3 or or 4 levels of translation tables with
> 4k pages, which gets us 512GB or 256TB of space.  With 64k pages 2
> levels of translation tables are used, and that gets us 4TB of address
> space.  If you map a few big databases it's really not going to take
> very long to run out of space.
>
> I guess it could be a runtime switch, like everything else.  :-)
>
> Andrew.
>

-- 
- DML


From Roger.Riggs at Oracle.com  Thu Sep 10 13:49:54 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 10 Sep 2015 09:49:54 -0400
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
In-Reply-To: <59018F23-A1FF-4443-B209-799FAF95C869@oracle.com>
References: <55EF4E51.2030506@Oracle.com> <55EF548E.2060601@Oracle.com>
	<CA+3eh13kWTrmwoOpt3gQgV8iqkOqMirn0o6hJp+pgWGGD_K-Cg@mail.gmail.com>
	<55F064BE.1050401@Oracle.com> <55F0A96F.8020602@Oracle.com>
	<55F0CA01.5090508@oracle.com> <55F18612.1090409@Oracle.com>
	<59018F23-A1FF-4443-B209-799FAF95C869@oracle.com>
Message-ID: <55F18A82.2020300@Oracle.com>

Hi Chris,

ok, updated the webrev with the 30 sec timeouts.
I also expect that the timeoutFactor on slow systems would be applied by 
jtreg.

Roger


On 9/10/2015 9:43 AM, Chris Hegarty wrote:
> Roger,
>
> The timeouts, in this test, are just to ensure that the test does not block indefinitely, if it encounters a bug in the JDK, right?  If a timeout is ever triggered then there is a bug, right?
correct
>
> If this is the case then, we have used larger timeouts in other areas ( net, concurrency ) to cover running on slooooow, or busy, machines. Typically 30 secs.   To ensure no false failures.  The large value doesn?t really matter because it is never expected to actually wait that long. If it does timeout, then there is definitely a JDK bug.  Does it make sense to bump these to 30 secs also?
>
> -Chris.
>
> On 10 Sep 2015, at 14:30, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
>> Hi Joe,
>>
>> I think adjusting the timeouts is already covered.
>> The test uses Process.waitFor(timeout) to wait for the process to exit, but only up to the timeout value.
>> The "Utils.adjustTimeout(5)", performs the desired adjustment based on the jtreg timeoutFactor.
>> Utils is in the testlibrary.
>>
>> Roger
>>
>>
>> On 9/9/2015 8:08 PM, Joseph D. Darcy wrote:
>>> Hi Roger,
>>>
>>> If timeouts need to be used, I suggest rather than fixed values they be adjusted according to the timeout factor being used in the test run.
>>>
>>> Can some sort of repeated testing with exponential backout to a longer timeout be used ? If the system is actually ready is a fraction of a second, it is preferable for the test to be able to complete without waiting the full timeout value. (Perhaps that is already encapsulated in the existing code.)
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> On 9/9/2015 2:49 PM, Roger Riggs wrote:
>>>> Hi,
>>>>
>>>> Please review this update to extract the uid on from the owner of the /proc/<pid> file.
>>>> It should be more reliable than using the owner of the /proc/<pid>/cmdline file.
>>>>
>>>> Webrev:
>>>>     http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>> On 9/9/2015 12:56 PM, Roger Riggs wrote:
>>>>> Hi Volker,
>>>>>
>>>>> Thanks for the review and diagnosis.
>>>>>
>>>>> Can opening /proc/pid be used as a fallback if the st_uid is zero or
>>>>> is it worth the overhead of stat'ing /proc/pid always?
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>> On 9/9/2015 11:46 AM, Volker Simonis wrote:
>>>>>> Hi Roger,
>>>>>>
>>>>>> I think your change looks good and it surely improves the test
>>>>>> stability but I don't think it solves the problem in all cases.
>>>>>>
>>>>>> I think this problem is caused by a <defunct> (i.e. "zombie") process
>>>>>> (the spawned process lived too short and was already a zombie when the
>>>>>> info object was created). If you look at the proc-file system entry of
>>>>>> a <defunct> process you can see that its 'cmdline' file has zero size
>>>>>> and the file is owned by root. This is exactly what is reported by the
>>>>>> corresponding info object in the bug report (user=root and no cmd
>>>>>> field).
>>>>>>
>>>>>> We may need to improve the way how we get the uid of a pid on Linux.
>>>>>> The current way of querying the owner of /proc/<pid>/cmdline seems to
>>>>>> be unreliable. We may instead take the owner of /proc/<pid> which
>>>>>> seems to be still the initial user of the process.
>>>>>>
>>>>>> Regards,
>>>>>> Volker
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 8, 2015 at 11:35 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>>>>>>> With link to webrev corrected:
>>>>>>>
>>>>>>> On 9/8/2015 5:08 PM, Roger Riggs wrote:
>>>>>>>> Please review an intermittent test bug fix.
>>>>>>>> The test setup time is very short and the user may be returned as 0 which
>>>>>>>> is reported as root.
>>>>>>>> The correction lengthens the time allowed for the process to start.
>>>>>>>>
>>>>>>>> The test is removed from the ProblemList.
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~rriggs//webrev-info-8133552
>>>>>>>>
>>>>>>>> Bug:
>>>>>>>>    https://bugs.openjdk.java.net/browse/JDK-8133552
>>>>>>>>
>>>>>>>> Thanks, Roger
>>>>>>>>



From ivan.gerasimov at oracle.com  Thu Sep 10 13:54:36 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 10 Sep 2015 16:54:36 +0300
Subject: [8u-dev] Request for review and for approval to backport: 8080115:
	(fs) Crash in libgio when calling Files.probeContentType(path) from
	parallel threads
Message-ID: <55F18B9C.8090602@oracle.com>

Hello!

Would you please approve the *almost* direct backport of the fix from 
jdk 9 to 8u?
The patch didn't apply automatically due to renaming of a function.

Bug: https://bugs.openjdk.java.net/browse/JDK-8080115
Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fe002a83ba79
Jdk9 review: 
http://mail.openjdk.java.net/pipermail/nio-dev/2015-August/003257.html

Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8080115/00/webrev/

The patched jdk was built/tested on all supported platforms.

Sincerely yours,
Ivan



From chris.hegarty at oracle.com  Thu Sep 10 13:59:29 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 10 Sep 2015 14:59:29 +0100
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
In-Reply-To: <55F18A82.2020300@Oracle.com>
References: <55EF4E51.2030506@Oracle.com> <55EF548E.2060601@Oracle.com>
	<CA+3eh13kWTrmwoOpt3gQgV8iqkOqMirn0o6hJp+pgWGGD_K-Cg@mail.gmail.com>
	<55F064BE.1050401@Oracle.com> <55F0A96F.8020602@Oracle.com>
	<55F0CA01.5090508@oracle.com> <55F18612.1090409@Oracle.com>
	<59018F23-A1FF-4443-B209-799FAF95C869@oracle.com>
	<55F18A82.2020300@Oracle.com>
Message-ID: <BFC52F93-D269-4601-866C-BD3C51EA40C0@oracle.com>

On 10 Sep 2015, at 14:49, Roger Riggs <Roger.Riggs at Oracle.com> wrote:

> Hi Chris,
> 
> ok, updated the webrev with the 30 sec timeouts.  

Thanks Roger.

I remember going many rounds on false timeouts from tests in other areas a few years back. We came to a consensus that 30 secs as a timeout, that should never be triggered, was a reasonable value.

> I also expect that the timeoutFactor on slow systems would be applied by jtreg.

Yes, but this does not cater for swamped systems.  I think we can err on the side of caution here, without any real cost.

Thanks,
-Chris.

> Roger
> 
> 
> On 9/10/2015 9:43 AM, Chris Hegarty wrote:
>> Roger,
>> 
>> The timeouts, in this test, are just to ensure that the test does not block indefinitely, if it encounters a bug in the JDK, right?  If a timeout is ever triggered then there is a bug, right?
>> 
> correct
>> 
>> If this is the case then, we have used larger timeouts in other areas ( net, concurrency ) to cover running on slooooow, or busy, machines. Typically 30 secs.   To ensure no false failures.  The large value doesn?t really matter because it is never expected to actually wait that long. If it does timeout, then there is definitely a JDK bug.  Does it make sense to bump these to 30 secs also?
>> 
>> -Chris.
>> 
>> On 10 Sep 2015, at 14:30, Roger Riggs 
>> <Roger.Riggs at oracle.com>
>>  wrote:
>> 
>> 
>>> Hi Joe,
>>> 
>>> I think adjusting the timeouts is already covered.
>>> The test uses Process.waitFor(timeout) to wait for the process to exit, but only up to the timeout value.
>>> The "Utils.adjustTimeout(5)", performs the desired adjustment based on the jtreg timeoutFactor.
>>> Utils is in the testlibrary.
>>> 
>>> Roger
>>> 
>>> 
>>> On 9/9/2015 8:08 PM, Joseph D. Darcy wrote:
>>> 
>>>> Hi Roger,
>>>> 
>>>> If timeouts need to be used, I suggest rather than fixed values they be adjusted according to the timeout factor being used in the test run.
>>>> 
>>>> Can some sort of repeated testing with exponential backout to a longer timeout be used ? If the system is actually ready is a fraction of a second, it is preferable for the test to be able to complete without waiting the full timeout value. (Perhaps that is already encapsulated in the existing code.)
>>>> 
>>>> Thanks,
>>>> 
>>>> -Joe
>>>> 
>>>> On 9/9/2015 2:49 PM, Roger Riggs wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Please review this update to extract the uid on from the owner of the /proc/<pid> file.
>>>>> It should be more reliable than using the owner of the /proc/<pid>/cmdline file.
>>>>> 
>>>>> Webrev:
>>>>>    
>>>>> http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/
>>>>> 
>>>>> 
>>>>> Thanks, Roger
>>>>> 
>>>>> 
>>>>> On 9/9/2015 12:56 PM, Roger Riggs wrote:
>>>>> 
>>>>>> Hi Volker,
>>>>>> 
>>>>>> Thanks for the review and diagnosis.
>>>>>> 
>>>>>> Can opening /proc/pid be used as a fallback if the st_uid is zero or
>>>>>> is it worth the overhead of stat'ing /proc/pid always?
>>>>>> 
>>>>>> Thanks, Roger
>>>>>> 
>>>>>> 
>>>>>> On 9/9/2015 11:46 AM, Volker Simonis wrote:
>>>>>> 
>>>>>>> Hi Roger,
>>>>>>> 
>>>>>>> I think your change looks good and it surely improves the test
>>>>>>> stability but I don't think it solves the problem in all cases.
>>>>>>> 
>>>>>>> I think this problem is caused by a <defunct> (i.e. "zombie") process
>>>>>>> (the spawned process lived too short and was already a zombie when the
>>>>>>> info object was created). If you look at the proc-file system entry of
>>>>>>> a <defunct> process you can see that its 'cmdline' file has zero size
>>>>>>> and the file is owned by root. This is exactly what is reported by the
>>>>>>> corresponding info object in the bug report (user=root and no cmd
>>>>>>> field).
>>>>>>> 
>>>>>>> We may need to improve the way how we get the uid of a pid on Linux.
>>>>>>> The current way of querying the owner of /proc/<pid>/cmdline seems to
>>>>>>> be unreliable. We may instead take the owner of /proc/<pid> which
>>>>>>> seems to be still the initial user of the process.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Volker
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Sep 8, 2015 at 11:35 PM, Roger Riggs 
>>>>>>> <Roger.Riggs at oracle.com>
>>>>>>>  wrote:
>>>>>>> 
>>>>>>>> With link to webrev corrected:
>>>>>>>> 
>>>>>>>> On 9/8/2015 5:08 PM, Roger Riggs wrote:
>>>>>>>> 
>>>>>>>>> Please review an intermittent test bug fix.
>>>>>>>>> The test setup time is very short and the user may be returned as 0 which
>>>>>>>>> is reported as root.
>>>>>>>>> The correction lengthens the time allowed for the process to start.
>>>>>>>>> 
>>>>>>>>> The test is removed from the ProblemList.
>>>>>>>>> 
>>>>>>>>> Webrev:
>>>>>>>>> 
>>>>>>>>> http://cr.openjdk.java.net/~rriggs//webrev-info-8133552
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Bug:
>>>>>>>>>   
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8133552
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thanks, Roger
>>>>>>>>> 
>>>>>>>>> 
> 



From aph at redhat.com  Thu Sep 10 14:05:49 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 10 Sep 2015 15:05:49 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F18A38.4090004@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
Message-ID: <55F18E3D.8020200@redhat.com>

On 09/10/2015 02:48 PM, David M. Lloyd wrote:
> On 09/10/2015 08:22 AM, Andrew Haley wrote:
>> On 09/10/2015 12:25 PM, Vitaly Davidovich wrote:
>>
>>> The safepoint happiness is unfortunately a separate issue in
>>> Hotspot, and it's definitely not happy times :).  Part of the
>>> problem is the piggybacking of various operations on a safepoint -
>>> the safepoint time alone (not counting GC, say) keeps growing.  You
>>> probably could piggyback this on GuaranteedSafepointInterval
>>> safepoints, but those are currently predicated on IC buffers needing
>>> to be cleaned.
>>
>> OK.  I see that there is a conflict here.
> 
> Is it possible that the operation could be simplified - down to setting 
> a flag maybe - so that the expensive/potentially dangerous stuff (the 
> actual unmap) can be done in a proper thread?

Sure.

The mapping can't be removed until you know for sure that no thread is
using it.  For that to be known you need a safepoint, but (you may
like this) the safepoint itself doesn't have to actually do anything.
I imagine it would go like this:

write-protect the guard page
trigger a safepoint ...
... wait for safepoint to complete
remove the mapping

>>> Would we exceed the complexity budget if posix systems would use
>>> memory remapping and windows safepoints?
>>
>> I can still see address space exhaustion happening on unices.
> 
> Still, it's important to remember that the status quo currently
> exhausts address space *and* actual backing resources, so anything
> is really an improvement at this point...

Yea, but much of the effort of developing something like this is the
overhead of discussions, creating bugs, and so on.  Once the box is
opened the extra effort of doing it properly is relatively cheap.  And
besides, where is the pleasure in writing a half-arsed solution?

Andrew.


From scolebourne at joda.org  Thu Sep 10 14:08:09 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 10 Sep 2015 15:08:09 +0100
Subject: RFR JDK-8133079 LocalDate/LocalTime ofInstant()
In-Reply-To: <55F188D3.9000804@Oracle.com>
References: <CACzrW9DiN5DPG1d1W=gT8NZTJnNwTH5fHe4bpRNHs94tPVatxQ@mail.gmail.com>
	<CACzrW9Dsap9AA83yVi1uESP_6O7cYSy9sC9NWe1uoosCQ6PEvA@mail.gmail.com>
	<55F188D3.9000804@Oracle.com>
Message-ID: <CACzrW9DkQxPFx=gV=mdYpEYnw2L84BX1MtMeBo4EVFym1mf7AQ@mail.gmail.com>

Shall I just open a number of these with things to be changed, so you
can deal with them in a batch then?
Stephen


On 10 September 2015 at 14:42, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi Stephen,
>
> I can take it up but probably won't get to it until after JavaOne. (Early
> Nov)
>
> Roger
>
>
>
> On 9/8/2015 2:53 PM, Stephen Colebourne wrote:
>>
>> Anyone like to take this on please?
>> Stephen
>> On 28 Aug 2015 00:07, "Stephen Colebourne" <scolebourne at joda.org> wrote:
>>
>>> External question sites indicate that users have difficulty converting
>>> between java.util.Date and LocalDate, and also between Instant and
>>> LocalDate/LocalTime. This user difficulty can be resolved with some
>>> additional methods.
>>>
>>> Currently, the following methods exist:
>>>
>>>   ZonedDateTime.ofInstant(Instant, ZoneId);
>>>   OffsetDateTime.ofInstant(Instant, ZoneId);
>>>   LocalDateTime.ofInstant(Instant, ZoneId);
>>>   OffsetTime.ofInstant(Instant, ZoneId);
>>>
>>> This enhancement proposes to add the same method to LocalDate and
>>> LocalTime. It can reasonably be argued this was a simple oversight in
>>> the original development.
>>>
>>> Diff attached to the JIRA:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8133079
>>>
>>> Would also appreciate a reviewer to ensure that the code and tests
>>> pass OK (as opposed to my best efforts on a very dubious
>>> Windows/Eclipse/JDK8 setup)
>>>
>>> Stephen
>>>
>


From sean.coffey at oracle.com  Thu Sep 10 14:10:10 2015
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 10 Sep 2015 15:10:10 +0100
Subject: [8u-dev] Request for review and for approval to backport:
	8080115: (fs) Crash in libgio when calling Files.probeContentType(path)
	from parallel threads
In-Reply-To: <55F18B9C.8090602@oracle.com>
References: <55F18B9C.8090602@oracle.com>
Message-ID: <55F18F42.2010806@oracle.com>

Looks fine. Approved.

Regards,
Sean.

On 10/09/2015 14:54, Ivan Gerasimov wrote:
> Hello!
>
> Would you please approve the *almost* direct backport of the fix from 
> jdk 9 to 8u?
> The patch didn't apply automatically due to renaming of a function.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8080115
> Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fe002a83ba79
> Jdk9 review: 
> http://mail.openjdk.java.net/pipermail/nio-dev/2015-August/003257.html
>
> Jdk8u webrev: http://cr.openjdk.java.net/~igerasim/8080115/00/webrev/
>
> The patched jdk was built/tested on all supported platforms.
>
> Sincerely yours,
> Ivan
>



From Roger.Riggs at Oracle.com  Thu Sep 10 14:11:34 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 10 Sep 2015 10:11:34 -0400
Subject: RFR JDK-8133079 LocalDate/LocalTime ofInstant()
In-Reply-To: <CACzrW9DkQxPFx=gV=mdYpEYnw2L84BX1MtMeBo4EVFym1mf7AQ@mail.gmail.com>
References: <CACzrW9DiN5DPG1d1W=gT8NZTJnNwTH5fHe4bpRNHs94tPVatxQ@mail.gmail.com>
	<CACzrW9Dsap9AA83yVi1uESP_6O7cYSy9sC9NWe1uoosCQ6PEvA@mail.gmail.com>
	<55F188D3.9000804@Oracle.com>
	<CACzrW9DkQxPFx=gV=mdYpEYnw2L84BX1MtMeBo4EVFym1mf7AQ@mail.gmail.com>
Message-ID: <55F18F96.2060001@Oracle.com>

Hi Stephen,

Yes, things that logically go together can be in the same bug/issue and 
be handled with a single
review cycle to keep the overhead down.

Thanks, Roger


On 9/10/2015 10:08 AM, Stephen Colebourne wrote:
> Shall I just open a number of these with things to be changed, so you
> can deal with them in a batch then?
> Stephen
>
>
> On 10 September 2015 at 14:42, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> Hi Stephen,
>>
>> I can take it up but probably won't get to it until after JavaOne. (Early
>> Nov)
>>
>> Roger
>>
>>
>>
>> On 9/8/2015 2:53 PM, Stephen Colebourne wrote:
>>> Anyone like to take this on please?
>>> Stephen
>>> On 28 Aug 2015 00:07, "Stephen Colebourne" <scolebourne at joda.org> wrote:
>>>
>>>> External question sites indicate that users have difficulty converting
>>>> between java.util.Date and LocalDate, and also between Instant and
>>>> LocalDate/LocalTime. This user difficulty can be resolved with some
>>>> additional methods.
>>>>
>>>> Currently, the following methods exist:
>>>>
>>>>    ZonedDateTime.ofInstant(Instant, ZoneId);
>>>>    OffsetDateTime.ofInstant(Instant, ZoneId);
>>>>    LocalDateTime.ofInstant(Instant, ZoneId);
>>>>    OffsetTime.ofInstant(Instant, ZoneId);
>>>>
>>>> This enhancement proposes to add the same method to LocalDate and
>>>> LocalTime. It can reasonably be argued this was a simple oversight in
>>>> the original development.
>>>>
>>>> Diff attached to the JIRA:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8133079
>>>>
>>>> Would also appreciate a reviewer to ensure that the code and tests
>>>> pass OK (as opposed to my best efforts on a very dubious
>>>> Windows/Eclipse/JDK8 setup)
>>>>
>>>> Stephen
>>>>



From vitalyd at gmail.com  Thu Sep 10 14:13:17 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 10 Sep 2015 10:13:17 -0400
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F18E3D.8020200@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
Message-ID: <CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>

So what happens after safepoint is done and thread accesses the mapping (it
would need protection NONE, not just write)? JVM is then going to trap the
signal and convert to an exception?

sent from my phone
On Sep 10, 2015 10:06 AM, "Andrew Haley" <aph at redhat.com> wrote:

> On 09/10/2015 02:48 PM, David M. Lloyd wrote:
> > On 09/10/2015 08:22 AM, Andrew Haley wrote:
> >> On 09/10/2015 12:25 PM, Vitaly Davidovich wrote:
> >>
> >>> The safepoint happiness is unfortunately a separate issue in
> >>> Hotspot, and it's definitely not happy times :).  Part of the
> >>> problem is the piggybacking of various operations on a safepoint -
> >>> the safepoint time alone (not counting GC, say) keeps growing.  You
> >>> probably could piggyback this on GuaranteedSafepointInterval
> >>> safepoints, but those are currently predicated on IC buffers needing
> >>> to be cleaned.
> >>
> >> OK.  I see that there is a conflict here.
> >
> > Is it possible that the operation could be simplified - down to setting
> > a flag maybe - so that the expensive/potentially dangerous stuff (the
> > actual unmap) can be done in a proper thread?
>
> Sure.
>
> The mapping can't be removed until you know for sure that no thread is
> using it.  For that to be known you need a safepoint, but (you may
> like this) the safepoint itself doesn't have to actually do anything.
> I imagine it would go like this:
>
> write-protect the guard page
> trigger a safepoint ...
> ... wait for safepoint to complete
> remove the mapping
>
> >>> Would we exceed the complexity budget if posix systems would use
> >>> memory remapping and windows safepoints?
> >>
> >> I can still see address space exhaustion happening on unices.
> >
> > Still, it's important to remember that the status quo currently
> > exhausts address space *and* actual backing resources, so anything
> > is really an improvement at this point...
>
> Yea, but much of the effort of developing something like this is the
> overhead of discussions, creating bugs, and so on.  Once the box is
> opened the extra effort of doing it properly is relatively cheap.  And
> besides, where is the pleasure in writing a half-arsed solution?
>
> Andrew.
>


From Roger.Riggs at Oracle.com  Thu Sep 10 14:17:54 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 10 Sep 2015 10:17:54 -0400
Subject: RFR 9: 8132883 : The spec of allChildren/children of
	j.l.Process/ProcessHandle need to be relaxed
Message-ID: <55F19112.8080108@Oracle.com>

Please review a couple of clarifications to the 
Process/ProcessHandle.allChildren methods.

8132883: Should not specify that non-alive processes have zero children.
        That is OS specific and cannot/should not be guaranteed by the spec
8131763:
   1. Requests a definition of 'direct' and 'indirect' children - direct 
children have the process as the parent
   2. Requests that the streams be specified as either sequential or 
parallel - the streams are sequential

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-allchildren-8132883/

Issues:
    https://bugs.openjdk.java.net/browse/JDK-8132883
    https://bugs.openjdk.java.net/browse/JDK-8131763

Thanks, Roger


From vitalyd at gmail.com  Thu Sep 10 14:21:01 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 10 Sep 2015 10:21:01 -0400
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F18413.2010700@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com>
Message-ID: <CAHjP37Gz1rSE1oW7hZrgzEzdOdcEqLOufam-gLqXKD1swYFSMg@mail.gmail.com>

Whether biased locking being enabled by default is up for debate; my
opinion is it should be off on modern CPUs.  If you're not contending, CAS
isn't much of an issue.  If you are contending, then you'll get revocations
which is more expensive than the CAS.  Biased locking would be profitable
on hardware where CAS is very expensive even if on uncontended cacheline.

If you remap to a none protected page, why is address exhaustion an issue?
It's the same thing you're suggesting without safepoint requirement.

sent from my phone
On Sep 10, 2015 9:22 AM, "Andrew Haley" <aph at redhat.com> wrote:

> On 09/10/2015 12:25 PM, Vitaly Davidovich wrote:
>
> > The safepoint happiness is unfortunately a separate issue in
> > Hotspot, and it's definitely not happy times :).  Part of the
> > problem is the piggybacking of various operations on a safepoint -
> > the safepoint time alone (not counting GC, say) keeps growing.  You
> > probably could piggyback this on GuaranteedSafepointInterval
> > safepoints, but those are currently predicated on IC buffers needing
> > to be cleaned.
>
> OK.  I see that there is a conflict here.
>
> > As for biased locking, you'll find many deployments that care about
> > latency turn it off entirely (it's not a very useful feature on
> > modern hardware, at least X86/64) precisely to avoid revocation
> > induced global pauses.
>
> Indeed so, yes.  (But biased locking seems to be the default.  Is that
> a good thing?)
>
> > Would we exceed the complexity budget if posix systems would use
> > memory remapping and windows safepoints?
>
> I can still see address space exhaustion happening on unices.
>
> On AArch64 we use either 3 or or 4 levels of translation tables with
> 4k pages, which gets us 512GB or 256TB of space.  With 64k pages 2
> levels of translation tables are used, and that gets us 4TB of address
> space.  If you map a few big databases it's really not going to take
> very long to run out of space.
>
> I guess it could be a runtime switch, like everything else.  :-)
>
> Andrew.
>


From aph at redhat.com  Thu Sep 10 14:22:04 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 10 Sep 2015 15:22:04 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
Message-ID: <55F1920C.1060509@redhat.com>

On 09/10/2015 03:13 PM, Vitaly Davidovich wrote:

> So what happens after safepoint is done and thread accesses the
> mapping (it would need protection NONE, not just write)? JVM is then
> going to trap the signal and convert to an exception?

One of us is missing something, and I don't think it's me.  :-)

There is a protection page (just one page) associated with every
mapping.  Every access to a mapping is guarded by that protection
page.  The protection page is mapped for as long as the
MappedByteBuffer is alive.

Andrew.


From vitalyd at gmail.com  Thu Sep 10 14:26:19 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 10 Sep 2015 10:26:19 -0400
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F1920C.1060509@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
Message-ID: <CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>

Yes, so what happens when that guard page is accessed by a thread after
safepoint? The safepoint does nothing, as you said, it just ensures no
thread is actively working against the mapping but it may still be
reachable.

sent from my phone
On Sep 10, 2015 10:22 AM, "Andrew Haley" <aph at redhat.com> wrote:

> On 09/10/2015 03:13 PM, Vitaly Davidovich wrote:
>
> > So what happens after safepoint is done and thread accesses the
> > mapping (it would need protection NONE, not just write)? JVM is then
> > going to trap the signal and convert to an exception?
>
> One of us is missing something, and I don't think it's me.  :-)
>
> There is a protection page (just one page) associated with every
> mapping.  Every access to a mapping is guarded by that protection
> page.  The protection page is mapped for as long as the
> MappedByteBuffer is alive.
>
> Andrew.
>


From aph at redhat.com  Thu Sep 10 14:32:11 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 10 Sep 2015 15:32:11 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
Message-ID: <55F1946B.5070704@redhat.com>

On 09/10/2015 03:26 PM, Vitaly Davidovich wrote:
> Yes, so what happens when that guard page is accessed by a thread after safepoint?

A segfault and a null pointer exception.

Andrew.



From vitalyd at gmail.com  Thu Sep 10 14:35:00 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 10 Sep 2015 10:35:00 -0400
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F1946B.5070704@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
Message-ID: <CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>

Well, you'd probably want something other than NPE here -- perhaps a new
dedicated exception to signal this condition.  And this means the segfault
handling now needs to know about this type of situation as well, rather
than just NPEs.

On Thu, Sep 10, 2015 at 10:32 AM, Andrew Haley <aph at redhat.com> wrote:

> On 09/10/2015 03:26 PM, Vitaly Davidovich wrote:
> > Yes, so what happens when that guard page is accessed by a thread after
> safepoint?
>
> A segfault and a null pointer exception.
>
> Andrew.
>
>


From chris.hegarty at oracle.com  Thu Sep 10 14:34:57 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 10 Sep 2015 15:34:57 +0100
Subject: RFR 9: 8132883 : The spec of allChildren/children of
	j.l.Process/ProcessHandle need to be relaxed
In-Reply-To: <55F19112.8080108@Oracle.com>
References: <55F19112.8080108@Oracle.com>
Message-ID: <A1E693A1-23DF-4792-890C-159554A383A3@oracle.com>

These spec clarifications look ok to me.

Being pedantic, should the ProcessHandle changes say 'the process?, rather than 'this process??

-Chris.

On 10 Sep 2015, at 15:17, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Please review a couple of clarifications to the Process/ProcessHandle.allChildren methods.
> 
> 8132883: Should not specify that non-alive processes have zero children.
>       That is OS specific and cannot/should not be guaranteed by the spec
> 8131763:
>  1. Requests a definition of 'direct' and 'indirect' children - direct children have the process as the parent
>  2. Requests that the streams be specified as either sequential or parallel - the streams are sequential
> 
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-allchildren-8132883/
> 
> Issues:
>   https://bugs.openjdk.java.net/browse/JDK-8132883
>   https://bugs.openjdk.java.net/browse/JDK-8131763
> 
> Thanks, Roger



From david.lloyd at redhat.com  Thu Sep 10 14:37:14 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 10 Sep 2015 09:37:14 -0500
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>	<55F02911.9030504@redhat.com>
	<55F02AEB.80101@redhat.com>	<55F02D05.2050509@redhat.com>
	<55F02EE0.4040901@redhat.com>	<55F03087.1010604@redhat.com>
	<55F0316B.7010303@redhat.com>	<55F03A38.1070604@redhat.com>
	<55F03BA9.20304@redhat.com>	<55F0DA0E.70506@oracle.com>
	<55F13873.8090204@redhat.com>	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>	<55F18413.2010700@redhat.com>
	<55F18A38.4090004@redhat.com>	<55F18E3D.8020200@redhat.com>	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>	<55F1920C.1060509@redhat.com>	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
Message-ID: <55F1959A.2070109@redhat.com>

Or, the Java methods which wrap this access can just catch NPE and throw 
the new exception type.

On 09/10/2015 09:35 AM, Vitaly Davidovich wrote:
> Well, you'd probably want something other than NPE here -- perhaps a new
> dedicated exception to signal this condition.  And this means the segfault
> handling now needs to know about this type of situation as well, rather
> than just NPEs.
>
> On Thu, Sep 10, 2015 at 10:32 AM, Andrew Haley <aph at redhat.com> wrote:
>
>> On 09/10/2015 03:26 PM, Vitaly Davidovich wrote:
>>> Yes, so what happens when that guard page is accessed by a thread after
>> safepoint?
>>
>> A segfault and a null pointer exception.
>>
>> Andrew.
>>
>>

-- 
- DML


From vitalyd at gmail.com  Thu Sep 10 14:40:07 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 10 Sep 2015 10:40:07 -0400
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F1959A.2070109@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
	<55F1959A.2070109@redhat.com>
Message-ID: <CAHjP37ELnDG4FoNPHTqOZ4pwb81k=Nt+C1DggjdrZLDodJLFeg@mail.gmail.com>

Sure, if we're comfortable saying that the only cause of NPE there is due
to this and not something else.

On Thu, Sep 10, 2015 at 10:37 AM, David M. Lloyd <david.lloyd at redhat.com>
wrote:

> Or, the Java methods which wrap this access can just catch NPE and throw
> the new exception type.
>
>
> On 09/10/2015 09:35 AM, Vitaly Davidovich wrote:
>
>> Well, you'd probably want something other than NPE here -- perhaps a new
>> dedicated exception to signal this condition.  And this means the segfault
>> handling now needs to know about this type of situation as well, rather
>> than just NPEs.
>>
>> On Thu, Sep 10, 2015 at 10:32 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 09/10/2015 03:26 PM, Vitaly Davidovich wrote:
>>>
>>>> Yes, so what happens when that guard page is accessed by a thread after
>>>>
>>> safepoint?
>>>
>>> A segfault and a null pointer exception.
>>>
>>> Andrew.
>>>
>>>
>>>
> --
> - DML
>


From Roger.Riggs at Oracle.com  Thu Sep 10 14:43:38 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 10 Sep 2015 10:43:38 -0400
Subject: RFR 9: 8132883 : The spec of allChildren/children of
	j.l.Process/ProcessHandle need to be relaxed
In-Reply-To: <A1E693A1-23DF-4792-890C-159554A383A3@oracle.com>
References: <55F19112.8080108@Oracle.com>
	<A1E693A1-23DF-4792-890C-159554A383A3@oracle.com>
Message-ID: <55F1971A.6040509@Oracle.com>

Hi Chris,

Corrected,  'the' reads better than 'this' and avoids potential confusion.

Thanks, Roger


On 9/10/2015 10:34 AM, Chris Hegarty wrote:
> These spec clarifications look ok to me.
>
> Being pedantic, should the ProcessHandle changes say 'the process?, rather than 'this process??
>
> -Chris.
>
> On 10 Sep 2015, at 15:17, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
>> Please review a couple of clarifications to the Process/ProcessHandle.allChildren methods.
>>
>> 8132883: Should not specify that non-alive processes have zero children.
>>        That is OS specific and cannot/should not be guaranteed by the spec
>> 8131763:
>>   1. Requests a definition of 'direct' and 'indirect' children - direct children have the process as the parent
>>   2. Requests that the streams be specified as either sequential or parallel - the streams are sequential
>>
>> Webrev:
>>    http://cr.openjdk.java.net/~rriggs/webrev-allchildren-8132883/
>>
>> Issues:
>>    https://bugs.openjdk.java.net/browse/JDK-8132883
>>    https://bugs.openjdk.java.net/browse/JDK-8131763
>>
>> Thanks, Roger



From aph at redhat.com  Thu Sep 10 14:45:30 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 10 Sep 2015 15:45:30 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
Message-ID: <55F1978A.6060801@redhat.com>

On 09/10/2015 03:35 PM, Vitaly Davidovich wrote:

> Well, you'd probably want something other than NPE here -- perhaps a
> new dedicated exception to signal this condition. 

Sure, if you like, but that's a detail.  We are arguing about what
colour to paint the bike shed.  :)

> And this means the segfault handling now needs to know about this
> type of situation as well, rather than just NPEs.

Maybe, but perhaps not.  The access to the guard page might just
trigger the usual segfault path, which (given an oop map) looks just
like a null pointer exception.

Andrew.


From chris.hegarty at oracle.com  Thu Sep 10 14:47:45 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 10 Sep 2015 15:47:45 +0100
Subject: RFR 9: 8132883 : The spec of allChildren/children of
	j.l.Process/ProcessHandle need to be relaxed
In-Reply-To: <55F1971A.6040509@Oracle.com>
References: <55F19112.8080108@Oracle.com>
	<A1E693A1-23DF-4792-890C-159554A383A3@oracle.com>
	<55F1971A.6040509@Oracle.com>
Message-ID: <569CD7B8-A365-4AC7-871A-C62492D9F701@oracle.com>

On 10 Sep 2015, at 15:43, Roger Riggs <Roger.Riggs at Oracle.com> wrote:

> Hi Chris,
> 
> Corrected,  'the' reads better than 'this' and avoids potential confusion.

Looks good.

-Chris.

> Thanks, Roger
> 
> 
> On 9/10/2015 10:34 AM, Chris Hegarty wrote:
>> These spec clarifications look ok to me.
>> 
>> Being pedantic, should the ProcessHandle changes say 'the process?, rather than 'this process??
>> 
>> -Chris.
>> 
>> On 10 Sep 2015, at 15:17, Roger Riggs 
>> <Roger.Riggs at oracle.com>
>>  wrote:
>> 
>> 
>>> Please review a couple of clarifications to the Process/ProcessHandle.allChildren methods.
>>> 
>>> 8132883: Should not specify that non-alive processes have zero children.
>>>       That is OS specific and cannot/should not be guaranteed by the spec
>>> 8131763:
>>>  1. Requests a definition of 'direct' and 'indirect' children - direct children have the process as the parent
>>>  2. Requests that the streams be specified as either sequential or parallel - the streams are sequential
>>> 
>>> Webrev:
>>>   
>>> http://cr.openjdk.java.net/~rriggs/webrev-allchildren-8132883/
>>> 
>>> 
>>> Issues:
>>>   
>>> https://bugs.openjdk.java.net/browse/JDK-8132883
>>> 
>>>   
>>> https://bugs.openjdk.java.net/browse/JDK-8131763
>>> 
>>> 
>>> Thanks, Roger
>>> 
> 



From vitalyd at gmail.com  Thu Sep 10 14:56:53 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 10 Sep 2015 10:56:53 -0400
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F1978A.6060801@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
	<55F1978A.6060801@redhat.com>
Message-ID: <CAHjP37ESKP=xv1H9ie+0oO5zmS7E-KPxmjpDQ4z_wOnN2pBhkA@mail.gmail.com>

>
> Sure, if you like, but that's a detail.  We are arguing about what
> colour to paint the bike shed.  :)


The reason it may be more than just a bikeshed is because if this requires
more cleverness in the segfault handler, then it's yet more work to make
this happen.  I agree it's an implementation detail, but I don't think it's
trivial (unless someone comes along and says that modifying the trap
handler to account for this type of scenario is trivial).  One would also
need to modify the safepoint code in the VM to allow skipping all the
housekeeping it does typically, but I suspect this part is fairly easy.

At any rate, this is probably the best that can be done if we don't want to
expose the unsafe method.  Part of me wonders whether this attempt to
preserve JVM integrity is really worth the cost; there're already ways to
bring down the JVM (e.g. JNI, existing Unsafe usage, etc), and so putting a
safety perimeter around this piece seems uninteresting (especially given
that people today are already using unsafe hacks for this).  I do think,
however, that avoiding safepoints on systems that allow atomic remapping
would be needed, although that increases the complexity of the solution
somewhat.

On Thu, Sep 10, 2015 at 10:45 AM, Andrew Haley <aph at redhat.com> wrote:

> On 09/10/2015 03:35 PM, Vitaly Davidovich wrote:
>
> > Well, you'd probably want something other than NPE here -- perhaps a
> > new dedicated exception to signal this condition.
>
> Sure, if you like, but that's a detail.  We are arguing about what
> colour to paint the bike shed.  :)
>
> > And this means the segfault handling now needs to know about this
> > type of situation as well, rather than just NPEs.
>
> Maybe, but perhaps not.  The access to the guard page might just
> trigger the usual segfault path, which (given an oop map) looks just
> like a null pointer exception.
>
> Andrew.
>


From aph at redhat.com  Thu Sep 10 15:04:41 2015
From: aph at redhat.com (Andrew Haley)
Date: Thu, 10 Sep 2015 16:04:41 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CAHjP37ESKP=xv1H9ie+0oO5zmS7E-KPxmjpDQ4z_wOnN2pBhkA@mail.gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
	<55F1978A.6060801@redhat.com>
	<CAHjP37ESKP=xv1H9ie+0oO5zmS7E-KPxmjpDQ4z_wOnN2pBhkA@mail.gmail.com>
Message-ID: <55F19C09.3000900@redhat.com>

On 09/10/2015 03:56 PM, Vitaly Davidovich wrote:
>     Sure, if you like, but that's a detail.  We are arguing about what
>     colour to paint the bike shed.  :)
>  
> The reason it may be more than just a bikeshed is because if this requires more cleverness in the segfault handler, then it's yet more work to make this happen.  I agree it's an implementation detail, but I don't think it's trivial (unless someone comes along and says that modifying the trap handler to account for this type of scenario is trivial).

I don't think that it's exactly trivial, but I've spent a fair bit of
time inside that segfault handler so I have a pretty good idea.  It is
somewhat troublesome that each OS and CPU has its own version.

> One would also need to modify the safepoint code in the VM to allow skipping all the housekeeping it does typically, but I suspect this part is fairly easy.
> 
> At any rate, this is probably the best that can be done if we don't want to expose the unsafe method.  Part of me wonders whether this attempt to preserve JVM integrity is really worth the cost; there're already ways to bring down the JVM (e.g. JNI, existing Unsafe usage, etc), and so putting a safety perimeter around this piece seems uninteresting (especially given that people today are already using unsafe hacks for this). 

I take your point.  However, I really like the idea of "Java as fast
as C, but safer!" for handling native data and think it's worth
expending a little effort on.

> I do think, however, that avoiding safepoints on systems that allow atomic remapping would be needed, although that increases the complexity of the solution somewhat.

Fair enough.

Andrew.


From volker.simonis at gmail.com  Thu Sep 10 15:52:25 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 10 Sep 2015 17:52:25 +0200
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
In-Reply-To: <55F0A96F.8020602@Oracle.com>
References: <55EF4E51.2030506@Oracle.com> <55EF548E.2060601@Oracle.com>
	<CA+3eh13kWTrmwoOpt3gQgV8iqkOqMirn0o6hJp+pgWGGD_K-Cg@mail.gmail.com>
	<55F064BE.1050401@Oracle.com> <55F0A96F.8020602@Oracle.com>
Message-ID: <CA+3eh11FbqCoyxExkAZCTdQ2AsCca5CS3VwhLWkiLYmEDN24UA@mail.gmail.com>

On Wed, Sep 9, 2015 at 11:49 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi,
>
> Please review this update to extract the uid on from the owner of the
> /proc/<pid> file.
> It should be more reliable than using the owner of the /proc/<pid>/cmdline
> file.
>
> Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/
>

Hi Roger,

the change looks good. I've only found one little problem:

In:

strncat(fn, "/cmdline", sizeof fn);

'fn' is not empty any more, so I think it should read:

strncat(fn, "/cmdline", sizeof fn - strnlen(fn, sizeof fn) - 1);

Also, increasing the timeout to 30 sec is reasonable.

Thank you and best regards,
Volker

> Thanks, Roger
>
>
>
> On 9/9/2015 12:56 PM, Roger Riggs wrote:
>>
>> Hi Volker,
>>
>> Thanks for the review and diagnosis.
>>
>> Can opening /proc/pid be used as a fallback if the st_uid is zero or
>> is it worth the overhead of stat'ing /proc/pid always?
>>
>> Thanks, Roger
>>
>>
>> On 9/9/2015 11:46 AM, Volker Simonis wrote:
>>>
>>> Hi Roger,
>>>
>>> I think your change looks good and it surely improves the test
>>> stability but I don't think it solves the problem in all cases.
>>>
>>> I think this problem is caused by a <defunct> (i.e. "zombie") process
>>> (the spawned process lived too short and was already a zombie when the
>>> info object was created). If you look at the proc-file system entry of
>>> a <defunct> process you can see that its 'cmdline' file has zero size
>>> and the file is owned by root. This is exactly what is reported by the
>>> corresponding info object in the bug report (user=root and no cmd
>>> field).
>>>
>>> We may need to improve the way how we get the uid of a pid on Linux.
>>> The current way of querying the owner of /proc/<pid>/cmdline seems to
>>> be unreliable. We may instead take the owner of /proc/<pid> which
>>> seems to be still the initial user of the process.
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Tue, Sep 8, 2015 at 11:35 PM, Roger Riggs <Roger.Riggs at oracle.com>
>>> wrote:
>>>>
>>>> With link to webrev corrected:
>>>>
>>>> On 9/8/2015 5:08 PM, Roger Riggs wrote:
>>>>>
>>>>> Please review an intermittent test bug fix.
>>>>> The test setup time is very short and the user may be returned as 0
>>>>> which
>>>>> is reported as root.
>>>>> The correction lengthens the time allowed for the process to start.
>>>>>
>>>>> The test is removed from the ProblemList.
>>>>>
>>>>> Webrev:
>>>>>     http://cr.openjdk.java.net/~rriggs//webrev-info-8133552
>>>>>
>>>>> Bug:
>>>>>    https://bugs.openjdk.java.net/browse/JDK-8133552
>>>>>
>>>>> Thanks, Roger
>>>>>
>>
>


From Roger.Riggs at Oracle.com  Thu Sep 10 17:03:53 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 10 Sep 2015 13:03:53 -0400
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
In-Reply-To: <CA+3eh11FbqCoyxExkAZCTdQ2AsCca5CS3VwhLWkiLYmEDN24UA@mail.gmail.com>
References: <55EF4E51.2030506@Oracle.com> <55EF548E.2060601@Oracle.com>
	<CA+3eh13kWTrmwoOpt3gQgV8iqkOqMirn0o6hJp+pgWGGD_K-Cg@mail.gmail.com>
	<55F064BE.1050401@Oracle.com> <55F0A96F.8020602@Oracle.com>
	<CA+3eh11FbqCoyxExkAZCTdQ2AsCca5CS3VwhLWkiLYmEDN24UA@mail.gmail.com>
Message-ID: <55F1B7F9.1060003@Oracle.com>

Hi Volker,

Thanks for the review, I added the code you provided to use the correct 
length.

Updated the webrev:
     http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/

Roger


On 9/10/2015 11:52 AM, Volker Simonis wrote:
> On Wed, Sep 9, 2015 at 11:49 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>> Hi,
>>
>> Please review this update to extract the uid on from the owner of the
>> /proc/<pid> file.
>> It should be more reliable than using the owner of the /proc/<pid>/cmdline
>> file.
>>
>> Webrev:
>>      http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/
>>
> Hi Roger,
>
> the change looks good. I've only found one little problem:
>
> In:
>
> strncat(fn, "/cmdline", sizeof fn);
>
> 'fn' is not empty any more, so I think it should read:
>
> strncat(fn, "/cmdline", sizeof fn - strnlen(fn, sizeof fn) - 1);
>
> Also, increasing the timeout to 30 sec is reasonable.
>
> Thank you and best regards,
> Volker
>
>> Thanks, Roger
>>
>>
>>
>> On 9/9/2015 12:56 PM, Roger Riggs wrote:
>>> Hi Volker,
>>>
>>> Thanks for the review and diagnosis.
>>>
>>> Can opening /proc/pid be used as a fallback if the st_uid is zero or
>>> is it worth the overhead of stat'ing /proc/pid always?
>>>
>>> Thanks, Roger
>>>
>>>
>>> On 9/9/2015 11:46 AM, Volker Simonis wrote:
>>>> Hi Roger,
>>>>
>>>> I think your change looks good and it surely improves the test
>>>> stability but I don't think it solves the problem in all cases.
>>>>
>>>> I think this problem is caused by a <defunct> (i.e. "zombie") process
>>>> (the spawned process lived too short and was already a zombie when the
>>>> info object was created). If you look at the proc-file system entry of
>>>> a <defunct> process you can see that its 'cmdline' file has zero size
>>>> and the file is owned by root. This is exactly what is reported by the
>>>> corresponding info object in the bug report (user=root and no cmd
>>>> field).
>>>>
>>>> We may need to improve the way how we get the uid of a pid on Linux.
>>>> The current way of querying the owner of /proc/<pid>/cmdline seems to
>>>> be unreliable. We may instead take the owner of /proc/<pid> which
>>>> seems to be still the initial user of the process.
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>>
>>>> On Tue, Sep 8, 2015 at 11:35 PM, Roger Riggs <Roger.Riggs at oracle.com>
>>>> wrote:
>>>>> With link to webrev corrected:
>>>>>
>>>>> On 9/8/2015 5:08 PM, Roger Riggs wrote:
>>>>>> Please review an intermittent test bug fix.
>>>>>> The test setup time is very short and the user may be returned as 0
>>>>>> which
>>>>>> is reported as root.
>>>>>> The correction lengthens the time allowed for the process to start.
>>>>>>
>>>>>> The test is removed from the ProblemList.
>>>>>>
>>>>>> Webrev:
>>>>>>      http://cr.openjdk.java.net/~rriggs//webrev-info-8133552
>>>>>>
>>>>>> Bug:
>>>>>>     https://bugs.openjdk.java.net/browse/JDK-8133552
>>>>>>
>>>>>> Thanks, Roger
>>>>>>



From dawid.weiss at gmail.com  Thu Sep 10 18:47:32 2015
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Thu, 10 Sep 2015 20:47:32 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F19C09.3000900@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com>
	<55F02AEB.80101@redhat.com> <55F02D05.2050509@redhat.com>
	<55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
	<55F1978A.6060801@redhat.com>
	<CAHjP37ESKP=xv1H9ie+0oO5zmS7E-KPxmjpDQ4z_wOnN2pBhkA@mail.gmail.com>
	<55F19C09.3000900@redhat.com>
Message-ID: <CAM21Rt_8FZDMPTK4sVeLXUrJB6F3w1z3QDp2H3cDAgVnVpbznQ@mail.gmail.com>

> there're already ways to bring down the JVM (e.g. JNI, existing Unsafe usage, etc),

If you can somehow pass switches to the JVM, this one wins my personal
beauty contest (from globals.hpp):

product(intx, SelfDestructTimer, 0,                                       \
          "Will cause VM to terminate after a given time (in minutes) "     \
          "(0 means off)")

Dawid


From vitalyd at gmail.com  Thu Sep 10 18:52:05 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 10 Sep 2015 14:52:05 -0400
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CAM21Rt_8FZDMPTK4sVeLXUrJB6F3w1z3QDp2H3cDAgVnVpbznQ@mail.gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
	<55F1978A.6060801@redhat.com>
	<CAHjP37ESKP=xv1H9ie+0oO5zmS7E-KPxmjpDQ4z_wOnN2pBhkA@mail.gmail.com>
	<55F19C09.3000900@redhat.com>
	<CAM21Rt_8FZDMPTK4sVeLXUrJB6F3w1z3QDp2H3cDAgVnVpbznQ@mail.gmail.com>
Message-ID: <CAHjP37F+xVtvXRRqy4zc5Arv823LBZfg1yAqNECPxf7OrGqOFA@mail.gmail.com>

To be fair, this one sounds like it would initiate an orderly/graceful
shutdown whereas a bug in JNI/Unsafe kills it almost instantly (modulo
error reporting/core dumping) :)

On Thu, Sep 10, 2015 at 2:47 PM, Dawid Weiss <dawid.weiss at gmail.com> wrote:

> > there're already ways to bring down the JVM (e.g. JNI, existing Unsafe
> usage, etc),
>
> If you can somehow pass switches to the JVM, this one wins my personal
> beauty contest (from globals.hpp):
>
> product(intx, SelfDestructTimer, 0,                                       \
>           "Will cause VM to terminate after a given time (in minutes) "
>  \
>           "(0 means off)")
>
> Dawid
>


From stuart.marks at oracle.com  Thu Sep 10 20:22:27 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 10 Sep 2015 13:22:27 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F0B7F1.8010200@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com> <55F0AD95.8060909@oracle.com>
	<55F0B43C.2030205@oracle.com> <55F0B7F1.8010200@oracle.com>
Message-ID: <55F1E683.9050905@oracle.com>



On 9/9/15 3:51 PM, Xueming Shen wrote:
> One more comment regarding the CME check.
>
> 2829                     if (expectedCount != modCount) {
> 2830                         throw new ConcurrentModificationException();
> 2831                     }
>
> While it definitely serves the purpose of "fail-fast", but given it's a
> ordered/sequential
> stream, this condition is always checked in the immediate next round of
> tryAdvance().
> Just doubt it really benefits anyone. It's true that it almost costs nothing
> though.

The stream is initially sequential, but it can be changed to parallel by the 
application. If this occurs, this spliterator would be wrapped by code that 
gathers up elements into batches for parallel processing, making the control 
flow more complicated.

2826                 // assert expectedCount == modCount
2827                 if (findPatternInBuffer(pattern, 0)) { // doesn't increment 
modCount
2828                     cons.accept(matcher.toMatchResult());
2829                     if (expectedCount != modCount) {
2830                         throw new ConcurrentModificationException();
2831                     }

I guess the question is, is it worth having two checks in each call to 
tryAdvance()? The first check has to be there in order to initialize modCount 
the first time (see also below), and since you have modCount, you might as well 
check it if it's nonnegative.

The check after the call to the Consumer might seem unnecessary, but note that 
there is no guarantee that tryAdvance() will be called again if the stream 
decides to terminate early. (Consider short-circuiting behavior of findFirst() 
and friends.) It's easy to see that this "extra" check is a guard against the 
Consumer modifying the scanner's state, which I think is fairly important.

> On 09/09/2015 03:35 PM, Xueming Shen wrote:
>> Hi Stuart,
>>
>> Can't modCount be increased to negative in extreme case?
>>
>> 2705             if (expectedCount>= 0&&  expectedCount != modCount) {
>> 2706                 throw new ConcurrentModificationException();
>> 2707             }

(This is in TokenSpliterator.)

Yes, as tokens are processed, modCount will be incremented continually and 
overflow will eventually occur, causing modCount to wrap around to negative. The 
expectedCount value is continually reinitialized from modCount, so when this 
happens, expectedCount will go negative as well. This will disable the CME check 
at the top of tryAdvance(). If hasNext() is true, though, expectedCount is 
reinitialized from modCount and it's checked unconditionally after the Consumer 
call, so that CME check won't be affected. Similar things can occur if modCount 
has wrapped around to negative before the stream processing starts.

Bottom line is that when modCount is negative, it will bypass half the CME 
checks in TokenSpliterator. But some checking will still be done.

The situation with FindSpliterator is a bit different. The modCount value isn't 
incremented while advancing the spliterator, but there is still the possibility 
that modCount could be negative by the time stream processing starts. If this 
occurs, each call to tryAdvance() will be treated as the initial case and 
expectedCount will be reinitialized from modCount. This means that, as before, 
some CME checking could be bypassed. The check after the Consumer call will 
still work properly though.

Looks like the apparently redundant CME check after the Consumer call is helping 
out after all. :-)

It would be nice if this were cleaner, but it still meets the criterion of "best 
effort". It doesn't appear to fail spuriously, either. I suppose it would halve 
the number of error cases if expectedCount were compared against its sentinel 
value of -1 instead of <= 0, but I haven't thought this through. Is it worth it? 
As things stand, CME checks will be missed only happen after a billion calls on 
the scanner, and this is only significant if the application starts modifying 
the scanner illegally at that point.

>> It'd be better to initialize expectedCount to modCount in constrocutor?

That's how I had it initially, but at Paul Sandoz' suggestion I delayed the 
initialization to the first call to tryAdvance(). This allows the Scanner's 
state to be modified after stream creation but before stream pipeline execution. 
This is the way that Paul's stream code in Matcher works. I'm not sure how 
important this is. Having Scanner be gratuitously different from Matcher seems 
like it would be irritating though.

s'marks


From paul.sandoz at oracle.com  Thu Sep 10 20:55:28 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 10 Sep 2015 22:55:28 +0200
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F1E683.9050905@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com> <55F0AD95.8060909@oracle.com>
	<55F0B43C.2030205@oracle.com> <55F0B7F1.8010200@oracle.com>
	<55F1E683.9050905@oracle.com>
Message-ID: <250389CB-028B-438D-9999-AB7BCDDEB144@oracle.com>

On 10 Sep 2015, at 22:22, Stuart Marks <stuart.marks at oracle.com> wrote:
>>> It'd be better to initialize expectedCount to modCount in constrocutor?
> 
> That's how I had it initially, but at Paul Sandoz' suggestion I delayed the initialization to the first call to tryAdvance().

Yes, it?s preferable to have a "late-binding? Spliterator, as is the case for Matcher and collections.

The ?best-effort? implementation is more than sufficient given the extremely low probability of non-detection.

Paul.

>  This allows the Scanner's state to be modified after stream creation but before stream pipeline execution. This is the way that Paul's stream code in Matcher works. I'm not sure how important this is. Having Scanner be gratuitously different from Matcher seems like it would be irritating though.
> 




From xueming.shen at oracle.com  Thu Sep 10 21:12:10 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 10 Sep 2015 14:12:10 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F1E683.9050905@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com> <55F0AD95.8060909@oracle.com>
	<55F0B43C.2030205@oracle.com> <55F0B7F1.8010200@oracle.com>
	<55F1E683.9050905@oracle.com>
Message-ID: <55F1F22A.4000802@oracle.com>

On 09/10/2015 01:22 PM, Stuart Marks wrote:
>
>
> On 9/9/15 3:51 PM, Xueming Shen wrote:
>> One more comment regarding the CME check.
>>
>> 2829                     if (expectedCount != modCount) {
>> 2830                         throw new ConcurrentModificationException();
>> 2831                     }
>>
>> While it definitely serves the purpose of "fail-fast", but given it's a
>> ordered/sequential
>> stream, this condition is always checked in the immediate next round of
>> tryAdvance().
>> Just doubt it really benefits anyone. It's true that it almost costs nothing
>> though.
>
> The stream is initially sequential, but it can be changed to parallel by the application. If this occurs, this spliterator would be wrapped by code that gathers up elements into batches for parallel processing, making the control flow more complicated.
>
> 2826                 // assert expectedCount == modCount
> 2827                 if (findPatternInBuffer(pattern, 0)) { // doesn't increment modCount
> 2828                     cons.accept(matcher.toMatchResult());
> 2829                     if (expectedCount != modCount) {
> 2830                         throw new ConcurrentModificationException();
> 2831                     }
>
> I guess the question is, is it worth having two checks in each call to tryAdvance()? The first check has to be there in order to initialize modCount the first time (see also below), and since you have modCount, you might as well check it if it's nonnegative.
>
> The check after the call to the Consumer might seem unnecessary, but note that there is no guarantee that tryAdvance() will be called again if the stream decides to terminate early. (Consider short-circuiting behavior of findFirst() and friends.) It's easy to see that this "extra" check is a guard against the Consumer modifying the scanner's state, which I think is fairly important.
>
>> On 09/09/2015 03:35 PM, Xueming Shen wrote:
>>> Hi Stuart,
>>>
>>> Can't modCount be increased to negative in extreme case?
>>>
>>> 2705             if (expectedCount>= 0&&  expectedCount != modCount) {
>>> 2706                 throw new ConcurrentModificationException();
>>> 2707             }
>
> (This is in TokenSpliterator.)
>
> Yes, as tokens are processed, modCount will be incremented continually and overflow will eventually occur, causing modCount to wrap around to negative. The expectedCount value is continually reinitialized from modCount, so when this happens, expectedCount will go negative as well. This will disable the CME check at the top of tryAdvance(). If hasNext() is true, though, expectedCount is reinitialized from modCount and it's checked unconditionally after the Consumer call, so that CME check won't be affected. Similar things can occur if modCount has wrapped around to negative before the stream processing starts.
>
> Bottom line is that when modCount is negative, it will bypass half the CME checks in TokenSpliterator. But some checking will still be done.
>
> The situation with FindSpliterator is a bit different. The modCount value isn't incremented while advancing the spliterator, but there is still the possibility that modCount could be negative by the time stream processing starts. If this occurs, each call to tryAdvance() will be treated as the initial case and expectedCount will be reinitialized from modCount. This means that, as before, some CME checking could be bypassed. The check after the Consumer call will still work properly though.
>
> Looks like the apparently redundant CME check after the Consumer call is helping out after all. :-)
>
> It would be nice if this were cleaner, but it still meets the criterion of "best effort". It doesn't appear to fail spuriously, either. I suppose it would halve the number of error cases if expectedCount were compared against its sentinel value of -1 instead of <= 0, but I haven't thought this through. Is it worth it? As things stand, CME checks will be missed only happen after a billion calls on the scanner, and this is only significant if the application starts modifying the scanner illegally at that point.

I think it might be a "nice to have" for a "fail-fast" effort after the the consumer
consumed/accepted the result (the second check), but isn't it a bug for the consumer
to accept any result if there is CME condition occurred already?

>
>>> It'd be better to initialize expectedCount to modCount in constrocutor?
>
> That's how I had it initially, but at Paul Sandoz' suggestion I delayed the initialization to the first call to tryAdvance(). This allows the Scanner's state to be modified after stream creation but before stream pipeline execution. This is the way that Paul's stream code in Matcher works. I'm not sure how important this is. Having Scanner be gratuitously different from Matcher seems like it would be irritating though.
>

I noticed the spec says "Scanning starts upon initiation of the terminal stream operation, using the
current state of this scanner..." guess it means the "CME" enforcement starts with the "stream
operation" starts (a kinda of later-initialization). But personally feel it may create a unnecessary
inconsistent situation, depends on whether or not there is state change between the creation of
the Stream object and the starting of the stream operation. But I'm not a stream expert :-)

-Sherman





From xueming.shen at oracle.com  Thu Sep 10 21:32:39 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 10 Sep 2015 14:32:39 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <250389CB-028B-438D-9999-AB7BCDDEB144@oracle.com>
References: <55E93797.8020408@oracle.com>	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>	<55EF8321.8040203@oracle.com>	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>	<55F0A558.9010304@oracle.com>
	<55F0AD95.8060909@oracle.com>	<55F0B43C.2030205@oracle.com>
	<55F0B7F1.8010200@oracle.com>	<55F1E683.9050905@oracle.com>
	<250389CB-028B-438D-9999-AB7BCDDEB144@oracle.com>
Message-ID: <55F1F6F7.5050800@oracle.com>

On 09/10/2015 01:55 PM, Paul Sandoz wrote:
> On 10 Sep 2015, at 22:22, Stuart Marks<stuart.marks at oracle.com>  wrote:
>>>> It'd be better to initialize expectedCount to modCount in constrocutor?
>> That's how I had it initially, but at Paul Sandoz' suggestion I delayed the initialization to the first call to tryAdvance().
> Yes, it?s preferable to have a "late-binding? Spliterator, as is the case for Matcher and collections.
>
> The ?best-effort? implementation is more than sufficient given the extremely low probability of non-detection.

Well, you only need to have a separate boolean field for the "first invocation of tryAdvance()"
instead of utilizing the modCount for two purposes. But it's true there is no guarantee nothing
is going to happen between the modCount check and  hasNext()... I leave it to the expert:-)

> Paul.
>
>>   This allows the Scanner's state to be modified after stream creation but before stream pipeline execution. This is the way that Paul's stream code in Matcher works. I'm not sure how important this is. Having Scanner be gratuitously different from Matcher seems like it would be irritating though.
>>
>



From peter.levart at gmail.com  Thu Sep 10 22:29:10 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 11 Sep 2015 00:29:10 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F1959A.2070109@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
	<55F1959A.2070109@redhat.com>
Message-ID: <55F20436.9030701@gmail.com>

Hi guys,

Perhaps there's no need for this protection/trap dance. If the situation 
is never tripped in correct programs (that unmap only after noone is 
using the buffers any more), then checking for address and throwing in 
case it is equal to some guard value is a never taken branch that is 
predicted perfectly. I wrote this little benchmark to test this claim:

@BenchmarkMode(Mode.AverageTime)
@Fork(value = 1, warmups = 0)
@Warmup(iterations = 5)
@Measurement(iterations = 10)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
public class MappedBufferBench {

     private ByteBuffer bb;

     @Setup(Level.Trial)
     public void setup() {
         bb = ByteBuffer.allocateDirect(64);
     }

     @Benchmark
     public int directBufferGet() {
         int sum = 0;
         for (int i = 0; i < 64; i++) {
             sum += bb.get(i);
         }
         return sum;
     }
}


The results are:

Original:

Benchmark                                 Mode   Samples Score  Score 
error    Units
j.t.MappedBufferBench.directBufferGet     avgt        10 17.740        
0.247    ns/op

Patched:

Benchmark                                 Mode   Samples Score  Score 
error    Units
j.t.MappedBufferBench.directBufferGet     avgt        10 17.796        
0.220    ns/op



What did I patch? There's a private method in DirectByteBuffer to 
convert index to address:

Original:

     private long ix(int i) {
         return address + (i << 0);
     }

Patched:

     private long ix(int i) {
         long a = address;
         if (a == 0L) throw new IllegalStateException();
         return a + (i << 0);
     }



That's not all that has to be done of course. There would still have to 
be a wait for safe-point to return before unmapping. This is just a 
demonstration that maybe guarding mapping with protection is not needed.


Regards, Peter

On 09/10/2015 04:37 PM, David M. Lloyd wrote:
> Or, the Java methods which wrap this access can just catch NPE and 
> throw the new exception type.
>
> On 09/10/2015 09:35 AM, Vitaly Davidovich wrote:
>> Well, you'd probably want something other than NPE here -- perhaps a new
>> dedicated exception to signal this condition.  And this means the 
>> segfault
>> handling now needs to know about this type of situation as well, rather
>> than just NPEs.
>>
>> On Thu, Sep 10, 2015 at 10:32 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>>> On 09/10/2015 03:26 PM, Vitaly Davidovich wrote:
>>>> Yes, so what happens when that guard page is accessed by a thread 
>>>> after
>>> safepoint?
>>>
>>> A segfault and a null pointer exception.
>>>
>>> Andrew.
>>>
>>>
>



From vitalyd at gmail.com  Thu Sep 10 22:42:08 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 10 Sep 2015 18:42:08 -0400
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F20436.9030701@gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
	<55F1959A.2070109@redhat.com> <55F20436.9030701@gmail.com>
Message-ID: <CAHjP37EqtLdH132C5wCaCOYL4R+-h3QX-wkt+3JUhMcu-u30wQ@mail.gmail.com>

There's still a race condition since someone may have passed the guard,
entered a safepoint, and then proceeded to access the memory.

sent from my phone
On Sep 10, 2015 6:29 PM, "Peter Levart" <peter.levart at gmail.com> wrote:

> Hi guys,
>
> Perhaps there's no need for this protection/trap dance. If the situation
> is never tripped in correct programs (that unmap only after noone is using
> the buffers any more), then checking for address and throwing in case it is
> equal to some guard value is a never taken branch that is predicted
> perfectly. I wrote this little benchmark to test this claim:
>
> @BenchmarkMode(Mode.AverageTime)
> @Fork(value = 1, warmups = 0)
> @Warmup(iterations = 5)
> @Measurement(iterations = 10)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @State(Scope.Benchmark)
> public class MappedBufferBench {
>
>     private ByteBuffer bb;
>
>     @Setup(Level.Trial)
>     public void setup() {
>         bb = ByteBuffer.allocateDirect(64);
>     }
>
>     @Benchmark
>     public int directBufferGet() {
>         int sum = 0;
>         for (int i = 0; i < 64; i++) {
>             sum += bb.get(i);
>         }
>         return sum;
>     }
> }
>
>
> The results are:
>
> Original:
>
> Benchmark                                 Mode   Samples Score  Score
> error    Units
> j.t.MappedBufferBench.directBufferGet     avgt        10 17.740
> 0.247    ns/op
>
> Patched:
>
> Benchmark                                 Mode   Samples Score  Score
> error    Units
> j.t.MappedBufferBench.directBufferGet     avgt        10 17.796
> 0.220    ns/op
>
>
>
> What did I patch? There's a private method in DirectByteBuffer to convert
> index to address:
>
> Original:
>
>     private long ix(int i) {
>         return address + (i << 0);
>     }
>
> Patched:
>
>     private long ix(int i) {
>         long a = address;
>         if (a == 0L) throw new IllegalStateException();
>         return a + (i << 0);
>     }
>
>
>
> That's not all that has to be done of course. There would still have to be
> a wait for safe-point to return before unmapping. This is just a
> demonstration that maybe guarding mapping with protection is not needed.
>
>
> Regards, Peter
>
> On 09/10/2015 04:37 PM, David M. Lloyd wrote:
>
>> Or, the Java methods which wrap this access can just catch NPE and throw
>> the new exception type.
>>
>> On 09/10/2015 09:35 AM, Vitaly Davidovich wrote:
>>
>>> Well, you'd probably want something other than NPE here -- perhaps a new
>>> dedicated exception to signal this condition.  And this means the
>>> segfault
>>> handling now needs to know about this type of situation as well, rather
>>> than just NPEs.
>>>
>>> On Thu, Sep 10, 2015 at 10:32 AM, Andrew Haley <aph at redhat.com> wrote:
>>>
>>> On 09/10/2015 03:26 PM, Vitaly Davidovich wrote:
>>>>
>>>>> Yes, so what happens when that guard page is accessed by a thread after
>>>>>
>>>> safepoint?
>>>>
>>>> A segfault and a null pointer exception.
>>>>
>>>> Andrew.
>>>>
>>>>
>>>>
>>
>


From david.holmes at oracle.com  Fri Sep 11 06:15:40 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 11 Sep 2015 16:15:40 +1000
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CAHjP37ESKP=xv1H9ie+0oO5zmS7E-KPxmjpDQ4z_wOnN2pBhkA@mail.gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
	<55F1978A.6060801@redhat.com>
	<CAHjP37ESKP=xv1H9ie+0oO5zmS7E-KPxmjpDQ4z_wOnN2pBhkA@mail.gmail.com>
Message-ID: <55F2718C.70602@oracle.com>

On 11/09/2015 12:56 AM, Vitaly Davidovich wrote:
>>
>> Sure, if you like, but that's a detail.  We are arguing about what
>> colour to paint the bike shed.  :)
>
>
> The reason it may be more than just a bikeshed is because if this requires
> more cleverness in the segfault handler, then it's yet more work to make
> this happen.  I agree it's an implementation detail, but I don't think it's
> trivial (unless someone comes along and says that modifying the trap
> handler to account for this type of scenario is trivial).  One would also
> need to modify the safepoint code in the VM to allow skipping all the
> housekeeping it does typically, but I suspect this part is fairly easy.

Not sure how the safepoint code is supposed to know this particular 
safepoint is "special".

David
-----


> At any rate, this is probably the best that can be done if we don't want to
> expose the unsafe method.  Part of me wonders whether this attempt to
> preserve JVM integrity is really worth the cost; there're already ways to
> bring down the JVM (e.g. JNI, existing Unsafe usage, etc), and so putting a
> safety perimeter around this piece seems uninteresting (especially given
> that people today are already using unsafe hacks for this).  I do think,
> however, that avoiding safepoints on systems that allow atomic remapping
> would be needed, although that increases the complexity of the solution
> somewhat.
>
> On Thu, Sep 10, 2015 at 10:45 AM, Andrew Haley <aph at redhat.com> wrote:
>
>> On 09/10/2015 03:35 PM, Vitaly Davidovich wrote:
>>
>>> Well, you'd probably want something other than NPE here -- perhaps a
>>> new dedicated exception to signal this condition.
>>
>> Sure, if you like, but that's a detail.  We are arguing about what
>> colour to paint the bike shed.  :)
>>
>>> And this means the segfault handling now needs to know about this
>>> type of situation as well, rather than just NPEs.
>>
>> Maybe, but perhaps not.  The access to the guard page might just
>> trigger the usual segfault path, which (given an oop map) looks just
>> like a null pointer exception.
>>
>> Andrew.
>>


From peter.levart at gmail.com  Fri Sep 11 07:16:52 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 11 Sep 2015 09:16:52 +0200
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <CAHjP37EqtLdH132C5wCaCOYL4R+-h3QX-wkt+3JUhMcu-u30wQ@mail.gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
	<55F1959A.2070109@redhat.com> <55F20436.9030701@gmail.com>
	<CAHjP37EqtLdH132C5wCaCOYL4R+-h3QX-wkt+3JUhMcu-u30wQ@mail.gmail.com>
Message-ID: <55F27FE4.6020808@gmail.com>



On 09/11/2015 12:42 AM, Vitaly Davidovich wrote:
>
> There's still a race condition since someone may have passed the 
> guard, entered a safepoint, and then proceeded to access the memory.
>

Yeah, and I realized yesterday after posting that this wouldn't work for 
views of the buffer (dulicate(), slice(), asXxxBuffer()) since they copy 
over the address to their instance field, so multiple instances point to 
the same block of memory with their own address fields...

Regards, Peter

> sent from my phone
>
> On Sep 10, 2015 6:29 PM, "Peter Levart" <peter.levart at gmail.com 
> <mailto:peter.levart at gmail.com>> wrote:
>
>     Hi guys,
>
>     Perhaps there's no need for this protection/trap dance. If the
>     situation is never tripped in correct programs (that unmap only
>     after noone is using the buffers any more), then checking for
>     address and throwing in case it is equal to some guard value is a
>     never taken branch that is predicted perfectly. I wrote this
>     little benchmark to test this claim:
>
>     @BenchmarkMode(Mode.AverageTime)
>     @Fork(value = 1, warmups = 0)
>     @Warmup(iterations = 5)
>     @Measurement(iterations = 10)
>     @OutputTimeUnit(TimeUnit.NANOSECONDS)
>     @State(Scope.Benchmark)
>     public class MappedBufferBench {
>
>         private ByteBuffer bb;
>
>         @Setup(Level.Trial)
>         public void setup() {
>             bb = ByteBuffer.allocateDirect(64);
>         }
>
>         @Benchmark
>         public int directBufferGet() {
>             int sum = 0;
>             for (int i = 0; i < 64; i++) {
>                 sum += bb.get(i);
>             }
>             return sum;
>         }
>     }
>
>
>     The results are:
>
>     Original:
>
>     Benchmark                                 Mode   Samples Score 
>     Score error    Units
>     j.t.MappedBufferBench.directBufferGet     avgt        10 17.740   
>         0.247    ns/op
>
>     Patched:
>
>     Benchmark                                 Mode   Samples Score 
>     Score error    Units
>     j.t.MappedBufferBench.directBufferGet     avgt        10 17.796   
>         0.220    ns/op
>
>
>
>     What did I patch? There's a private method in DirectByteBuffer to
>     convert index to address:
>
>     Original:
>
>         private long ix(int i) {
>             return address + (i << 0);
>         }
>
>     Patched:
>
>         private long ix(int i) {
>             long a = address;
>             if (a == 0L) throw new IllegalStateException();
>             return a + (i << 0);
>         }
>
>
>
>     That's not all that has to be done of course. There would still
>     have to be a wait for safe-point to return before unmapping. This
>     is just a demonstration that maybe guarding mapping with
>     protection is not needed.
>
>
>     Regards, Peter
>
>     On 09/10/2015 04:37 PM, David M. Lloyd wrote:
>
>         Or, the Java methods which wrap this access can just catch NPE
>         and throw the new exception type.
>
>         On 09/10/2015 09:35 AM, Vitaly Davidovich wrote:
>
>             Well, you'd probably want something other than NPE here --
>             perhaps a new
>             dedicated exception to signal this condition.  And this
>             means the segfault
>             handling now needs to know about this type of situation as
>             well, rather
>             than just NPEs.
>
>             On Thu, Sep 10, 2015 at 10:32 AM, Andrew Haley
>             <aph at redhat.com <mailto:aph at redhat.com>> wrote:
>
>                 On 09/10/2015 03:26 PM, Vitaly Davidovich wrote:
>
>                     Yes, so what happens when that guard page is
>                     accessed by a thread after
>
>                 safepoint?
>
>                 A segfault and a null pointer exception.
>
>                 Andrew.
>
>
>
>



From volker.simonis at gmail.com  Fri Sep 11 08:14:11 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 11 Sep 2015 10:14:11 +0200
Subject: RFR 9: 8133552 : java/lang/ProcessHandle/InfoTest.java fails
	intermittently - incorrect user
In-Reply-To: <55F1B7F9.1060003@Oracle.com>
References: <55EF4E51.2030506@Oracle.com> <55EF548E.2060601@Oracle.com>
	<CA+3eh13kWTrmwoOpt3gQgV8iqkOqMirn0o6hJp+pgWGGD_K-Cg@mail.gmail.com>
	<55F064BE.1050401@Oracle.com> <55F0A96F.8020602@Oracle.com>
	<CA+3eh11FbqCoyxExkAZCTdQ2AsCca5CS3VwhLWkiLYmEDN24UA@mail.gmail.com>
	<55F1B7F9.1060003@Oracle.com>
Message-ID: <CA+3eh11tkfL+CXWOOEASp43tfq9Mj+xXsfrojqXJr0LOmcZc9w@mail.gmail.com>

Hi Roger,

looks good now.

Thanks,
Volker


On Thu, Sep 10, 2015 at 7:03 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi Volker,
>
> Thanks for the review, I added the code you provided to use the correct
> length.
>
> Updated the webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/
>
> Roger
>
>
>
> On 9/10/2015 11:52 AM, Volker Simonis wrote:
>
> On Wed, Sep 9, 2015 at 11:49 PM, Roger Riggs <Roger.Riggs at oracle.com> wrote:
>
> Hi,
>
> Please review this update to extract the uid on from the owner of the
> /proc/<pid> file.
> It should be more reliable than using the owner of the /proc/<pid>/cmdline
> file.
>
> Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-info-8133552/
>
> Hi Roger,
>
> the change looks good. I've only found one little problem:
>
> In:
>
> strncat(fn, "/cmdline", sizeof fn);
>
> 'fn' is not empty any more, so I think it should read:
>
> strncat(fn, "/cmdline", sizeof fn - strnlen(fn, sizeof fn) - 1);
>
> Also, increasing the timeout to 30 sec is reasonable.
>
> Thank you and best regards,
> Volker
>
> Thanks, Roger
>
>
>
> On 9/9/2015 12:56 PM, Roger Riggs wrote:
>
> Hi Volker,
>
> Thanks for the review and diagnosis.
>
> Can opening /proc/pid be used as a fallback if the st_uid is zero or
> is it worth the overhead of stat'ing /proc/pid always?
>
> Thanks, Roger
>
>
> On 9/9/2015 11:46 AM, Volker Simonis wrote:
>
> Hi Roger,
>
> I think your change looks good and it surely improves the test
> stability but I don't think it solves the problem in all cases.
>
> I think this problem is caused by a <defunct> (i.e. "zombie") process
> (the spawned process lived too short and was already a zombie when the
> info object was created). If you look at the proc-file system entry of
> a <defunct> process you can see that its 'cmdline' file has zero size
> and the file is owned by root. This is exactly what is reported by the
> corresponding info object in the bug report (user=root and no cmd
> field).
>
> We may need to improve the way how we get the uid of a pid on Linux.
> The current way of querying the owner of /proc/<pid>/cmdline seems to
> be unreliable. We may instead take the owner of /proc/<pid> which
> seems to be still the initial user of the process.
>
> Regards,
> Volker
>
>
> On Tue, Sep 8, 2015 at 11:35 PM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
> With link to webrev corrected:
>
> On 9/8/2015 5:08 PM, Roger Riggs wrote:
>
> Please review an intermittent test bug fix.
> The test setup time is very short and the user may be returned as 0
> which
> is reported as root.
> The correction lengthens the time allowed for the process to start.
>
> The test is removed from the ProblemList.
>
> Webrev:
>     http://cr.openjdk.java.net/~rriggs//webrev-info-8133552
>
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8133552
>
> Thanks, Roger
>
>


From aph at redhat.com  Fri Sep 11 08:37:10 2015
From: aph at redhat.com (Andrew Haley)
Date: Fri, 11 Sep 2015 09:37:10 +0100
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F2718C.70602@oracle.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
	<55F1978A.6060801@redhat.com>
	<CAHjP37ESKP=xv1H9ie+0oO5zmS7E-KPxmjpDQ4z_wOnN2pBhkA@mail.gmail.com>
	<55F2718C.70602@oracle.com>
Message-ID: <55F292B6.9000003@redhat.com>

On 09/11/2015 07:15 AM, David Holmes wrote:
> On 11/09/2015 12:56 AM, Vitaly Davidovich wrote:
>>>
>>> Sure, if you like, but that's a detail.  We are arguing about what
>>> colour to paint the bike shed.  :)
>>
>>
>> The reason it may be more than just a bikeshed is because if this requires
>> more cleverness in the segfault handler, then it's yet more work to make
>> this happen.  I agree it's an implementation detail, but I don't think it's
>> trivial (unless someone comes along and says that modifying the trap
>> handler to account for this type of scenario is trivial).  One would also
>> need to modify the safepoint code in the VM to allow skipping all the
>> housekeeping it does typically, but I suspect this part is fairly easy.
> 
> Not sure how the safepoint code is supposed to know this particular 
> safepoint is "special".

I guess I don't know what the problem is: when you request a safepoint you
also pass a code saying what you want to happen.

Andrew.



From david.holmes at oracle.com  Fri Sep 11 10:00:57 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 11 Sep 2015 20:00:57 +1000
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F292B6.9000003@redhat.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
	<55F1978A.6060801@redhat.com>
	<CAHjP37ESKP=xv1H9ie+0oO5zmS7E-KPxmjpDQ4z_wOnN2pBhkA@mail.gmail.com>
	<55F2718C.70602@oracle.com> <55F292B6.9000003@redhat.com>
Message-ID: <55F2A659.6040102@oracle.com>

On 11/09/2015 6:37 PM, Andrew Haley wrote:
> On 09/11/2015 07:15 AM, David Holmes wrote:
>> On 11/09/2015 12:56 AM, Vitaly Davidovich wrote:
>>>>
>>>> Sure, if you like, but that's a detail.  We are arguing about what
>>>> colour to paint the bike shed.  :)
>>>
>>>
>>> The reason it may be more than just a bikeshed is because if this requires
>>> more cleverness in the segfault handler, then it's yet more work to make
>>> this happen.  I agree it's an implementation detail, but I don't think it's
>>> trivial (unless someone comes along and says that modifying the trap
>>> handler to account for this type of scenario is trivial).  One would also
>>> need to modify the safepoint code in the VM to allow skipping all the
>>> housekeeping it does typically, but I suspect this part is fairly easy.
>>
>> Not sure how the safepoint code is supposed to know this particular
>> safepoint is "special".
>
> I guess I don't know what the problem is: when you request a safepoint you
> also pass a code saying what you want to happen.

There are actions that can also happen at a safepoint that are not part 
of the VMOperation for which the safepoint was initiated:

// Various cleaning tasks that should be done periodically at safepoints
void SafepointSynchronize::do_cleanup_tasks() {
   {
     TraceTime t1("deflating idle monitors", TraceSafepointCleanupTime);
     ObjectSynchronizer::deflate_idle_monitors();
   }

   {
     TraceTime t2("updating inline caches", TraceSafepointCleanupTime);
     InlineCacheBuffer::update_inline_caches();
   }
   {
     TraceTime t3("compilation policy safepoint handler", 
TraceSafepointCleanupTime);
     CompilationPolicy::policy()->do_safepoint_work();
   }

   {
     TraceTime t4("mark nmethods", TraceSafepointCleanupTime);
     NMethodSweeper::mark_active_nmethods();
   }

   if (SymbolTable::needs_rehashing()) {
     TraceTime t5("rehashing symbol table", TraceSafepointCleanupTime);
     SymbolTable::rehash_table();
   }

   if (StringTable::needs_rehashing()) {
     TraceTime t6("rehashing string table", TraceSafepointCleanupTime);
     StringTable::rehash_table();
   }

   // rotate log files?
   if (UseGCLogFileRotation) {
     gclog_or_tty->rotate_log(false);
   }

   {
     // CMS delays purging the CLDG until the beginning of the next 
safepoint and to
     // make sure concurrent sweep is done
     TraceTime t7("purging class loader data graph", 
TraceSafepointCleanupTime);
     ClassLoaderDataGraph::purge_if_needed();
   }
}

All the above happens at the end of SafepointSynchronize::begin, before 
the VMOperation is processed.

David
-----


> Andrew.
>


From vitalyd at gmail.com  Fri Sep 11 10:28:47 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Fri, 11 Sep 2015 06:28:47 -0400
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F2A659.6040102@oracle.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F02911.9030504@redhat.com> <55F02AEB.80101@redhat.com>
	<55F02D05.2050509@redhat.com> <55F02EE0.4040901@redhat.com>
	<55F03087.1010604@redhat.com> <55F0316B.7010303@redhat.com>
	<55F03A38.1070604@redhat.com> <55F03BA9.20304@redhat.com>
	<55F0DA0E.70506@oracle.com> <55F13873.8090204@redhat.com>
	<CAHjP37F-vwzP33WDfydspgWsMkzYuupJhqdEfJD_32kh5t_16g@mail.gmail.com>
	<55F18413.2010700@redhat.com> <55F18A38.4090004@redhat.com>
	<55F18E3D.8020200@redhat.com>
	<CAHjP37HF=sfW9nN8g3j7udGuUo-JnSDuq_KHWuqnwMmGENfyGg@mail.gmail.com>
	<55F1920C.1060509@redhat.com>
	<CAHjP37F0q9TVXidWSuebiWNaUOcTLObTr6ZOoJdnS=xd=gBs7w@mail.gmail.com>
	<55F1946B.5070704@redhat.com>
	<CAHjP37ECPwG38EE61W5Og4CTy+us16tifkgV0EL6i_Dz7NnvDQ@mail.gmail.com>
	<55F1978A.6060801@redhat.com>
	<CAHjP37ESKP=xv1H9ie+0oO5zmS7E-KPxmjpDQ4z_wOnN2pBhkA@mail.gmail.com>
	<55F2718C.70602@oracle.com> <55F292B6.9000003@redhat.com>
	<55F2A659.6040102@oracle.com>
Message-ID: <CAHjP37HzYoHW4vhGx27d6Edb=zebCP7+ao2kG46esUorHjXPVQ@mail.gmail.com>

Those are precisely the ones I was referring to that we'd want to avoid
when requesting a safepoint for this scenario.  That ought to be a matter
of simply passing a flag to safepoint synchronization telling it to skip
cleanup tasks.

sent from my phone
On Sep 11, 2015 6:01 AM, "David Holmes" <david.holmes at oracle.com> wrote:

> On 11/09/2015 6:37 PM, Andrew Haley wrote:
>
>> On 09/11/2015 07:15 AM, David Holmes wrote:
>>
>>> On 11/09/2015 12:56 AM, Vitaly Davidovich wrote:
>>>
>>>>
>>>>> Sure, if you like, but that's a detail.  We are arguing about what
>>>>> colour to paint the bike shed.  :)
>>>>>
>>>>
>>>>
>>>> The reason it may be more than just a bikeshed is because if this
>>>> requires
>>>> more cleverness in the segfault handler, then it's yet more work to make
>>>> this happen.  I agree it's an implementation detail, but I don't think
>>>> it's
>>>> trivial (unless someone comes along and says that modifying the trap
>>>> handler to account for this type of scenario is trivial).  One would
>>>> also
>>>> need to modify the safepoint code in the VM to allow skipping all the
>>>> housekeeping it does typically, but I suspect this part is fairly easy.
>>>>
>>>
>>> Not sure how the safepoint code is supposed to know this particular
>>> safepoint is "special".
>>>
>>
>> I guess I don't know what the problem is: when you request a safepoint you
>> also pass a code saying what you want to happen.
>>
>
> There are actions that can also happen at a safepoint that are not part of
> the VMOperation for which the safepoint was initiated:
>
> // Various cleaning tasks that should be done periodically at safepoints
> void SafepointSynchronize::do_cleanup_tasks() {
>   {
>     TraceTime t1("deflating idle monitors", TraceSafepointCleanupTime);
>     ObjectSynchronizer::deflate_idle_monitors();
>   }
>
>   {
>     TraceTime t2("updating inline caches", TraceSafepointCleanupTime);
>     InlineCacheBuffer::update_inline_caches();
>   }
>   {
>     TraceTime t3("compilation policy safepoint handler",
> TraceSafepointCleanupTime);
>     CompilationPolicy::policy()->do_safepoint_work();
>   }
>
>   {
>     TraceTime t4("mark nmethods", TraceSafepointCleanupTime);
>     NMethodSweeper::mark_active_nmethods();
>   }
>
>   if (SymbolTable::needs_rehashing()) {
>     TraceTime t5("rehashing symbol table", TraceSafepointCleanupTime);
>     SymbolTable::rehash_table();
>   }
>
>   if (StringTable::needs_rehashing()) {
>     TraceTime t6("rehashing string table", TraceSafepointCleanupTime);
>     StringTable::rehash_table();
>   }
>
>   // rotate log files?
>   if (UseGCLogFileRotation) {
>     gclog_or_tty->rotate_log(false);
>   }
>
>   {
>     // CMS delays purging the CLDG until the beginning of the next
> safepoint and to
>     // make sure concurrent sweep is done
>     TraceTime t7("purging class loader data graph",
> TraceSafepointCleanupTime);
>     ClassLoaderDataGraph::purge_if_needed();
>   }
> }
>
> All the above happens at the end of SafepointSynchronize::begin, before
> the VMOperation is processed.
>
> David
> -----
>
>
> Andrew.
>>
>>


From Roger.Riggs at Oracle.com  Fri Sep 11 15:30:06 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 11 Sep 2015 11:30:06 -0400
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection to
	discard output
Message-ID: <55F2F37E.20101@Oracle.com>

Please review a proposed [1] ProcessBuilder addition to define a 
Redirect that will discard output.
The implementation is to redirect output to /dev/null or NUL on Windows.

Please review and comment if there are any unexpected side effects.

Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/

Issue:
   https://bugs.openjdk.java.net/browse/JDK-8132541

Thanks, Roger

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034639.html


From miroslav.kos at oracle.com  Fri Sep 11 15:58:50 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Fri, 11 Sep 2015 17:58:50 +0200
Subject: [9] Review request JDK-8131667: JAX-WS Plugability Layer: using
	java.util.ServiceLoader
In-Reply-To: <55DF5656.9040606@oracle.com>
References: <55D4A2CB.70900@oracle.com> <55D60BD4.4090901@oracle.com>
	<55DF5656.9040606@oracle.com>
Message-ID: <55F2FA3A.6010406@oracle.com>

On 27/08/15 20:26, Miroslav Kos wrote:
> On 20/08/15 19:18, Alan Bateman wrote:
>> On 19/08/2015 16:37, Miroslav Kos wrote:
>>> Hi everybody,
>>>
>>> I am sending changes for review.
>>>
>>> CCC: http://ccc.us.oracle.com/8131667
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8131667
>>> webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.01/
>>>
>>> It's about migrating to standard java.util.ServiceLoader. This part 
>>> of service discovery was implemented previously "own" way. There are 
>>> some changes in javadoc and implementation has been refactored in 
>>> order to use same code as is in JAX-B and SAAJ.
>> I skimmed through this and it mostly looks okay. One thing that 
>> probably should be re-examined is the catch Exception in 
>> fromJDKProperties as an exception accessing or parsing 
>> jaxws.properties will be difficult to diagnose with the code as it is.
>>
>> -Alan
> Hi Alan,
> I added logging (at least for now) - would it work for you?
> updated webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.02/
>
> If you think the exception shouldn't be ignored I suggest to solve 
> this in separate issue (and maybe revisit all similar cases in 
> SAAJ/JAX-*)
>
> Thanks
> Miran
Hi Alan,
would you have some time to check the changes?

Thanks
Miran




From david.lloyd at redhat.com  Fri Sep 11 16:34:14 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 11 Sep 2015 11:34:14 -0500
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection
	to discard output
In-Reply-To: <55F2F37E.20101@Oracle.com>
References: <55F2F37E.20101@Oracle.com>
Message-ID: <55F30286.4010105@redhat.com>

Nifty, thanks!

On 09/11/2015 10:30 AM, Roger Riggs wrote:
> Please review a proposed [1] ProcessBuilder addition to define a
> Redirect that will discard output.
> The implementation is to redirect output to /dev/null or NUL on Windows.
>
> Please review and comment if there are any unexpected side effects.
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/
>
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8132541
>
> Thanks, Roger
>
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034639.html

-- 
- DML


From forax at univ-mlv.fr  Fri Sep 11 17:11:05 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 11 Sep 2015 19:11:05 +0200 (CEST)
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection
	to	discard output
In-Reply-To: <55F2F37E.20101@Oracle.com>
References: <55F2F37E.20101@Oracle.com>
Message-ID: <644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>

Great !,
minor comments,
nullFile should be NULL_FILE and @since 9 -> @since 1.9

regards,
R?mi

----- Mail original -----
> De: "Roger Riggs" <Roger.Riggs at Oracle.com>
> ?: "Core-Libs-Dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 11 Septembre 2015 17:30:06
> Objet: RFR: 8132541 : (process) ProcessBuilder support for redirection to	discard output
> 
> Please review a proposed [1] ProcessBuilder addition to define a
> Redirect that will discard output.
> The implementation is to redirect output to /dev/null or NUL on Windows.
> 
> Please review and comment if there are any unexpected side effects.
> 
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/
> 
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8132541
> 
> Thanks, Roger
> 
> [1]
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034639.html
> 


From Roger.Riggs at Oracle.com  Fri Sep 11 18:08:00 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 11 Sep 2015 14:08:00 -0400
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection
	to discard output
In-Reply-To: <644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
References: <55F2F37E.20101@Oracle.com>
	<644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
Message-ID: <55F31880.6000207@Oracle.com>

Hi Remi,

I corrected the NULL_FILE naming.

The versioning for 9 (see Project Verona) will be dropping the leading 
"1."  so I thought
to start now.

When Verona is committed, it will include a bulk change of "1.9" to "9".

Thanks, Roger


On 9/11/2015 1:11 PM, Remi Forax wrote:
> Great !,
> minor comments,
> nullFile should be NULL_FILE and @since 9 -> @since 1.9
>
> regards,
> R?mi
>
> ----- Mail original -----
>> De: "Roger Riggs" <Roger.Riggs at Oracle.com>
>> ?: "Core-Libs-Dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Vendredi 11 Septembre 2015 17:30:06
>> Objet: RFR: 8132541 : (process) ProcessBuilder support for redirection to	discard output
>>
>> Please review a proposed [1] ProcessBuilder addition to define a
>> Redirect that will discard output.
>> The implementation is to redirect output to /dev/null or NUL on Windows.
>>
>> Please review and comment if there are any unexpected side effects.
>>
>> Webrev:
>>     http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/
>>
>> Issue:
>>     https://bugs.openjdk.java.net/browse/JDK-8132541
>>
>> Thanks, Roger
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034639.html
>>



From mandy.chung at oracle.com  Sat Sep 12 22:44:30 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Sat, 12 Sep 2015 15:44:30 -0700
Subject: RFR: 8033661: readConfiguration does not cleanly reinitialize the
	logging system
In-Reply-To: <55F06497.5010300@oracle.com>
References: <55F06497.5010300@oracle.com>
Message-ID: <1F185ECE-B5B1-4175-ABAA-B86FCD0861EC@oracle.com>


> On Sep 9, 2015, at 9:55 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a candidate fix for:
> 
> 8033661: readConfiguration does not cleanly reinitialize the
>         logging system
> https://bugs.openjdk.java.net/browse/JDK-8033661
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.00/
> 
> LogManager.readConfiguration() presents a number of flaws that may not
> be fixable without endangering backward compatibility, or stability.
> Some of them have been quite aptly summed up in JDK-8033661.

Thanks for the detailed analysis.  I agree that adding a new method to reinitialize the logging configuration is the right thing to do. 

Have you considered keeping the same method name, readConfiguration with the new remapper parameter?  The downside is the difference that the reset is not invoked.  It might not matter because as you add in @apiNote that the existing readConfiguration method may be overridden for custom LogManager but discouraged to be used by applications.  Related question: should the existing readConfiguration methods be deprecated and recommend to use the new method(s)?   Can custom LogManager call updateConfiguration in their constructor instead of overriding readConfiguration?  If the existing readConfiguration methods should be deprecated, i think keeping the same method name may be a better choice.

1749      * Updates an existing configuration.

We should specify what ?existing configuration? is. If ?java.util.logging.config.class? is set and it?s instantiated successfully, readConfiguration will not read from any configuration file.  updateConfiguration only reads the config file regardless if ?java.util.logging.config.class? is set.

1761      * @param remapper 

?re? probably not needed here.   I think ?mapper? should work.

Use @throws instead of @exception

VisitedLogger class:
1714         public static VisitedLoggers of(Map<Logger, String> visited) {
1715             assert visited == null || visited instanceof IdentityHashMap;
1716             return visited == null ? NEVER : new VisitedLoggers(visited);
1717         }

Instead of doing the assert, what about changing the parameter type to IdentityHashMap?

Is VisitedLoggers class necessary?  Would it be more explicit to readers to use a Set (it doesn?t need to be a map) that each logger is visited once?  

ConfigurationProperties class: This enum class is also a Predicate and it has several static methods for updateConfiguratoin to use e.g.

final Stream<String> allKeys = updatePropertyNames.stream()
        .filter(ConfigurationProperties::isOf)
        .filter(k -> ConfigurationProperties.isChanging(k, previous, next));

I have to read the comment and follow the implementation of these methods to figure out what it?s going on here.  It could be simplified and made the code easily to tell what are being filtered here.   It seems to me that you want to define LevelProperty, HandlerProperty, UseParentProperty types, each of which will handle any change (as it?s currently done in the switch statement). 

ConfigurationProperties.ALL - why not use ConfigurationProperties.values()?

Mandy



From withoutpointk at gmail.com  Sun Sep 13 09:08:52 2015
From: withoutpointk at gmail.com (Adrian)
Date: Sun, 13 Sep 2015 05:08:52 -0400
Subject: URLClassPath does unnecessary linear search through every jar and jar
	entry to find resource
Message-ID: <CAL_yH3i8-jTORx_oHVbA_ATXGiRtkqd5g==82EWfpyge7xbOmQ@mail.gmail.com>

Hi,

I posted about this earlier (few weeks ago), and got some responses
about concerns which I addressed in my last email, though I didn't
hear back about it.
My apologies if I shouldn't be sending this; I'm not sure what the
protocol is about this stuff

Classloading on a standard Java application with jars on the classpath
currently does a linear search through every jar on the classpath, and
every entry in a jar, for every class loaded.
As URLClassPath searches for an entry/resource/class, it's possible to
cache each entry it encounters -> where to find it, so in the future
if a resource has already been seen we don't need to repeat the ~2d
search

Original thread (august list):
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/035009.html
Last message (september list):
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035016.html

I got 3 responses: 2 concerning changes to jars at runtime
(invalidating cache), and 1 saying you're not supposed to modify jars
at runtime (can confirm via source code, and manual testing - it
crashes the JVM)

In my last message I addressed
- jars being modified (which you're not supposed to do; the current
classloader does not handle this) or the classpath changing (only
possible if you make public fields/methods via reflection, and this
could easily be handled gracefully)
- some details of the finding resource process (e.g. the meta index,
when the cache for jar entries can't be used because of the semantics
of other loaders/types of entries on the classpath)
- a reference implementation of caching that I believe is simple and
compliant with existing functionality
- some basic numbers on performance

---
So in this email I wanted to explain the problem again, hopefully more
clearly now

URLClassPath is used by URLClassLoader to find classes, though it
could be used for finding any resource on a classpath.
URLClassPath keeps an array of URLs, which are typically folders or
jars on the local filesystem.
They can be http or ftp or other files, but that's not
relevant/doesn't affect this problem

To find a resource/class (URLClassPath#getResource), it:
1. Loops through the URLs in order
2. Creates Loader objects for each URL lazily (URLClassPath$FileLoader
or URLClassPath$JarLoader). So if the Loader for the first URL finds
all the resources, Loaders for the remaining entries on the classpath
are never created/looked at
3. Calls Loader#getResource and returns the resource if found
(otherwise keep searching)

URLClassPath$JarLoader creates its corresponding JarFile either in the
constructor or in getResource (depending on the meta index - the
details I explained in my last email I won't repeat)
When a JarFile is created, it opens the jar file on the file system,
reads the central directory of the jar/zip file, and creates an
internal linked list with all its entries

JarFile objects are immutable; you can only open them for read/delete
(see constructor API
http://docs.oracle.com/javase/7/docs/api/java/util/jar/JarFile.html#JarFile(java.io.File,%20boolean,%20int)
), they do not detect if the file has been modified externally, and
you only "append" or "delete" entries by creating a new jar
(JarOutputStream)

When URLClassPath$JarLoader#getResource calls JarFile#getEntry; in the
C code it searches through the linked list
(jdk/src/share/native/java/util/zip/zip_util.c, ZIP_GetEntry - jar
files are just zip files, and the java JarFile object just extends
ZipFile)

Since the order in which jar files and jar entries are searched is
invariant, we can create a map of resource -> first jar which contains
it

However, we don't want to introduce additional overhead.
When a JarFile is created, it already builds the internal linked list
- it's O(number of entries)
I propose that after the JarLoader creates the JarFile, it iterates
through its entries and adds them to the cache (if the map does not
already contain the resource, i.e. an earlier jar contains the
resource)
This adds a small overhead when instantiating loaders - but creating
the JarLoader/JarFile is still technically O(number of entries), and
now getResource is constant time, instead of requiring a linear search
through every jar and the linked list of entries for each jar
(O(number of jars * entries/jar))

There are several caveats when the cache cannot be used with non-jar
URLs on the classpath, and the meta index, but I explain them in my
last email along with comments in the reference implementation

---
Regarding modified jars:
- moved/renamed: the file handle is still valid and it doesn't affect
the JVM/classloading
- deleted: the file handle is still valid and it doesn't affect the
JVM/classloading
- modified: the JVM crashes

The first two may not be intuitive, but remember that file handles
point to files; not paths on the filesystem.
So even though a jar appears renamed in the shell, the java process
has opened a file, somewhere in the c implementation of file objects
it has the file handle, and when the JVM does the system call read on
the file handle say to read the class from the jar file, it all works
fine
For what it's worth, here's a stack overflow answer as "source":
http://stackoverflow.com/questions/2028874/what-happens-to-an-open-file-handler-on-linux-if-the-pointed-file-gets-moved-de

---
There is a protected method URLClassLoader#addURL which appends a URL
to the classpath.
People could use reflection to make it public.
Because jars are opened lazily and the cache is also built lazily
whenever a jar is opened, it doesn't matter if paths are appended

Regarding people making extensive use of reflection to modify the
order of entries on the classpath, I believe that's irrelevant as
that's clearly not the semantic of URLClassLoader/URLClassPath.
People who need custom classloading rules create custom classloaders;
that's the purpose of classloaders being extensible

---
Anyways, I hope this was discussion worthy.
I've looked much into this and believe I haven't missed anything, but
if someone knows why it hasn't/can't be done any insight would be
appreciated!
Alan from the last email thread said "There was a lot of experiments
and prototypes in the past along these lines" - are the results
public?
He also mentioned improving classloading in Java's upcoming module
system (originally planned for Java 7, currently delayed to Java 9),
but I believe the algorithmic complexity and performance of
URLClassLoader could be improved without complicated changes

Please let me know what you think, and thanks for your time!

Best regards,
Adrian


From alexander.v.stepanov at oracle.com  Sun Sep 13 15:25:45 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Sun, 13 Sep 2015 18:25:45 +0300
Subject: RFR [9] 8133650: replace some <tt> tags (obsolete in html5) in CORBA
	docs
Message-ID: <55F59579.9000206@oracle.com>

Hello,

Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133650/webrev.00/
for
https://bugs.openjdk.java.net/browse/JDK-8133650

Just another portion of deprecated <tt> tags replaced with {@code }.

A single (expected) change was indicated by specdiff (in ORB.java).

Thanks,
Alexander


From lance.andersen at oracle.com  Sun Sep 13 16:10:30 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sun, 13 Sep 2015 12:10:30 -0400
Subject: RFR [9] 8133650: replace some <tt> tags (obsolete in html5) in
	CORBA docs
In-Reply-To: <55F59579.9000206@oracle.com>
References: <55F59579.9000206@oracle.com>
Message-ID: <2A0EEC8F-B07C-4F66-BFD4-FD8ABDE74B7E@oracle.com>

I did not see any issues looking at the udiffs.  I assume based on your specdiff comment this should be good to go

On Sep 13, 2015, at 11:25 AM, Alexander Stepanov <alexander.v.stepanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~avstepan/8133650/webrev.00/



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 alexander.v.stepanov at oracle.com  Sun Sep 13 17:38:48 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Sun, 13 Sep 2015 20:38:48 +0300
Subject: RFR [9] 8133650: replace some <tt> tags (obsolete in html5) in
	CORBA docs
In-Reply-To: <2A0EEC8F-B07C-4F66-BFD4-FD8ABDE74B7E@oracle.com>
References: <55F59579.9000206@oracle.com>
	<2A0EEC8F-B07C-4F66-BFD4-FD8ABDE74B7E@oracle.com>
Message-ID: <55F5B4A8.5080100@oracle.com>

Thanks!

Regards,
Alexander

On 9/13/2015 7:10 PM, Lance Andersen wrote:
> I did not see any issues looking at the udiffs.  I assume based on 
> your specdiff comment this should be good to go
>
> On Sep 13, 2015, at 11:25 AM, Alexander Stepanov 
> <alexander.v.stepanov at oracle.com 
> <mailto:alexander.v.stepanov at oracle.com>> wrote:
>
>> http://cr.openjdk.java.net/~avstepan/8133650/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Eavstepan/8133650/webrev.00/>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From daniel.fuchs at oracle.com  Mon Sep 14 08:48:55 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 14 Sep 2015 10:48:55 +0200
Subject: RFR: 8033661: readConfiguration does not cleanly reinitialize the
	logging system
In-Reply-To: <1F185ECE-B5B1-4175-ABAA-B86FCD0861EC@oracle.com>
References: <55F06497.5010300@oracle.com>
	<1F185ECE-B5B1-4175-ABAA-B86FCD0861EC@oracle.com>
Message-ID: <55F689F7.2060407@oracle.com>

Hi Mandy,

Thanks a lot for the feedback!

On 13/09/15 00:44, Mandy Chung wrote:
>
>> On Sep 9, 2015, at 9:55 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> Hi,
>>
>> Please find below a candidate fix for:
>>
>> 8033661: readConfiguration does not cleanly reinitialize the
>>          logging system
>> https://bugs.openjdk.java.net/browse/JDK-8033661
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.00/
>>
>> LogManager.readConfiguration() presents a number of flaws that may not
>> be fixable without endangering backward compatibility, or stability.
>> Some of them have been quite aptly summed up in JDK-8033661.
>
> Thanks for the detailed analysis.  I agree that adding a new method to
> reinitialize the logging configuration is the right thing to do.
>
> Have you considered keeping the same method name, readConfiguration with
> the new remapper parameter?  The downside is the difference that the
> reset is not invoked.

No - I didn't consider it. The algorithm implemented by the new
method is quite different from what was implemented in the
previous readConfiguration() methods - so the idea of overloading
readConfiguration() didn't come to my mind.

>  It might not matter because as you add in @apiNote that the existing
>  readConfiguration method may be overridden for custom LogManager but
>  discouraged to be used by applications.

> Related question: should the existing readConfiguration methods be
> deprecated and recommend to use the new method(s)?

What I see is that the old readConfiguration does the appropriate job
when called for the first time, before any logger has been created.
There is probably some application out there that override it to
install their own configuration.
For this reason I am not sure if it should be deprecated.

>  Can custom LogManager call updateConfiguration in their constructor
>  instead of overriding readConfiguration?

I believe that would be bad - it would go against what we've been
trying to do with https://bugs.openjdk.java.net/browse/JDK-8023168


> If the existing readConfiguration methods should be deprecated,
> i think keeping the same method name may be a better choice.

I'll leave the decision for that (keeping the same name) to you.
I'm not sure we can deprecate the old methods.
IMHO it is difficult to deprecate a method that is actually
called internally by LogManager, and stop calling it would be
risky WRT to compatibility.


>
> 1749      * Updates an existing configuration.
>
> We should specify what ?existing configuration? is.
> If ?java.util.logging.config.class? is set and it?s instantiated successfully,
> readConfiguration will not read from any configuration file.
> updateConfiguration only reads the config file regardless if
> ?java.util.logging.config.class? is set.

Right. That's a good point.

> 1761      * @param remapper
>
> ?re? probably not needed here.   I think ?mapper? should work.

OK


> Use @throws instead of @exception

OK

>
> VisitedLogger class:
> 1714         public static VisitedLoggers of(Map<Logger, String> visited) {
> 1715             assert visited == null || visited instanceof IdentityHashMap;
> 1716             return visited == null ? NEVER : new VisitedLoggers(visited);
> 1717         }
>
> Instead of doing the assert, what about changing the parameter type to IdentityHashMap?

can do.

>
> Is VisitedLoggers class necessary?  Would it be more explicit to readers to use a Set (it doesn?t need to be a map) that each logger is visited once?

We don't have an IdentityHashSet - which is the reason while I'm using
an IdentityHashMap here.

> ConfigurationProperties class: This enum class is also a Predicate and
> it has several static methods for updateConfiguratoin to use e.g.
>
> final Stream<String> allKeys = updatePropertyNames.stream()
>          .filter(ConfigurationProperties::isOf)
>          .filter(k -> ConfigurationProperties.isChanging(k, previous, next));
>
> I have to read the comment and follow the implementation of these methods to figure
> out what it?s going on here.  It could be simplified and made the code easily
> to tell what are being filtered here.

> It seems to me that you want to define LevelProperty, HandlerProperty, UseParentProperty types,
> each of which will handle any change (as it?s currently done in the switch statement).

yes - which is why the enum is useful - as it allows to model all
these.

>
> ConfigurationProperties.ALL - why not use ConfigurationProperties.values()?

Well - I could reverse the question :-)

best regards,

-- daniel


>
> Mandy
>



From paul.sandoz at oracle.com  Mon Sep 14 10:24:35 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 14 Sep 2015 12:24:35 +0200
Subject: Collections.emptyList().spliterator() is not ORDERED
In-Reply-To: <3D197E7F-CF35-44C1-B0B7-DC9C9DAE513E@oracle.com>
References: <726458471.20150906162111@gmail.com>
	<4B4AA2BA-DA81-486A-ACFA-8CBF2FB57DDE@oracle.com>
	<792598028.20150907152032@gmail.com>
	<3D197E7F-CF35-44C1-B0B7-DC9C9DAE513E@oracle.com>
Message-ID: <2CE95009-4024-475D-AC8A-734ADF2C8E17@oracle.com>

On 7 Sep 2015, at 15:23, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>> By the way, probably it's reasonable then for Arrays.asList to check
>> the array length like:
>> 
>>   public static <T> List<T> asList(T... a) {
>>       if(a.length == 0)
>>         return Collections.emptyList();
>>       return new ArrayList<>(a);
>>   }
>> 
>> This would make Arrays.asList() (without arguments) and
>> Collections.emptyList() perfectly consistent (now their spliterators
>> report different characteristics) and reduce the number of heap
>> objects. Probably there are some caveats I'm not aware of. Sorry if it
>> was already discussed.
>> 
> 
> This has not been discussed, it?s an edge case micro-optimisation but seems reasonable.
> 

There is a reason not to do this. At the moment Arrays.asList specifies no constraints on the identity of the returned List. Adding the micro-optimisation will change that. It?s an edge case and a questionable use-case too, but considering that i would conservatively leave things as they are.

Paul.


From asashour at yahoo.com  Mon Sep 14 11:05:43 2015
From: asashour at yahoo.com (Ahmed Ashour)
Date: Mon, 14 Sep 2015 11:05:43 +0000 (UTC)
Subject: Space before comma
Message-ID: <841658402.2141441.1442228743970.JavaMail.yahoo@mail.yahoo.com>

Hi all,
I would like to prepare a patch for removing space before comma in .java files of 'jdk9/dev/jdk'. ?Of course, there are places where spaces are needed for vertical alignment with previous/next lines.
Would that add a value, or there is no need for such a patch?
P.S. I signed the OCA
Thanks,Ahmed

From rob.mckenna at oracle.com  Mon Sep 14 15:25:32 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 14 Sep 2015 16:25:32 +0100
Subject: RFR: 8129957 - Deadlock in JNDI LDAP implementation when closing
	the LDAP context
In-Reply-To: <55C8A1DD.7020508@oracle.com>
References: <55C8A1DD.7020508@oracle.com>
Message-ID: <55F6E6EC.2020300@oracle.com>

Hi folks,

So on further investigation it looks like we could get away with 
reducing the amount of locking in LdapClient. Here is a proposed fix 
followed by a description:

http://cr.openjdk.java.net/~robm/8129957/webrev.02/

processConnectionClosure():
- Remove the synchronization from processConnectionClosure and handle it 
further down in notifyUnsolicited

removeUnsolicited():
- Remove the synchronized block in removeUnsolicited as its redundant. 
Vectors are synchronized already.

processUnsolicited()
- Remove the initial synchronized block in processUnsolicited and limit 
it to the area around the unsolicited size check / notice creation. 
(again, due to the notifyUnsolicited changes)
- Remove the redundant unsolicited.size check from the end of 
processUnsolicited

notifyUnsolicited():
- Synchronize on the unsolicited vector in order to create a copy of 
that vector and empty it if e is a NamingException.
- Outside the notifyUnsolicited synchronize block, loop through the copy 
of unsolicited and call fireUnsolicited on each element.
- The main potential problem with this fix would be if an LdapCtx became 
unsolicited before we got to it in the for loop. However since both 
LdapCtx.fireUnsolicited and LdapCtx.removeUnsolicited sync on 
eventSupport and LdapCtx.fireUnsolicited double checks to make sure it 
is still unsolicited, that should be fine.

	-Rob


On 10/08/15 14:06, Rob McKenna wrote:
> Hi folks,
>
> We have a hang between LdapClient / Ctx due to the fact that
> Connection.cleanup() calls LdapClient.processConnectionClosure which
> locks the unsolicited vector and in turn calls LdapCtx.fireUnsolicited
> which locks the eventSupport object. Unfortunately when an
> LdapCtx.close() occurs at the same time, its removeUnsolicited method
> locks the eventSupport object first and then attempts to call
> LdapClient.removeUnsolicited which attempts to lock the unsolicited vector.
>
> So:
>
> thread 1:
>
> Connection.cleanup ->
> LdapClient.processConnectionClosure (LOCK VECTOR) ->
> LdapCtx.fireUnsolicited (LOCK EVENTSUPPORT)
>
> (LdapClient is looping through LdapCtx objects in the unsolicited vector)
>
> thread 2:
>
> LdapCtx.close (LOCK LDAPCTX) ->
> LdapCtx.removeUnsolicited (LOCK EVENTSUPPORT) ->
> LdapClient.removeUnsolicited (LOCK VECTOR)
>
> (A single LdapCtx removes itself from its LdapClient unsolicited list)
>
>
> My proposed solution is to have both threads lock the LdapClient before
> locking either the unsolicited vector or the eventSupport object.
>
> Webrev at: http://cr.openjdk.java.net/~robm/8129957/webrev.01/
>
>      -Rob


From kim at galatea-associates.com  Thu Sep 10 13:47:02 2015
From: kim at galatea-associates.com (Carolyn Kim)
Date: Thu, 10 Sep 2015 09:47:02 -0400
Subject: Fwd: Question about CachedRowSetImpl
In-Reply-To: <CA+rSem9s4D=nmeEfqwVFjTObd57GPkwfUk3JNVGToR5fPvkgpw@mail.gmail.com>
References: <CA+rSem9s4D=nmeEfqwVFjTObd57GPkwfUk3JNVGToR5fPvkgpw@mail.gmail.com>
Message-ID: <CA+rSem-QcHEXndo=S_RQXF=6aqZ=-MwM4e4SgYLRH_cfPabj1w@mail.gmail.com>

Hi,

I have a question about CachedRowSetImpl. I'm trying to use its pagination
function. But it seems like it does not work with populate method. I think
I'm seeing the same issue that's described here:
https://bugs.openjdk.java.net/browse/JDK-6382534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel

I am currently using JDK 7.55 and I'm still seeing this issue. Could you
tell me which version of JDK includes this fix?

Thank you very much,
Carolyn


From markrmiller at gmail.com  Wed Sep  9 16:01:23 2015
From: markrmiller at gmail.com (Mark Miller)
Date: Wed, 09 Sep 2015 16:01:23 +0000
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F05447.1040107@gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F04070.1030006@gmail.com> <55F0461A.2070005@gmail.com>
	<CAM21Rt9gFwZFxwRiAP16AR7gakc4_rDcZUNmdHr98uVYFwJJ1Q@mail.gmail.com>
	<55F05447.1040107@gmail.com>
Message-ID: <CAOGUouwNrd7RtZzkYzqF8=EkZkUzFY4JdE9jmaNzTLd9aY5eBg@mail.gmail.com>

It seems less than ideal to count on System.gc to do this as a library
though.

Now the user has to worry about what affect System.gc has on what JVM with
what Garbage Collector and whether or not ExplicitGCInvokesConcurrent was
turned on for the JVM, or...

- Mark

On Wed, Sep 9, 2015 at 11:46 AM Peter Levart <peter.levart at gmail.com> wrote:

>
>
> On 09/09/2015 04:56 PM, Dawid Weiss wrote:
> >> I think it would be best to leave to the application to decide and
> >> implement the tracking and also triggering GC at times when it
> approaches
> >> the limit.
> > I disagree. The GC -- when and how it is triggered -- should be
> > transparent to the application. We don't want to manage GC, we want to
> > (truly) release the resources we allocated (and we know when they are
> > no longer needed).
> >
> > What you suggest is essentially managing GC from application level. I
> > don't think it's the right approach to solve the problem.
> >
> > Dawid
>
> Hi Dawid,
>
> By wanting to truly release the resources you allocated, you are
> essentially wanting to manage the resources yourself. If you are willing
> to track the active mapped byte buffers manually yourself, then what
> about the following idea:
>
> - you track the number of mapped buffers (or mapped address space) that
> you "know" is active in the application manually.
> - you track the number of mapped buffers (or mapped address space) that
> is actually mapped at a particular time (by utilizing an after-unmap
> call-back that would have to be added to MappedByteBuffer API)
> - when the difference of those two tracked quantities reaches certain
> amount or percentage, you give a kick to GC to do it's job, as it is
> lagging behind.
>
> I would not call this managing GC, but just hinting GC at the right
> time. The most burden in this approach would be the manual tracking of
> active buffers, but you are willing to do that anyway by wanting to
> manually release the resources. Everything else can be made automatic.
>
>
> Regards, Peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at lucene.apache.org
> For additional commands, e-mail: dev-help at lucene.apache.org
>
> --
- Mark
about.me/markrmiller


From rcmuir at gmail.com  Wed Sep  9 15:53:39 2015
From: rcmuir at gmail.com (Robert Muir)
Date: Wed, 9 Sep 2015 11:53:39 -0400
Subject: Suggested fix for JDK-4724038 (Add unmap method to
	MappedByteBuffer)
In-Reply-To: <55F05447.1040107@gmail.com>
References: <033e01d0eaed$7ec039a0$7c40ace0$@apache.org>
	<55F04070.1030006@gmail.com> <55F0461A.2070005@gmail.com>
	<CAM21Rt9gFwZFxwRiAP16AR7gakc4_rDcZUNmdHr98uVYFwJJ1Q@mail.gmail.com>
	<55F05447.1040107@gmail.com>
Message-ID: <CAOdYfZU8go1d+NVUwrW+AHu59ujnid08Mrdaq_NEMePLsa9WZw@mail.gmail.com>

On Wed, Sep 9, 2015 at 11:46 AM, Peter Levart <peter.levart at gmail.com> wrote:
>
> By wanting to truly release the resources you allocated, you are essentially
> wanting to manage the resources yourself. If you are willing to track the
> active mapped byte buffers manually yourself, then what about the following
> idea:
>

As Uwe mentioned that is probably not truly necessary. If lucene
cannot delete a file, it retries it later periodically until it works.
So if things were unmapped "soonish", for the lucene case things would
be fine I think.

I do realize other apps may not have that infrastructure/luxury...


From daniel.fuchs at oracle.com  Mon Sep 14 16:25:59 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 14 Sep 2015 18:25:59 +0200
Subject: RFR: 8033661: readConfiguration does not cleanly reinitialize the
	logging system
In-Reply-To: <1F185ECE-B5B1-4175-ABAA-B86FCD0861EC@oracle.com>
References: <55F06497.5010300@oracle.com>
	<1F185ECE-B5B1-4175-ABAA-B86FCD0861EC@oracle.com>
Message-ID: <55F6F517.8000100@oracle.com>

Hi Mandy,

On 13/09/15 00:44, Mandy Chung wrote:
> Have you considered keeping the same method name, readConfiguration
> with the new remapper parameter?  The downside is the difference that
> the reset is not invoked.  It might not matter because as you add in
> @apiNote that the existing readConfiguration method may be overridden
> for custom LogManager but discouraged to be used by applications.

I have reworked the API notes...

The class level documentation says:

  * <p>
  * If the "java.util.logging.config.class" property is set, then the
  * property value is treated as a class name.  The given class will be
  * loaded, an object will be instantiated, and that object's constructor
  * is responsible for reading in the initial configuration.  (That object
  * may use other system properties to control its configuration.)  The
  * alternate configuration class can use {@code 
readConfiguration(InputStream)}
  * to define properties in the LogManager.


So with that in mind, I have slightly altered the @apiNotes:

in readConfiguration():

      * @apiNote {@code readConfiguration} is principally useful for
      *    establishing the LogManager primordial configuration.
      *    <p>
      *    Calling this method directly from the application code after the
      *    LogManager has been initialized is discouraged.

           etc...

The rationale is that an application which needs to establish
a custom configuration should probably use the
{@code "java.util.logging.config.class"} property, and
call LogManager.readConfiguration(InputStream) from there,
as hinted in the class-level documentation.

in readConfiguration(InputStream):

      * @apiNote {@code readConfiguration} is principally useful for 
applications
      *    which use the {@code "java.util.logging.config.class"} property
      *    to establish their own custom configuration.
      *    <p>
      *    Calling this method directly from the application code after the
      *    LogManager has been initialized is discouraged.

Same rationale than above. After thinking it over I'm not
sure overriding readConfiguration is something we should
encourage. I would prefer some wording that does not imply
it :-)

>
> 1749      * Updates an existing configuration.
>
> We should specify what ?existing configuration? is.
> If ?java.util.logging.config.class? is set and it?s instantiated successfully,
> readConfiguration will not read from any configuration file.
> updateConfiguration only reads the config file regardless
> if ?java.util.logging.config.class? is set.

I updated the doc for updateConfiguration(mapper):

      * Updates an existing configuration.
      * <p>
      * @implSpec
      * This is equivalent to calling:
      * <pre>
      *   try (final InputStream in = new 
FileInputStream(&lt;logging.properties&gt;)) {
      *       final BufferedInputStream bin = new BufferedInputStream(in);
      *       updateConfiguration(bin, mapper);
      *   }
      * </pre>
      * where {@code <logging.properties>} is the logging configuration 
file path.
      * <p>
      * Note that this method not take into account the value of the
      * {@code "java.util.logging.config.class"} property.
      * The {@code "java.util.logging.config.file"} system property is read
      * to find the logging properties file, whether the
      * {@code "java.util.logging.config.class"} property is set or not.
      * If the {@code "java.util.logging.config.file"} system property 
is not
      * defined then the default configuration is used.
      * The default configuration is typically loaded from the 
properties file
      * "{@code conf/logging.properties}" in the Java installation 
directory.
      *

in updateConfiguration(InputStream, mapper), after the table:

      * <p>
      * Note that this method has no special handling for the "config" 
property.
      * The new value provided by the mapper function will be stored in the
      * LogManager properties, but {@code updateConfiguration} will not 
parse its
      * value nor instantiate the classes it points to.


>
> 1761      * @param remapper
>
> ?re? probably not needed here.   I think ?mapper? should work.

OK. Should I still use the term of 'remapping function' then?
Or does that become 'mapping function' too?


Here is the new webrev - with the other comments from your previous
mail also integrated:

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

best regards,

-- daniel




From Roger.Riggs at Oracle.com  Mon Sep 14 17:23:13 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 14 Sep 2015 13:23:13 -0400
Subject: Space before comma
In-Reply-To: <841658402.2141441.1442228743970.JavaMail.yahoo@mail.yahoo.com>
References: <841658402.2141441.1442228743970.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <55F70281.9030707@Oracle.com>

Hi Ahmed,

Such a changeset doesn't add much value by itself.  Have you looked for 
some small scale
bug that would be interesting?  Try looking for issues with a label like 
jdk-starter. [1]

Pick something that seems obvious and you feel you can completely understand
the issue, how to write a test first to prove its an issue, and then the 
bug fix
that passes the test.

Roger

[1] query like:  labels in (starter, starterbugs, starterbug, 
starter_bugs, starter_bug, starter-bug, starter-bugs, openjdk-starter, 
jdk-starter) AND resolution = unresolved


On 9/14/2015 7:05 AM, Ahmed Ashour wrote:
> Hi all,
> I would like to prepare a patch for removing space before comma in .java files of 'jdk9/dev/jdk'.  Of course, there are places where spaces are needed for vertical alignment with previous/next lines.
> Would that add a value, or there is no need for such a patch?
> P.S. I signed the OCA
> Thanks,Ahmed



From joe.darcy at oracle.com  Tue Sep 15 00:30:01 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 14 Sep 2015 17:30:01 -0700
Subject: JDK 9 RFR of JDK-8136506: Include sun.arch.data.model as a property
	that can be queried by jtreg
Message-ID: <55F76689.10903@oracle.com>

Hello,

Please review the patch below for

     JDK-8136506: Include sun.arch.data.model as a property that can be 
queried by jtreg

The jtreg TEST.ROOT file in the HotSpot repository puts

sun.arch.data.model

on the list of properties which can be queried by an @requires clause in 
jtreg. This property lets one determine if a jdk/jre is 32-bits or 64-bits.

It would be convenient and consistent for this property to be available 
to be queried by tests in the jdk repo too.

Thanks,

-Joe

diff -r 64827b676968 test/TEST.ROOT
--- a/test/TEST.ROOT    Mon Sep 14 19:54:58 2015 +0300
+++ b/test/TEST.ROOT    Mon Sep 14 17:24:52 2015 -0700
@@ -23,5 +23,8 @@
  # Group definitions
  groups=TEST.groups [closed/TEST.groups]

+# Allow querying of sun.arch.data.model in @requires clauses
+requires.properties=sun.arch.data.model
+
  # Tests using jtreg 4.1 b11 features
  requiredVersion=4.1 b11



From ecki at zusammenkunft.net  Tue Sep 15 09:28:32 2015
From: ecki at zusammenkunft.net (Bernd)
Date: Tue, 15 Sep 2015 09:28:32 +0000
Subject: Question about CachedRowSetImpl
In-Reply-To: <CA+rSem-QcHEXndo=S_RQXF=6aqZ=-MwM4e4SgYLRH_cfPabj1w@mail.gmail.com>
References: <CA+rSem9s4D=nmeEfqwVFjTObd57GPkwfUk3JNVGToR5fPvkgpw@mail.gmail.com>
	<CA+rSem-QcHEXndo=S_RQXF=6aqZ=-MwM4e4SgYLRH_cfPabj1w@mail.gmail.com>
Message-ID: <CABOR3+yx+hwqpHTVqkczj0UJxyaBrVB-AdecCTFc4xuj=Ked8g@mail.gmail.com>

Hello,

Can you provide a full stacktrace, the copy+paste of the error message,
what jdbc driver you use and a code snippet? (I think from the age of the
bug it must be even fixed in 1.6 long ago)

Gruss
Bernd

Carolyn Kim <kim at galatea-associates.com> schrieb am Mo., 14. Sep. 2015
18:33:

> Hi,
>
> I have a question about CachedRowSetImpl. I'm trying to use its pagination
> function. But it seems like it does not work with populate method. I think
> I'm seeing the same issue that's described here:
>
> https://bugs.openjdk.java.net/browse/JDK-6382534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel
>
> I am currently using JDK 7.55 and I'm still seeing this issue. Could you
> tell me which version of JDK includes this fix?
>
> Thank you very much,
> Carolyn
>


From Alan.Bateman at oracle.com  Tue Sep 15 09:38:53 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 15 Sep 2015 10:38:53 +0100
Subject: JDK 9 RFR of JDK-8136506: Include sun.arch.data.model as a
	property that can be queried by jtreg
In-Reply-To: <55F76689.10903@oracle.com>
References: <55F76689.10903@oracle.com>
Message-ID: <55F7E72D.4060403@oracle.com>



On 15/09/2015 01:30, Joseph D. Darcy wrote:
> Hello,
>
> Please review the patch below for
>
>     JDK-8136506: Include sun.arch.data.model as a property that can be 
> queried by jtreg
>
This looks okay, are there are any tests lining up to use this?

-Alan


From miroslav.kos at oracle.com  Tue Sep 15 13:39:28 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Tue, 15 Sep 2015 15:39:28 +0200
Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using
	java.util.ServiceLoader
Message-ID: <55F81F90.7040204@oracle.com>

Hi everybody,

I am sending changes for review for
JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader

JBS: https://bugs.openjdk.java.net/browse/JDK-8131334
webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/

It's about migrating to standard java.util.ServiceLoader. This part of 
service discovery was implemented previously "own" way. There are some 
changes in javadoc and implementation has been refactored in order to 
use same code as in JAX-WS and JAX-B.

Testing - I run JAX-WS unit tests (JAX-WS standalone repo), JCK9 + new 
tests specificaly developed for testing service discovery in SAAJ.

Thanks
Miran


From Alan.Bateman at oracle.com  Tue Sep 15 13:46:02 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 15 Sep 2015 14:46:02 +0100
Subject: [9] Review request JDK-8131667: JAX-WS Plugability Layer: using
	java.util.ServiceLoader
In-Reply-To: <55DF5656.9040606@oracle.com>
References: <55D4A2CB.70900@oracle.com> <55D60BD4.4090901@oracle.com>
	<55DF5656.9040606@oracle.com>
Message-ID: <55F8211A.3060400@oracle.com>



On 27/08/2015 19:26, Miroslav Kos wrote:
> Hi Alan,
> I added logging (at least for now) - would it work for you?
> updated webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.02/
>
> If you think the exception shouldn't be ignored I suggest to solve 
> this in separate issue (and maybe revisit all similar cases in 
> SAAJ/JAX-*)
The logging looks okay now.

A minor comment is that in fromJDKProperties then you can avoid toFile() 
and just use Files.exists(f) if you want.

-Alan


From peter.levart at gmail.com  Tue Sep 15 15:31:13 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 15 Sep 2015 17:31:13 +0200
Subject: URLClassPath does unnecessary linear search through every jar and
	jar entry to find resource
In-Reply-To: <CAL_yH3i8-jTORx_oHVbA_ATXGiRtkqd5g==82EWfpyge7xbOmQ@mail.gmail.com>
References: <CAL_yH3i8-jTORx_oHVbA_ATXGiRtkqd5g==82EWfpyge7xbOmQ@mail.gmail.com>
Message-ID: <55F839C1.5000608@gmail.com>

Hi Adrian,

I looked briefly at your code and claims and have some comments inline...

On 09/13/2015 11:08 AM, Adrian wrote:
> Hi,
>
> I posted about this earlier (few weeks ago), and got some responses
> about concerns which I addressed in my last email, though I didn't
> hear back about it.
> My apologies if I shouldn't be sending this; I'm not sure what the
> protocol is about this stuff
>
> Classloading on a standard Java application with jars on the classpath
> currently does a linear search through every jar on the classpath, and
> every entry in a jar, for every class loaded.
> As URLClassPath searches for an entry/resource/class, it's possible to
> cache each entry it encounters -> where to find it, so in the future
> if a resource has already been seen we don't need to repeat the ~2d
> search
>
> Original thread (august list):
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/035009.html
> Last message (september list):
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035016.html
>
> I got 3 responses: 2 concerning changes to jars at runtime
> (invalidating cache), and 1 saying you're not supposed to modify jars
> at runtime (can confirm via source code, and manual testing - it
> crashes the JVM)
>
> In my last message I addressed
> - jars being modified (which you're not supposed to do; the current
> classloader does not handle this) or the classpath changing (only
> possible if you make public fields/methods via reflection, and this
> could easily be handled gracefully)
> - some details of the finding resource process (e.g. the meta index,
> when the cache for jar entries can't be used because of the semantics
> of other loaders/types of entries on the classpath)
> - a reference implementation of caching that I believe is simple and
> compliant with existing functionality
> - some basic numbers on performance
>
> ---
> So in this email I wanted to explain the problem again, hopefully more
> clearly now
>
> URLClassPath is used by URLClassLoader to find classes, though it
> could be used for finding any resource on a classpath.
> URLClassPath keeps an array of URLs, which are typically folders or
> jars on the local filesystem.
> They can be http or ftp or other files, but that's not
> relevant/doesn't affect this problem
>
> To find a resource/class (URLClassPath#getResource), it:
> 1. Loops through the URLs in order
> 2. Creates Loader objects for each URL lazily (URLClassPath$FileLoader
> or URLClassPath$JarLoader). So if the Loader for the first URL finds
> all the resources, Loaders for the remaining entries on the classpath
> are never created/looked at
> 3. Calls Loader#getResource and returns the resource if found
> (otherwise keep searching)
>
> URLClassPath$JarLoader creates its corresponding JarFile either in the
> constructor or in getResource (depending on the meta index - the
> details I explained in my last email I won't repeat)
> When a JarFile is created, it opens the jar file on the file system,
> reads the central directory of the jar/zip file, and creates an
> internal linked list with all its entries

It's not actually a linked list, but a hash table. See 
jdk/src/java.base/share/native/libzip/zip_util.[c,h] ...

the jzfile.table is an array of jint mapping (entry-name-hash-code % 
table.length) -> index into jzfile.entries
the jzfile.entries is an array of jzcell which represent heads of hash 
buckets that are linked with jzcell.next

So look-ups into individual jar/zip files should be O(1). But each 
look-up does cross the Java/JNI boundary, so it has a fixed JNI overhead 
too. If there are lots of jar files in class path, you pay for the 
unsuccessful hash-table look-ups before finding the resource. This 
overhead is not that big, but increases with the number of jar files in 
class path. Each look-up into class path is therefore O(N) where N = # 
of jar files...

>
> JarFile objects are immutable; you can only open them for read/delete
> (see constructor API
> http://docs.oracle.com/javase/7/docs/api/java/util/jar/JarFile.html#JarFile(java.io.File,%20boolean,%20int)
> ), they do not detect if the file has been modified externally, and
> you only "append" or "delete" entries by creating a new jar
> (JarOutputStream)
>
> When URLClassPath$JarLoader#getResource calls JarFile#getEntry; in the
> C code it searches through the linked list
> (jdk/src/share/native/java/util/zip/zip_util.c, ZIP_GetEntry - jar
> files are just zip files, and the java JarFile object just extends
> ZipFile)
>
> Since the order in which jar files and jar entries are searched is
> invariant, we can create a map of resource -> first jar which contains
> it
>
> However, we don't want to introduce additional overhead.
> When a JarFile is created, it already builds the internal linked list
> - it's O(number of entries)
> I propose that after the JarLoader creates the JarFile, it iterates
> through its entries and adds them to the cache (if the map does not
> already contain the resource, i.e. an earlier jar contains the
> resource)
> This adds a small overhead when instantiating loaders - but creating
> the JarLoader/JarFile is still technically O(number of entries), and
> now getResource is constant time, instead of requiring a linear search
> through every jar and the linked list of entries for each jar
> (O(number of jars * entries/jar))

Have you measured your entry iteration and cache initialization 
overhead? When iterating over JarEntries, the code invokes 10 native 
methods for each returned JarEntry:

         long jzentry = getNextEntry(jzfile, i++)
         getEntryFlag(jzentry);
         getEntryBytes(jzentry, JZENTRY_NAME)
         getEntryTime(jzentry)
         getEntryCrc(jzentry)
         getEntrySize(jzentry)
         getEntryCSize(jzentry)
         getEntryMethod(jzentry)
         getEntryBytes(jzentry, JZENTRY_EXTRA)
         getEntryBytes(jzentry, JZENTRY_COMMENT)

...it uses CharsetDecoder 1 or 2 times to decode the name and optional 
comment of each JarEntry, it allocates several java objects...

So I have a feeling that initializing your cache when JarFiles are 
constructed, would increase start-up time and not decrease it. It may 
pay-of on the long run though. For achieving short start-up time, JDK 
tries to be as lazy as possible. Your cache goes against that.

ZipFile native code tries hard to keep the memory usage down for 
maintaining the look-up hash table. It only keeps hash codes in the 
table, with offsets into memory mapped ZIP central directory for each 
entry. Your proposed java-side cache is also a hash table, but it's 
memory footprint is much bigger.

I have made a little experiment to see if JNI overhead for negative 
answers from ZipFile.getEntry(name) is really that big. I modified 
ZipFile.java/ZipFile.c to expose access to a look-up hash table that is 
maintained in native code to the java side via two direct ByteBuffers. I 
screen each ZipFile.getEntry(name) with a probe that gives a negative 
answer for majority of negative lookups without invoking JNI methods. 
Here are the changes I made for this experiment:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile.getEntry/webrev.01/

I have tested the changed JDK with the following JMH benchmark:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile.getEntry/ZipFileBench.java

This benchmark measures the ZipFile.getEntry(name) method on 2 jar files 
(rt.jar ~20K entries, idea.jar ~40K entries) looking up entries in 1st 
jar file with names of the entries taken from the 2nd jar file:

Original:

Benchmark                        (_zipTuple)  Mode  Samples Score    
Error  Units
j.t.ZipFileBench.getEntry      rt.jar:rt.jar  avgt        8  721.536 ? 
17.344  ns/op
j.t.ZipFileBench.getEntry    rt.jar:idea.jar  avgt        8  501.451 ? 
10.298  ns/op
j.t.ZipFileBench.getEntry    idea.jar:rt.jar  avgt        8  423.513 ? 
23.268  ns/op

Patched:

Benchmark                        (_zipTuple)  Mode  Samples Score     
Error  Units
j.t.ZipFileBench.getEntry      rt.jar:rt.jar  avgt        8  743.281 ?  
13.467  ns/op
j.t.ZipFileBench.getEntry    rt.jar:idea.jar  avgt        8  392.569 ?   
7.710  ns/op
j.t.ZipFileBench.getEntry    idea.jar:rt.jar  avgt        8  333.249 ?  
14.069  ns/op


The rt.jar:rt.jar therefore gives the score for successful look-ups, 
while rt.jar:idea.jar and idea.jar:rt.jar give the score for 
unsuccessful look-ups.

The screening of JNI call improves unsuccessful lookup by 20-25% while 
not hurting much the successful lookup. The successful look-up could be 
improved so that it wouldn't have any overhead by utilizing the result 
of the screening probe that must now be re-computed in native code once 
more (see TODO).

So is this worth the trouble? I don't know.

Adrian, does this patch improve your situation (don't forget to set the 
system property -Dsun.zip.useNativeTableProbe=true to enable the 
feature)? This patch should not hurt startup performance, as it does not 
maintain or initialize any additional data structures (besides 2 
ByteBuffer objects per ZipFile that only expose native memory to Java code).

Regards, Peter

>
> There are several caveats when the cache cannot be used with non-jar
> URLs on the classpath, and the meta index, but I explain them in my
> last email along with comments in the reference implementation
>
> ---
> Regarding modified jars:
> - moved/renamed: the file handle is still valid and it doesn't affect
> the JVM/classloading
> - deleted: the file handle is still valid and it doesn't affect the
> JVM/classloading
> - modified: the JVM crashes
>
> The first two may not be intuitive, but remember that file handles
> point to files; not paths on the filesystem.
> So even though a jar appears renamed in the shell, the java process
> has opened a file, somewhere in the c implementation of file objects
> it has the file handle, and when the JVM does the system call read on
> the file handle say to read the class from the jar file, it all works
> fine
> For what it's worth, here's a stack overflow answer as "source":
> http://stackoverflow.com/questions/2028874/what-happens-to-an-open-file-handler-on-linux-if-the-pointed-file-gets-moved-de
>
> ---
> There is a protected method URLClassLoader#addURL which appends a URL
> to the classpath.
> People could use reflection to make it public.
> Because jars are opened lazily and the cache is also built lazily
> whenever a jar is opened, it doesn't matter if paths are appended
>
> Regarding people making extensive use of reflection to modify the
> order of entries on the classpath, I believe that's irrelevant as
> that's clearly not the semantic of URLClassLoader/URLClassPath.
> People who need custom classloading rules create custom classloaders;
> that's the purpose of classloaders being extensible
>
> ---
> Anyways, I hope this was discussion worthy.
> I've looked much into this and believe I haven't missed anything, but
> if someone knows why it hasn't/can't be done any insight would be
> appreciated!
> Alan from the last email thread said "There was a lot of experiments
> and prototypes in the past along these lines" - are the results
> public?
> He also mentioned improving classloading in Java's upcoming module
> system (originally planned for Java 7, currently delayed to Java 9),
> but I believe the algorithmic complexity and performance of
> URLClassLoader could be improved without complicated changes
>
> Please let me know what you think, and thanks for your time!
>
> Best regards,
> Adrian



From joe.darcy at oracle.com  Tue Sep 15 15:43:45 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 15 Sep 2015 08:43:45 -0700
Subject: JDK 9 RFR of JDK-8136506: Include sun.arch.data.model as a
	property that can be queried by jtreg
In-Reply-To: <55F7E72D.4060403@oracle.com>
References: <55F76689.10903@oracle.com> <55F7E72D.4060403@oracle.com>
Message-ID: <55F83CB1.6050002@oracle.com>

On 9/15/2015 2:38 AM, Alan Bateman wrote:
>
>
> On 15/09/2015 01:30, Joseph D. Darcy wrote:
>> Hello,
>>
>> Please review the patch below for
>>
>>     JDK-8136506: Include sun.arch.data.model as a property that can 
>> be queried by jtreg
>>
> This looks okay, are there are any tests lining up to use this?
>

In this case, I have a closed test which would benefit from the property.

-Joe



From martinrb at google.com  Tue Sep 15 22:13:32 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 15 Sep 2015 15:13:32 -0700
Subject: RFR: 8136570: Avoid setting environment variables related to /usr/dt
Message-ID: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>

I reported this bug 12 years ago, but it was closed Will Not Fix, and this
year I see java programs crashing because of it!
This is a partial fix.

https://bugs.openjdk.java.net/browse/JDK-8136570
https://bugs.openjdk.java.net/browse/JDK-4953367
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/


From Roger.Riggs at Oracle.com  Tue Sep 15 22:20:29 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 15 Sep 2015 18:20:29 -0400
Subject: RFR 9: 8133528 : java/lang/ProcessHandle/OnExitTest.java fails
	intermittently
Message-ID: <55F899AD.9050200@Oracle.com>

Please review this test fix to remove checks for subprocesses not 
spawned by the test.
There are spurious processes (like virus checkers) that show up 
unexpectedly.

webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-onexittest-8133528/

Issue:
   https://bugs.openjdk.java.net/browse/JDK-8133528

Thanks, Roger



From huizhe.wang at oracle.com  Tue Sep 15 22:40:42 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 15 Sep 2015 15:40:42 -0700
Subject: RFR 9: 8133528 : java/lang/ProcessHandle/OnExitTest.java fails
	intermittently
In-Reply-To: <55F899AD.9050200@Oracle.com>
References: <55F899AD.9050200@Oracle.com>
Message-ID: <55F89E6A.3030700@oracle.com>

Looks good to me, Roger.

Thanks,
Joe

On 9/15/2015 3:20 PM, Roger Riggs wrote:
> Please review this test fix to remove checks for subprocesses not 
> spawned by the test.
> There are spurious processes (like virus checkers) that show up 
> unexpectedly.
>
> webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-onexittest-8133528/
>
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8133528
>
> Thanks, Roger
>



From philip.race at oracle.com  Tue Sep 15 22:49:39 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 15 Sep 2015 15:49:39 -0700
Subject: <AWT Dev> RFR: 8136570: Avoid setting environment variables
	related to /usr/dt
In-Reply-To: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>
References: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>
Message-ID: <55F8A083.3020300@oracle.com>

I don't understand that original assessment.
Switching to XAWT had no impact on this code except to make it pointless.
i.e it did not prevent its execution.

I doubt there is any code left in the JDK that will derive any
benefit from it still being there. All CDE/Motif & Xt related code is gone.
This should have been removed along with it but was doubtless not
in plain sight to whoever did that.

So unless I am missing something you could go further and just delete it.

-phil.

On 9/15/2015 3:13 PM, Martin Buchholz wrote:
> I reported this bug 12 years ago, but it was closed Will Not Fix, and 
> this year I see java programs crashing because of it!
> This is a partial fix.
>
> https://bugs.openjdk.java.net/browse/JDK-8136570
> https://bugs.openjdk.java.net/browse/JDK-4953367
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/ <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/>



From martinrb at google.com  Wed Sep 16 00:09:37 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 15 Sep 2015 17:09:37 -0700
Subject: <AWT Dev> RFR: 8136570: Avoid setting environment variables
	related to /usr/dt
In-Reply-To: <55F8A083.3020300@oracle.com>
References: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>
	<55F8A083.3020300@oracle.com>
Message-ID: <CA+kOe0_zfJSapN0GrAHQBJF-=yqVQuEA_KQbr7xZE3KQY4fHJg@mail.gmail.com>

We would be entirely happy if the environment frobbing code were to be
deleted.
Should I change my code to do that?

On Tue, Sep 15, 2015 at 3:49 PM, Phil Race <philip.race at oracle.com> wrote:

> I don't understand that original assessment.
> Switching to XAWT had no impact on this code except to make it pointless.
> i.e it did not prevent its execution.
>
> I doubt there is any code left in the JDK that will derive any
> benefit from it still being there. All CDE/Motif & Xt related code is gone.
> This should have been removed along with it but was doubtless not
> in plain sight to whoever did that.
>
> So unless I am missing something you could go further and just delete it.
>
> -phil.
>
>
> On 9/15/2015 3:13 PM, Martin Buchholz wrote:
>
>> I reported this bug 12 years ago, but it was closed Will Not Fix, and
>> this year I see java programs crashing because of it!
>> This is a partial fix.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8136570
>> https://bugs.openjdk.java.net/browse/JDK-4953367
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/ <
>> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/
>> >
>>
>
>


From martinrb at google.com  Wed Sep 16 00:42:25 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 15 Sep 2015 17:42:25 -0700
Subject: RFR: 8136583: Core libraries should use blessed modifier order
Message-ID: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>

Hi, Chris and Paul,
I'd like you to do a very boring code review.

This change is entirely machine generated. (the script is more interesting)
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patch
https://bugs.openjdk.java.net/browse/JDK-8136583


From joe.darcy at oracle.com  Wed Sep 16 02:11:18 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Tue, 15 Sep 2015 19:11:18 -0700
Subject: JDK 9 RFR of JDK-8134795: Port fdlibm pow to Java
Message-ID: <55F8CFC6.5020104@oracle.com>

Hello,

At long last, I've started the port of the C version of FDLIBM (freely 
distributable math library) from C to Java, beginning with the pow method:

     JDK-8134795: Port fdlibm pow to Java
     http://cr.openjdk.java.net/~darcy/8134795.6/

The FDLIBM algorithms provide direct backing to the more interesting 
methods in java.lang.StrictMath and indirect backing to the 
corresponding java.lang.Math methods on some platforms (depending on 
whether or not platform-optimized alternative versions are being used).

Having this functionality in Java versus C offers a number of 
advantages, including easier maintenance and improved performance (the 
Java -> C -> Java transitions are expensive).

My general approach for code organization of the port is to add a new 
package-private class named "FdLibm" in the java.lang package. The 
calculation code to support a particular math function will have its own 
nested class inside FdLibm. This structure allows sharing of helper code 
across the different FDLIBM functions without bloating the number of 
source files in java.lang. Floating-point constants will generally be 
initialized using the precise (if obscure) hexadecimal floating-point 
notation accepted in Java since JDK 5. (See JLS 3.10.2 Floating-Point 
Literals for details, 
https://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10.2) 
For further clarify, underscores are used to separate groups of digits 
to make it easier to see if a full-precision value is being provided 
(underscores in numeric literals were Project Coin feature in JDK 7).

Future refinements of the port may restrict the range of the strictfp 
modifier or remove it entirely. The current usage of strictfp should be 
correct, if not necessarily optimal from a performance perspective. To 
make floating-point code reproducible about platforms, a semantic 
requirement for StrictMath, within the FP-default and FP-strict model  
in Java, it is not necessarily required to declare a method strictfp. 
Declaring a method strictfp will do the job, but if the code in question 
neither overflows nor underflows, strictfp is not necessary for 
cross-platform reproducibility. If the code only overflows and 
underflows are *not* possible, storing down to a variable can in some 
cases be sufficient for reproducibility without strictfp. Additional 
case analysis along this lines would need to be done to the pow 
algorithm to limit the scope of its strictfp usage.)

The original C code was written many years back and was written in a 
style different than idiomatic Java today. The port as it stand is much 
closer to idiomatic Java than the original; however, some vestiges of 
original style remain, a few to make mapping back to the C code easier 
if that is necessary. To make the reviewing easier, in the webrev I 
listed e_pow.c as the original file to compare FdLibm.java against. 
However, in actuality e_pow.c is deleted and FdLibm.java is added as a 
new file. The original C code was severely whitespace deficient compared 
to idiomatic Java so many of the line-by-line differences are just to 
provide more humane and readable spacing.

A substantively similar version of this port has gone through jprt and 
the build succeed and jdk_lang test group passed on all platforms.

Thanks to Brian Burkhalter for earlier pre-reviews on several of the 
previous iterations of this port. Earlier iterations of the port were 
also reviewed by an Oracle numerical expert outside of the JDK group.

Thanks,

-Joe


From ecki at zusammenkunft.net  Wed Sep 16 02:48:00 2015
From: ecki at zusammenkunft.net (ecki at zusammenkunft.net)
Date: Wed, 16 Sep 2015 04:48:00 +0200
Subject: Modifier order for 'default' (was: RFR: 8136583: Core libraries
	should use blessed modifier order)
In-Reply-To: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
References: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
Message-ID: <003bba8a-2848-4c04-92c4-ef64a497acc5.maildroid@localhost>

Martin, this will be known as the "blame martin" patch, good work.

But more seriously a minor thing I noticed in your shell script (as well as the mentioned sources and some coding guidelines), the new interface `default` method modifier is not defined in any of those lists.

Not sure if it is actually a problem for this patch (there seems to be no line with default modifier), but its just a general observation (with the hidden hope to get an authoritative consensus of the location of `default` as well, even when it might be the wrong mailinglist).

Greetings
Bernd
-- 
http://bernd.eckenfels.net

-----Original Message-----
From: Martin Buchholz <martinrb at google.com>
To: core-libs-dev <core-libs-dev at openjdk.java.net>, Chris Hegarty <chris.hegarty at oracle.com>, Paul Sandoz <paul.sandoz at oracle.com>
Sent: Mi., 16 Sep. 2015 2:54
Subject: RFR: 8136583: Core libraries should use blessed modifier order

Hi, Chris and Paul,
I'd like you to do a very boring code review.

This change is entirely machine generated. (the script is more interesting)
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patch
https://bugs.openjdk.java.net/browse/JDK-8136583


From stuart.marks at oracle.com  Wed Sep 16 04:48:57 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 15 Sep 2015 21:48:57 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F1F22A.4000802@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com> <55F0AD95.8060909@oracle.com>
	<55F0B43C.2030205@oracle.com> <55F0B7F1.8010200@oracle.com>
	<55F1E683.9050905@oracle.com> <55F1F22A.4000802@oracle.com>
Message-ID: <55F8F4B9.80802@oracle.com>



On 9/10/15 2:12 PM, Xueming Shen wrote:
> I think it might be a "nice to have" for a "fail-fast" effort after the the
> consumer consumed/accepted the result (the second check), but isn't it a bug
> for the consumer to accept any result if there is CME condition occurred
> already?

I'm not sure which spliterator we're talking about at this point, but the issue 
is similar between them. Prior to calling the consumer's accept() method, in 
FindSpliterator, the modCount has previously been asserted to be equal to 
expectedCount. In TokenSpliterator, the expectedCount is refreshed from the 
modCount immediately prior to calling accept(). (This is done because advancing 
the spliterator in this case increments the modCount.)

In both spliterators, then, the expectedCount should be equal to the modCount 
immediately prior to the call to accept(). Also in both spliterators, the 
modCount and expectedCount are compared immediately after accept(), and if they 
aren't equal, CME is thrown.

What this guards against is the accept() method -- really, one of the 
application's lambdas that's been passed to a pipeline operation -- modifying 
the state of the scanner. This only really works in a sequential stream, but 
it's all we've got. (In a parallel stream, I think the element is buffered 
somewhere and is handed to another thread. If that other thread attempts to 
modify the scanner's state, all bets are off because of memory visibility issues.)

Anyway, at least for sequential streams, this check does properly guard against 
the case where somebody modifies the scanner's state from within a pipeline 
operation. There are tests for this too; see ScanTest.streamComodTest().

>>>> It'd be better to initialize expectedCount to modCount in constrocutor?
>>
>> That's how I had it initially, but at Paul Sandoz' suggestion I delayed the
>> initialization to the first call to tryAdvance(). This allows the Scanner's
>> state to be modified after stream creation but before stream pipeline
>> execution. This is the way that Paul's stream code in Matcher works. I'm not
>> sure how important this is. Having Scanner be gratuitously different from
>> Matcher seems like it would be irritating though.
>
> I noticed the spec says "Scanning starts upon initiation of the terminal
> stream operation, using the current state of this scanner..." guess it means
> the "CME" enforcement starts with the "stream operation" starts (a kinda of
> later-initialization). But personally feel it may create a unnecessary
> inconsistent situation, depends on whether or not there is state change
> between the creation of the Stream object and the starting of the stream
> operation. But I'm not a stream > expert :-)

Well, one of my earlier revisions basically said that you can't touch the 
Scanner at all after tokens() or findAll() has been called. This works, but is 
unnessarily restrictive, and it's inconsistent with Paul's approach with 
Matcher.results().

This is pretty easy to see because the constructors for the new spliterators 
simply initialize themselves, but they don't hang onto any state from the 
scanner. The only actual dependence on the state of the scanner starts at the 
first call to tryAdvance(), which is when the first element is actually 
introduced to the stream. It's safe for  the application to change the state of 
the scanner any time up until that point. It does introduce a little bit of 
complexity in that there's an additional state in the expectedCount checking (as 
we've seen) :-). But it does allow a bit more flexibility with the caller's 
handling of the scanner and a stream derived from it.

s'marks


From thomas.stuefe at gmail.com  Wed Sep 16 08:33:50 2015
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 16 Sep 2015 10:33:50 +0200
Subject: RFR: 8136570: Avoid setting environment variables related to
	/usr/dt
In-Reply-To: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>
References: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>
Message-ID: <CAA-vtUz0Qq4+7mHc4M_FpmGGQowO4_AGswTjPaOje2qmG+jJZw@mail.gmail.com>

Hi Martin,

would it be not sufficient to just test for existence of /usr/dt before the
two calls to setPathEnvironment() and leave the rest as it is? I also think
the intend would be clearer ("only call this if CDE is installed").

Kind Regards, Thomas



On Wed, Sep 16, 2015 at 12:13 AM, Martin Buchholz <martinrb at google.com>
wrote:

> I reported this bug 12 years ago, but it was closed Will Not Fix, and this
> year I see java programs crashing because of it!
> This is a partial fix.
>
> https://bugs.openjdk.java.net/browse/JDK-8136570
> https://bugs.openjdk.java.net/browse/JDK-4953367
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/
>


From volker.simonis at gmail.com  Wed Sep 16 09:02:47 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 16 Sep 2015 11:02:47 +0200
Subject: JDK 9 RFR of JDK-8134795: Port fdlibm pow to Java
In-Reply-To: <55F8CFC6.5020104@oracle.com>
References: <55F8CFC6.5020104@oracle.com>
Message-ID: <CA+3eh13QqXcPWHc-b4a5=cnPb7yRzFDJjjatBdC2BPGMohP6Cg@mail.gmail.com>

Hi Joe,

nice clean-up! From a maintenance point of view the the old fdlibm has
been a burden and a constant source of warnings with newer compilers.

What about the final arrays in Pow.compute (BP, DP_H, DP_L). In the
Interpreter (and even in C2 without EscapeAnalysis) this will lead to
allocations every time the method is called. Making them static fields
of 'Pow' will help here. On the other hand, if the arrays are static
fields of 'Pow', C2 will not be able to directly use the constants but
will have to load them from the array. So altogether, your current
implementation is optimal with HotSpot (with EscapeAnalysis turned on
by default) but might not be the best for other VMs without
EscapaAnalysis.

Have you done any benchmarking which compares the new Java against the
old C implementation?

Regards,
Volker

On Wed, Sep 16, 2015 at 4:11 AM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> Hello,
>
> At long last, I've started the port of the C version of FDLIBM (freely
> distributable math library) from C to Java, beginning with the pow method:
>
>     JDK-8134795: Port fdlibm pow to Java
>     http://cr.openjdk.java.net/~darcy/8134795.6/
>
> The FDLIBM algorithms provide direct backing to the more interesting methods
> in java.lang.StrictMath and indirect backing to the corresponding
> java.lang.Math methods on some platforms (depending on whether or not
> platform-optimized alternative versions are being used).
>
> Having this functionality in Java versus C offers a number of advantages,
> including easier maintenance and improved performance (the Java -> C -> Java
> transitions are expensive).
>
> My general approach for code organization of the port is to add a new
> package-private class named "FdLibm" in the java.lang package. The
> calculation code to support a particular math function will have its own
> nested class inside FdLibm. This structure allows sharing of helper code
> across the different FDLIBM functions without bloating the number of source
> files in java.lang. Floating-point constants will generally be initialized
> using the precise (if obscure) hexadecimal floating-point notation accepted
> in Java since JDK 5. (See JLS 3.10.2 Floating-Point Literals for details,
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10.2) For
> further clarify, underscores are used to separate groups of digits to make
> it easier to see if a full-precision value is being provided (underscores in
> numeric literals were Project Coin feature in JDK 7).
>
> Future refinements of the port may restrict the range of the strictfp
> modifier or remove it entirely. The current usage of strictfp should be
> correct, if not necessarily optimal from a performance perspective. To make
> floating-point code reproducible about platforms, a semantic requirement for
> StrictMath, within the FP-default and FP-strict model  in Java, it is not
> necessarily required to declare a method strictfp. Declaring a method
> strictfp will do the job, but if the code in question neither overflows nor
> underflows, strictfp is not necessary for cross-platform reproducibility. If
> the code only overflows and underflows are *not* possible, storing down to a
> variable can in some cases be sufficient for reproducibility without
> strictfp. Additional case analysis along this lines would need to be done to
> the pow algorithm to limit the scope of its strictfp usage.)
>
> The original C code was written many years back and was written in a style
> different than idiomatic Java today. The port as it stand is much closer to
> idiomatic Java than the original; however, some vestiges of original style
> remain, a few to make mapping back to the C code easier if that is
> necessary. To make the reviewing easier, in the webrev I listed e_pow.c as
> the original file to compare FdLibm.java against. However, in actuality
> e_pow.c is deleted and FdLibm.java is added as a new file. The original C
> code was severely whitespace deficient compared to idiomatic Java so many of
> the line-by-line differences are just to provide more humane and readable
> spacing.
>
> A substantively similar version of this port has gone through jprt and the
> build succeed and jdk_lang test group passed on all platforms.
>
> Thanks to Brian Burkhalter for earlier pre-reviews on several of the
> previous iterations of this port. Earlier iterations of the port were also
> reviewed by an Oracle numerical expert outside of the JDK group.
>
> Thanks,
>
> -Joe


From vyom.tewari at oracle.com  Wed Sep 16 09:08:29 2015
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Wed, 16 Sep 2015 14:38:29 +0530
Subject: RFR 8073542 : File Leak in
	jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c
Message-ID: <55F9318D.2030100@oracle.com>

Hi All,

Please review my changes for below bug.

Bug:
       JDK-8073542 : File Leak in 
jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c
Webrev:
http://cr.openjdk.java.net/~dfuchs/vyom/8073542/webrev.00

This change ensure that if "setsocketopt" fails we close the 
corresponding fd and throw correct  exception.

Thanks,
Vyom


From paul.sandoz at oracle.com  Wed Sep 16 10:57:56 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 16 Sep 2015 12:57:56 +0200
Subject: RFR: 8136583: Core libraries should use blessed modifier order
In-Reply-To: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
References: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
Message-ID: <8D030D97-115E-4B8E-8E5D-BA3CAD504D9E@oracle.com>


On 16 Sep 2015, at 02:42, Martin Buchholz <martinrb at google.com> wrote:

> Hi, Chris and Paul,
> I'd like you to do a very boring code review.
> 
> This change is entirely machine generated. (the script is more interesting)
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patch
> https://bugs.openjdk.java.net/browse/JDK-8136583

AFAICT the script you used to produce the changes looks fine (a perl script embedded into a bash script :-) ).

After a certain point i cannot review the actual changes, my eye-balls give up :-) so i have to trust that it all compiles and tests run. Did you apply this patch internally and test?

Paul.






From miroslav.kos at oracle.com  Wed Sep 16 11:07:31 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Wed, 16 Sep 2015 13:07:31 +0200
Subject: [9] Review request JDK-8131667: JAX-WS Plugability Layer: using
	java.util.ServiceLoader
In-Reply-To: <55F8211A.3060400@oracle.com>
References: <55D4A2CB.70900@oracle.com> <55D60BD4.4090901@oracle.com>
	<55DF5656.9040606@oracle.com> <55F8211A.3060400@oracle.com>
Message-ID: <55F94D73.7060404@oracle.com>

On 15/09/15 15:46, Alan Bateman wrote:
>
>
> On 27/08/2015 19:26, Miroslav Kos wrote:
>> Hi Alan,
>> I added logging (at least for now) - would it work for you?
>> updated webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.02/
>>
>> If you think the exception shouldn't be ignored I suggest to solve 
>> this in separate issue (and maybe revisit all similar cases in 
>> SAAJ/JAX-*)
> The logging looks okay now.
>
> A minor comment is that in fromJDKProperties then you can avoid 
> toFile() and just use Files.exists(f) if you want.
>
> -Alan
Fixed here: http://cr.openjdk.java.net/~mkos/8131667/jaxws.03/

Thanks
Miran


From paul.sandoz at oracle.com  Wed Sep 16 11:34:39 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 16 Sep 2015 13:34:39 +0200
Subject: Modifier order for 'default' (was: RFR: 8136583: Core libraries
	should use blessed modifier order)
In-Reply-To: <003bba8a-2848-4c04-92c4-ef64a497acc5.maildroid@localhost>
References: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
	<003bba8a-2848-4c04-92c4-ef64a497acc5.maildroid@localhost>
Message-ID: <DB9878BC-C151-4D79-A1AD-F4343C5F593F@oracle.com>

Hi Bernd,

In some respects ?default? is easy. It can only occur on non-abstract methods on interfaces, and declaring such methods ?public? is redundant (as is the case for abstract methods on interfaces, where also declaring ?abstract? is redundant). [*] And there are more redundant cases related to enums and nested classes.

A further clean up would to run relevant code inspections in the IDE to remove redundant declarations.

Paul.

[*] FWIW there are a few cases of ?public default? and ?default public? in the OpenJDK source code

On 16 Sep 2015, at 04:48, ecki at zusammenkunft.net wrote:

> Martin, this will be known as the "blame martin" patch, good work.
> 
> But more seriously a minor thing I noticed in your shell script (as well as the mentioned sources and some coding guidelines), the new interface `default` method modifier is not defined in any of those lists.
> 
> Not sure if it is actually a problem for this patch (there seems to be no line with default modifier), but its just a general observation (with the hidden hope to get an authoritative consensus of the location of `default` as well, even when it might be the wrong mailinglist).
> 
> Greetings
> Bernd
> --
> http://bernd.eckenfels.net
> 
> -----Original Message-----
> From: Martin Buchholz <martinrb at google.com>
> To: core-libs-dev <core-libs-dev at openjdk.java.net>, Chris Hegarty <chris.hegarty at oracle.com>, Paul Sandoz <paul.sandoz at oracle.com>
> Sent: Mi., 16 Sep. 2015 2:54
> Subject: RFR: 8136583: Core libraries should use blessed modifier order
> 
> Hi, Chris and Paul,
> I'd like you to do a very boring code review.
> 
> This change is entirely machine generated. (the script is more interesting)
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patch
> https://bugs.openjdk.java.net/browse/JDK-8136583



From Alan.Bateman at oracle.com  Wed Sep 16 12:54:03 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Sep 2015 13:54:03 +0100
Subject: RFR: 8136583: Core libraries should use blessed modifier order
In-Reply-To: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
References: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
Message-ID: <55F9666B.5010502@oracle.com>

On 16/09/2015 01:42, Martin Buchholz wrote:
> Hi, Chris and Paul,
> I'd like you to do a very boring code review.
>
> This change is entirely machine generated. (the script is more interesting)
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patch
> https://bugs.openjdk.java.net/browse/JDK-8136583
I skimmed over the webrev and it looks good. Have you considered getting 
the script to the point where it should be pushed to make/scripts or 
maybe one of the repos in the code tools project.

-Alan


From claes.redestad at oracle.com  Wed Sep 16 12:58:17 2015
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 16 Sep 2015 14:58:17 +0200
Subject: RFR: 8136583: Core libraries should use blessed modifier order
In-Reply-To: <55F9666B.5010502@oracle.com>
References: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
	<55F9666B.5010502@oracle.com>
Message-ID: <55F96769.9080301@oracle.com>


On 2015-09-16 14:54, Alan Bateman wrote:
> On 16/09/2015 01:42, Martin Buchholz wrote:
>> Hi, Chris and Paul,
>> I'd like you to do a very boring code review.
>>
>> This change is entirely machine generated. (the script is more 
>> interesting)
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patch 
>>
>> https://bugs.openjdk.java.net/browse/JDK-8136583
> I skimmed over the webrev and it looks good. Have you considered 
> getting the script to the point where it should be pushed to 
> make/scripts or maybe one of the repos in the code tools project.
>
> -Alan

Maybe something to integrate into jcheck? (The validation/matching, not 
the substitution itself)

/Claes



From ivan.gerasimov at oracle.com  Wed Sep 16 13:44:46 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 16 Sep 2015 16:44:46 +0300
Subject: RFR 8073542 : File Leak in
	jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c
In-Reply-To: <55F9318D.2030100@oracle.com>
References: <55F9318D.2030100@oracle.com>
Message-ID: <55F9724E.1020703@oracle.com>

Hi Vyom!

The change looks fine, thanks.

You've used strerr() to extract the error string, so it may be good to 
coordinate your patch with the fix for JDK-8133249.
Robert (CCed) is working on it at the moment.

Sincerely yours,
Ivan

On 16.09.2015 12:08, Vyom Tewari wrote:
> Hi All,
>
> Please review my changes for below bug.
>
> Bug:
>       JDK-8073542 : File Leak in 
> jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/vyom/8073542/webrev.00
>
> This change ensure that if "setsocketopt" fails we close the 
> corresponding fd and throw correct  exception.
>
> Thanks,
> Vyom
>



From chris.hegarty at oracle.com  Wed Sep 16 14:03:17 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 16 Sep 2015 15:03:17 +0100
Subject: RFR 8073542 : File Leak in
	jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c
In-Reply-To: <55F9318D.2030100@oracle.com>
References: <55F9318D.2030100@oracle.com>
Message-ID: <55F976A5.1000807@oracle.com>

The changes look good to me Vyom.

-Chris.

On 16/09/15 10:08, Vyom Tewari wrote:
> Hi All,
>
> Please review my changes for below bug.
>
> Bug:
>        JDK-8073542 : File Leak in
> jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/vyom/8073542/webrev.00
>
> This change ensure that if "setsocketopt" fails we close the
> corresponding fd and throw correct  exception.
>
> Thanks,
> Vyom


From Alan.Bateman at oracle.com  Wed Sep 16 14:03:40 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 16 Sep 2015 15:03:40 +0100
Subject: [9] Review request JDK-8131667: JAX-WS Plugability Layer: using
	java.util.ServiceLoader
In-Reply-To: <55F94D73.7060404@oracle.com>
References: <55D4A2CB.70900@oracle.com> <55D60BD4.4090901@oracle.com>
	<55DF5656.9040606@oracle.com> <55F8211A.3060400@oracle.com>
	<55F94D73.7060404@oracle.com>
Message-ID: <55F976BC.90708@oracle.com>



On 16/09/2015 12:07, Miroslav Kos wrote:
> On 15/09/15 15:46, Alan Bateman wrote:
>>
>>
>> On 27/08/2015 19:26, Miroslav Kos wrote:
>>> Hi Alan,
>>> I added logging (at least for now) - would it work for you?
>>> updated webrev: http://cr.openjdk.java.net/~mkos/8131667/jaxws.02/
>>>
>>> If you think the exception shouldn't be ignored I suggest to solve 
>>> this in separate issue (and maybe revisit all similar cases in 
>>> SAAJ/JAX-*)
>> The logging looks okay now.
>>
>> A minor comment is that in fromJDKProperties then you can avoid 
>> toFile() and just use Files.exists(f) if you want.
>>
>> -Alan
> Fixed here: http://cr.openjdk.java.net/~mkos/8131667/jaxws.03/
Looks okay to me.

-Alan.


From chris.hegarty at oracle.com  Wed Sep 16 14:25:15 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 16 Sep 2015 15:25:15 +0100
Subject: RFR: 8136583: Core libraries should use blessed modifier order
In-Reply-To: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
References: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
Message-ID: <55F97BCB.6060004@oracle.com>

Martin,

On 16/09/15 01:42, Martin Buchholz wrote:
> Hi, Chris and Paul,
> I'd like you to do a very boring code review.
>
> This change is entirely machine generated. (the script is more interesting)
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patch
> https://bugs.openjdk.java.net/browse/JDK-8136583

The changes look fine. I ran them through the Oracle build and test 
system, no surprises.

I agree with Alan, such a script would be useful if it were checked in 
somewhere. That way other modules and test sources could be tackled, and 
periodically checked/updated.

-Chris.


From peter.levart at gmail.com  Wed Sep 16 15:19:14 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 16 Sep 2015 17:19:14 +0200
Subject: RFR: 8136583: Core libraries should use blessed modifier order
In-Reply-To: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
References: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
Message-ID: <55F98872.6030008@gmail.com>

Hi Martin,

On 09/16/2015 02:42 AM, Martin Buchholz wrote:
> Hi, Chris and Paul,
> I'd like you to do a very boring code review.
>
> This change is entirely machine generated. (the script is more interesting)
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patch
> https://bugs.openjdk.java.net/browse/JDK-8136583

Reviewing the diff would be boring, yes. More interesting is trying to 
understand the script.

I re-implemented your script in some other language (called Java ;-) and 
compared the results. Nothing can beat concise expressiveness of bash 
instantiations of perl template, but Java lambdas and streams are not 
too shabby either. Here's a re-implementation in 2 expressions and 1 
statement:

import java.io.IOException;
import java.io.UncheckedIOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.Arrays;
import java.util.List;
import java.util.function.Function;
import java.util.regex.Pattern;
import java.util.stream.Collectors;
import java.util.stream.IntStream;
import java.util.stream.Stream;

import static java.nio.file.StandardCopyOption.*;
import static java.nio.file.StandardOpenOption.*;

public class BlessedModifierOrder {

     static final List<String> modifiers = Arrays.asList(
         "public", "protected", "private",
         "abstract", "static", "final", "transient",
         "volatile", "synchronized", "native", "strictfp"
     );

     static final Function<String, String> editor = IntStream
         .range(3, modifiers.size())
         .mapToObj(i -> Pattern.compile(
             "^([A-Za-z@ ]*)\\b(" +
             modifiers.subList(i, 
modifiers.size()).stream().collect(Collectors.joining("|")) +
             ") +(" +
             modifiers.subList(0, 
i).stream().collect(Collectors.joining("|")) +
             ")\\b"
         ))
         .map(pattern -> (Function<String, String>) line -> {
             String editedLine;
             while (!line.equals(editedLine = 
pattern.matcher(line).replaceFirst("$1$3 $2"))) {
                 line = editedLine;
             }
             return line;
         })
         .reduce(Function.identity(), (f1, f2) -> f1.andThen(f2));

     public static void main(String[] args) {
         Stream.of(args)
               .map(Paths::get)
               .flatMap(dir -> {
                   try (Stream<Path> files = Files.find(
                       dir, Integer.MAX_VALUE,
                       (p, attr) -> attr.isRegularFile() && 
p.toString().endsWith(".java")
                   )) {
                       return files.collect(Collectors.toList()).stream();
                   } catch (IOException e) {
                       throw new UncheckedIOException(e);
                   }
               })
               .forEach(file -> {
                   try (Stream<String> linesStream = Files.lines(file)) {
                       List<String> lines = linesStream.map(editor)
.collect(Collectors.toList());
                       Path newFile = 
file.resolveSibling(file.getFileName() + ".new");
                       Files.write(newFile, lines, WRITE, CREATE, 
TRUNCATE_EXISTING);
                       Files.move(newFile, file, ATOMIC_MOVE, 
REPLACE_EXISTING);
                   } catch (IOException e) {
                       throw new UncheckedIOException(e);
                   }
               });
     }
}


Anyway, the result is exactly the same.


Regards, Peter



From xueming.shen at oracle.com  Wed Sep 16 15:43:43 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 16 Sep 2015 08:43:43 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F8F4B9.80802@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com> <55F0AD95.8060909@oracle.com>
	<55F0B43C.2030205@oracle.com> <55F0B7F1.8010200@oracle.com>
	<55F1E683.9050905@oracle.com> <55F1F22A.4000802@oracle.com>
	<55F8F4B9.80802@oracle.com>
Message-ID: <55F98E2F.4050507@oracle.com>

On 9/15/15 9:48 PM, Stuart Marks wrote:
>
>
> On 9/10/15 2:12 PM, Xueming Shen wrote:
>> I think it might be a "nice to have" for a "fail-fast" effort after 
>> the the
>> consumer consumed/accepted the result (the second check), but isn't 
>> it a bug
>> for the consumer to accept any result if there is CME condition occurred
>> already?
>
> I'm not sure which spliterator we're talking about at this point, but 
> the issue is similar between them. Prior to calling the consumer's 
> accept() method, in FindSpliterator, the modCount has previously been 
> asserted to be equal to expectedCount. In TokenSpliterator, the 
> expectedCount is refreshed from the modCount immediately prior to 
> calling accept(). (This is done because advancing the spliterator in 
> this case increments the modCount.)
>
> In both spliterators, then, the expectedCount should be equal to the 
> modCount immediately prior to the call to accept(). Also in both 
> spliterators, the modCount and expectedCount are compared immediately 
> after accept(), and if they aren't equal, CME is thrown.
>

For both spliterators, particularly the token() method. The check after 
the accept() method is fine
(as you suggested below, it guards against the wrong doing by the user 
code inside the accept()).
I'm talking about the check "immediately" prior to the call to accept(). 
It will not function after the
modCount tips over to the negative int value, because the "expectedCount 
 >=0" check.

Consider the use scenario that the Scanner is on top of an endless input 
stream, you have a token
stream on top of it. The check before the "accept(token" will not be 
performed until the
expectedCount/modCount tips back to positive value again from the 
negative, then off, then on...
During the off period (it will take a while from negative back to 
positive), the stream will just work
fine to feed the accept() the "next" token even if there is another 
thread keeps "stealing" tokens from
the same scanner, if the timing is right.  Looks like not really a 
"fail-fast" in this scenario.

This can be "easily" addressed, if you have a separate boolean field 
such as "initlized". The code
can look like below in tryAdvance(...)

     if (!initialize) {
         expectedCount = modCount;
     }
     if (expectedCount != modCount) {
         throw new CME();
     }
     ...

Well, if you think this is an unlikely use scenario and the intention of 
the check/guard here
is mainly to prevent the wrong doing within the pipe operation, then it 
might not worth the
extra field, and I'm fine with the latest webrev.

-Sherman


> What this guards against is the accept() method -- really, one of the 
> application's lambdas that's been passed to a pipeline operation -- 
> modifying the state of the scanner. This only really works in a 
> sequential stream, but it's all we've got. (In a parallel stream, I 
> think the element is buffered somewhere and is handed to another 
> thread. If that other thread attempts to modify the scanner's state, 
> all bets are off because of memory visibility issues.)
>
> Anyway, at least for sequential streams, this check does properly 
> guard against the case where somebody modifies the scanner's state 
> from within a pipeline operation. There are tests for this too; see 
> ScanTest.streamComodTest().
>



From xueming.shen at oracle.com  Wed Sep 16 15:56:34 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 16 Sep 2015 08:56:34 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F98E2F.4050507@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com> <55F0AD95.8060909@oracle.com>
	<55F0B43C.2030205@oracle.com> <55F0B7F1.8010200@oracle.com>
	<55F1E683.9050905@oracle.com> <55F1F22A.4000802@oracle.com>
	<55F8F4B9.80802@oracle.com> <55F98E2F.4050507@oracle.com>
Message-ID: <55F99132.90500@oracle.com>

On 9/16/15 8:43 AM, Xueming Shen wrote:
> On 9/15/15 9:48 PM, Stuart Marks wrote:
>>
>>
>> On 9/10/15 2:12 PM, Xueming Shen wrote:
>>> I think it might be a "nice to have" for a "fail-fast" effort after 
>>> the the
>>> consumer consumed/accepted the result (the second check), but isn't 
>>> it a bug
>>> for the consumer to accept any result if there is CME condition 
>>> occurred
>>> already?
>>
>> I'm not sure which spliterator we're talking about at this point, but 
>> the issue is similar between them. Prior to calling the consumer's 
>> accept() method, in FindSpliterator, the modCount has previously been 
>> asserted to be equal to expectedCount. In TokenSpliterator, the 
>> expectedCount is refreshed from the modCount immediately prior to 
>> calling accept(). (This is done because advancing the spliterator in 
>> this case increments the modCount.)
>>
>> In both spliterators, then, the expectedCount should be equal to the 
>> modCount immediately prior to the call to accept(). Also in both 
>> spliterators, the modCount and expectedCount are compared immediately 
>> after accept(), and if they aren't equal, CME is thrown.
>>
>
> For both spliterators, particularly the token() method. The check 
> after the accept() method is fine
> (as you suggested below, it guards against the wrong doing by the user 
> code inside the accept()).
> I'm talking about the check "immediately" prior to the call to 
> accept(). It will not function after the
> modCount tips over to the negative int value, because the 
> "expectedCount >=0" check.
>
> Consider the use scenario that the Scanner is on top of an endless 
> input stream, you have a token
> stream on top of it. The check before the "accept(token" will not be 
> performed until the
> expectedCount/modCount tips back to positive value again from the 
> negative, then off, then on...
> During the off period (it will take a while from negative back to 
> positive), the stream will just work
> fine to feed the accept() the "next" token even if there is another 
> thread keeps "stealing" tokens from
> the same scanner, if the timing is right.  Looks like not really a 
> "fail-fast" in this scenario.
>
> This can be "easily" addressed, if you have a separate boolean field 
> such as "initlized". The code
> can look like below in tryAdvance(...)
>
>     if (!initialize) {
>         expectedCount = modCount;
     ---> initialized = true;


>     }
>     if (expectedCount != modCount) {
>         throw new CME();
>     }
>     ...
>
> Well, if you think this is an unlikely use scenario and the intention 
> of the check/guard here
> is mainly to prevent the wrong doing within the pipe operation, then 
> it might not worth the
> extra field, and I'm fine with the latest webrev.
>
> -Sherman
>
>
>> What this guards against is the accept() method -- really, one of the 
>> application's lambdas that's been passed to a pipeline operation -- 
>> modifying the state of the scanner. This only really works in a 
>> sequential stream, but it's all we've got. (In a parallel stream, I 
>> think the element is buffered somewhere and is handed to another 
>> thread. If that other thread attempts to modify the scanner's state, 
>> all bets are off because of memory visibility issues.)
>>
>> Anyway, at least for sequential streams, this check does properly 
>> guard against the case where somebody modifies the scanner's state 
>> from within a pipeline operation. There are tests for this too; see 
>> ScanTest.streamComodTest().
>>
>



From philip.race at oracle.com  Wed Sep 16 16:00:45 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 16 Sep 2015 09:00:45 -0700
Subject: <AWT Dev> RFR: 8136570: Avoid setting environment variables
	related to /usr/dt
In-Reply-To: <CA+kOe0_zfJSapN0GrAHQBJF-=yqVQuEA_KQbr7xZE3KQY4fHJg@mail.gmail.com>
References: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>
	<55F8A083.3020300@oracle.com>
	<CA+kOe0_zfJSapN0GrAHQBJF-=yqVQuEA_KQbr7xZE3KQY4fHJg@mail.gmail.com>
Message-ID: <55F9922D.5000705@oracle.com>

That is fine by me. If any one on awt-dev knows of a reason to keep it
they should speak up.

-phil.

On 9/15/15 5:09 PM, Martin Buchholz wrote:
> We would be entirely happy if the environment frobbing code were to be 
> deleted.
> Should I change my code to do that?
>
> On Tue, Sep 15, 2015 at 3:49 PM, Phil Race <philip.race at oracle.com 
> <mailto:philip.race at oracle.com>> wrote:
>
>     I don't understand that original assessment.
>     Switching to XAWT had no impact on this code except to make it
>     pointless.
>     i.e it did not prevent its execution.
>
>     I doubt there is any code left in the JDK that will derive any
>     benefit from it still being there. All CDE/Motif & Xt related code
>     is gone.
>     This should have been removed along with it but was doubtless not
>     in plain sight to whoever did that.
>
>     So unless I am missing something you could go further and just
>     delete it.
>
>     -phil.
>
>
>     On 9/15/2015 3:13 PM, Martin Buchholz wrote:
>
>         I reported this bug 12 years ago, but it was closed Will Not
>         Fix, and this year I see java programs crashing because of it!
>         This is a partial fix.
>
>         https://bugs.openjdk.java.net/browse/JDK-8136570
>         https://bugs.openjdk.java.net/browse/JDK-4953367
>         http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/
>         <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/>
>         <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/>
>
>
>



From daniel.fuchs at oracle.com  Wed Sep 16 16:44:22 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 16 Sep 2015 18:44:22 +0200
Subject: RFR 8073542 : File Leak in
	jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c
In-Reply-To: <55F976A5.1000807@oracle.com>
References: <55F9318D.2030100@oracle.com> <55F976A5.1000807@oracle.com>
Message-ID: <55F99C66.3050900@oracle.com>

Hi Vyom,

I will sponsor your change and push the fix for you.
I'll sync up with Rob to check that we don't step on each other's toes.

best regards,

-- daniel

On 16/09/15 16:03, Chris Hegarty wrote:
> The changes look good to me Vyom.
>
> -Chris.
>
> On 16/09/15 10:08, Vyom Tewari wrote:
>> Hi All,
>>
>> Please review my changes for below bug.
>>
>> Bug:
>>        JDK-8073542 : File Leak in
>> jdk/src/java/base/unix/native/libnet/PlainDatagramSocketImpl.c
>> Webrev:
>> http://cr.openjdk.java.net/~dfuchs/vyom/8073542/webrev.00
>>
>> This change ensure that if "setsocketopt" fails we close the
>> corresponding fd and throw correct  exception.
>>
>> Thanks,
>> Vyom



From joe.darcy at oracle.com  Wed Sep 16 16:58:15 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 16 Sep 2015 09:58:15 -0700
Subject: JDK 9 RFR of JDK-8134795: Port fdlibm pow to Java
In-Reply-To: <CA+3eh13QqXcPWHc-b4a5=cnPb7yRzFDJjjatBdC2BPGMohP6Cg@mail.gmail.com>
References: <55F8CFC6.5020104@oracle.com>
	<CA+3eh13QqXcPWHc-b4a5=cnPb7yRzFDJjjatBdC2BPGMohP6Cg@mail.gmail.com>
Message-ID: <55F99FA7.1030803@oracle.com>

Hi Volker,

On 9/16/2015 2:02 AM, Volker Simonis wrote:
> Hi Joe,
>
> nice clean-up! From a maintenance point of view the the old fdlibm has
> been a burden and a constant source of warnings with newer compilers.
>
> What about the final arrays in Pow.compute (BP, DP_H, DP_L). In the
> Interpreter (and even in C2 without EscapeAnalysis) this will lead to
> allocations every time the method is called. Making them static fields
> of 'Pow' will help here. On the other hand, if the arrays are static
> fields of 'Pow', C2 will not be able to directly use the constants but
> will have to load them from the array. So altogether, your current
> implementation is optimal with HotSpot (with EscapeAnalysis turned on
> by default) but might not be the best for other VMs without
> EscapaAnalysis.
>
> Have you done any benchmarking which compares the new Java against the
> old C implementation?
>
>

I don't have exact stats to share, but some quick benchmarks indicate it 
is noticeably faster, more than 10%. The less computation pow does in a 
given case, the faster the Java version should be since the Java -> C -> 
Java cost should roughly be fixed.

Once the code is fully in Java, I would expect further tweaks to refine 
the code. For example, the original FDLIM code used the idiom of pointer 
aliasing a two-element int array with a double. (This idiom was also the 
source of many of those compiler warnings ;-) We can't directly use that 
idiom in Java, but the early versions of the port were a close 
transliteration of the C sources with equivalent Java method calls. That 
still left the code as operating on 32-bit quantities or doing 
comparisons of the double value by looking at its 32 high-order bits. 
Many of those 32-bit operations were removed as the port progressed to 
use clearer (if not also faster) operations such as comparing 64-bit 
double values directly as 64-bit double values.

For example, to my eye I'd much rather read

  185             // Special value of x
  186             if (x_abs == 0.0 ||
  187                 x_abs == INFINITY ||
  188                 x_abs == 1.0) {
  189                 z = x_abs;                 // x is +/-0, +/-inf, +/-1
  190                 if (y < 0.0)
  191                     z = 1.0/z;     // z = (1/|x|)

where x_abs is a double holding the absolute value of x, than the 
original semantically equivalent original

  178     /* special value of x */
  179         if(lx==0) {
  180             if(ix==0x7ff00000||ix==0||ix==0x3ff00000){
  181                 z = ax;                 /*x is +-0,+-inf,+-1*/
  182                 if(hy<0) z = one/z;     /* z = (1/|x|) */

where lx is the lower-order 32 bits of x and ix is the high-order 32 
bits of x with the sign bit zeroed out.

The version sent out for review still has some remaining 32-bit centered 
operations and at least some of those could be eliminated.

Thanks,

-Joe


From martinrb at google.com  Wed Sep 16 17:25:09 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 16 Sep 2015 10:25:09 -0700
Subject: Modifier order for 'default' (was: RFR: 8136583: Core libraries
	should use blessed modifier order)
In-Reply-To: <DB9878BC-C151-4D79-A1AD-F4343C5F593F@oracle.com>
References: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
	<003bba8a-2848-4c04-92c4-ef64a497acc5.maildroid@localhost>
	<DB9878BC-C151-4D79-A1AD-F4343C5F593F@oracle.com>
Message-ID: <CA+kOe0--1+SA0KBn5pcpaNC3CxpcEJAbuD=nj-SS3b8AH95Krg@mail.gmail.com>

So although default "looks like" a modifier, technically it's not, but it
can be inferred from values of other modifiers.  Method.isDefault:

    public boolean isDefault() {
        // Default methods are public non-abstract instance methods
        // declared in an interface.
        return ((getModifiers() & (Modifier.ABSTRACT | Modifier.PUBLIC |
Modifier.STATIC)) ==
                Modifier.PUBLIC) && getDeclaringClass().isInterface();
    }

In practice, it's reasonable to insist that "default" comes first - it's a
pseudo-modifier.  The JLS could bless that (maybe it already does?)


On Wed, Sep 16, 2015 at 4:34 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi Bernd,
>
> In some respects ?default? is easy. It can only occur on non-abstract
> methods on interfaces, and declaring such methods ?public? is redundant (as
> is the case for abstract methods on interfaces, where also declaring
> ?abstract? is redundant). [*] And there are more redundant cases related to
> enums and nested classes.
>
> A further clean up would to run relevant code inspections in the IDE to
> remove redundant declarations.
>
> Paul.
>
> [*] FWIW there are a few cases of ?public default? and ?default public? in
> the OpenJDK source code
>
> On 16 Sep 2015, at 04:48, ecki at zusammenkunft.net wrote:
>
> > Martin, this will be known as the "blame martin" patch, good work.
> >
> > But more seriously a minor thing I noticed in your shell script (as well
> as the mentioned sources and some coding guidelines), the new interface
> `default` method modifier is not defined in any of those lists.
> >
> > Not sure if it is actually a problem for this patch (there seems to be
> no line with default modifier), but its just a general observation (with
> the hidden hope to get an authoritative consensus of the location of
> `default` as well, even when it might be the wrong mailinglist).
> >
> > Greetings
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> > -----Original Message-----
> > From: Martin Buchholz <martinrb at google.com>
> > To: core-libs-dev <core-libs-dev at openjdk.java.net>, Chris Hegarty <
> chris.hegarty at oracle.com>, Paul Sandoz <paul.sandoz at oracle.com>
> > Sent: Mi., 16 Sep. 2015 2:54
> > Subject: RFR: 8136583: Core libraries should use blessed modifier order
> >
> > Hi, Chris and Paul,
> > I'd like you to do a very boring code review.
> >
> > This change is entirely machine generated. (the script is more
> interesting)
> >
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patch
> > https://bugs.openjdk.java.net/browse/JDK-8136583
>
>


From martinrb at google.com  Wed Sep 16 17:53:55 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 16 Sep 2015 10:53:55 -0700
Subject: <AWT Dev> RFR: 8136570: Avoid setting environment variables
	related to /usr/dt
In-Reply-To: <55F9922D.5000705@oracle.com>
References: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>
	<55F8A083.3020300@oracle.com>
	<CA+kOe0_zfJSapN0GrAHQBJF-=yqVQuEA_KQbr7xZE3KQY4fHJg@mail.gmail.com>
	<55F9922D.5000705@oracle.com>
Message-ID: <CA+kOe0-Ekw-GmJy6AF9s95kBo0NzuXbozUmPRKPT_avHaLGsoA@mail.gmail.com>

Webrev regenerated
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/usr-dt-environment.patch
and is now the best kind of change, a pure-deletion change.

On Wed, Sep 16, 2015 at 9:00 AM, Phil Race <philip.race at oracle.com> wrote:

> That is fine by me. If any one on awt-dev knows of a reason to keep it
> they should speak up.
>
> -phil.
>
>
> On 9/15/15 5:09 PM, Martin Buchholz wrote:
>
> We would be entirely happy if the environment frobbing code were to be
> deleted.
> Should I change my code to do that?
>
> On Tue, Sep 15, 2015 at 3:49 PM, Phil Race <philip.race at oracle.com> wrote:
>
>> I don't understand that original assessment.
>> Switching to XAWT had no impact on this code except to make it pointless.
>> i.e it did not prevent its execution.
>>
>> I doubt there is any code left in the JDK that will derive any
>> benefit from it still being there. All CDE/Motif & Xt related code is
>> gone.
>> This should have been removed along with it but was doubtless not
>> in plain sight to whoever did that.
>>
>> So unless I am missing something you could go further and just delete it.
>>
>> -phil.
>>
>>
>> On 9/15/2015 3:13 PM, Martin Buchholz wrote:
>>
>>> I reported this bug 12 years ago, but it was closed Will Not Fix, and
>>> this year I see java programs crashing because of it!
>>> This is a partial fix.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8136570
>>> https://bugs.openjdk.java.net/browse/JDK-4953367
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/
>>> <
>>> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/
>>> >
>>>
>>
>>
>
>


From martinrb at google.com  Wed Sep 16 17:57:30 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 16 Sep 2015 10:57:30 -0700
Subject: RFR: 8136570: Avoid setting environment variables related to
	/usr/dt
In-Reply-To: <CAA-vtUz0Qq4+7mHc4M_FpmGGQowO4_AGswTjPaOje2qmG+jJZw@mail.gmail.com>
References: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>
	<CAA-vtUz0Qq4+7mHc4M_FpmGGQowO4_AGswTjPaOje2qmG+jJZw@mail.gmail.com>
Message-ID: <CA+kOe08kSm2kyh_cbsRJXddiQ58QqfcXW1K45Z4UZiYvGQUDQg@mail.gmail.com>

Mostly moot, now that we have consensus on just deleting these entirely,
but my (original) code was safer because it calls putenv in fewer cases.
Who knows what /usr/dt is "supposed" to look like these days?  "Common"
Desktop Environment not so "common" anymore...

On Wed, Sep 16, 2015 at 1:33 AM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi Martin,
>
> would it be not sufficient to just test for existence of /usr/dt before
> the two calls to setPathEnvironment() and leave the rest as it is? I also
> think the intend would be clearer ("only call this if CDE is installed").
>
> Kind Regards, Thomas
>
>
>
> On Wed, Sep 16, 2015 at 12:13 AM, Martin Buchholz <martinrb at google.com>
> wrote:
>
>> I reported this bug 12 years ago, but it was closed Will Not Fix, and this
>> year I see java programs crashing because of it!
>> This is a partial fix.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8136570
>> https://bugs.openjdk.java.net/browse/JDK-4953367
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/
>>
>
>


From alejandro.murillo at oracle.com  Wed Sep 16 18:03:39 2015
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Wed, 16 Sep 2015 12:03:39 -0600
Subject: [verona.stage] RFR 8087203: Adapt Version.java.template to the JEP-223
	new version string format
Message-ID: <55F9AEFB.1030005@oracle.com>

Please review these changes:

Bug: https://bugs.openjdk.java.net/browse/JDK-8087203
Webrev: http://cr.openjdk.java.net/~amurillo/9/8087203/

The actual code changes for this bug (8087203) were entered along
with the ones for 8087202. The changes here are just fixing some
javadoc comments in that template

Thanks

-- 
Alejandro



From martinrb at google.com  Wed Sep 16 18:20:14 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 16 Sep 2015 11:20:14 -0700
Subject: RFR: 8136583: Core libraries should use blessed modifier order
In-Reply-To: <55F98872.6030008@gmail.com>
References: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
	<55F98872.6030008@gmail.com>
Message-ID: <CA+kOe0-dJ3UVHDAYKsL90wVkbb3m3GCDKQHog40KA4US+E_s4g@mail.gmail.com>

Peter, that Java program is awesome, but ...
the original perl seems more readable to me (!)
even if I apply some not-yet-done perl golf to it,
and it seems to me that if we're rewriting in Java we can get the benefits
of Java, i.e. correctness, which you can probably get by tapping into
javac's conversion to AST.  This would allow you to get modifiers split
across lines correct, for example.

In practice we want to change the order within e.g. javadoc comments as
well, but we'll leave that to a bolder future code janitor.

On Wed, Sep 16, 2015 at 8:19 AM, Peter Levart <peter.levart at gmail.com>
wrote:

> Hi Martin,
>
>
> On 09/16/2015 02:42 AM, Martin Buchholz wrote:
>
> Hi, Chris and Paul,
> I'd like you to do a very boring code review.
>
> This change is entirely machine generated. (the script is more interesting)http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patchhttps://bugs.openjdk.java.net/browse/JDK-8136583
>
>
> Reviewing the diff would be boring, yes. More interesting is trying to
> understand the script.
>
> I re-implemented your script in some other language (called Java ;-) and
> compared the results. Nothing can beat concise expressiveness of bash
> instantiations of perl template, but Java lambdas and streams are not too
> shabby either. Here's a re-implementation in 2 expressions and 1 statement:
>
> import java.io.IOException;
> import java.io.UncheckedIOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import java.util.List;
> import java.util.function.Function;
> import java.util.regex.Pattern;
> import java.util.stream.Collectors;
> import java.util.stream.IntStream;
> import java.util.stream.Stream;
>
> import static java.nio.file.StandardCopyOption.*;
> import static java.nio.file.StandardOpenOption.*;
>
> public class BlessedModifierOrder {
>
>     static final List<String> modifiers = Arrays.asList(
>         "public", "protected", "private",
>         "abstract", "static", "final", "transient",
>         "volatile", "synchronized", "native", "strictfp"
>     );
>
>     static final Function<String, String> editor = IntStream
>         .range(3, modifiers.size())
>         .mapToObj(i -> Pattern.compile(
>             "^([A-Za-z@ ]*)\\b(" +
>             modifiers.subList(i,
> modifiers.size()).stream().collect(Collectors.joining("|")) +
>             ") +(" +
>             modifiers.subList(0,
> i).stream().collect(Collectors.joining("|")) +
>             ")\\b"
>         ))
>         .map(pattern -> (Function<String, String>) line -> {
>             String editedLine;
>             while (!line.equals(editedLine =
> pattern.matcher(line).replaceFirst("$1$3 $2"))) {
>                 line = editedLine;
>             }
>             return line;
>         })
>         .reduce(Function.identity(), (f1, f2) -> f1.andThen(f2));
>
>     public static void main(String[] args) {
>         Stream.of(args)
>               .map(Paths::get)
>               .flatMap(dir -> {
>                   try (Stream<Path> files = Files.find(
>                       dir, Integer.MAX_VALUE,
>                       (p, attr) -> attr.isRegularFile() &&
> p.toString().endsWith(".java")
>                   )) {
>                       return files.collect(Collectors.toList()).stream();
>                   } catch (IOException e) {
>                       throw new UncheckedIOException(e);
>                   }
>               })
>               .forEach(file -> {
>                   try (Stream<String> linesStream = Files.lines(file)) {
>                       List<String> lines = linesStream.map(editor)
>
> .collect(Collectors.toList());
>                       Path newFile =
> file.resolveSibling(file.getFileName() + ".new");
>                       Files.write(newFile, lines, WRITE, CREATE,
> TRUNCATE_EXISTING);
>                       Files.move(newFile, file, ATOMIC_MOVE,
> REPLACE_EXISTING);
>                   } catch (IOException e) {
>                       throw new UncheckedIOException(e);
>                   }
>               });
>     }
> }
>
>
> Anyway, the result is exactly the same.
>
>
> Regards, Peter
>
>


From alejandro.murillo at oracle.com  Wed Sep 16 18:23:53 2015
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Wed, 16 Sep 2015 12:23:53 -0600
Subject: [verona.stage] RFR 8134365: Test test/sun/misc/Version/Version.java
	should follow Verona rules for trailing zeros
Message-ID: <55F9B3B9.6000706@oracle.com>

Please review this change:

Bug: https://bugs.openjdk.java.net/browse/JDK-8134365
Webrev: http://cr.openjdk.java.net/~amurillo/9/8134365/

This change modifies the toString() method of: 
test/sun/misc/Version/Version.java
so that it doesn't  include trailing zeros when  the some version fields
are not defined. For  example, if  the version is  9-ea+b2,
"toString()" should not return 9.0.0.0-ea+b2

note that this class will eventually be modified to use the Java API to 
parse,
validate, and compare version strings once it is available.
That's being tracked under: https://bugs.openjdk.java.net/browse/JDK-8136651

Thanks

-- 
Alejandro



From joe.darcy at oracle.com  Wed Sep 16 18:49:24 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 16 Sep 2015 11:49:24 -0700
Subject: RFR: 8136583: Core libraries should use blessed modifier order
In-Reply-To: <CA+kOe0-dJ3UVHDAYKsL90wVkbb3m3GCDKQHog40KA4US+E_s4g@mail.gmail.com>
References: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
	<55F98872.6030008@gmail.com>
	<CA+kOe0-dJ3UVHDAYKsL90wVkbb3m3GCDKQHog40KA4US+E_s4g@mail.gmail.com>
Message-ID: <55F9B9B4.9000503@oracle.com>

FWIW, for a related possible future cleanup some modifiers by convention 
can be omitted, such as abstract on normal interface methods. The 
printModifiers method written annotation processing

http://hg.openjdk.java.net/jdk9/dev/langtools/file/286fc9270404/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java

tries to output the informative modifiers (in the suggested order).

-Joe

On 9/16/2015 11:20 AM, Martin Buchholz wrote:
> Peter, that Java program is awesome, but ...
> the original perl seems more readable to me (!)
> even if I apply some not-yet-done perl golf to it,
> and it seems to me that if we're rewriting in Java we can get the benefits
> of Java, i.e. correctness, which you can probably get by tapping into
> javac's conversion to AST.  This would allow you to get modifiers split
> across lines correct, for example.
>
> In practice we want to change the order within e.g. javadoc comments as
> well, but we'll leave that to a bolder future code janitor.
>
> On Wed, Sep 16, 2015 at 8:19 AM, Peter Levart <peter.levart at gmail.com>
> wrote:
>
>> Hi Martin,
>>
>>
>> On 09/16/2015 02:42 AM, Martin Buchholz wrote:
>>
>> Hi, Chris and Paul,
>> I'd like you to do a very boring code review.
>>
>> This change is entirely machine generated. (the script is more interesting)http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patchhttps://bugs.openjdk.java.net/browse/JDK-8136583
>>
>>
>> Reviewing the diff would be boring, yes. More interesting is trying to
>> understand the script.
>>
>> I re-implemented your script in some other language (called Java ;-) and
>> compared the results. Nothing can beat concise expressiveness of bash
>> instantiations of perl template, but Java lambdas and streams are not too
>> shabby either. Here's a re-implementation in 2 expressions and 1 statement:
>>
>> import java.io.IOException;
>> import java.io.UncheckedIOException;
>> import java.nio.file.Files;
>> import java.nio.file.Path;
>> import java.nio.file.Paths;
>> import java.util.Arrays;
>> import java.util.List;
>> import java.util.function.Function;
>> import java.util.regex.Pattern;
>> import java.util.stream.Collectors;
>> import java.util.stream.IntStream;
>> import java.util.stream.Stream;
>>
>> import static java.nio.file.StandardCopyOption.*;
>> import static java.nio.file.StandardOpenOption.*;
>>
>> public class BlessedModifierOrder {
>>
>>      static final List<String> modifiers = Arrays.asList(
>>          "public", "protected", "private",
>>          "abstract", "static", "final", "transient",
>>          "volatile", "synchronized", "native", "strictfp"
>>      );
>>
>>      static final Function<String, String> editor = IntStream
>>          .range(3, modifiers.size())
>>          .mapToObj(i -> Pattern.compile(
>>              "^([A-Za-z@ ]*)\\b(" +
>>              modifiers.subList(i,
>> modifiers.size()).stream().collect(Collectors.joining("|")) +
>>              ") +(" +
>>              modifiers.subList(0,
>> i).stream().collect(Collectors.joining("|")) +
>>              ")\\b"
>>          ))
>>          .map(pattern -> (Function<String, String>) line -> {
>>              String editedLine;
>>              while (!line.equals(editedLine =
>> pattern.matcher(line).replaceFirst("$1$3 $2"))) {
>>                  line = editedLine;
>>              }
>>              return line;
>>          })
>>          .reduce(Function.identity(), (f1, f2) -> f1.andThen(f2));
>>
>>      public static void main(String[] args) {
>>          Stream.of(args)
>>                .map(Paths::get)
>>                .flatMap(dir -> {
>>                    try (Stream<Path> files = Files.find(
>>                        dir, Integer.MAX_VALUE,
>>                        (p, attr) -> attr.isRegularFile() &&
>> p.toString().endsWith(".java")
>>                    )) {
>>                        return files.collect(Collectors.toList()).stream();
>>                    } catch (IOException e) {
>>                        throw new UncheckedIOException(e);
>>                    }
>>                })
>>                .forEach(file -> {
>>                    try (Stream<String> linesStream = Files.lines(file)) {
>>                        List<String> lines = linesStream.map(editor)
>>
>> .collect(Collectors.toList());
>>                        Path newFile =
>> file.resolveSibling(file.getFileName() + ".new");
>>                        Files.write(newFile, lines, WRITE, CREATE,
>> TRUNCATE_EXISTING);
>>                        Files.move(newFile, file, ATOMIC_MOVE,
>> REPLACE_EXISTING);
>>                    } catch (IOException e) {
>>                        throw new UncheckedIOException(e);
>>                    }
>>                });
>>      }
>> }
>>
>>
>> Anyway, the result is exactly the same.
>>
>>
>> Regards, Peter
>>
>>



From martinrb at google.com  Wed Sep 16 19:36:17 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 16 Sep 2015 12:36:17 -0700
Subject: RFR: 8136656: Check in blessed-modifier-order.sh
Message-ID: <CA+kOe09V+akTJojt7Bq7oAZeTt-HdZZ8-bWbGLGGUbE51GXbyg@mail.gmail.com>

Hi guys,

Here's the requested script checkin:

https://bugs.openjdk.java.net/browse/JDK-8136656
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order.sh/


From martinrb at google.com  Wed Sep 16 19:41:43 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 16 Sep 2015 12:41:43 -0700
Subject: RFR: 8136583: Core libraries should use blessed modifier order
In-Reply-To: <55F9B9B4.9000503@oracle.com>
References: <CA+kOe08C7dMLSFEwsQkwZyfFDj1JbnzFJr1HXvTmwip+J3br+w@mail.gmail.com>
	<55F98872.6030008@gmail.com>
	<CA+kOe0-dJ3UVHDAYKsL90wVkbb3m3GCDKQHog40KA4US+E_s4g@mail.gmail.com>
	<55F9B9B4.9000503@oracle.com>
Message-ID: <CA+kOe09LK9nx14P9qtHh9wZ9vT8-n8hz6F9vkGk2KMtYUdGvmg@mail.gmail.com>

I love both hacky regexy perl and AST-based super-correct javaey analysis,
and I welcome the competition!  My hacky script knows its limits and is not
going to try to get e.g. enclosing class vs. interface correct.

On Wed, Sep 16, 2015 at 11:49 AM, joe darcy <joe.darcy at oracle.com> wrote:

> FWIW, for a related possible future cleanup some modifiers by convention
> can be omitted, such as abstract on normal interface methods. The
> printModifiers method written annotation processing
>
>
> http://hg.openjdk.java.net/jdk9/dev/langtools/file/286fc9270404/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java
>
> tries to output the informative modifiers (in the suggested order).
>
> -Joe
>
> On 9/16/2015 11:20 AM, Martin Buchholz wrote:
>
>> Peter, that Java program is awesome, but ...
>> the original perl seems more readable to me (!)
>> even if I apply some not-yet-done perl golf to it,
>> and it seems to me that if we're rewriting in Java we can get the benefits
>> of Java, i.e. correctness, which you can probably get by tapping into
>> javac's conversion to AST.  This would allow you to get modifiers split
>> across lines correct, for example.
>>
>> In practice we want to change the order within e.g. javadoc comments as
>> well, but we'll leave that to a bolder future code janitor.
>>
>> On Wed, Sep 16, 2015 at 8:19 AM, Peter Levart <peter.levart at gmail.com>
>> wrote:
>>
>> Hi Martin,
>>>
>>>
>>> On 09/16/2015 02:42 AM, Martin Buchholz wrote:
>>>
>>> Hi, Chris and Paul,
>>> I'd like you to do a very boring code review.
>>>
>>> This change is entirely machine generated. (the script is more
>>> interesting)
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-order.patchhttps://bugs.openjdk.java.net/browse/JDK-8136583
>>>
>>>
>>>
>>> Reviewing the diff would be boring, yes. More interesting is trying to
>>> understand the script.
>>>
>>> I re-implemented your script in some other language (called Java ;-) and
>>> compared the results. Nothing can beat concise expressiveness of bash
>>> instantiations of perl template, but Java lambdas and streams are not too
>>> shabby either. Here's a re-implementation in 2 expressions and 1
>>> statement:
>>>
>>> import java.io.IOException;
>>> import java.io.UncheckedIOException;
>>> import java.nio.file.Files;
>>> import java.nio.file.Path;
>>> import java.nio.file.Paths;
>>> import java.util.Arrays;
>>> import java.util.List;
>>> import java.util.function.Function;
>>> import java.util.regex.Pattern;
>>> import java.util.stream.Collectors;
>>> import java.util.stream.IntStream;
>>> import java.util.stream.Stream;
>>>
>>> import static java.nio.file.StandardCopyOption.*;
>>> import static java.nio.file.StandardOpenOption.*;
>>>
>>> public class BlessedModifierOrder {
>>>
>>>      static final List<String> modifiers = Arrays.asList(
>>>          "public", "protected", "private",
>>>          "abstract", "static", "final", "transient",
>>>          "volatile", "synchronized", "native", "strictfp"
>>>      );
>>>
>>>      static final Function<String, String> editor = IntStream
>>>          .range(3, modifiers.size())
>>>          .mapToObj(i -> Pattern.compile(
>>>              "^([A-Za-z@ ]*)\\b(" +
>>>              modifiers.subList(i,
>>> modifiers.size()).stream().collect(Collectors.joining("|")) +
>>>              ") +(" +
>>>              modifiers.subList(0,
>>> i).stream().collect(Collectors.joining("|")) +
>>>              ")\\b"
>>>          ))
>>>          .map(pattern -> (Function<String, String>) line -> {
>>>              String editedLine;
>>>              while (!line.equals(editedLine =
>>> pattern.matcher(line).replaceFirst("$1$3 $2"))) {
>>>                  line = editedLine;
>>>              }
>>>              return line;
>>>          })
>>>          .reduce(Function.identity(), (f1, f2) -> f1.andThen(f2));
>>>
>>>      public static void main(String[] args) {
>>>          Stream.of(args)
>>>                .map(Paths::get)
>>>                .flatMap(dir -> {
>>>                    try (Stream<Path> files = Files.find(
>>>                        dir, Integer.MAX_VALUE,
>>>                        (p, attr) -> attr.isRegularFile() &&
>>> p.toString().endsWith(".java")
>>>                    )) {
>>>                        return
>>> files.collect(Collectors.toList()).stream();
>>>                    } catch (IOException e) {
>>>                        throw new UncheckedIOException(e);
>>>                    }
>>>                })
>>>                .forEach(file -> {
>>>                    try (Stream<String> linesStream = Files.lines(file)) {
>>>                        List<String> lines = linesStream.map(editor)
>>>
>>> .collect(Collectors.toList());
>>>                        Path newFile =
>>> file.resolveSibling(file.getFileName() + ".new");
>>>                        Files.write(newFile, lines, WRITE, CREATE,
>>> TRUNCATE_EXISTING);
>>>                        Files.move(newFile, file, ATOMIC_MOVE,
>>> REPLACE_EXISTING);
>>>                    } catch (IOException e) {
>>>                        throw new UncheckedIOException(e);
>>>                    }
>>>                });
>>>      }
>>> }
>>>
>>>
>>> Anyway, the result is exactly the same.
>>>
>>>
>>> Regards, Peter
>>>
>>>
>>>
>


From Roger.Riggs at Oracle.com  Wed Sep 16 21:44:52 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 16 Sep 2015 17:44:52 -0400
Subject: RFR 9: 8132735: java/lang/ProcessHandle/TreeTest failed with
	java.lang.AssertionError: Start with zero children
Message-ID: <55F9E2D4.5060100@Oracle.com>

Please review this test fix so the test code only operates on processes 
it spawns.
On Windows, other processes may show up as children that are not part of 
the test.

Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-treetest-8132735/

Issue:
    https://bugs.openjdk.java.net/browse/JDK-8132735

Thanks, Roger



From martinrb at google.com  Wed Sep 16 22:17:46 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 16 Sep 2015 15:17:46 -0700
Subject: RFR [9] 8133188: docs: replace <tt> tags (obsolete in html5) for
	java.util
In-Reply-To: <55C8A98C.3090002@oracle.com>
References: <55C8A98C.3090002@oracle.com>
Message-ID: <CA+kOe08q8P4zU-b3OYxk8rOXr8aQ8KUGcbreLJukViL_eihhjQ@mail.gmail.com>

Why not try to fix *all* the "easy" occurrences in the repo (except for
owners who prefer to fix their own) using an automated script?

On Mon, Aug 10, 2015 at 6:39 AM, Alexander Stepanov <
alexander.v.stepanov at oracle.com> wrote:

> Hello,
>
> Could you please review the following fix:
> http://cr.openjdk.java.net/~avstepan/8133188/webrev.01
> for
> https://bugs.openjdk.java.net/browse/JDK-8133188
>
> Just a next portion of "<tt>" tags removed.
>
> specdiff report:
>
> http://cr.openjdk.java.net/~avstepan/8133188/specdiff.util/overview-summary.html
>  - some constructs like
> "<tt>(o==null&nbsp;?&nbsp;e==null&nbsp;:&nbsp;o.equals(e))</tt>"
> were replaced with "{@code Objects.equals(o, e)}"
> (e.g.,
> http://cr.openjdk.java.net/~avstepan/8133188/webrev.01/src/java.base/share/classes/java/util/LinkedList.java.udiff.html);
> - please see JDK-8133188 comments.
>
> Thanks,
> Alexander
>


From stuart.marks at oracle.com  Wed Sep 16 23:08:09 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 16 Sep 2015 16:08:09 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F98E2F.4050507@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com> <55F0AD95.8060909@oracle.com>
	<55F0B43C.2030205@oracle.com> <55F0B7F1.8010200@oracle.com>
	<55F1E683.9050905@oracle.com> <55F1F22A.4000802@oracle.com>
	<55F8F4B9.80802@oracle.com> <55F98E2F.4050507@oracle.com>
Message-ID: <55F9F659.3080103@oracle.com>



On 9/16/15 8:43 AM, Xueming Shen wrote:

> I'm talking about the check "immediately" prior to the call to accept(). It
> will not function after the modCount tips over to the negative int value,
> because the "expectedCount >=0" check.
>
> Consider the use scenario that the Scanner is on top of an endless input
> stream, you have a token stream on top of it. The check before the
> "accept(token" will not be performed until the expectedCount/modCount tips
> back to positive value again from the negative, then off, then on... During
> the off period (it will take a while from negative back to positive), the
> stream will just work fine to feed the accept() the "next" token even if
> there is another thread keeps "stealing" tokens from the same scanner, if the
> timing is right.  Looks like not really a "fail-fast" in this scenario.

Right, after modCount wraps around to negative, the CME checking becomes 
dysfunctional. It doesn't do any harm, but it ceases to perform proper checking. 
This is kind of a corner case but ... well I admit I did have to do a fair bit 
of puzzling to figure out what the behavior would be and to prove to myself that 
it was benign.

> This can be "easily" addressed, if you have a separate boolean field such as
> "initialized". The code can look like below in tryAdvance(...)

[edited per your subsequent message]

>
>      if (!initialized) {
>          expectedCount = modCount;
>          initialized = true;
>      }
>      if (expectedCount != modCount) {
>          throw new CME();
>      }
>      ...
>
> Well, if you think this is an unlikely use scenario and the intention of the
> check/guard here is mainly to prevent the wrong doing within the pipe
> operation, then it might not worth the extra field, and I'm fine with the
> latest webrev.

The cost of the additional field is negligible. I haven't written out the code 
but I suspect that an explicit "initialized" field will be easier to reason 
about, certainly easier to understand than the behavior that occurs if modCount 
wraps around to negative.

Note that this also applies to Matcher, although it's less likely since 
Matcher's input is a CharSequence instead of an indefinite-sized source such as 
a file or an input stream. In talking to Paul Sandoz about this (author of the 
streams stuff for Matcher) he felt it was important to keep the behaviors of 
Matcher and Scanner consistent.

But this has dragged out somewhat and I don't really want to add Matcher changes 
to this changeset. How about I do the following:

1) I'll push the latest webrev as it stands.

2) I'll file a separate bug to clean up Scanner's and Matcher's spliterators' 
modCount checking to avoid the overflow issue.

3) I'll fix all the spliterators at the same time.

How does that sound?

s'marks


From xueming.shen at oracle.com  Wed Sep 16 23:11:38 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 16 Sep 2015 16:11:38 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F9F659.3080103@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com> <55F0AD95.8060909@oracle.com>
	<55F0B43C.2030205@oracle.com> <55F0B7F1.8010200@oracle.com>
	<55F1E683.9050905@oracle.com> <55F1F22A.4000802@oracle.com>
	<55F8F4B9.80802@oracle.com> <55F98E2F.4050507@oracle.com>
	<55F9F659.3080103@oracle.com>
Message-ID: <55F9F72A.70407@oracle.com>

On 09/16/2015 04:08 PM, Stuart Marks wrote:
>
>
> On 9/16/15 8:43 AM, Xueming Shen wrote:
>
>> I'm talking about the check "immediately" prior to the call to accept(). It
>> will not function after the modCount tips over to the negative int value,
>> because the "expectedCount >=0" check.
>>
>> Consider the use scenario that the Scanner is on top of an endless input
>> stream, you have a token stream on top of it. The check before the
>> "accept(token" will not be performed until the expectedCount/modCount tips
>> back to positive value again from the negative, then off, then on... During
>> the off period (it will take a while from negative back to positive), the
>> stream will just work fine to feed the accept() the "next" token even if
>> there is another thread keeps "stealing" tokens from the same scanner, if the
>> timing is right.  Looks like not really a "fail-fast" in this scenario.
>
> Right, after modCount wraps around to negative, the CME checking becomes dysfunctional. It doesn't do any harm, but it ceases to perform proper checking. This is kind of a corner case but ... well I admit I did have to do a fair bit of puzzling to figure out what the behavior would be and to prove to myself that it was benign.
>
>> This can be "easily" addressed, if you have a separate boolean field such as
>> "initialized". The code can look like below in tryAdvance(...)
>
> [edited per your subsequent message]
>
>>
>>      if (!initialized) {
>>          expectedCount = modCount;
>>          initialized = true;
>>      }
>>      if (expectedCount != modCount) {
>>          throw new CME();
>>      }
>>      ...
>>
>> Well, if you think this is an unlikely use scenario and the intention of the
>> check/guard here is mainly to prevent the wrong doing within the pipe
>> operation, then it might not worth the extra field, and I'm fine with the
>> latest webrev.
>
> The cost of the additional field is negligible. I haven't written out the code but I suspect that an explicit "initialized" field will be easier to reason about, certainly easier to understand than the behavior that occurs if modCount wraps around to negative.
>
> Note that this also applies to Matcher, although it's less likely since Matcher's input is a CharSequence instead of an indefinite-sized source such as a file or an input stream. In talking to Paul Sandoz about this (author of the streams stuff for Matcher) he felt it was important to keep the behaviors of Matcher and Scanner consistent.
>
> But this has dragged out somewhat and I don't really want to add Matcher changes to this changeset. How about I do the following:
>
> 1) I'll push the latest webrev as it stands.
>
> 2) I'll file a separate bug to clean up Scanner's and Matcher's spliterators' modCount checking to avoid the overflow issue.
>
> 3) I'll fix all the spliterators at the same time.
>
> How does that sound?

I'm fine with it.

-sherman



From stuart.marks at oracle.com  Thu Sep 17 00:01:15 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 16 Sep 2015 17:01:15 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F9F72A.70407@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com> <55F0AD95.8060909@oracle.com>
	<55F0B43C.2030205@oracle.com> <55F0B7F1.8010200@oracle.com>
	<55F1E683.9050905@oracle.com> <55F1F22A.4000802@oracle.com>
	<55F8F4B9.80802@oracle.com> <55F98E2F.4050507@oracle.com>
	<55F9F659.3080103@oracle.com> <55F9F72A.70407@oracle.com>
Message-ID: <55FA02CB.2050502@oracle.com>



On 9/16/15 4:11 PM, Xueming Shen wrote:
> On 09/16/2015 04:08 PM, Stuart Marks wrote:

>> 1) I'll push the latest webrev as it stands.
>>
>> 2) I'll file a separate bug to clean up Scanner's and Matcher's spliterators'
>> modCount checking to avoid the overflow issue.
>>
>> 3) I'll fix all the spliterators at the same time.
>>
>> How does that sound?
>
> I'm fine with it.

OK, I've pushed 8072722:

	http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b997ba72d8d4

And I've filed the following bug:

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

Thanks for your flexibility.

s'marks


From mandy.chung at oracle.com  Thu Sep 17 00:44:36 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 16 Sep 2015 17:44:36 -0700
Subject: [verona.stage] RFR 8134365: Test
	test/sun/misc/Version/Version.java should follow Verona rules
	for trailing zeros
In-Reply-To: <55F9B3B9.6000706@oracle.com>
References: <55F9B3B9.6000706@oracle.com>
Message-ID: <F92F6601-EF27-4496-8C82-36FDF0AA94F3@oracle.com>


> On Sep 16, 2015, at 11:23 AM, Alejandro E Murillo <alejandro.murillo at oracle.com> wrote:
> 
> Please review this change:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8134365
> Webrev: http://cr.openjdk.java.net/~amurillo/9/8134365/
> 
> This change modifies the toString() method of: test/sun/misc/Version/Version.java
> so that it doesn't  include trailing zeros when  the some version fields
> are not defined. For  example, if  the version is  9-ea+b2,
> "toString()" should not return 9.0.0.0-ea+b2

This looks okay to me.

Mandy



From mandy.chung at oracle.com  Thu Sep 17 04:52:53 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 16 Sep 2015 21:52:53 -0700
Subject: RFR: 8033661: readConfiguration does not cleanly reinitialize the
	logging system
In-Reply-To: <55F6F517.8000100@oracle.com>
References: <55F06497.5010300@oracle.com>
	<1F185ECE-B5B1-4175-ABAA-B86FCD0861EC@oracle.com>
	<55F6F517.8000100@oracle.com>
Message-ID: <EBE38931-6036-4908-8C50-9F7C8B34E729@oracle.com>


> On Sep 14, 2015, at 9:25 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> So with that in mind, I have slightly altered the @apiNotes:
> 
> in readConfiguration():
> 
>     * @apiNote {@code readConfiguration} is principally useful for
>     *    establishing the LogManager primordial configuration.
>     *    <p>
>     *    Calling this method directly from the application code after the
>     *    LogManager has been initialized is discouraged.
> 

What about:

This method is intended for LogManager primordial configuration.  Use 
the {@link #updateConfiguration} method to reload configuration after
the LogManager has been initialized.

I think it?s worth cleaning up the specification about logging configuration - moving the rules about locating the configuration properties from the class javadoc to the specification of the readConfiguration method

for example, move these 3 paragraphs 
  If the "java.util.logging.config.class" property is set, ?..
  If "java.util.logging.config.class" property is not set, ..
  If neither of these properties is defined

 to replace "The same rules are used for locating the configuration properties as are used at startup?..?.

Note that readConfiguration() reads from system property.

> 
> The rationale is that an application which needs to establish
> a custom configuration should probably use the
> {@code "java.util.logging.config.class"} property, and
> call LogManager.readConfiguration(InputStream) from there,
> as hinted in the class-level documentation.
> 
> in readConfiguration(InputStream):

This will not reinitialize the logging configuration specified in the "java.util.logging.config.class? system property.  So I think moving the rules to locate logging configuration to readConfiguration() method will help.

What does this line do:
  String names[] = parseClassNames("config?);


> 
>     * @apiNote {@code readConfiguration} is principally useful for applications
>     *    which use the {@code "java.util.logging.config.class"} property
>     *    to establish their own custom configuration.
>     *    <p>
>     *    Calling this method directly from the application code after the
>     *    LogManager has been initialized is discouraged.

Since it?s not deprecated, instead of a note to discourage using it, it seems to be more useful to describe the behavior of this method and issues with the handler etc after reset.  

Then recommend to use the {@link #updateConfiguration} method to reload configuration after
the LogManager has been initialized.

> 
>> 
>> 1749      * Updates an existing configuration.
>> 
>> We should specify what ?existing configuration? is.
>> If ?java.util.logging.config.class? is set and it?s instantiated successfully,
>> readConfiguration will not read from any configuration file.
>> updateConfiguration only reads the config file regardless
>> if ?java.util.logging.config.class? is set.
> 
> I updated the doc for updateConfiguration(mapper):
> 
>  :
>  

I think this method should only read the logging config file if the "java.util.logging.config.class? property is not set.  If set, it should be instantiated successfully and that will never read the logging config file. 

The spec should say:

Update the logging configuration.  It will read the logging properties file that was read at startup time.

If the "java.util.logging.config.file" system property is set, the logging configuration is read from the path specified in the property value.  If the "java.util.logging.config.file" system property is not set, then the default configuration is used. 

Question:
If ?java.util.logging.config.class? is set, should it throw an exception instead of silently continue or read from the default configuration.

Should it re-read the system property at runtime or cached value?  What if  ?java.util.logging.config.file? is not set at startup but later set at runtime after LogManager was initialized?

> 
> 
>> 
>> 1761      * @param remapper
>> 
>> ?re? probably not needed here.   I think ?mapper? should work.
> 
> OK. Should I still use the term of 'remapping function' then?
> Or does that become 'mapping function' too?
> 

Can it simply refer it as ?a function mapping from a pair of the current value and the new value of a key to the value to be applied"

What about something like this:

mapper - a functional interface that takes a configuration key and returns a function that takes the value in the current configuration and the value in the given configuration as parameters and produces the actual value to be applied. If the mapper is null, or the function the mapper returns is null, then the value in the given configuration will be the new value. A null value passed as parameter to the function indicates that no value was present in the corresponding configuration.

Another way can define some variables to represent all these values and functions so that the specification can refer to these variables instead.  I can work with you on the specification.


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

Implementation side - looks okay.  Some comments:

I found some VisitedLoggers methods unnecessary.  It may help if we can change
  VisitedLoggers.test(Logger) - name can be obtained from Logger.getName()
  VisitedLoggers.

Instead of calling VisitedLoggers.of(null), it seems more explicit to call VisitedLogger.NEVER (or FALSE)

Is it useful to have ModType.EQUAL or SAME and non null value guaranteed.

Perhaps time to change LoggerContext.getLoggerNames to return Set<String>.

ConfigurationProperties - it?s an enum, should it be ConfigurationProperty instead?  ConfigProperty might work too.

ConfigurationProperties.isChanging method - would ?compare? and ?equals? work here?  Using some commonly used method names will help readers to understand the code easier.

final List<Logger> tmp = cxs.isEmpty() ?.
- would ?loggers? work here - anything better than tmp?  It?s actually the list of candidate loggers to be updated with the new configuration properties.

There are several words referenced ?reestablished?, ?reinitialized?, ?update?.  It?d help if the same word is used consistently in the specification and comment.

I haven?t reviewed the tests yet.
Mandy




From amaembo at gmail.com  Thu Sep 17 06:02:01 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Thu, 17 Sep 2015 12:02:01 +0600
Subject: [PATCH] Collectors.counting() does unnecessary boxing on every
	accumulation
Message-ID: <455620165.20150917120201@gmail.com>

Hello!

Could you please consider the following very simple patch to
Collectors.counting() implementation?

diff --git a/src/java.base/share/classes/java/util/stream/Collectors.java b/src/java.base/share/classes/java/util/stream/Collectors.java
--- a/src/java.base/share/classes/java/util/stream/Collectors.java
+++ b/src/java.base/share/classes/java/util/stream/Collectors.java
@@ -504,7 +504,7 @@
      */
     public static <T> Collector<T, ?, Long>
     counting() {
-        return reducing(0L, e -> 1L, Long::sum);
+        return summingLong(e -> 1L);
     }
 
     /**

===== END-OF-PATCH =====

Current implementation uses reducing collector which is not
primitive-specialized, thus on every accumulation event the current
Long value is unboxed, then boxed again (inside one-element Object[]
array created in "reducing"). As this collector is intended for
downstream use, these boxes are usually stored as map values for
different keys, thus JIT-compiler has practically no chance to
optimize out these operations. In contrast summingLong is more
performant as it uses the primitive long[] one-element array and
modifies it in-place.

Though it's quite obvious that this change should improve the
performance, I did some simple benchmark here:
https://gist.github.com/amaembo/6d9c0e74fec99c665620
Using summingLong can be up to 30% faster.

With best regards,
Tagir Valeev.



From peter.levart at gmail.com  Thu Sep 17 07:11:24 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 17 Sep 2015 09:11:24 +0200
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55F9F659.3080103@oracle.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com> <55F0AD95.8060909@oracle.com>
	<55F0B43C.2030205@oracle.com> <55F0B7F1.8010200@oracle.com>
	<55F1E683.9050905@oracle.com> <55F1F22A.4000802@oracle.com>
	<55F8F4B9.80802@oracle.com> <55F98E2F.4050507@oracle.com>
	<55F9F659.3080103@oracle.com>
Message-ID: <55FA679C.8010702@gmail.com>

As an alternative to additional boolean field, you could use one bit of 
expectedCount/modCount int field(s):

- let initial value of expectedCount be 1 (odd value)
- instead of (expectedCount >= 0) ==> (expectedCount != 1)
- let initial value of modCount be 0 (even value)
- instead of modCount++ ==> modCount += 2;

Regards, Peter

On 09/17/2015 01:08 AM, Stuart Marks wrote:
>
>
> On 9/16/15 8:43 AM, Xueming Shen wrote:
>
>> I'm talking about the check "immediately" prior to the call to 
>> accept(). It
>> will not function after the modCount tips over to the negative int 
>> value,
>> because the "expectedCount >=0" check.
>>
>> Consider the use scenario that the Scanner is on top of an endless input
>> stream, you have a token stream on top of it. The check before the
>> "accept(token" will not be performed until the expectedCount/modCount 
>> tips
>> back to positive value again from the negative, then off, then on... 
>> During
>> the off period (it will take a while from negative back to positive), 
>> the
>> stream will just work fine to feed the accept() the "next" token even if
>> there is another thread keeps "stealing" tokens from the same 
>> scanner, if the
>> timing is right.  Looks like not really a "fail-fast" in this scenario.
>
> Right, after modCount wraps around to negative, the CME checking 
> becomes dysfunctional. It doesn't do any harm, but it ceases to 
> perform proper checking. This is kind of a corner case but ... well I 
> admit I did have to do a fair bit of puzzling to figure out what the 
> behavior would be and to prove to myself that it was benign.
>
>> This can be "easily" addressed, if you have a separate boolean field 
>> such as
>> "initialized". The code can look like below in tryAdvance(...)
>
> [edited per your subsequent message]
>
>>
>>      if (!initialized) {
>>          expectedCount = modCount;
>>          initialized = true;
>>      }
>>      if (expectedCount != modCount) {
>>          throw new CME();
>>      }
>>      ...
>>
>> Well, if you think this is an unlikely use scenario and the intention 
>> of the
>> check/guard here is mainly to prevent the wrong doing within the pipe
>> operation, then it might not worth the extra field, and I'm fine with 
>> the
>> latest webrev.
>
> The cost of the additional field is negligible. I haven't written out 
> the code but I suspect that an explicit "initialized" field will be 
> easier to reason about, certainly easier to understand than the 
> behavior that occurs if modCount wraps around to negative.
>
> Note that this also applies to Matcher, although it's less likely 
> since Matcher's input is a CharSequence instead of an indefinite-sized 
> source such as a file or an input stream. In talking to Paul Sandoz 
> about this (author of the streams stuff for Matcher) he felt it was 
> important to keep the behaviors of Matcher and Scanner consistent.
>
> But this has dragged out somewhat and I don't really want to add 
> Matcher changes to this changeset. How about I do the following:
>
> 1) I'll push the latest webrev as it stands.
>
> 2) I'll file a separate bug to clean up Scanner's and Matcher's 
> spliterators' modCount checking to avoid the overflow issue.
>
> 3) I'll fix all the spliterators at the same time.
>
> How does that sound?
>
> s'marks



From magnus.ihse.bursie at oracle.com  Thu Sep 17 08:11:52 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 17 Sep 2015 10:11:52 +0200
Subject: RFR: 8136656: Check in blessed-modifier-order.sh
In-Reply-To: <CA+kOe09V+akTJojt7Bq7oAZeTt-HdZZ8-bWbGLGGUbE51GXbyg@mail.gmail.com>
References: <CA+kOe09V+akTJojt7Bq7oAZeTt-HdZZ8-bWbGLGGUbE51GXbyg@mail.gmail.com>
Message-ID: <55FA75C8.6000500@oracle.com>

On 2015-09-16 21:36, Martin Buchholz wrote:
> Hi guys,
>
> Here's the requested script checkin:
>
> https://bugs.openjdk.java.net/browse/JDK-8136656
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order.sh/

Martin,

We're trying to retire the "make/scripts" directory, since this is 
unrelated to the make code. Can you please put the file in "common/bin" 
instead?

/Magnus


From chris.hegarty at oracle.com  Thu Sep 17 08:14:26 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 17 Sep 2015 09:14:26 +0100
Subject: RFR: 8136656: Check in blessed-modifier-order.sh
In-Reply-To: <CA+kOe09V+akTJojt7Bq7oAZeTt-HdZZ8-bWbGLGGUbE51GXbyg@mail.gmail.com>
References: <CA+kOe09V+akTJojt7Bq7oAZeTt-HdZZ8-bWbGLGGUbE51GXbyg@mail.gmail.com>
Message-ID: <9B4887EB-34F3-46D4-BED6-8E8541CDFF35@oracle.com>

On 16 Sep 2015, at 20:36, Martin Buchholz <martinrb at google.com> wrote:

> Hi guys,
> 
> Here's the requested script checkin:
> 
> https://bugs.openjdk.java.net/browse/JDK-8136656
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order.sh/

Looks fine.  Just add an appropriate licence header, move to 'common/bin?, and you?re all set.

-Chris.

From lange.fabian at gmail.com  Thu Sep 17 09:09:28 2015
From: lange.fabian at gmail.com (Fabian Lange)
Date: Thu, 17 Sep 2015 11:09:28 +0200
Subject: ProcessBuilder still leaking memory
Message-ID: <CAFNq5NNAVcif=BfzOvYKwyu7JU4ZqUd7OWq=+CYE3+VFJMpBpw@mail.gmail.com>

Hi all,
I am still seeing a memory leak caused by process builder
It seems to be the same as reported here:
https://bugs.openjdk.java.net/browse/JDK-8054841

which is claimed to be fixed, but in 8u45 and 8u60 it still reproduces on
my Amazon Linux
Linux ip-10-208-67-36 3.2.30-49.59.amzn1.x86_64 #1 SMP Wed Oct 3 19:54:33
UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

can I assist somehow in resolving the leak? Feel free to contact me off
list.

What is interesting, is that contrary to the OP, my real application dies
with java.lang.OutOfMemoryError: Java heap space on an array allocation.
The java process remains alive, but does not react to kill -3 or anything.

Best regards,
Fabian


From paul.sandoz at oracle.com  Thu Sep 17 09:21:46 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 17 Sep 2015 11:21:46 +0200
Subject: [PATCH] Collectors.counting() does unnecessary boxing on every
	accumulation
In-Reply-To: <455620165.20150917120201@gmail.com>
References: <455620165.20150917120201@gmail.com>
Message-ID: <B45A80AA-3DC0-4CAE-843A-3E08A475BC96@oracle.com>

Hi Tagir,

Thanks, looks good.

I created:

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

and i also included an update to a test.

Assuming no further review comments i will commit tomorrow.

Paul.

diff -r 4be07e0eb9b6 test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java
--- a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java	Thu Sep 17 10:37:39 2015 +0800
+++ b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java	Thu Sep 17 11:21:16 2015 +0200
@@ -31,6 +31,7 @@

 import java.util.HashSet;
 import java.util.concurrent.atomic.AtomicInteger;
+import java.util.stream.Collectors;
 import java.util.stream.DoubleStream;
 import java.util.stream.DoubleStreamTestDataProvider;
 import java.util.stream.IntStream;
@@ -61,6 +62,12 @@
                 expectedResult(expectedCount).
                 exercise();

+        // Test counting collector
+        withData(data).
+                terminal(s -> s, s -> s.collect(Collectors.counting())).
+                expectedResult(expectedCount).
+                exercise();
+
         // Test with stateful distinct op that is a barrier or lazy
         // depending if source is not already distinct and encounter order is
         // preserved or not


On 17 Sep 2015, at 08:02, Tagir F. Valeev <amaembo at gmail.com> wrote:

> Hello!
> 
> Could you please consider the following very simple patch to
> Collectors.counting() implementation?
> 
> diff --git a/src/java.base/share/classes/java/util/stream/Collectors.java b/src/java.base/share/classes/java/util/stream/Collectors.java
> --- a/src/java.base/share/classes/java/util/stream/Collectors.java
> +++ b/src/java.base/share/classes/java/util/stream/Collectors.java
> @@ -504,7 +504,7 @@
>      */
>     public static <T> Collector<T, ?, Long>
>     counting() {
> -        return reducing(0L, e -> 1L, Long::sum);
> +        return summingLong(e -> 1L);
>     }
> 
>     /**
> 
> ===== END-OF-PATCH =====
> 
> Current implementation uses reducing collector which is not
> primitive-specialized, thus on every accumulation event the current
> Long value is unboxed, then boxed again (inside one-element Object[]
> array created in "reducing"). As this collector is intended for
> downstream use, these boxes are usually stored as map values for
> different keys, thus JIT-compiler has practically no chance to
> optimize out these operations. In contrast summingLong is more
> performant as it uses the primitive long[] one-element array and
> modifies it in-place.
> 
> Though it's quite obvious that this change should improve the
> performance, I did some simple benchmark here:
> https://gist.github.com/amaembo/6d9c0e74fec99c665620
> Using summingLong can be up to 30% faster.
> 
> With best regards,
> Tagir Valeev.
> 



From amaembo at gmail.com  Thu Sep 17 09:33:27 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Thu, 17 Sep 2015 15:33:27 +0600
Subject: [PATCH] Collectors.counting() does unnecessary boxing on every
	accumulation
In-Reply-To: <B45A80AA-3DC0-4CAE-843A-3E08A475BC96@oracle.com>
References: <455620165.20150917120201@gmail.com>
	<B45A80AA-3DC0-4CAE-843A-3E08A475BC96@oracle.com>
Message-ID: <725444915.20150917153327@gmail.com>

Hello!

Thank you very much!

With best regards,
Tagir Valeev.

PS> Hi Tagir,

PS> Thanks, looks good.

PS> I created:

PS>   https://bugs.openjdk.java.net/browse/JDK-8136686

PS> and i also included an update to a test.

PS> Assuming no further review comments i will commit tomorrow.

PS> Paul.

PS> diff -r 4be07e0eb9b6
PS> test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java
PS> ---
PS> a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java Thu Sep 17 10:37:39 2015 +0800
PS> +++
PS> b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java Thu Sep 17 11:21:16 2015 +0200
PS> @@ -31,6 +31,7 @@

PS>  import java.util.HashSet;
PS>  import java.util.concurrent.atomic.AtomicInteger;
PS> +import java.util.stream.Collectors;
PS>  import java.util.stream.DoubleStream;
PS>  import java.util.stream.DoubleStreamTestDataProvider;
PS>  import java.util.stream.IntStream;
PS> @@ -61,6 +62,12 @@
PS>                  expectedResult(expectedCount).
PS>                  exercise();

PS> +        // Test counting collector
PS> +        withData(data).
PS> +                terminal(s -> s, s ->
PS> s.collect(Collectors.counting())).
PS> +                expectedResult(expectedCount).
PS> +                exercise();
PS> +
PS>          // Test with stateful distinct op that is a barrier or lazy
PS>          // depending if source is not already distinct and encounter order is
PS>          // preserved or not


PS> On 17 Sep 2015, at 08:02, Tagir F. Valeev <amaembo at gmail.com> wrote:

>> Hello!
>> 
>> Could you please consider the following very simple patch to
>> Collectors.counting() implementation?
>> 
>> diff --git a/src/java.base/share/classes/java/util/stream/Collectors.java b/src/java.base/share/classes/java/util/stream/Collectors.java
>> --- a/src/java.base/share/classes/java/util/stream/Collectors.java
>> +++ b/src/java.base/share/classes/java/util/stream/Collectors.java
>> @@ -504,7 +504,7 @@
>>      */
>>     public static <T> Collector<T, ?, Long>
>>     counting() {
>> -        return reducing(0L, e -> 1L, Long::sum);
>> +        return summingLong(e -> 1L);
>>     }
>> 
>>     /**
>> 
>> ===== END-OF-PATCH =====
>> 
>> Current implementation uses reducing collector which is not
>> primitive-specialized, thus on every accumulation event the current
>> Long value is unboxed, then boxed again (inside one-element Object[]
>> array created in "reducing"). As this collector is intended for
>> downstream use, these boxes are usually stored as map values for
>> different keys, thus JIT-compiler has practically no chance to
>> optimize out these operations. In contrast summingLong is more
>> performant as it uses the primitive long[] one-element array and
>> modifies it in-place.
>> 
>> Though it's quite obvious that this change should improve the
>> performance, I did some simple benchmark here:
>> https://gist.github.com/amaembo/6d9c0e74fec99c665620
>> Using summingLong can be up to 30% faster.
>> 
>> With best regards,
>> Tagir Valeev.
>> 



From volker.simonis at gmail.com  Thu Sep 17 10:08:58 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 17 Sep 2015 12:08:58 +0200
Subject: RFR(XS): 8136690: AIX: libjimage should be linked with the C++
	compiler
Message-ID: <CA+3eh10_Z1YwXtqv7EsJZ5xwdO-vgXKEJcQY7Bxhidvaw5qSwQ@mail.gmail.com>

Hi,

can somebody please review the following AIX change which fixes the
build on AIX after "8087181 Move native jimage code to its own library
(maybe libjimage)":

http://cr.openjdk.java.net/~simonis/webrevs/2015/8136690/
https://bugs.openjdk.java.net/browse/JDK-8136690

Change 8087181 moved the jimage code into its own library into the jdk
repository. Although libjimage is a C++ library it is currently linked
by the C compiler together with platform dependent C++ system
libraries (and I'm not sure if this is done intentionally or if it is
just a copy-and-paste error).

On AIX linking a C++ library with the C-compiler doesn't work and we
have to link the library with the C++ compiler which automatically
adds all the required dependencies.

Thank you and best regards,
Volker


From magnus.ihse.bursie at oracle.com  Thu Sep 17 13:00:13 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 17 Sep 2015 15:00:13 +0200
Subject: RFR(XS): 8136690: AIX: libjimage should be linked with the C++
	compiler
In-Reply-To: <CA+3eh10_Z1YwXtqv7EsJZ5xwdO-vgXKEJcQY7Bxhidvaw5qSwQ@mail.gmail.com>
References: <CA+3eh10_Z1YwXtqv7EsJZ5xwdO-vgXKEJcQY7Bxhidvaw5qSwQ@mail.gmail.com>
Message-ID: <55FAB95D.40100@oracle.com>

On 2015-09-17 12:08, Volker Simonis wrote:
> Hi,
>
> can somebody please review the following AIX change which fixes the
> build on AIX after "8087181 Move native jimage code to its own library
> (maybe libjimage)":
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8136690/
> https://bugs.openjdk.java.net/browse/JDK-8136690

Looks good to me.

/Magnus
>
> Change 8087181 moved the jimage code into its own library into the jdk
> repository. Although libjimage is a C++ library it is currently linked
> by the C compiler together with platform dependent C++ system
> libraries (and I'm not sure if this is done intentionally or if it is
> just a copy-and-paste error).
>
> On AIX linking a C++ library with the C-compiler doesn't work and we
> have to link the library with the C++ compiler which automatically
> adds all the required dependencies.
>
> Thank you and best regards,
> Volker



From vincent.x.ryan at oracle.com  Thu Sep 17 13:12:46 2015
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 17 Sep 2015 14:12:46 +0100
Subject: RFR: 8129957 - Deadlock in JNDI LDAP implementation when closing
	the LDAP context
In-Reply-To: <55F6E6EC.2020300@oracle.com>
References: <55C8A1DD.7020508@oracle.com> <55F6E6EC.2020300@oracle.com>
Message-ID: <D1F831E5-0E5F-43B2-B83F-C14A9D90BD6A@oracle.com>

Your proposed fix looks fine Rob.
Thanks.


> On 14 Sep 2015, at 16:25, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> Hi folks,
> 
> So on further investigation it looks like we could get away with reducing the amount of locking in LdapClient. Here is a proposed fix followed by a description:
> 
> http://cr.openjdk.java.net/~robm/8129957/webrev.02/
> 
> processConnectionClosure():
> - Remove the synchronization from processConnectionClosure and handle it further down in notifyUnsolicited
> 
> removeUnsolicited():
> - Remove the synchronized block in removeUnsolicited as its redundant. Vectors are synchronized already.
> 
> processUnsolicited()
> - Remove the initial synchronized block in processUnsolicited and limit it to the area around the unsolicited size check / notice creation. (again, due to the notifyUnsolicited changes)
> - Remove the redundant unsolicited.size check from the end of processUnsolicited
> 
> notifyUnsolicited():
> - Synchronize on the unsolicited vector in order to create a copy of that vector and empty it if e is a NamingException.
> - Outside the notifyUnsolicited synchronize block, loop through the copy of unsolicited and call fireUnsolicited on each element.
> - The main potential problem with this fix would be if an LdapCtx became unsolicited before we got to it in the for loop. However since both LdapCtx.fireUnsolicited and LdapCtx.removeUnsolicited sync on eventSupport and LdapCtx.fireUnsolicited double checks to make sure it is still unsolicited, that should be fine.
> 
> 	-Rob
> 
> 
> On 10/08/15 14:06, Rob McKenna wrote:
>> Hi folks,
>> 
>> We have a hang between LdapClient / Ctx due to the fact that
>> Connection.cleanup() calls LdapClient.processConnectionClosure which
>> locks the unsolicited vector and in turn calls LdapCtx.fireUnsolicited
>> which locks the eventSupport object. Unfortunately when an
>> LdapCtx.close() occurs at the same time, its removeUnsolicited method
>> locks the eventSupport object first and then attempts to call
>> LdapClient.removeUnsolicited which attempts to lock the unsolicited vector.
>> 
>> So:
>> 
>> thread 1:
>> 
>> Connection.cleanup ->
>> LdapClient.processConnectionClosure (LOCK VECTOR) ->
>> LdapCtx.fireUnsolicited (LOCK EVENTSUPPORT)
>> 
>> (LdapClient is looping through LdapCtx objects in the unsolicited vector)
>> 
>> thread 2:
>> 
>> LdapCtx.close (LOCK LDAPCTX) ->
>> LdapCtx.removeUnsolicited (LOCK EVENTSUPPORT) ->
>> LdapClient.removeUnsolicited (LOCK VECTOR)
>> 
>> (A single LdapCtx removes itself from its LdapClient unsolicited list)
>> 
>> 
>> My proposed solution is to have both threads lock the LdapClient before
>> locking either the unsolicited vector or the eventSupport object.
>> 
>> Webrev at: http://cr.openjdk.java.net/~robm/8129957/webrev.01/
>> 
>>     -Rob



From alejandro.murillo at oracle.com  Thu Sep 17 13:21:14 2015
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Thu, 17 Sep 2015 07:21:14 -0600
Subject: [verona.stage] RFR 8134365: Test
	test/sun/misc/Version/Version.java
	should follow Verona rules for trailing zeros
In-Reply-To: <F92F6601-EF27-4496-8C82-36FDF0AA94F3@oracle.com>
References: <55F9B3B9.6000706@oracle.com>
	<F92F6601-EF27-4496-8C82-36FDF0AA94F3@oracle.com>
Message-ID: <55FABE4A.4080306@oracle.com>


On 9/16/2015 6:44 PM, Mandy Chung wrote:
>> On Sep 16, 2015, at 11:23 AM, Alejandro E Murillo <alejandro.murillo at oracle.com> wrote:
>>
>> Please review this change:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134365
>> Webrev: http://cr.openjdk.java.net/~amurillo/9/8134365/
>>
>> This change modifies the toString() method of: test/sun/misc/Version/Version.java
>> so that it doesn't  include trailing zeros when  the some version fields
>> are not defined. For  example, if  the version is  9-ea+b2,
>> "toString()" should not return 9.0.0.0-ea+b2
> This looks okay to me.
>
> Mandy
>
Thanks Mandy

-- 
Alejandro



From sean.coffey at oracle.com  Thu Sep 17 13:50:03 2015
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 17 Sep 2015 14:50:03 +0100
Subject: RFR (xs) : 8077874 : [TESTBUG] The test
	com/sun/corba/cachedSocket/7056731.sh should not be run on JRE
Message-ID: <55FAC50B.4080702@oracle.com>

Test bug correction to allow the jdb command to be launched via 
compilejdk parameter where necessary. I've checked for similar usage 
across other corba tests and this one seems to be the only one. Also 
made a small edit to use the $JAVA variable where possible. (was already 
defined)

bug report : https://bugs.openjdk.java.net/browse/JDK-8077874
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8077874.jdk9/webrev/

-- 
Regards,
Sean.



From ivan.gerasimov at oracle.com  Thu Sep 17 16:04:38 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 17 Sep 2015 19:04:38 +0300
Subject: ProcessBuilder still leaking memory
In-Reply-To: <CAFNq5NNAVcif=BfzOvYKwyu7JU4ZqUd7OWq=+CYE3+VFJMpBpw@mail.gmail.com>
References: <CAFNq5NNAVcif=BfzOvYKwyu7JU4ZqUd7OWq=+CYE3+VFJMpBpw@mail.gmail.com>
Message-ID: <55FAE496.2050106@oracle.com>

Hi Fabian!

The issue JDK-8054841 was due to failing to free natively allocated memory.
It wouldn't cause Java heap space exhaustion, so you must be observing 
something different.

Can you please provide some more details about your use case?

Sincerely yours,
Ivan

On 17.09.2015 12:09, Fabian Lange wrote:
> Hi all,
> I am still seeing a memory leak caused by process builder
> It seems to be the same as reported here:
> https://bugs.openjdk.java.net/browse/JDK-8054841
>
> which is claimed to be fixed, but in 8u45 and 8u60 it still reproduces on
> my Amazon Linux
> Linux ip-10-208-67-36 3.2.30-49.59.amzn1.x86_64 #1 SMP Wed Oct 3 19:54:33
> UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> can I assist somehow in resolving the leak? Feel free to contact me off
> list.
>
> What is interesting, is that contrary to the OP, my real application dies
> with java.lang.OutOfMemoryError: Java heap space on an array allocation.
> The java process remains alive, but does not react to kill -3 or anything.
>
> Best regards,
> Fabian
>



From martinrb at google.com  Thu Sep 17 16:08:13 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 17 Sep 2015 09:08:13 -0700
Subject: RFR: 8136656: Check in blessed-modifier-order.sh
In-Reply-To: <9B4887EB-34F3-46D4-BED6-8E8541CDFF35@oracle.com>
References: <CA+kOe09V+akTJojt7Bq7oAZeTt-HdZZ8-bWbGLGGUbE51GXbyg@mail.gmail.com>
	<9B4887EB-34F3-46D4-BED6-8E8541CDFF35@oracle.com>
Message-ID: <CA+kOe0_H37wPjQirYOWfu3gKDdLfAMK1C-BuTu4aiXPKhjSHDA@mail.gmail.com>

Done!

On Thu, Sep 17, 2015 at 1:14 AM, Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> On 16 Sep 2015, at 20:36, Martin Buchholz <martinrb at google.com> wrote:
>
> > Hi guys,
> >
> > Here's the requested script checkin:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8136656
> >
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order.sh/
>
> Looks fine.  Just add an appropriate licence header, move to 'common/bin?,
> and you?re all set.
>
> -Chris.


From chris.hegarty at oracle.com  Thu Sep 17 16:08:51 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 17 Sep 2015 17:08:51 +0100
Subject: RFR 9: 8132735: java/lang/ProcessHandle/TreeTest failed with
	java.lang.AssertionError: Start with zero children
In-Reply-To: <55F9E2D4.5060100@Oracle.com>
References: <55F9E2D4.5060100@Oracle.com>
Message-ID: <08622FF5-B374-411D-9626-135DEDBA8D82@oracle.com>

Looks ok to me Roger.

-Chris.

On 16 Sep 2015, at 22:44, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Please review this test fix so the test code only operates on processes it spawns.
> On Windows, other processes may show up as children that are not part of the test.
> 
> Webrev:
>  http://cr.openjdk.java.net/~rriggs/webrev-treetest-8132735/
> 
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8132735
> 
> Thanks, Roger
> 



From chris.hegarty at oracle.com  Thu Sep 17 16:09:56 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 17 Sep 2015 17:09:56 +0100
Subject: RFR: 8136656: Check in blessed-modifier-order.sh
In-Reply-To: <CA+kOe0_H37wPjQirYOWfu3gKDdLfAMK1C-BuTu4aiXPKhjSHDA@mail.gmail.com>
References: <CA+kOe09V+akTJojt7Bq7oAZeTt-HdZZ8-bWbGLGGUbE51GXbyg@mail.gmail.com>
	<9B4887EB-34F3-46D4-BED6-8E8541CDFF35@oracle.com>
	<CA+kOe0_H37wPjQirYOWfu3gKDdLfAMK1C-BuTu4aiXPKhjSHDA@mail.gmail.com>
Message-ID: <6A95504A-9F86-4A61-B5AA-85E094385C94@oracle.com>

On 17 Sep 2015, at 17:08, Martin Buchholz <martinrb at google.com> wrote:

> Done!

The updated webrev ( in-place ) looks good to me Martin.

-Chris.

> On Thu, Sep 17, 2015 at 1:14 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> On 16 Sep 2015, at 20:36, Martin Buchholz <martinrb at google.com> wrote:
> 
> > Hi guys,
> >
> > Here's the requested script checkin:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8136656
> > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order.sh/
> 
> Looks fine.  Just add an appropriate licence header, move to 'common/bin?, and you?re all set.
> 
> -Chris.
> 



From philip.race at oracle.com  Thu Sep 17 16:10:37 2015
From: philip.race at oracle.com (Phil Race)
Date: Thu, 17 Sep 2015 09:10:37 -0700
Subject: <AWT Dev> RFR: 8136570: Avoid setting environment variables
	related to /usr/dt
In-Reply-To: <CA+kOe0-Ekw-GmJy6AF9s95kBo0NzuXbozUmPRKPT_avHaLGsoA@mail.gmail.com>
References: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>
	<55F8A083.3020300@oracle.com>
	<CA+kOe0_zfJSapN0GrAHQBJF-=yqVQuEA_KQbr7xZE3KQY4fHJg@mail.gmail.com>
	<55F9922D.5000705@oracle.com>
	<CA+kOe0-Ekw-GmJy6AF9s95kBo0NzuXbozUmPRKPT_avHaLGsoA@mail.gmail.com>
Message-ID: <55FAE5FD.30209@oracle.com>

+1 ( ie approved). May need a core-libs reviewer too ?

-phil.

On 9/16/2015 10:53 AM, Martin Buchholz wrote:
> Webrev regenerated
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/usr-dt-environment.patch 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/usr-dt-environment.patch> 
>
> and is now the best kind of change, a pure-deletion change.
>
> On Wed, Sep 16, 2015 at 9:00 AM, Phil Race <philip.race at oracle.com 
> <mailto:philip.race at oracle.com>> wrote:
>
>     That is fine by me. If any one on awt-dev knows of a reason to keep it
>     they should speak up.
>
>     -phil.
>
>
>     On 9/15/15 5:09 PM, Martin Buchholz wrote:
>>     We would be entirely happy if the environment frobbing code were
>>     to be deleted.
>>     Should I change my code to do that?
>>
>>     On Tue, Sep 15, 2015 at 3:49 PM, Phil Race
>>     <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>>
>>         I don't understand that original assessment.
>>         Switching to XAWT had no impact on this code except to make
>>         it pointless.
>>         i.e it did not prevent its execution.
>>
>>         I doubt there is any code left in the JDK that will derive any
>>         benefit from it still being there. All CDE/Motif & Xt related
>>         code is gone.
>>         This should have been removed along with it but was doubtless not
>>         in plain sight to whoever did that.
>>
>>         So unless I am missing something you could go further and
>>         just delete it.
>>
>>         -phil.
>>
>>
>>         On 9/15/2015 3:13 PM, Martin Buchholz wrote:
>>
>>             I reported this bug 12 years ago, but it was closed Will
>>             Not Fix, and this year I see java programs crashing
>>             because of it!
>>             This is a partial fix.
>>
>>             https://bugs.openjdk.java.net/browse/JDK-8136570
>>             https://bugs.openjdk.java.net/browse/JDK-4953367
>>             http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/
>>             <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/>
>>             <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/>
>>
>>
>>
>
>



From martinrb at google.com  Thu Sep 17 16:12:29 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 17 Sep 2015 09:12:29 -0700
Subject: <AWT Dev> RFR: 8136570: Avoid setting environment variables
	related to /usr/dt
In-Reply-To: <55FAE5FD.30209@oracle.com>
References: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>
	<55F8A083.3020300@oracle.com>
	<CA+kOe0_zfJSapN0GrAHQBJF-=yqVQuEA_KQbr7xZE3KQY4fHJg@mail.gmail.com>
	<55F9922D.5000705@oracle.com>
	<CA+kOe0-Ekw-GmJy6AF9s95kBo0NzuXbozUmPRKPT_avHaLGsoA@mail.gmail.com>
	<55FAE5FD.30209@oracle.com>
Message-ID: <CA+kOe09YLaHAy=Hd==F6-HnuhByOLJJLk4FRSBq2Sw4tb=87VA@mail.gmail.com>

Too late, I just committed...
If people have second thoughts, this change should be watered down rather
than reverted anyways, so an independent followup change seems reasonable.

On Thu, Sep 17, 2015 at 9:10 AM, Phil Race <philip.race at oracle.com> wrote:

> +1 ( ie approved). May need a core-libs reviewer too ?
>
> -phil.
>
> On 9/16/2015 10:53 AM, Martin Buchholz wrote:
>
>> Webrev regenerated
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/usr-dt-environment.patch
>> <
>> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/usr-dt-environment.patch>
>>
>> and is now the best kind of change, a pure-deletion change.
>>
>> On Wed, Sep 16, 2015 at 9:00 AM, Phil Race <philip.race at oracle.com
>> <mailto:philip.race at oracle.com>> wrote:
>>
>>     That is fine by me. If any one on awt-dev knows of a reason to keep it
>>     they should speak up.
>>
>>     -phil.
>>
>>
>>     On 9/15/15 5:09 PM, Martin Buchholz wrote:
>>
>>>     We would be entirely happy if the environment frobbing code were
>>>     to be deleted.
>>>     Should I change my code to do that?
>>>
>>>     On Tue, Sep 15, 2015 at 3:49 PM, Phil Race
>>>     <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>>>
>>>         I don't understand that original assessment.
>>>         Switching to XAWT had no impact on this code except to make
>>>         it pointless.
>>>         i.e it did not prevent its execution.
>>>
>>>         I doubt there is any code left in the JDK that will derive any
>>>         benefit from it still being there. All CDE/Motif & Xt related
>>>         code is gone.
>>>         This should have been removed along with it but was doubtless not
>>>         in plain sight to whoever did that.
>>>
>>>         So unless I am missing something you could go further and
>>>         just delete it.
>>>
>>>         -phil.
>>>
>>>
>>>         On 9/15/2015 3:13 PM, Martin Buchholz wrote:
>>>
>>>             I reported this bug 12 years ago, but it was closed Will
>>>             Not Fix, and this year I see java programs crashing
>>>             because of it!
>>>             This is a partial fix.
>>>
>>>             https://bugs.openjdk.java.net/browse/JDK-8136570
>>>             https://bugs.openjdk.java.net/browse/JDK-4953367
>>>
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/
>>>             <
>>> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/
>>> >
>>>             <
>>> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/
>>> >
>>>
>>>
>>>
>>>
>>
>>
>


From martinrb at google.com  Thu Sep 17 16:24:36 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 17 Sep 2015 09:24:36 -0700
Subject: Running blessed-modifier-order on the rest of the JDK
Message-ID: <CA+kOe0-7knrYt_53D4NQ1oVmYbREL403dUD0VdFn6ymPtHPKeg@mail.gmail.com>

flush with success, I ran blessed-modifier-order on the entire JDK forest,
and it seems to work fine.
But we want to leave out code maintained elsewhere.  How to identify that?

Below are changes inside javadoc, which seem fine to me.

 $ hg tcommand hg diff | g '^[+-]  *\*'
-         * Access to final protected superclass member from outer class.
+         * Access to protected final superclass member from outer class.
-     * per a class in order to initialize a final static logger variable,
which is then used
+     * per a class in order to initialize a static final logger variable,
which is then used
-     * it is advised that the method is called only once per a class in
order to initialize a final static logger variable,
+     * it is advised that the method is called only once per a class in
order to initialize a static final logger variable,
-     * it is advised that the method is called only once per a class in
order to initialize a final static logger variable,
+     * it is advised that the method is called only once per a class in
order to initialize a static final logger variable,
-     *     synchronized static method of that class.
+     *     static synchronized method of that class.
- * abstract protected methods defined in this class need not synchronize
+ * protected abstract methods defined in this class need not synchronize
- *     final static ImageIcon longIcon = new ImageIcon("long.gif");
- *     final static ImageIcon shortIcon = new ImageIcon("short.gif");
+ *     static final ImageIcon longIcon = new ImageIcon("long.gif");
+ *     static final ImageIcon shortIcon = new ImageIcon("short.gif");
- * All attributes should be static private with accessors to simpify change
+ * All attributes should be private static with accessors to simpify change
- * This class holds only final static member variables that are constants
+ * This class holds only static final member variables that are constants
- * inherited static protected members differently when accessed
+ * inherited protected static members differently when accessed

# How big?
 $ hg tcommand hg st | grep -w M | wc -l
1952


From stuart.marks at oracle.com  Thu Sep 17 18:00:40 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 17 Sep 2015 11:00:40 -0700
Subject: <AWT Dev> RFR: 8136570: Avoid setting environment variables
	related to /usr/dt
In-Reply-To: <CA+kOe09YLaHAy=Hd==F6-HnuhByOLJJLk4FRSBq2Sw4tb=87VA@mail.gmail.com>
References: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>
	<55F8A083.3020300@oracle.com>
	<CA+kOe0_zfJSapN0GrAHQBJF-=yqVQuEA_KQbr7xZE3KQY4fHJg@mail.gmail.com>
	<55F9922D.5000705@oracle.com>
	<CA+kOe0-Ekw-GmJy6AF9s95kBo0NzuXbozUmPRKPT_avHaLGsoA@mail.gmail.com>
	<55FAE5FD.30209@oracle.com>
	<CA+kOe09YLaHAy=Hd==F6-HnuhByOLJJLk4FRSBq2Sw4tb=87VA@mail.gmail.com>
Message-ID: <55FAFFC8.104@oracle.com>

Doctor Deprecator approves.

Not only is this a win because it's a pure-deletion change, it's a double win 
because it removes a side effect from a function that's supposed to "get" and 
initialize Java properties values.

s'marks

On 9/17/15 9:12 AM, Martin Buchholz wrote:
> Too late, I just committed...
> If people have second thoughts, this change should be watered down rather
> than reverted anyways, so an independent followup change seems reasonable.
>
> On Thu, Sep 17, 2015 at 9:10 AM, Phil Race <philip.race at oracle.com> wrote:
>
>> +1 ( ie approved). May need a core-libs reviewer too ?
>>
>> -phil.
>>
>> On 9/16/2015 10:53 AM, Martin Buchholz wrote:
>>
>>> Webrev regenerated
>>>
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/usr-dt-environment.patch
>>> <
>>> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/usr-dt-environment.patch>
>>>
>>> and is now the best kind of change, a pure-deletion change.
>>>
>>> On Wed, Sep 16, 2015 at 9:00 AM, Phil Race <philip.race at oracle.com
>>> <mailto:philip.race at oracle.com>> wrote:
>>>
>>>      That is fine by me. If any one on awt-dev knows of a reason to keep it
>>>      they should speak up.
>>>
>>>      -phil.
>>>
>>>
>>>      On 9/15/15 5:09 PM, Martin Buchholz wrote:
>>>
>>>>      We would be entirely happy if the environment frobbing code were
>>>>      to be deleted.
>>>>      Should I change my code to do that?
>>>>
>>>>      On Tue, Sep 15, 2015 at 3:49 PM, Phil Race
>>>>      <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>>>>
>>>>          I don't understand that original assessment.
>>>>          Switching to XAWT had no impact on this code except to make
>>>>          it pointless.
>>>>          i.e it did not prevent its execution.
>>>>
>>>>          I doubt there is any code left in the JDK that will derive any
>>>>          benefit from it still being there. All CDE/Motif & Xt related
>>>>          code is gone.
>>>>          This should have been removed along with it but was doubtless not
>>>>          in plain sight to whoever did that.
>>>>
>>>>          So unless I am missing something you could go further and
>>>>          just delete it.
>>>>
>>>>          -phil.
>>>>
>>>>
>>>>          On 9/15/2015 3:13 PM, Martin Buchholz wrote:
>>>>
>>>>              I reported this bug 12 years ago, but it was closed Will
>>>>              Not Fix, and this year I see java programs crashing
>>>>              because of it!
>>>>              This is a partial fix.
>>>>
>>>>              https://bugs.openjdk.java.net/browse/JDK-8136570
>>>>              https://bugs.openjdk.java.net/browse/JDK-4953367
>>>>
>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/
>>>>              <
>>>> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/
>>>>>
>>>>              <
>>>> http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/usr-dt-environment/
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>


From brian.burkhalter at oracle.com  Thu Sep 17 19:27:10 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 17 Sep 2015 12:27:10 -0700
Subject: JDK 9 RFR of JDK-8134795: Port fdlibm pow to Java
In-Reply-To: <55F8CFC6.5020104@oracle.com>
References: <55F8CFC6.5020104@oracle.com>
Message-ID: <2A2BBC47-A5AC-484A-B468-EB9CF792F817@oracle.com>

Hi Joe,

This looks fine. +1.

Brian

On Sep 15, 2015, at 7:11 PM, Joseph D. Darcy <Joe.Darcy at Oracle.Com> wrote:

> At long last, I've started the port of the C version of FDLIBM (freely distributable math library) from C to Java, beginning with the pow method:
> 
>    JDK-8134795: Port fdlibm pow to Java
>    http://cr.openjdk.java.net/~darcy/8134795.6/
> 
> The FDLIBM algorithms provide direct backing to the more interesting methods in java.lang.StrictMath and indirect backing to the corresponding java.lang.Math methods on some platforms (depending on whether or not platform-optimized alternative versions are being used).



From jeffhain at rocketmail.com  Thu Sep 17 22:12:57 2015
From: jeffhain at rocketmail.com (Jeff Hain)
Date: Thu, 17 Sep 2015 22:12:57 +0000 (UTC)
Subject: JDK 9 RFR of JDK-8134795: Port fdlibm pow to Java
Message-ID: <1142192764.1716914.1442527977806.JavaMail.yahoo@mail.yahoo.com>

Hi.



>At long last, I've started the port of the C version of FDLIBM (freely
>distributable math library) from C to Java, beginning with the pow method:


I ran it through tests of my math lib (jafama),
and found the following issue:

// ok
??? StrictMath.pow(1.0000000000000004, 2.1E9) = 1.0000009325877754
FdLibm.Pow.compute(1.0000000000000004, 2.1E9) = 1.0000009325877754

// overflows early
??? StrictMath.pow(1.0000000000000004, 2.2E9) = 1.0000009769967388
FdLibm.Pow.compute(1.0000000000000004, 2.2E9) = Infinity

// actual overflow is much further
??? StrictMath.pow(1.0000000000000004, 1.59828858065033216E18) = 1.7976931348621944E308
??? StrictMath.pow(1.0000000000000004, 1.59828858065033242E18) = Infinity



Comparing the behavior of your code with that of Eric Blake's StrictMath
(the version I got has other issues, but not that one),
it could be corrected by replacing

if (x_abs > 1.0) {

with

if (x_abs >= 1.0000009536743164) {



After that modification, tests didn't show any difference with StrictMath.



-Jeff



From iris.clark at oracle.com  Thu Sep 17 22:17:25 2015
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 17 Sep 2015 15:17:25 -0700 (PDT)
Subject: [verona.stage] RFR 8087203: Adapt Version.java.template to the
	JEP-223 new version string format
In-Reply-To: <55F9AEFB.1030005@oracle.com>
References: <55F9AEFB.1030005@oracle.com>
Message-ID: <3ace7703-9d33-4457-a8dc-776e65d0a2d0@default>

Hi, Alejandro.

This cleanup looks good to me. 

Thanks,
iris (not a JDK 9 Reviewer)

-----Original Message-----
From: Alejandro E Murillo 
Sent: Wednesday, September 16, 2015 11:04 AM
To: core-libs-dev at openjdk.java.net
Cc: verona-dev at openjdk.java.net
Subject: [verona.stage] RFR 8087203: Adapt Version.java.template to the JEP-223 new version string format

Please review these changes:

Bug: https://bugs.openjdk.java.net/browse/JDK-8087203
Webrev: http://cr.openjdk.java.net/~amurillo/9/8087203/

The actual code changes for this bug (8087203) were entered along with the ones for 8087202. The changes here are just fixing some javadoc comments in that template

Thanks

--
Alejandro



From joe.darcy at oracle.com  Fri Sep 18 04:10:16 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 17 Sep 2015 21:10:16 -0700
Subject: JDK 9 RFR of JDK-8134795: Port fdlibm pow to Java
In-Reply-To: <1142192764.1716914.1442527977806.JavaMail.yahoo@mail.yahoo.com>
References: <1142192764.1716914.1442527977806.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <55FB8EA8.6060907@oracle.com>

Hi Jeff,

Thanks for the bug report; I'll take a look into this,

-Joe

On 9/17/2015 3:12 PM, Jeff Hain wrote:
> Hi.
>
>
>
> >At long last, I've started the port of the C version of FDLIBM (freely
> >distributable math library) from C to Java, beginning with the pow 
> method:
>
>
> I ran it through tests of my math lib (jafama),
> and found the following issue:
>
> // ok
>     StrictMath.pow(1.0000000000000004, 2.1E9) = 1.0000009325877754
> FdLibm.Pow.compute(1.0000000000000004, 2.1E9) = 1.0000009325877754
>
> // overflows early
>     StrictMath.pow(1.0000000000000004, 2.2E9) = 1.0000009769967388
> FdLibm.Pow.compute(1.0000000000000004, 2.2E9) = Infinity
>
> // actual overflow is much further
>     StrictMath.pow(1.0000000000000004, 1.59828858065033216E18) = 
> 1.7976931348621944E308
>     StrictMath.pow(1.0000000000000004, 1.59828858065033242E18) = Infinity
>
>
>
> Comparing the behavior of your code with that of Eric Blake's StrictMath
> (the version I got has other issues, but not that one),
> it could be corrected by replacing
>
> if (x_abs > 1.0) {
>
> with
>
> if (x_abs >= 1.0000009536743164) {
>
>
>
> After that modification, tests didn't show any difference with StrictMath.
>
>
>
> -Jeff
>



From magnus.ihse.bursie at oracle.com  Fri Sep 18 07:19:42 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 18 Sep 2015 09:19:42 +0200
Subject: RFR: 8136656: Check in blessed-modifier-order.sh
In-Reply-To: <6A95504A-9F86-4A61-B5AA-85E094385C94@oracle.com>
References: <CA+kOe09V+akTJojt7Bq7oAZeTt-HdZZ8-bWbGLGGUbE51GXbyg@mail.gmail.com>
	<9B4887EB-34F3-46D4-BED6-8E8541CDFF35@oracle.com>
	<CA+kOe0_H37wPjQirYOWfu3gKDdLfAMK1C-BuTu4aiXPKhjSHDA@mail.gmail.com>
	<6A95504A-9F86-4A61-B5AA-85E094385C94@oracle.com>
Message-ID: <55FBBB0E.90201@oracle.com>

On 2015-09-17 18:09, Chris Hegarty wrote:
> On 17 Sep 2015, at 17:08, Martin Buchholz <martinrb at google.com> wrote:
>
>> Done!
> The updated webrev ( in-place ) looks good to me Martin.

Agree.

/Magnus

>
> -Chris.
>
>> On Thu, Sep 17, 2015 at 1:14 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> On 16 Sep 2015, at 20:36, Martin Buchholz <martinrb at google.com> wrote:
>>
>>> Hi guys,
>>>
>>> Here's the requested script checkin:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8136656
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order.sh/
>> Looks fine.  Just add an appropriate licence header, move to 'common/bin?, and you?re all set.
>>
>> -Chris.
>>



From magnus.ihse.bursie at oracle.com  Fri Sep 18 07:26:24 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 18 Sep 2015 09:26:24 +0200
Subject: Running blessed-modifier-order on the rest of the JDK
In-Reply-To: <CA+kOe0-7knrYt_53D4NQ1oVmYbREL403dUD0VdFn6ymPtHPKeg@mail.gmail.com>
References: <CA+kOe0-7knrYt_53D4NQ1oVmYbREL403dUD0VdFn6ymPtHPKeg@mail.gmail.com>
Message-ID: <55FBBCA0.4040802@oracle.com>

On 2015-09-17 18:24, Martin Buchholz wrote:
> flush with success, I ran blessed-modifier-order on the entire JDK forest,
> and it seems to work fine.
> But we want to leave out code maintained elsewhere.  How to identify that?

As far as I know, the only way to figure out if code is maintained 
elsewhere is to ask someone knowledgable about the code. I've run into 
this problem before, e.g. with regard to warnings (fixing warnings in 
upstream code is much more hassle and probably not a worthwile activity).

Maybe we should adopt some kind of standard, e.g. putting some kind of 
marker file (upstream-source.info?) in directories with upstream source? 
This would allow for easy identification of code maintained elsewhere, 
and might also be a good place to put additional information about the 
upstream project, e.g. a source URL.

Apart from that, I think the job you're doing is great. The JDK code 
base itself really ought to be a paragon in code quality and style, and 
this takes it even further toward that goal.

/Magnus

>
> Below are changes inside javadoc, which seem fine to me.
>
>   $ hg tcommand hg diff | g '^[+-]  *\*'
> -         * Access to final protected superclass member from outer class.
> +         * Access to protected final superclass member from outer class.
> -     * per a class in order to initialize a final static logger variable,
> which is then used
> +     * per a class in order to initialize a static final logger variable,
> which is then used
> -     * it is advised that the method is called only once per a class in
> order to initialize a final static logger variable,
> +     * it is advised that the method is called only once per a class in
> order to initialize a static final logger variable,
> -     * it is advised that the method is called only once per a class in
> order to initialize a final static logger variable,
> +     * it is advised that the method is called only once per a class in
> order to initialize a static final logger variable,
> -     *     synchronized static method of that class.
> +     *     static synchronized method of that class.
> - * abstract protected methods defined in this class need not synchronize
> + * protected abstract methods defined in this class need not synchronize
> - *     final static ImageIcon longIcon = new ImageIcon("long.gif");
> - *     final static ImageIcon shortIcon = new ImageIcon("short.gif");
> + *     static final ImageIcon longIcon = new ImageIcon("long.gif");
> + *     static final ImageIcon shortIcon = new ImageIcon("short.gif");
> - * All attributes should be static private with accessors to simpify change
> + * All attributes should be private static with accessors to simpify change
> - * This class holds only final static member variables that are constants
> + * This class holds only static final member variables that are constants
> - * inherited static protected members differently when accessed
> + * inherited protected static members differently when accessed
>
> # How big?
>   $ hg tcommand hg st | grep -w M | wc -l
> 1952



From alejandro.murillo at oracle.com  Fri Sep 18 14:57:54 2015
From: alejandro.murillo at oracle.com (Alejandro E Murillo)
Date: Fri, 18 Sep 2015 08:57:54 -0600
Subject: [verona.stage] RFR 8087203: Adapt Version.java.template to the
	JEP-223 new version string format
In-Reply-To: <3ace7703-9d33-4457-a8dc-776e65d0a2d0@default>
References: <55F9AEFB.1030005@oracle.com>
	<3ace7703-9d33-4457-a8dc-776e65d0a2d0@default>
Message-ID: <55FC2672.6080104@oracle.com>


Thanks Iris

Alejandro

On 9/17/2015 4:17 PM, Iris Clark wrote:
> Hi, Alejandro.
>
> This cleanup looks good to me.
>
> Thanks,
> iris (not a JDK 9 Reviewer)
>
> -----Original Message-----
> From: Alejandro E Murillo
> Sent: Wednesday, September 16, 2015 11:04 AM
> To: core-libs-dev at openjdk.java.net
> Cc: verona-dev at openjdk.java.net
> Subject: [verona.stage] RFR 8087203: Adapt Version.java.template to the JEP-223 new version string format
>
> Please review these changes:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8087203
> Webrev: http://cr.openjdk.java.net/~amurillo/9/8087203/
>
> The actual code changes for this bug (8087203) were entered along with the ones for 8087202. The changes here are just fixing some javadoc comments in that template
>
> Thanks
>
> --
> Alejandro
>

-- 
Alejandro



From aleksey.shipilev at oracle.com  Fri Sep 18 15:17:09 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 18 Sep 2015 18:17:09 +0300
Subject: Review: Indify String Concat JEP
Message-ID: <55FC2AF5.5010704@oracle.com>

Hi,

I recently sent the review request to compiler-dev@ [1], but got no
response. Resending at corelibs-dev@ to gain more exposure.

Please review the submitted "Indify String Concat" JEP. It seems
complete to me: with working implementation, testing, and general
understanding of an issue. Start here:
  https://bugs.openjdk.java.net/browse/JDK-8085796

General feedback, comments, concerns, testing is appreciated.

Thanks,
-Aleksey

[1]
http://mail.openjdk.java.net/pipermail/compiler-dev/2015-September/009785.html



From mark.reinhold at oracle.com  Fri Sep 18 16:17:37 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 18 Sep 2015 09:17:37 -0700 (PDT)
Subject: JEP 264: Platform Logging API and Service
Message-ID: <20150918161737.CF3F171F93@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/264

- Mark


From david.lloyd at redhat.com  Fri Sep 18 16:19:08 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 18 Sep 2015 11:19:08 -0500
Subject: JEP 264: Platform Logging API and Service
In-Reply-To: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
References: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
Message-ID: <55FC397C.5030602@redhat.com>

On 09/18/2015 11:17 AM, mark.reinhold at oracle.com wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/264

+1 good idea!
-- 
- DML


From chris.hegarty at oracle.com  Fri Sep 18 17:13:55 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 18 Sep 2015 18:13:55 +0100
Subject: RFR (xs) : 8077874 : [TESTBUG] The test
	com/sun/corba/cachedSocket/7056731.sh should not be run on JRE
In-Reply-To: <55FAC50B.4080702@oracle.com>
References: <55FAC50B.4080702@oracle.com>
Message-ID: <2C1CBDA6-71E7-400D-B8C4-B11CE15D4326@oracle.com>

Looks fine to me Sean.

-Chris.

On 17 Sep 2015, at 14:50, Se?n Coffey <sean.coffey at oracle.com> wrote:

> Test bug correction to allow the jdb command to be launched via compilejdk parameter where necessary. I've checked for similar usage across other corba tests and this one seems to be the only one. Also made a small edit to use the $JAVA variable where possible. (was already defined)
> 
> bug report : https://bugs.openjdk.java.net/browse/JDK-8077874
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8077874.jdk9/webrev/
> 
> -- 
> Regards,
> Sean.
> 



From martinrb at google.com  Fri Sep 18 17:37:28 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 18 Sep 2015 10:37:28 -0700
Subject: <AWT Dev> RFR: 8136570: Avoid setting environment variables
	related to /usr/dt
In-Reply-To: <55FAFFC8.104@oracle.com>
References: <CA+kOe08q-rruFWLkig8=MYT3dTWNb+2VtPb_196doMcK7DW05g@mail.gmail.com>
	<55F8A083.3020300@oracle.com>
	<CA+kOe0_zfJSapN0GrAHQBJF-=yqVQuEA_KQbr7xZE3KQY4fHJg@mail.gmail.com>
	<55F9922D.5000705@oracle.com>
	<CA+kOe0-Ekw-GmJy6AF9s95kBo0NzuXbozUmPRKPT_avHaLGsoA@mail.gmail.com>
	<55FAE5FD.30209@oracle.com>
	<CA+kOe09YLaHAy=Hd==F6-HnuhByOLJJLk4FRSBq2Sw4tb=87VA@mail.gmail.com>
	<55FAFFC8.104@oracle.com>
Message-ID: <CA+kOe0_L86fgbhg_UY2NWuLgCZ5+XZECfHT8LO1RGyZLKk2kTQ@mail.gmail.com>

On Thu, Sep 17, 2015 at 11:00 AM, Stuart Marks <stuart.marks at oracle.com>
wrote:

> Doctor Deprecator approves.
>
> Not only is this a win because it's a pure-deletion change, it's a double
> win because it removes a side effect from a function that's supposed to
> "get" and initialize Java properties values.


It's hard for everyone to accept that putenv really is a crash time bomb,
especially us old timers from the pre-threading days.


From martinrb at google.com  Fri Sep 18 19:38:20 2015
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 18 Sep 2015 12:38:20 -0700
Subject: Running blessed-modifier-order on the rest of the JDK
In-Reply-To: <55FBBCA0.4040802@oracle.com>
References: <CA+kOe0-7knrYt_53D4NQ1oVmYbREL403dUD0VdFn6ymPtHPKeg@mail.gmail.com>
	<55FBBCA0.4040802@oracle.com>
Message-ID: <CA+kOe0-fjd0gKGbfBfXvEDXmTGyfdFEPZmriEkrxU--d8YrvYA@mail.gmail.com>

(I'm on both sides of the upstream/downstream divide)

It's a good idea to have a per-directory-tree metadata file that can
provide information about the tree where it is found, like TEST.ROOT but
more general and extensible.  Here at Google we actually have files named
METADATA - this makes it obvious where future metadata needs can be met.
 java/util/METADATA could e.g. explain which files are maintained in Doug
Lea's CVS.

On Fri, Sep 18, 2015 at 12:26 AM, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:

> On 2015-09-17 18:24, Martin Buchholz wrote:
>
>> flush with success, I ran blessed-modifier-order on the entire JDK forest,
>> and it seems to work fine.
>> But we want to leave out code maintained elsewhere.  How to identify that?
>>
>
> As far as I know, the only way to figure out if code is maintained
> elsewhere is to ask someone knowledgable about the code. I've run into this
> problem before, e.g. with regard to warnings (fixing warnings in upstream
> code is much more hassle and probably not a worthwile activity).
>
> Maybe we should adopt some kind of standard, e.g. putting some kind of
> marker file (upstream-source.info?) in directories with upstream source?
> This would allow for easy identification of code maintained elsewhere, and
> might also be a good place to put additional information about the upstream
> project, e.g. a source URL.
>
> Apart from that, I think the job you're doing is great. The JDK code base
> itself really ought to be a paragon in code quality and style, and this
> takes it even further toward that goal.
>
> /Magnus
>
>
>
>> Below are changes inside javadoc, which seem fine to me.
>>
>>   $ hg tcommand hg diff | g '^[+-]  *\*'
>> -         * Access to final protected superclass member from outer class.
>> +         * Access to protected final superclass member from outer class.
>> -     * per a class in order to initialize a final static logger variable,
>> which is then used
>> +     * per a class in order to initialize a static final logger variable,
>> which is then used
>> -     * it is advised that the method is called only once per a class in
>> order to initialize a final static logger variable,
>> +     * it is advised that the method is called only once per a class in
>> order to initialize a static final logger variable,
>> -     * it is advised that the method is called only once per a class in
>> order to initialize a final static logger variable,
>> +     * it is advised that the method is called only once per a class in
>> order to initialize a static final logger variable,
>> -     *     synchronized static method of that class.
>> +     *     static synchronized method of that class.
>> - * abstract protected methods defined in this class need not synchronize
>> + * protected abstract methods defined in this class need not synchronize
>> - *     final static ImageIcon longIcon = new ImageIcon("long.gif");
>> - *     final static ImageIcon shortIcon = new ImageIcon("short.gif");
>> + *     static final ImageIcon longIcon = new ImageIcon("long.gif");
>> + *     static final ImageIcon shortIcon = new ImageIcon("short.gif");
>> - * All attributes should be static private with accessors to simpify
>> change
>> + * All attributes should be private static with accessors to simpify
>> change
>> - * This class holds only final static member variables that are constants
>> + * This class holds only static final member variables that are constants
>> - * inherited static protected members differently when accessed
>> + * inherited protected static members differently when accessed
>>
>> # How big?
>>   $ hg tcommand hg st | grep -w M | wc -l
>> 1952
>>
>
>


From stuart.marks at oracle.com  Fri Sep 18 21:56:42 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 18 Sep 2015 14:56:42 -0700
Subject: RFR(m) 2: 8072722: add stream support to Scanner
In-Reply-To: <55FA679C.8010702@gmail.com>
References: <55E93797.8020408@oracle.com>
	<C3D807C3-B54B-4774-9ABE-B9C961A75345@oracle.com>
	<55EF8321.8040203@oracle.com>
	<E2EAABF2-71FA-4923-B9E8-E87852F503D4@oracle.com>
	<55F0A558.9010304@oracle.com> <55F0AD95.8060909@oracle.com>
	<55F0B43C.2030205@oracle.com> <55F0B7F1.8010200@oracle.com>
	<55F1E683.9050905@oracle.com> <55F1F22A.4000802@oracle.com>
	<55F8F4B9.80802@oracle.com> <55F98E2F.4050507@oracle.com>
	<55F9F659.3080103@oracle.com> <55FA679C.8010702@gmail.com>
Message-ID: <55FC889A.7070400@oracle.com>



On 9/17/15 12:11 AM, Peter Levart wrote:
> As an alternative to additional boolean field, you could use one bit of
> expectedCount/modCount int field(s):
>
> - let initial value of expectedCount be 1 (odd value)
> - instead of (expectedCount >= 0) ==> (expectedCount != 1)
> - let initial value of modCount be 0 (even value)
> - instead of modCount++ ==> modCount += 2;

Hi Peter,

This certainly avoids the overflow issues, but I think much of Sherman's concern 
is over the clarity of the code. I'm not sure that we're so concerned about an 
additional field in the spliterator instance that we'd steal a bit from 
expectedCount.

Still, I'll link this thread to the new bug to make sure it doesn't get lost.

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

s'marks




From brian.burkhalter at oracle.com  Sat Sep 19 00:33:45 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 18 Sep 2015 17:33:45 -0700
Subject: [9] RFR of 5100935: No way to access the 64-bit integer
	multiplication of 64-bit CPUs efficiently
Message-ID: <3B559334-8ED3-4BEA-85E9-7AA9CD57AA91@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-5100935
Patch:	http://cr.openjdk.java.net/~bpb/5100935/webrev.00/

Summary: Add multiplyFull() and multiplyHigh() methods to java.lang.Math.

This change addresses the Java specification and implementation only. The addition of compiler intrinsics for these methods will be tracked separately.

Thanks,

Brian

From withoutpointk at gmail.com  Sat Sep 19 08:04:12 2015
From: withoutpointk at gmail.com (Adrian)
Date: Sat, 19 Sep 2015 04:04:12 -0400
Subject: URLClassPath does unnecessary linear search through every jar and
	jar entry to find resource
In-Reply-To: <55F839C1.5000608@gmail.com>
References: <CAL_yH3i8-jTORx_oHVbA_ATXGiRtkqd5g==82EWfpyge7xbOmQ@mail.gmail.com>
	<55F839C1.5000608@gmail.com>
Message-ID: <CAL_yH3gZqDceqe25CFWFv+HoPs0zwiPpyfe0BsGn4nHcUMDQ2A@mail.gmail.com>

Hi Peter,

Thanks for your response! And sorry for my late reply
I was wondering why zip_util was using the hash of the name... missed
the line "idx = zip->table[hsh % zip->tablelen];" before the loop.
My bad, I should have looked closer into it and realized it was a hash
before claiming it was doing a linear search for every entry

I've not used jmh before, but believe I set it up properly and ran the
benchmark with/without your patch.
I copied over rt.jar (~62MB) and replaced idea.jar with the next
largest jar file I could find (~18MB); I'm assuming the specific
contents don't matter
I get similar results to yours:

Original
Benchmark                  (_zipTuple)  Mode  Cnt     Score     Error  Units
ZipFileBench.getEntry    rt.jar:rt.jar  avgt    8  1153.436 ? 261.162  ns/op
ZipFileBench.getEntry  rt.jar:idea.jar  avgt    8   515.975 ?  14.451  ns/op
ZipFileBench.getEntry  idea.jar:rt.jar  avgt    8   486.993 ?  25.501  ns/op

Patched
Benchmark                  (_zipTuple)  Mode  Cnt     Score    Error  Units
ZipFileBench.getEntry    rt.jar:rt.jar  avgt    8  1162.392 ? 18.514  ns/op
ZipFileBench.getEntry  rt.jar:idea.jar  avgt    8   360.032 ?  9.854  ns/op
ZipFileBench.getEntry  idea.jar:rt.jar  avgt    8   320.842 ? 11.421  ns/op

---
In my situation, I notice about 30-40ms improvements in classloading
time, measured using sun.misc.PerfCounter.getFindClassTime() (part of
the vanilla JVM, didn't have to add this)

Regarding the cache, since the second level is nolonger needed, I
removed the cache resource name -> jar entry
The performance is about the same as when I had the second map (which
was redundant as JarFile#getEntry is ~constant time anyways)
There's about 200-250ms improvement in classloading/find class time

However, I find with different workloads the performance varies,
although it seems even in the worst case when every single jar on the
classpath is opened (and processed and contents added to the map
resource -> which jar/jarloader), it's only ~5-8ms slower than the
control (vanilla JVM)
I haven't found a case where the cache adds notable overhead, but I'll
try to get back soon with more data

Best regards,
Adrian


On Tue, Sep 15, 2015 at 11:31 AM, Peter Levart <peter.levart at gmail.com> wrote:
> Hi Adrian,
>
> I looked briefly at your code and claims and have some comments inline...
>
>
> On 09/13/2015 11:08 AM, Adrian wrote:
>>
>> Hi,
>>
>> I posted about this earlier (few weeks ago), and got some responses
>> about concerns which I addressed in my last email, though I didn't
>> hear back about it.
>> My apologies if I shouldn't be sending this; I'm not sure what the
>> protocol is about this stuff
>>
>> Classloading on a standard Java application with jars on the classpath
>> currently does a linear search through every jar on the classpath, and
>> every entry in a jar, for every class loaded.
>> As URLClassPath searches for an entry/resource/class, it's possible to
>> cache each entry it encounters -> where to find it, so in the future
>> if a resource has already been seen we don't need to repeat the ~2d
>> search
>>
>> Original thread (august list):
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-August/035009.html
>> Last message (september list):
>>
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035016.html
>>
>> I got 3 responses: 2 concerning changes to jars at runtime
>> (invalidating cache), and 1 saying you're not supposed to modify jars
>> at runtime (can confirm via source code, and manual testing - it
>> crashes the JVM)
>>
>> In my last message I addressed
>> - jars being modified (which you're not supposed to do; the current
>> classloader does not handle this) or the classpath changing (only
>> possible if you make public fields/methods via reflection, and this
>> could easily be handled gracefully)
>> - some details of the finding resource process (e.g. the meta index,
>> when the cache for jar entries can't be used because of the semantics
>> of other loaders/types of entries on the classpath)
>> - a reference implementation of caching that I believe is simple and
>> compliant with existing functionality
>> - some basic numbers on performance
>>
>> ---
>> So in this email I wanted to explain the problem again, hopefully more
>> clearly now
>>
>> URLClassPath is used by URLClassLoader to find classes, though it
>> could be used for finding any resource on a classpath.
>> URLClassPath keeps an array of URLs, which are typically folders or
>> jars on the local filesystem.
>> They can be http or ftp or other files, but that's not
>> relevant/doesn't affect this problem
>>
>> To find a resource/class (URLClassPath#getResource), it:
>> 1. Loops through the URLs in order
>> 2. Creates Loader objects for each URL lazily (URLClassPath$FileLoader
>> or URLClassPath$JarLoader). So if the Loader for the first URL finds
>> all the resources, Loaders for the remaining entries on the classpath
>> are never created/looked at
>> 3. Calls Loader#getResource and returns the resource if found
>> (otherwise keep searching)
>>
>> URLClassPath$JarLoader creates its corresponding JarFile either in the
>> constructor or in getResource (depending on the meta index - the
>> details I explained in my last email I won't repeat)
>> When a JarFile is created, it opens the jar file on the file system,
>> reads the central directory of the jar/zip file, and creates an
>> internal linked list with all its entries
>
>
> It's not actually a linked list, but a hash table. See
> jdk/src/java.base/share/native/libzip/zip_util.[c,h] ...
>
> the jzfile.table is an array of jint mapping (entry-name-hash-code %
> table.length) -> index into jzfile.entries
> the jzfile.entries is an array of jzcell which represent heads of hash
> buckets that are linked with jzcell.next
>
> So look-ups into individual jar/zip files should be O(1). But each look-up
> does cross the Java/JNI boundary, so it has a fixed JNI overhead too. If
> there are lots of jar files in class path, you pay for the unsuccessful
> hash-table look-ups before finding the resource. This overhead is not that
> big, but increases with the number of jar files in class path. Each look-up
> into class path is therefore O(N) where N = # of jar files...
>
>
>>
>> JarFile objects are immutable; you can only open them for read/delete
>> (see constructor API
>>
>> http://docs.oracle.com/javase/7/docs/api/java/util/jar/JarFile.html#JarFile(java.io.File,%20boolean,%20int)
>> ), they do not detect if the file has been modified externally, and
>> you only "append" or "delete" entries by creating a new jar
>> (JarOutputStream)
>>
>> When URLClassPath$JarLoader#getResource calls JarFile#getEntry; in the
>> C code it searches through the linked list
>> (jdk/src/share/native/java/util/zip/zip_util.c, ZIP_GetEntry - jar
>> files are just zip files, and the java JarFile object just extends
>> ZipFile)
>>
>> Since the order in which jar files and jar entries are searched is
>> invariant, we can create a map of resource -> first jar which contains
>> it
>>
>> However, we don't want to introduce additional overhead.
>> When a JarFile is created, it already builds the internal linked list
>> - it's O(number of entries)
>> I propose that after the JarLoader creates the JarFile, it iterates
>> through its entries and adds them to the cache (if the map does not
>> already contain the resource, i.e. an earlier jar contains the
>> resource)
>> This adds a small overhead when instantiating loaders - but creating
>> the JarLoader/JarFile is still technically O(number of entries), and
>> now getResource is constant time, instead of requiring a linear search
>> through every jar and the linked list of entries for each jar
>> (O(number of jars * entries/jar))
>
>
> Have you measured your entry iteration and cache initialization overhead?
> When iterating over JarEntries, the code invokes 10 native methods for each
> returned JarEntry:
>
>         long jzentry = getNextEntry(jzfile, i++)
>         getEntryFlag(jzentry);
>         getEntryBytes(jzentry, JZENTRY_NAME)
>         getEntryTime(jzentry)
>         getEntryCrc(jzentry)
>         getEntrySize(jzentry)
>         getEntryCSize(jzentry)
>         getEntryMethod(jzentry)
>         getEntryBytes(jzentry, JZENTRY_EXTRA)
>         getEntryBytes(jzentry, JZENTRY_COMMENT)
>
> ...it uses CharsetDecoder 1 or 2 times to decode the name and optional
> comment of each JarEntry, it allocates several java objects...
>
> So I have a feeling that initializing your cache when JarFiles are
> constructed, would increase start-up time and not decrease it. It may pay-of
> on the long run though. For achieving short start-up time, JDK tries to be
> as lazy as possible. Your cache goes against that.
>
> ZipFile native code tries hard to keep the memory usage down for maintaining
> the look-up hash table. It only keeps hash codes in the table, with offsets
> into memory mapped ZIP central directory for each entry. Your proposed
> java-side cache is also a hash table, but it's memory footprint is much
> bigger.
>
> I have made a little experiment to see if JNI overhead for negative answers
> from ZipFile.getEntry(name) is really that big. I modified
> ZipFile.java/ZipFile.c to expose access to a look-up hash table that is
> maintained in native code to the java side via two direct ByteBuffers. I
> screen each ZipFile.getEntry(name) with a probe that gives a negative answer
> for majority of negative lookups without invoking JNI methods. Here are the
> changes I made for this experiment:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile.getEntry/webrev.01/
>
> I have tested the changed JDK with the following JMH benchmark:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/ZipFile.getEntry/ZipFileBench.java
>
> This benchmark measures the ZipFile.getEntry(name) method on 2 jar files
> (rt.jar ~20K entries, idea.jar ~40K entries) looking up entries in 1st jar
> file with names of the entries taken from the 2nd jar file:
>
> Original:
>
> Benchmark                        (_zipTuple)  Mode  Samples Score    Error
> Units
> j.t.ZipFileBench.getEntry      rt.jar:rt.jar  avgt        8  721.536 ?
> 17.344  ns/op
> j.t.ZipFileBench.getEntry    rt.jar:idea.jar  avgt        8  501.451 ?
> 10.298  ns/op
> j.t.ZipFileBench.getEntry    idea.jar:rt.jar  avgt        8  423.513 ?
> 23.268  ns/op
>
> Patched:
>
> Benchmark                        (_zipTuple)  Mode  Samples Score     Error
> Units
> j.t.ZipFileBench.getEntry      rt.jar:rt.jar  avgt        8  743.281 ?
> 13.467  ns/op
> j.t.ZipFileBench.getEntry    rt.jar:idea.jar  avgt        8  392.569 ?
> 7.710  ns/op
> j.t.ZipFileBench.getEntry    idea.jar:rt.jar  avgt        8  333.249 ?
> 14.069  ns/op
>
>
> The rt.jar:rt.jar therefore gives the score for successful look-ups, while
> rt.jar:idea.jar and idea.jar:rt.jar give the score for unsuccessful
> look-ups.
>
> The screening of JNI call improves unsuccessful lookup by 20-25% while not
> hurting much the successful lookup. The successful look-up could be improved
> so that it wouldn't have any overhead by utilizing the result of the
> screening probe that must now be re-computed in native code once more (see
> TODO).
>
> So is this worth the trouble? I don't know.
>
> Adrian, does this patch improve your situation (don't forget to set the
> system property -Dsun.zip.useNativeTableProbe=true to enable the feature)?
> This patch should not hurt startup performance, as it does not maintain or
> initialize any additional data structures (besides 2 ByteBuffer objects per
> ZipFile that only expose native memory to Java code).
>
> Regards, Peter
>
>
>>
>> There are several caveats when the cache cannot be used with non-jar
>> URLs on the classpath, and the meta index, but I explain them in my
>> last email along with comments in the reference implementation
>>
>> ---
>> Regarding modified jars:
>> - moved/renamed: the file handle is still valid and it doesn't affect
>> the JVM/classloading
>> - deleted: the file handle is still valid and it doesn't affect the
>> JVM/classloading
>> - modified: the JVM crashes
>>
>> The first two may not be intuitive, but remember that file handles
>> point to files; not paths on the filesystem.
>> So even though a jar appears renamed in the shell, the java process
>> has opened a file, somewhere in the c implementation of file objects
>> it has the file handle, and when the JVM does the system call read on
>> the file handle say to read the class from the jar file, it all works
>> fine
>> For what it's worth, here's a stack overflow answer as "source":
>>
>> http://stackoverflow.com/questions/2028874/what-happens-to-an-open-file-handler-on-linux-if-the-pointed-file-gets-moved-de
>>
>> ---
>> There is a protected method URLClassLoader#addURL which appends a URL
>> to the classpath.
>> People could use reflection to make it public.
>> Because jars are opened lazily and the cache is also built lazily
>> whenever a jar is opened, it doesn't matter if paths are appended
>>
>> Regarding people making extensive use of reflection to modify the
>> order of entries on the classpath, I believe that's irrelevant as
>> that's clearly not the semantic of URLClassLoader/URLClassPath.
>> People who need custom classloading rules create custom classloaders;
>> that's the purpose of classloaders being extensible
>>
>> ---
>> Anyways, I hope this was discussion worthy.
>> I've looked much into this and believe I haven't missed anything, but
>> if someone knows why it hasn't/can't be done any insight would be
>> appreciated!
>> Alan from the last email thread said "There was a lot of experiments
>> and prototypes in the past along these lines" - are the results
>> public?
>> He also mentioned improving classloading in Java's upcoming module
>> system (originally planned for Java 7, currently delayed to Java 9),
>> but I believe the algorithmic complexity and performance of
>> URLClassLoader could be improved without complicated changes
>>
>> Please let me know what you think, and thanks for your time!
>>
>> Best regards,
>> Adrian
>
>


From alexander.v.stepanov at oracle.com  Sat Sep 19 13:58:14 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Sat, 19 Sep 2015 16:58:14 +0300
Subject: RFR [9] 8133651: replace some <tt> tags (obsolete in html5) in
	core-libs docs
Message-ID: <55FD69F6.7080009@oracle.com>

Hello,

Could you please review the following fix
http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/
http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html
for
https://bugs.openjdk.java.net/browse/JDK-8133651

Just another portion of deprecated <tt> (and <xmp>) tags replaced with 
{@code }. Some misprints were also fixed.


The following (expected) changes were detected by specdiff:
- removed needless dashes in java.util.Locale,
- removed needless curly brace in xml.bind.annotation.XmlElementRef

Please let me know if the following changes are desirable or not:
http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html

Thanks,
Alexander


From Sergey.Bylokhov at oracle.com  Sat Sep 19 19:51:29 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 19 Sep 2015 22:51:29 +0300
Subject: [9] RFR of 5100935: No way to access the 64-bit integer
	multiplication of 64-bit CPUs efficiently
In-Reply-To: <3B559334-8ED3-4BEA-85E9-7AA9CD57AA91@oracle.com>
References: <3B559334-8ED3-4BEA-85E9-7AA9CD57AA91@oracle.com>
Message-ID: <55FDBCC1.8060708@oracle.com>

> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-5100935
> Patch:	http://cr.openjdk.java.net/~bpb/5100935/webrev.00/
>
> Summary: Add multiplyFull() and multiplyHigh() methods to java.lang.Math.
>
> This change addresses the Java specification and implementation only. The addition of compiler intrinsics for these methods will be tracked separately.
>

Hello, I have a related question about the adding of methods to the Math 
class. Some methods **Exact methods were added to the Math class in 
jdk8, which throws an exceptions in case of overflow. Is it possible to 
add the similar saturation arithmetic? It would be quite good to realize 
a full range of these methods, and give the chance to hotspot to use an 
intrinsic.

This is mostly request from the java2d team:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-December/000954.html
"I currently use an utility-class heavily for the XRender Java2D
backend, which performs saturated casts:

1.) return (short) (x > Short.MAX_VALUE ? Short.MAX_VALUE : (x <
Short.MIN_VALUE ? Short.MIN_VALUE : x));
2.) return (short) (x > 65535 ? 65535 : (x < 0) ? 0 : x);

I spent quite some time benchmarking/tuning the
protocol-generation-methods, and a lot of cycles are spent in those
saturated casts, even if the utility methods are static.
E.g. XRenderFillRectangle takes 40 cycles without clamping, but
already 70 cycles with on my core2duo with hotspot-server/jdk 14.0.
Hotspot seems to solve the problem always with conditional jumps,
although well predictable ones.

Modern processors seem to have support for this kind of operation, in
x86 there's packssdw in MMX/SSE2.
I think something like a saturated cast could be quite useful, there
are already cast-methods in Long/Integer/Short - what do you think
about adding saturated casts to that API?
Those could be instrified to use MMX/SSE2 if available.

If that would be too specific how hard would it be to add this kind of
optimization to hotspot?
How far does SIMD support in hotspot go (I read some time ago there've
been some optimizations), if SIMD would be supported 4 casts could be
done in a single cycle :)


-- 
Best regards, Sergey.


From ralph.goers at dslextreme.com  Sun Sep 20 05:54:45 2015
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Sat, 19 Sep 2015 22:54:45 -0700
Subject: JEP 264: Platform Logging API and Service
In-Reply-To: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
References: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
Message-ID: <075935D9-57E4-4417-B7A3-F6408998804A@dslextreme.com>

I do have some questions on this.  

Would anyone realistically be able to use SLF4J/Logback or Log4j 2 as the implementation?  The logging implementation needs to be able to configure itself before logging can realistically be performed. If logging initialization happens too soon the application?s configuration may not be able to be located. 

Also, to do this would SLF4J/Logback or Log4j 2 have to be added to the boot classpath for them to be used for this?

Ralph

> On Sep 18, 2015, at 9:17 AM, mark.reinhold at oracle.com wrote:
> 
> New JEP Candidate: http://openjdk.java.net/jeps/264
> 
> - Mark
> 




From peter.levart at gmail.com  Sun Sep 20 13:46:00 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Sun, 20 Sep 2015 15:46:00 +0200
Subject: JEP 264: Platform Logging API and Service
In-Reply-To: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
References: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
Message-ID: <55FEB898.6050106@gmail.com>



On 09/18/2015 06:17 PM, mark.reinhold at oracle.com wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/264
>
> - Mark

Hi,

What is the purpose of exposing a factory for loggers in the generally 
exported package (java.lang) and making it standard Java API as opposed 
to keeping it internal API as it is now 
(sun.util.logging.PlatformLogger)? Is this going to become an official 
front-end for JDK-internal and applications use, available in the 
platform itself?

Otherwise I think it's good to add support for interfacing other 
backends (besides JDK14 Logging and stderr) to platform logger. If one 
wants to interface some other backend to platform logger now, it's 
actually doable, but only via the intermediate JDK14 Logging API, like this:

PlatformLogger -> j.u.l.Logger -> jul-to-slf4j -> slf4j-WHATEVER-BACKEND

Adding support to skip JDK14 Logging would simplify configuration and 
make it more lightweight.

Regards, Peter



From Alan.Bateman at oracle.com  Mon Sep 21 11:24:43 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 21 Sep 2015 12:24:43 +0100
Subject: Review: Indify String Concat JEP
In-Reply-To: <55FC2AF5.5010704@oracle.com>
References: <55FC2AF5.5010704@oracle.com>
Message-ID: <55FFE8FB.3090409@oracle.com>


On 18/09/2015 16:17, Aleksey Shipilev wrote:
> Hi,
>
> I recently sent the review request to compiler-dev@ [1], but got no
> response. Resending at corelibs-dev@ to gain more exposure.
>
> Please review the submitted "Indify String Concat" JEP. It seems
> complete to me: with working implementation, testing, and general
> understanding of an issue. Start here:
>    https://bugs.openjdk.java.net/browse/JDK-8085796
>
> General feedback, comments, concerns, testing is appreciated.
>
The main concerns that come to mind reading through this is potential 
startup overhead and potential recursive initialization/bootstrapping 
issues where the BSM might need to do string concatenation. However, 
you've covered those points quite well in the Risks and Assumptions section.

On startup overhead then it might be amortized by the initialization of 
the module system as you suggest. It might be something else. We don't 
want to discourage use of lambda expressions or method reference so the 
first use of LF or whatever the initialization cost is will need to be 
worked on anyway.

I see the proposal is to exempt java.base. It probably could be finer 
grained than all of java.base but tricky to determine that subset. Even 
if all of java.base is exempt then I think there are initialization 
issues that need to be looked at. Peter Levart had a proposed patch for 
at least one of this issues at one point but there might be others [1]. 
One other thing is that JEP 261 proposes the -Xoverride option (maybe it 
might be renamed to -Xpatch) for patching/override classes in java.base. 
Anyone using that to override classes used early in the startup would 
need to be careful to use the right javac option.

One other other on exemptions is that it might need to be javac too, at 
least for the JDK build where the newly built compiler runs with the 
boot JDK to compile everything else. I can't quite tell from a first 
read if the proposal is that javac emit indy by default, if not then 
this may be a non-issue.

-Alan.

[1] http://mail.openjdk.java.net/pipermail/mlvm-dev/2015-March/006387.html


From paul.sandoz at oracle.com  Mon Sep 21 13:42:29 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 21 Sep 2015 15:42:29 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
Message-ID: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>

Hi,

Please review the following which adds methods to Arrays to check indexes and ranges:

  https://bugs.openjdk.java.net/browse/JDK-8135248
  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/

The original motivation was an intrinsic method, Arrays.checkIndex, to check if an index is within bounds. Such an intrinsic guides HotSpot towards better optimisations for bounds checks using one unsigned comparison instead of two signed comparisons, and better eliding of integer to long conversions when an index is used to create an offset for Unsafe access. The end result is more efficient array access especially so from within unrolled loops. The VarHandles work will use Arrays.checkIndex for array access.

A follow up issue [1] will track the intrinsification of Arrays.checkIndex.

We thought it would be opportunistic to support two further common use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
checkFromIndexSize. There is no current plan to intrinsify these methods.

Bounds checking is not difficult but it can be easy to make trivial mistakes. Thus it is advantageous to consolidate such checks not just from an optimization perspective but from a correctness and security/integrity perspective.

There are many areas in the JDK where such checks are performed. A follow up issue [2] will track updates to use the new methods.

The main challenge for these new methods is to design in such a way that

1) existing use-cases can still report the same set of exceptions with the same messages;
2) method byte code size is not unduly increased, thus perturbing inlining; and
3) there is a reasonable path for any future support of long indexes.

Paul.

[1] https://bugs.openjdk.java.net/browse/JDK-8042997
[2] https://bugs.openjdk.java.net/browse/JDK-8135250


From scolebourne at joda.org  Mon Sep 21 13:52:53 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 21 Sep 2015 14:52:53 +0100
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
Message-ID: <CACzrW9B_dKnFUdAv1SCY5nfx_mmYxdSHBtGs5rqdj4JibD7P1A@mail.gmail.com>

While I think I understand the need for the lambda/exception interface
(backwards compatibility) it is definitely weird as a method
signature.

It would seem very worthwhile to add overloaded versions of each of
these methods that do not have the OutOfBoundsToException in the
argument list. Instead, these overloads would throw a "standard"
exception. Such methods would then be much more amenable to just being
dropped into existing application code, where the precise exception
that is thrown is less of a concern.

Stephen



On 21 September 2015 at 14:42, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Hi,
>
> Please review the following which adds methods to Arrays to check indexes and ranges:
>
>   https://bugs.openjdk.java.net/browse/JDK-8135248
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
>
> The original motivation was an intrinsic method, Arrays.checkIndex, to check if an index is within bounds. Such an intrinsic guides HotSpot towards better optimisations for bounds checks using one unsigned comparison instead of two signed comparisons, and better eliding of integer to long conversions when an index is used to create an offset for Unsafe access. The end result is more efficient array access especially so from within unrolled loops. The VarHandles work will use Arrays.checkIndex for array access.
>
> A follow up issue [1] will track the intrinsification of Arrays.checkIndex.
>
> We thought it would be opportunistic to support two further common use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> checkFromIndexSize. There is no current plan to intrinsify these methods.
>
> Bounds checking is not difficult but it can be easy to make trivial mistakes. Thus it is advantageous to consolidate such checks not just from an optimization perspective but from a correctness and security/integrity perspective.
>
> There are many areas in the JDK where such checks are performed. A follow up issue [2] will track updates to use the new methods.
>
> The main challenge for these new methods is to design in such a way that
>
> 1) existing use-cases can still report the same set of exceptions with the same messages;
> 2) method byte code size is not unduly increased, thus perturbing inlining; and
> 3) there is a reasonable path for any future support of long indexes.
>
> Paul.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> [2] https://bugs.openjdk.java.net/browse/JDK-8135250


From vitalyd at gmail.com  Mon Sep 21 14:01:16 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 21 Sep 2015 10:01:16 -0400
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
Message-ID: <CAHjP37Eb38LwD6LomviRBcYS=oGstyXbBAhTMvGmu-gdph0EDg@mail.gmail.com>

So is this saying that enhancing Hotspot JIT to detect range check patterns
better is too much work? On the surface, it seems odd to need intrinsics, a
functional interface, and fixed template for getting efficient range checks.

Also, this may end up with similar profile pollution problems as things
like Objects.requireNonNull.

sent from my phone
On Sep 21, 2015 9:42 AM, "Paul Sandoz" <paul.sandoz at oracle.com> wrote:

> Hi,
>
> Please review the following which adds methods to Arrays to check indexes
> and ranges:
>
>   https://bugs.openjdk.java.net/browse/JDK-8135248
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
>
> The original motivation was an intrinsic method, Arrays.checkIndex, to
> check if an index is within bounds. Such an intrinsic guides HotSpot
> towards better optimisations for bounds checks using one unsigned
> comparison instead of two signed comparisons, and better eliding of integer
> to long conversions when an index is used to create an offset for Unsafe
> access. The end result is more efficient array access especially so from
> within unrolled loops. The VarHandles work will use Arrays.checkIndex for
> array access.
>
> A follow up issue [1] will track the intrinsification of Arrays.checkIndex.
>
> We thought it would be opportunistic to support two further common
> use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> checkFromIndexSize. There is no current plan to intrinsify these methods.
>
> Bounds checking is not difficult but it can be easy to make trivial
> mistakes. Thus it is advantageous to consolidate such checks not just from
> an optimization perspective but from a correctness and security/integrity
> perspective.
>
> There are many areas in the JDK where such checks are performed. A follow
> up issue [2] will track updates to use the new methods.
>
> The main challenge for these new methods is to design in such a way that
>
> 1) existing use-cases can still report the same set of exceptions with the
> same messages;
> 2) method byte code size is not unduly increased, thus perturbing
> inlining; and
> 3) there is a reasonable path for any future support of long indexes.
>
> Paul.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> [2] https://bugs.openjdk.java.net/browse/JDK-8135250
>


From Roger.Riggs at Oracle.com  Mon Sep 21 14:17:14 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 21 Sep 2015 10:17:14 -0400
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
Message-ID: <5600116A.4000500@Oracle.com>

Hi Paul,

java.util.Arrays.java: line 5236:  new IndexOutOfBoundsException()
  - It is always appreciated when debugging to be given a message with 
the index that is out of range and the range expected.

When converting existing code, is it expected that the exception 
messages will be unchanged?

I can't quite visualize how this would be applied to existing code.
Will there be any benefit to adding static checking methods to the 
typically thrown exceptions
that can be used as method references instead of the implicitly defined 
lambdas?

typo:

test/java/util/Arrays/CheckIndex.java:
  - line 78, 91, etc  "withing" -> "within"

Roger


On 9/21/2015 9:42 AM, Paul Sandoz wrote:
> Hi,
>
> Please review the following which adds methods to Arrays to check indexes and ranges:
>
>    https://bugs.openjdk.java.net/browse/JDK-8135248
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
>
> The original motivation was an intrinsic method, Arrays.checkIndex, to check if an index is within bounds. Such an intrinsic guides HotSpot towards better optimisations for bounds checks using one unsigned comparison instead of two signed comparisons, and better eliding of integer to long conversions when an index is used to create an offset for Unsafe access. The end result is more efficient array access especially so from within unrolled loops. The VarHandles work will use Arrays.checkIndex for array access.
>
> A follow up issue [1] will track the intrinsification of Arrays.checkIndex.
>
> We thought it would be opportunistic to support two further common use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> checkFromIndexSize. There is no current plan to intrinsify these methods.
>
> Bounds checking is not difficult but it can be easy to make trivial mistakes. Thus it is advantageous to consolidate such checks not just from an optimization perspective but from a correctness and security/integrity perspective.
>
> There are many areas in the JDK where such checks are performed. A follow up issue [2] will track updates to use the new methods.
>
> The main challenge for these new methods is to design in such a way that
>
> 1) existing use-cases can still report the same set of exceptions with the same messages;
> 2) method byte code size is not unduly increased, thus perturbing inlining; and
> 3) there is a reasonable path for any future support of long indexes.
>
> Paul.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> [2] https://bugs.openjdk.java.net/browse/JDK-8135250



From paul.sandoz at oracle.com  Mon Sep 21 14:28:17 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 21 Sep 2015 16:28:17 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <CACzrW9B_dKnFUdAv1SCY5nfx_mmYxdSHBtGs5rqdj4JibD7P1A@mail.gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<CACzrW9B_dKnFUdAv1SCY5nfx_mmYxdSHBtGs5rqdj4JibD7P1A@mail.gmail.com>
Message-ID: <B27CE548-E6F5-4994-B07A-00C1CA367864@oracle.com>


On 21 Sep 2015, at 15:52, Stephen Colebourne <scolebourne at joda.org> wrote:

> While I think I understand the need for the lambda/exception interface
> (backwards compatibility) it is definitely weird as a method
> signature.

Backwards compat has definitely influenced things, but the approach was also considered useful for new cases where customized exceptions/messages are required.


> 
> It would seem very worthwhile to add overloaded versions of each of
> these methods that do not have the OutOfBoundsToException in the
> argument list. Instead, these overloads would throw a "standard"
> exception.

That seems reasonable e.g.:

public static
int checkIndex(int index, int length) IndexOutOfBoundsException {
    return checkIndex(index, length, null);
}



> Such methods would then be much more amenable to just being
> dropped into existing application code, where the precise exception
> that is thrown is less of a concern.
> 

Though is passing ?null? such a big deal?

Paul.


From forax at univ-mlv.fr  Mon Sep 21 14:28:12 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 21 Sep 2015 16:28:12 +0200 (CEST)
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <CAHjP37Eb38LwD6LomviRBcYS=oGstyXbBAhTMvGmu-gdph0EDg@mail.gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<CAHjP37Eb38LwD6LomviRBcYS=oGstyXbBAhTMvGmu-gdph0EDg@mail.gmail.com>
Message-ID: <134135175.456263.1442845692769.JavaMail.zimbra@u-pem.fr>

Hi Vitaly,
checkIndex has not the same issue as requireNonNull if it is intrisified because
the code that generate the IR node graph can not use the profiling info of the interpreter
thus the assembly code generated will always bail out if the index is wrong.

R?mi 

----- Mail original -----
> De: "Vitaly Davidovich" <vitalyd at gmail.com>
> ?: "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 21 Septembre 2015 16:01:16
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> 
> So is this saying that enhancing Hotspot JIT to detect range check patterns
> better is too much work? On the surface, it seems odd to need intrinsics, a
> functional interface, and fixed template for getting efficient range checks.
> 
> Also, this may end up with similar profile pollution problems as things
> like Objects.requireNonNull.
> 
> sent from my phone
> On Sep 21, 2015 9:42 AM, "Paul Sandoz" <paul.sandoz at oracle.com> wrote:
> 
> > Hi,
> >
> > Please review the following which adds methods to Arrays to check indexes
> > and ranges:
> >
> >   https://bugs.openjdk.java.net/browse/JDK-8135248
> >
> > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
> >
> > The original motivation was an intrinsic method, Arrays.checkIndex, to
> > check if an index is within bounds. Such an intrinsic guides HotSpot
> > towards better optimisations for bounds checks using one unsigned
> > comparison instead of two signed comparisons, and better eliding of integer
> > to long conversions when an index is used to create an offset for Unsafe
> > access. The end result is more efficient array access especially so from
> > within unrolled loops. The VarHandles work will use Arrays.checkIndex for
> > array access.
> >
> > A follow up issue [1] will track the intrinsification of Arrays.checkIndex.
> >
> > We thought it would be opportunistic to support two further common
> > use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> > checkFromIndexSize. There is no current plan to intrinsify these methods.
> >
> > Bounds checking is not difficult but it can be easy to make trivial
> > mistakes. Thus it is advantageous to consolidate such checks not just from
> > an optimization perspective but from a correctness and security/integrity
> > perspective.
> >
> > There are many areas in the JDK where such checks are performed. A follow
> > up issue [2] will track updates to use the new methods.
> >
> > The main challenge for these new methods is to design in such a way that
> >
> > 1) existing use-cases can still report the same set of exceptions with the
> > same messages;
> > 2) method byte code size is not unduly increased, thus perturbing
> > inlining; and
> > 3) there is a reasonable path for any future support of long indexes.
> >
> > Paul.
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> > [2] https://bugs.openjdk.java.net/browse/JDK-8135250
> >
> 


From vitalyd at gmail.com  Mon Sep 21 14:31:18 2015
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 21 Sep 2015 10:31:18 -0400
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <134135175.456263.1442845692769.JavaMail.zimbra@u-pem.fr>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<CAHjP37Eb38LwD6LomviRBcYS=oGstyXbBAhTMvGmu-gdph0EDg@mail.gmail.com>
	<134135175.456263.1442845692769.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAHjP37GjEzY_c0zn+_TgCavk-ApGkcRjrHjTGLpRv0OUT9uMag@mail.gmail.com>

Interesting - I didn't realize intrinsics cannot use profile info (kind of
odd - why is that?).  Thanks for pointing that out though.

sent from my phone
On Sep 21, 2015 10:28 AM, "Remi Forax" <forax at univ-mlv.fr> wrote:

> Hi Vitaly,
> checkIndex has not the same issue as requireNonNull if it is intrisified
> because
> the code that generate the IR node graph can not use the profiling info of
> the interpreter
> thus the assembly code generated will always bail out if the index is
> wrong.
>
> R?mi
>
> ----- Mail original -----
> > De: "Vitaly Davidovich" <vitalyd at gmail.com>
> > ?: "Paul Sandoz" <paul.sandoz at oracle.com>
> > Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoy?: Lundi 21 Septembre 2015 16:01:16
> > Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> >
> > So is this saying that enhancing Hotspot JIT to detect range check
> patterns
> > better is too much work? On the surface, it seems odd to need
> intrinsics, a
> > functional interface, and fixed template for getting efficient range
> checks.
> >
> > Also, this may end up with similar profile pollution problems as things
> > like Objects.requireNonNull.
> >
> > sent from my phone
> > On Sep 21, 2015 9:42 AM, "Paul Sandoz" <paul.sandoz at oracle.com> wrote:
> >
> > > Hi,
> > >
> > > Please review the following which adds methods to Arrays to check
> indexes
> > > and ranges:
> > >
> > >   https://bugs.openjdk.java.net/browse/JDK-8135248
> > >
> > >
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
> > >
> > > The original motivation was an intrinsic method, Arrays.checkIndex, to
> > > check if an index is within bounds. Such an intrinsic guides HotSpot
> > > towards better optimisations for bounds checks using one unsigned
> > > comparison instead of two signed comparisons, and better eliding of
> integer
> > > to long conversions when an index is used to create an offset for
> Unsafe
> > > access. The end result is more efficient array access especially so
> from
> > > within unrolled loops. The VarHandles work will use Arrays.checkIndex
> for
> > > array access.
> > >
> > > A follow up issue [1] will track the intrinsification of
> Arrays.checkIndex.
> > >
> > > We thought it would be opportunistic to support two further common
> > > use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> > > checkFromIndexSize. There is no current plan to intrinsify these
> methods.
> > >
> > > Bounds checking is not difficult but it can be easy to make trivial
> > > mistakes. Thus it is advantageous to consolidate such checks not just
> from
> > > an optimization perspective but from a correctness and
> security/integrity
> > > perspective.
> > >
> > > There are many areas in the JDK where such checks are performed. A
> follow
> > > up issue [2] will track updates to use the new methods.
> > >
> > > The main challenge for these new methods is to design in such a way
> that
> > >
> > > 1) existing use-cases can still report the same set of exceptions with
> the
> > > same messages;
> > > 2) method byte code size is not unduly increased, thus perturbing
> > > inlining; and
> > > 3) there is a reasonable path for any future support of long indexes.
> > >
> > > Paul.
> > >
> > > [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> > > [2] https://bugs.openjdk.java.net/browse/JDK-8135250
> > >
> >
>


From forax at univ-mlv.fr  Mon Sep 21 14:45:32 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 21 Sep 2015 16:45:32 +0200 (CEST)
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <CACzrW9B_dKnFUdAv1SCY5nfx_mmYxdSHBtGs5rqdj4JibD7P1A@mail.gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<CACzrW9B_dKnFUdAv1SCY5nfx_mmYxdSHBtGs5rqdj4JibD7P1A@mail.gmail.com>
Message-ID: <673914291.466765.1442846732766.JavaMail.zimbra@u-pem.fr>

I agree with Stephen.

Calling the function interface with the name ...Exception seems very wrong to me.

The convention of ArrayIOOBE or StringIOOBE is to just report the bad index with no further info,
currently with your code it's not possible to write
  checkIndex(index, ArrayIndexOutOuBoundException::new).

so the functional interface for checkIndex should be int -> Object or long -> Object if you change ArrayIOOBE and StringIOOBE to store a long.
This functional Interface already exists under the name java.util.function.LongFunction.

For the two other methods that checks several index, again the convention is to report the bad index / size, so a LongFunction is enough too,
yes, it means that you can not check several index at once with things like (a < 0) | (b < 0) but because the semantics you propose is different
from what is usually done, you will not be alble to use those methods inside the JDK without introducing incompatibilities.

cheers,
R?mi 

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 21 Septembre 2015 15:52:53
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> 
> While I think I understand the need for the lambda/exception interface
> (backwards compatibility) it is definitely weird as a method
> signature.
> 
> It would seem very worthwhile to add overloaded versions of each of
> these methods that do not have the OutOfBoundsToException in the
> argument list. Instead, these overloads would throw a "standard"
> exception. Such methods would then be much more amenable to just being
> dropped into existing application code, where the precise exception
> that is thrown is less of a concern.
> 
> Stephen
> 
> 
> 
> On 21 September 2015 at 14:42, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> > Hi,
> >
> > Please review the following which adds methods to Arrays to check indexes
> > and ranges:
> >
> >   https://bugs.openjdk.java.net/browse/JDK-8135248
> >   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
> >
> > The original motivation was an intrinsic method, Arrays.checkIndex, to
> > check if an index is within bounds. Such an intrinsic guides HotSpot
> > towards better optimisations for bounds checks using one unsigned
> > comparison instead of two signed comparisons, and better eliding of
> > integer to long conversions when an index is used to create an offset for
> > Unsafe access. The end result is more efficient array access especially so
> > from within unrolled loops. The VarHandles work will use Arrays.checkIndex
> > for array access.
> >
> > A follow up issue [1] will track the intrinsification of Arrays.checkIndex.
> >
> > We thought it would be opportunistic to support two further common
> > use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> > checkFromIndexSize. There is no current plan to intrinsify these methods.
> >
> > Bounds checking is not difficult but it can be easy to make trivial
> > mistakes. Thus it is advantageous to consolidate such checks not just from
> > an optimization perspective but from a correctness and security/integrity
> > perspective.
> >
> > There are many areas in the JDK where such checks are performed. A follow
> > up issue [2] will track updates to use the new methods.
> >
> > The main challenge for these new methods is to design in such a way that
> >
> > 1) existing use-cases can still report the same set of exceptions with the
> > same messages;
> > 2) method byte code size is not unduly increased, thus perturbing inlining;
> > and
> > 3) there is a reasonable path for any future support of long indexes.
> >
> > Paul.
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> > [2] https://bugs.openjdk.java.net/browse/JDK-8135250
> 


From forax at univ-mlv.fr  Mon Sep 21 14:52:14 2015
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 21 Sep 2015 16:52:14 +0200 (CEST)
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <CAHjP37GjEzY_c0zn+_TgCavk-ApGkcRjrHjTGLpRv0OUT9uMag@mail.gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<CAHjP37Eb38LwD6LomviRBcYS=oGstyXbBAhTMvGmu-gdph0EDg@mail.gmail.com>
	<134135175.456263.1442845692769.JavaMail.zimbra@u-pem.fr>
	<CAHjP37GjEzY_c0zn+_TgCavk-ApGkcRjrHjTGLpRv0OUT9uMag@mail.gmail.com>
Message-ID: <476156942.471008.1442847134838.JavaMail.zimbra@u-pem.fr>

An intrinsic replace a method, so the bytecoded method is never executed by the interpreter (it's not fully true in tiers mode), 
so it's not that you can not use the profile info is that there is no profile info. 

In the case of checkIndex, even if c1 compiles the bytecoded version of checkIndex, the profile info will be useless, 
so even if the code that generated the IR nodes can look for the profile info there is no point to do that. 
It's better here to be blind and to always ask to bailout into the interpreter if the index is wrong. 

R?mi 

----- Mail original -----

> De: "Vitaly Davidovich" <vitalyd at gmail.com>
> ?: "R?mi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "Paul Sandoz"
> <paul.sandoz at oracle.com>
> Envoy?: Lundi 21 Septembre 2015 16:31:18
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges

> Interesting - I didn't realize intrinsics cannot use profile info (kind of
> odd - why is that?). Thanks for pointing that out though.

> sent from my phone
> On Sep 21, 2015 10:28 AM, "Remi Forax" < forax at univ-mlv.fr > wrote:

> > Hi Vitaly,
> 
> > checkIndex has not the same issue as requireNonNull if it is intrisified
> > because
> 
> > the code that generate the IR node graph can not use the profiling info of
> > the interpreter
> 
> > thus the assembly code generated will always bail out if the index is
> > wrong.
> 

> > R?mi
> 

> > ----- Mail original -----
> 
> > > De: "Vitaly Davidovich" < vitalyd at gmail.com >
> 
> > > ?: "Paul Sandoz" < paul.sandoz at oracle.com >
> 
> > > Cc: "core-libs-dev" < core-libs-dev at openjdk.java.net >
> 
> > > Envoy?: Lundi 21 Septembre 2015 16:01:16
> 
> > > Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> 
> > >
> 
> > > So is this saying that enhancing Hotspot JIT to detect range check
> > > patterns
> 
> > > better is too much work? On the surface, it seems odd to need intrinsics,
> > > a
> 
> > > functional interface, and fixed template for getting efficient range
> > > checks.
> 
> > >
> 
> > > Also, this may end up with similar profile pollution problems as things
> 
> > > like Objects.requireNonNull.
> 
> > >
> 
> > > sent from my phone
> 
> > > On Sep 21, 2015 9:42 AM, "Paul Sandoz" < paul.sandoz at oracle.com > wrote:
> 
> > >
> 
> > > > Hi,
> 
> > > >
> 
> > > > Please review the following which adds methods to Arrays to check
> > > > indexes
> 
> > > > and ranges:
> 
> > > >
> 
> > > > https://bugs.openjdk.java.net/browse/JDK-8135248
> 
> > > >
> 
> > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
> 
> > > >
> 
> > > > The original motivation was an intrinsic method, Arrays.checkIndex, to
> 
> > > > check if an index is within bounds. Such an intrinsic guides HotSpot
> 
> > > > towards better optimisations for bounds checks using one unsigned
> 
> > > > comparison instead of two signed comparisons, and better eliding of
> > > > integer
> 
> > > > to long conversions when an index is used to create an offset for
> > > > Unsafe
> 
> > > > access. The end result is more efficient array access especially so
> > > > from
> 
> > > > within unrolled loops. The VarHandles work will use Arrays.checkIndex
> > > > for
> 
> > > > array access.
> 
> > > >
> 
> > > > A follow up issue [1] will track the intrinsification of
> > > > Arrays.checkIndex.
> 
> > > >
> 
> > > > We thought it would be opportunistic to support two further common
> 
> > > > use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> 
> > > > checkFromIndexSize. There is no current plan to intrinsify these
> > > > methods.
> 
> > > >
> 
> > > > Bounds checking is not difficult but it can be easy to make trivial
> 
> > > > mistakes. Thus it is advantageous to consolidate such checks not just
> > > > from
> 
> > > > an optimization perspective but from a correctness and
> > > > security/integrity
> 
> > > > perspective.
> 
> > > >
> 
> > > > There are many areas in the JDK where such checks are performed. A
> > > > follow
> 
> > > > up issue [2] will track updates to use the new methods.
> 
> > > >
> 
> > > > The main challenge for these new methods is to design in such a way
> > > > that
> 
> > > >
> 
> > > > 1) existing use-cases can still report the same set of exceptions with
> > > > the
> 
> > > > same messages;
> 
> > > > 2) method byte code size is not unduly increased, thus perturbing
> 
> > > > inlining; and
> 
> > > > 3) there is a reasonable path for any future support of long indexes.
> 
> > > >
> 
> > > > Paul.
> 
> > > >
> 
> > > > [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> 
> > > > [2] https://bugs.openjdk.java.net/browse/JDK-8135250
> 
> > > >
> 
> > >
> 


From forax at univ-mlv.fr  Mon Sep 21 15:00:58 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 21 Sep 2015 17:00:58 +0200 (CEST)
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <673914291.466765.1442846732766.JavaMail.zimbra@u-pem.fr>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<CACzrW9B_dKnFUdAv1SCY5nfx_mmYxdSHBtGs5rqdj4JibD7P1A@mail.gmail.com>
	<673914291.466765.1442846732766.JavaMail.zimbra@u-pem.fr>
Message-ID: <570970406.484675.1442847658530.JavaMail.zimbra@u-pem.fr>

Re-reading my own message and find it confusing ...
what I'm saying is that instead of trying to retrofit all (100%) of the already existing checkIndex,
we should have a simple checkIndex with a sane semantics that cover most of the usage.

R?mi 

----- Mail original -----
> De: "Remi Forax" <forax at univ-mlv.fr>
> ?: "Stephen Colebourne" <scolebourne at joda.org>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 21 Septembre 2015 16:45:32
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> 
> I agree with Stephen.
> 
> Calling the function interface with the name ...Exception seems very wrong to
> me.
> 
> The convention of ArrayIOOBE or StringIOOBE is to just report the bad index
> with no further info,
> currently with your code it's not possible to write
>   checkIndex(index, ArrayIndexOutOuBoundException::new).
> 
> so the functional interface for checkIndex should be int -> Object or long ->
> Object if you change ArrayIOOBE and StringIOOBE to store a long.
> This functional Interface already exists under the name
> java.util.function.LongFunction.
> 
> For the two other methods that checks several index, again the convention is
> to report the bad index / size, so a LongFunction is enough too,
> yes, it means that you can not check several index at once with things like
> (a < 0) | (b < 0) but because the semantics you propose is different
> from what is usually done, you will not be alble to use those methods inside
> the JDK without introducing incompatibilities.
> 
> cheers,
> R?mi
> 
> ----- Mail original -----
> > De: "Stephen Colebourne" <scolebourne at joda.org>
> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoy?: Lundi 21 Septembre 2015 15:52:53
> > Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> > 
> > While I think I understand the need for the lambda/exception interface
> > (backwards compatibility) it is definitely weird as a method
> > signature.
> > 
> > It would seem very worthwhile to add overloaded versions of each of
> > these methods that do not have the OutOfBoundsToException in the
> > argument list. Instead, these overloads would throw a "standard"
> > exception. Such methods would then be much more amenable to just being
> > dropped into existing application code, where the precise exception
> > that is thrown is less of a concern.
> > 
> > Stephen
> > 
> > 
> > 
> > On 21 September 2015 at 14:42, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> > > Hi,
> > >
> > > Please review the following which adds methods to Arrays to check indexes
> > > and ranges:
> > >
> > >   https://bugs.openjdk.java.net/browse/JDK-8135248
> > >   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
> > >
> > > The original motivation was an intrinsic method, Arrays.checkIndex, to
> > > check if an index is within bounds. Such an intrinsic guides HotSpot
> > > towards better optimisations for bounds checks using one unsigned
> > > comparison instead of two signed comparisons, and better eliding of
> > > integer to long conversions when an index is used to create an offset for
> > > Unsafe access. The end result is more efficient array access especially
> > > so
> > > from within unrolled loops. The VarHandles work will use
> > > Arrays.checkIndex
> > > for array access.
> > >
> > > A follow up issue [1] will track the intrinsification of
> > > Arrays.checkIndex.
> > >
> > > We thought it would be opportunistic to support two further common
> > > use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> > > checkFromIndexSize. There is no current plan to intrinsify these methods.
> > >
> > > Bounds checking is not difficult but it can be easy to make trivial
> > > mistakes. Thus it is advantageous to consolidate such checks not just
> > > from
> > > an optimization perspective but from a correctness and security/integrity
> > > perspective.
> > >
> > > There are many areas in the JDK where such checks are performed. A follow
> > > up issue [2] will track updates to use the new methods.
> > >
> > > The main challenge for these new methods is to design in such a way that
> > >
> > > 1) existing use-cases can still report the same set of exceptions with
> > > the
> > > same messages;
> > > 2) method byte code size is not unduly increased, thus perturbing
> > > inlining;
> > > and
> > > 3) there is a reasonable path for any future support of long indexes.
> > >
> > > Paul.
> > >
> > > [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> > > [2] https://bugs.openjdk.java.net/browse/JDK-8135250
> > 
> 


From scolebourne at joda.org  Mon Sep 21 15:15:41 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 21 Sep 2015 16:15:41 +0100
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <B27CE548-E6F5-4994-B07A-00C1CA367864@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<CACzrW9B_dKnFUdAv1SCY5nfx_mmYxdSHBtGs5rqdj4JibD7P1A@mail.gmail.com>
	<B27CE548-E6F5-4994-B07A-00C1CA367864@oracle.com>
Message-ID: <CACzrW9C_BEKexPJnJEfV0NCKqkFnAKAsx2eeQDa0g6brW9kVQA@mail.gmail.com>

On 21 September 2015 at 15:28, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> It would seem very worthwhile to add overloaded versions of each of
>> these methods that do not have the OutOfBoundsToException in the
>> argument list. Instead, these overloads would throw a "standard"
>> exception.
>
> That seems reasonable e.g.:
>
> public static
> int checkIndex(int index, int length) IndexOutOfBoundsException {
>     return checkIndex(index, length, null);
> }
>
>> Such methods would then be much more amenable to just being
>> dropped into existing application code, where the precise exception
>> that is thrown is less of a concern.
> Though is passing ?null? such a big deal?

Best to try and avoid asking application developers to pass null in to
get a special behaviour. In fact, the method could even reject null
and throw an exception, which would make more sense.

I agree with Remi on naming at least - a functional interface ending
"Exception" is likely to be confusing.

Stephen


From paul.sandoz at oracle.com  Mon Sep 21 15:21:04 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 21 Sep 2015 17:21:04 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <5600116A.4000500@Oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<5600116A.4000500@Oracle.com>
Message-ID: <802A6224-484C-41D1-A0AC-3589E0F0608C@oracle.com>


On 21 Sep 2015, at 16:17, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Paul,
> 
> java.util.Arrays.java: line 5236:  new IndexOutOfBoundsException()
> - It is always appreciated when debugging to be given a message with the index that is out of range and the range expected.
> 

Added:

? new IndexOutOfBoundsException(String.format(
 "Out of bounds for range [0, %d) with out of bound values %d and %d", length, a, b))


> When converting existing code, is it expected that the exception messages will be unchanged?
> 

Yes, that is intention, based on looking at various use-cases in Arrays/Spliterators/String/AbstractString/AbstractStringBuilder/*Buffer. I could have missed a few cases. Note that one can always play the ?capture? card at the expense of an allocation per check. which may be less of a concern for the sub-range checks.


> I can't quite visualize how this would be applied to existing code.

Existing code would provide an instance of OutOfBoundsToException for each particular use-case.

Take this following method in String:

public void getChars(int srcBegin, int srcEnd, char dst[], int dstBegin) {
    if (srcBegin < 0) {
        throw new StringIndexOutOfBoundsException(srcBegin);
    }
    if (srcEnd > value.length) {
        throw new StringIndexOutOfBoundsException(srcEnd);
    }
    if (srcBegin > srcEnd) {
        throw new StringIndexOutOfBoundsException(srcEnd - srcBegin);
    }
    System.arraycopy(value, srcBegin, dst, dstBegin, srcEnd - srcBegin);
}

Which could be updated as follows (modulo using lambdas early in at start up):

public void getChars(int srcBegin, int srcEnd, char dst[], int dstBegin) {
    Arrays.checkFromToIndex(srcBegin, srcEnd, value.length, (f, t, l) -> {
        long v;
        if (f < 0) {
            v = f;
        } else if (t > l) {
            v = t;
        } else v = t - f;
        return new StringIndexOutOfBoundsException((int) v);
    });
    System.arraycopy(value, srcBegin, dst, dstBegin, srcEnd - srcBegin);
}

Or the following in AbstractStringBuilder:

public AbstractStringBuilder insert(int index, char[] str, int offset,
                                    int len)
{
    if ((index < 0) || (index > length()))
        throw new StringIndexOutOfBoundsException(index);
    if ((offset < 0) || (len < 0) || (offset > str.length - len))
        throw new StringIndexOutOfBoundsException(
            "offset " + offset + ", len " + len + ", str.length "
            + str.length);
    ensureCapacityInternal(count + len);
    System.arraycopy(value, index, value, index + len, count - index);
    System.arraycopy(str, offset, value, index, len);
    count += len;
    return this;
}

public AbstractStringBuilder insert(int index, char[] str, int offset,
                                    int len)
{
    Arrays.checkIndex(index, length(),
                      (i, a, l) -> new StringIndexOutOfBoundsException((int) i));

    Arrays.checkFromIndexSize(offset, len, str.length,
                      (f, s, l) -> new StringIndexOutOfBoundsException(
                              "offset " + f + ", len " + s + ", str.length " + l));

    ensureCapacityInternal(count + len);
    System.arraycopy(value, index, value, index + len, count - index);
    System.arraycopy(str, offset, value, index, len);
    count += len;
    return this;
}

The casts obviously suck, but that could be solved with a new (package private, maybe) constructor. One thing we could do to improve the situation is add factory methods to IOOBE, AIOOBE, SIOOBE for the three use-cases such that method refs could be easily be used.


> Will there be any benefit to adding static checking methods to the typically thrown exceptions
> that can be used as method references instead of the implicitly defined lambdas?
> 
> typo:
> 
> test/java/util/Arrays/CheckIndex.java:
> - line 78, 91, etc  "withing" -> ?within?
> 

Thanks, updated,
Paul.


From peter.levart at gmail.com  Mon Sep 21 15:22:22 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 21 Sep 2015 17:22:22 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
Message-ID: <560020AE.1060707@gmail.com>

Hi Paul,

It seems that all that is needed for performance is to intrinsify static 
methods Integer.compareUnsigned(int, int) and Long.compareUnsigned(long, 
long). Or would that not be enough? Then perhaps explicit compare 
operations would suffice:

public class Integer {
...
     public static boolean unsignedLess(int a, int b);
     public static boolean unsignedLessOrEqual(int a, int b);

You could still have Arrays.checkIndex methods, but they could be pure 
bytecode methods with standard exception types / messages. And if one 
needs special exception types / messages, (s)he can use the intrinsified 
comparison methods directly and imperative code to throw the exception.

What do you think?

Regards, Peter

On 09/21/2015 03:42 PM, Paul Sandoz wrote:
> Hi,
>
> Please review the following which adds methods to Arrays to check indexes and ranges:
>
>    https://bugs.openjdk.java.net/browse/JDK-8135248
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
>
> The original motivation was an intrinsic method, Arrays.checkIndex, to check if an index is within bounds. Such an intrinsic guides HotSpot towards better optimisations for bounds checks using one unsigned comparison instead of two signed comparisons, and better eliding of integer to long conversions when an index is used to create an offset for Unsafe access. The end result is more efficient array access especially so from within unrolled loops. The VarHandles work will use Arrays.checkIndex for array access.
>
> A follow up issue [1] will track the intrinsification of Arrays.checkIndex.
>
> We thought it would be opportunistic to support two further common use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> checkFromIndexSize. There is no current plan to intrinsify these methods.
>
> Bounds checking is not difficult but it can be easy to make trivial mistakes. Thus it is advantageous to consolidate such checks not just from an optimization perspective but from a correctness and security/integrity perspective.
>
> There are many areas in the JDK where such checks are performed. A follow up issue [2] will track updates to use the new methods.
>
> The main challenge for these new methods is to design in such a way that
>
> 1) existing use-cases can still report the same set of exceptions with the same messages;
> 2) method byte code size is not unduly increased, thus perturbing inlining; and
> 3) there is a reasonable path for any future support of long indexes.
>
> Paul.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> [2] https://bugs.openjdk.java.net/browse/JDK-8135250



From paul.sandoz at oracle.com  Mon Sep 21 15:46:07 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 21 Sep 2015 17:46:07 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <673914291.466765.1442846732766.JavaMail.zimbra@u-pem.fr>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<CACzrW9B_dKnFUdAv1SCY5nfx_mmYxdSHBtGs5rqdj4JibD7P1A@mail.gmail.com>
	<673914291.466765.1442846732766.JavaMail.zimbra@u-pem.fr>
Message-ID: <8F845D19-214F-4FB5-BA6B-0E48BB687AE2@oracle.com>


On 21 Sep 2015, at 16:45, Remi Forax <forax at univ-mlv.fr> wrote:

> I agree with Stephen.
> 
> Calling the function interface with the name ...Exception seems very wrong to me.
> 

Agreed, need to think of a better name. One solution is to remove it all together :-) see below.


> The convention of ArrayIOOBE or StringIOOBE is to just report the bad index with no further info,
> currently with your code it's not possible to write
>  checkIndex(index, ArrayIndexOutOuBoundException::new).
> 
> so the functional interface for checkIndex should be int -> Object or long -> Object if you change ArrayIOOBE and StringIOOBE to store a long.
> This functional Interface already exists under the name java.util.function.LongFunction.
> 

The friction here is trying to cater for the existing use-cases in the JDK, after a cursory 5 minute search you will find many conventions :-)

From the use-cases i have looked at so far I believe it?s possible to support nearly all with BiFunction<Integer, Integer, RuntimeException> (i started out with that in mind), in some cases a process of elimination can be used for reporting. Other use-cases could be supported with capture.

There is a use-case in AbstractStringBuilder that requires all three values, that is the only one i have found so far in the JDK. I would be interested to know if there are others and also if people are doing that in their own code too.

I would be happy to sacrifice the use-case in AbstractStringBuilder for using BiFunction<Integer, Integer, RuntimeException>, and add appropriate constructors or factory methods on the common exception types for method ref usage.

Paul.

> For the two other methods that checks several index, again the convention is to report the bad index / size, so a LongFunction is enough too,
> yes, it means that you can not check several index at once with things like (a < 0) | (b < 0) but because the semantics you propose is different
> from what is usually done, you will not be alble to use those methods inside the JDK without introducing incompatibilities.
> 
> cheers,
> R?mi



From peter.levart at gmail.com  Mon Sep 21 15:53:29 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 21 Sep 2015 17:53:29 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <560020AE.1060707@gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<560020AE.1060707@gmail.com>
Message-ID: <560027F9.5000806@gmail.com>



On 09/21/2015 05:22 PM, Peter Levart wrote:
> Hi Paul,
>
> It seems that all that is needed for performance is to intrinsify 
> static methods Integer.compareUnsigned(int, int) and 
> Long.compareUnsigned(long, long). Or would that not be enough? Then 
> perhaps explicit compare operations would suffice:
>
> public class Integer {
> ...
>     public static boolean unsignedLess(int a, int b);
>     public static boolean unsignedLessOrEqual(int a, int b);
>
> You could still have Arrays.checkIndex methods, but they could be pure 
> bytecode methods with standard exception types / messages. And if one 
> needs special exception types / messages, (s)he can use the 
> intrinsified comparison methods directly and imperative code to throw 
> the exception.
>
> What do you think?
>
> Regards, Peter

Or,

...have intrinsified method(s) in the form of:

public class Arrays {
...
     public static boolean isIndexValid(int i, int length);
     public static boolean isFromToIndexValid(int from, int to, int length);
     ...

... and pure bytecode checkXXXIndex methods implemented in terms of 
above but just for standard exceptions. Code throwing customized 
exceptions would use isXXXIndexValid methods and imperative code to 
construct and throw exception.

The question is whether boolean return from intrinsic method coupled 
with if statement in bytecode optimizes equally well as if the branch 
was in the intrinsified method itself.


Regards, Peter


>
> On 09/21/2015 03:42 PM, Paul Sandoz wrote:
>> Hi,
>>
>> Please review the following which adds methods to Arrays to check 
>> indexes and ranges:
>>
>>    https://bugs.openjdk.java.net/browse/JDK-8135248
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
>>
>> The original motivation was an intrinsic method, Arrays.checkIndex, 
>> to check if an index is within bounds. Such an intrinsic guides 
>> HotSpot towards better optimisations for bounds checks using one 
>> unsigned comparison instead of two signed comparisons, and better 
>> eliding of integer to long conversions when an index is used to 
>> create an offset for Unsafe access. The end result is more efficient 
>> array access especially so from within unrolled loops. The VarHandles 
>> work will use Arrays.checkIndex for array access.
>>
>> A follow up issue [1] will track the intrinsification of 
>> Arrays.checkIndex.
>>
>> We thought it would be opportunistic to support two further common 
>> use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
>> checkFromIndexSize. There is no current plan to intrinsify these 
>> methods.
>>
>> Bounds checking is not difficult but it can be easy to make trivial 
>> mistakes. Thus it is advantageous to consolidate such checks not just 
>> from an optimization perspective but from a correctness and 
>> security/integrity perspective.
>>
>> There are many areas in the JDK where such checks are performed. A 
>> follow up issue [2] will track updates to use the new methods.
>>
>> The main challenge for these new methods is to design in such a way that
>>
>> 1) existing use-cases can still report the same set of exceptions 
>> with the same messages;
>> 2) method byte code size is not unduly increased, thus perturbing 
>> inlining; and
>> 3) there is a reasonable path for any future support of long indexes.
>>
>> Paul.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8042997
>> [2] https://bugs.openjdk.java.net/browse/JDK-8135250
>



From rob.mckenna at oracle.com  Mon Sep 21 15:53:48 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 21 Sep 2015 16:53:48 +0100
Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr in
	getLastErrorString
Message-ID: <5600280C.9040601@oracle.com>

Hi folks,

Requesting a review of this change which switches corelibs usages of the 
thread-unsafe strerror over to strerror_r/strerror_s:

http://cr.openjdk.java.net/~robm/8133249/webrev.01/

	-Rob



From peter.levart at gmail.com  Mon Sep 21 16:11:09 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 21 Sep 2015 18:11:09 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <8F845D19-214F-4FB5-BA6B-0E48BB687AE2@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<CACzrW9B_dKnFUdAv1SCY5nfx_mmYxdSHBtGs5rqdj4JibD7P1A@mail.gmail.com>
	<673914291.466765.1442846732766.JavaMail.zimbra@u-pem.fr>
	<8F845D19-214F-4FB5-BA6B-0E48BB687AE2@oracle.com>
Message-ID: <56002C1D.5090403@gmail.com>



On 09/21/2015 05:46 PM, Paul Sandoz wrote:
> On 21 Sep 2015, at 16:45, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> I agree with Stephen.
>>
>> Calling the function interface with the name ...Exception seems very wrong to me.
>>
> Agreed, need to think of a better name. One solution is to remove it all together :-) see below.
>
>
>> The convention of ArrayIOOBE or StringIOOBE is to just report the bad index with no further info,
>> currently with your code it's not possible to write
>>   checkIndex(index, ArrayIndexOutOuBoundException::new).
>>
>> so the functional interface for checkIndex should be int -> Object or long -> Object if you change ArrayIOOBE and StringIOOBE to store a long.
>> This functional Interface already exists under the name java.util.function.LongFunction.
>>
> The friction here is trying to cater for the existing use-cases in the JDK, after a cursory 5 minute search you will find many conventions :-)
>
>  From the use-cases i have looked at so far I believe it?s possible to support nearly all with BiFunction<Integer, Integer, RuntimeException> (i started out with that in mind), in some cases a process of elimination can be used for reporting. Other use-cases could be supported with capture.
>
> There is a use-case in AbstractStringBuilder that requires all three values, that is the only one i have found so far in the JDK. I would be interested to know if there are others and also if people are doing that in their own code too.
>
> I would be happy to sacrifice the use-case in AbstractStringBuilder for using BiFunction<Integer, Integer, RuntimeException>, and add appropriate constructors or factory methods on the common exception types for method ref usage.
>
> Paul.

Don't forget that AbstractStringBuilder is used in String concatenation 
which might be used very early in the life of VM and that lambdas need 
invokedynamic which initializes java.lang.invoke infrastructure which 
doesn't work currently if it happens before System class loader is 
initialized... (same chicken-egg issues as with string concatenation JEP 
by Alexey Shipilev - they can be solved though, but it would be easier 
to not need lambdas if possible. They don't make code look any nicer in 
these cases anyway).

Regards, Peter

>
>> For the two other methods that checks several index, again the convention is to report the bad index / size, so a LongFunction is enough too,
>> yes, it means that you can not check several index at once with things like (a < 0) | (b < 0) but because the semantics you propose is different
>> from what is usually done, you will not be alble to use those methods inside the JDK without introducing incompatibilities.
>>
>> cheers,
>> R?mi



From christos at zoulas.com  Mon Sep 21 16:32:56 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Mon, 21 Sep 2015 12:32:56 -0400
Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr
	in getLastErrorString
In-Reply-To: <5600280C.9040601@oracle.com> from Rob McKenna (Sep 21,  4:53pm)
Message-ID: <20150921163256.83FD317FDAF@rebar.astron.com>

On Sep 21,  4:53pm, rob.mckenna at oracle.com (Rob McKenna) wrote:
-- Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr 

| Hi folks,
| 
| Requesting a review of this change which switches corelibs usages of the 
| thread-unsafe strerror over to strerror_r/strerror_s:
| 
| http://cr.openjdk.java.net/~robm/8133249/webrev.01/

I like this change, but in jdk_strerror.c:

1. Why are you using "errno" instead of "err" in the linux strerror_r()
   invocation?
2. Isn't the "Unknown error" test going to break on non-english locales?

Best,

christos


From paul.sandoz at oracle.com  Mon Sep 21 17:05:10 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 21 Sep 2015 19:05:10 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <56002C1D.5090403@gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<CACzrW9B_dKnFUdAv1SCY5nfx_mmYxdSHBtGs5rqdj4JibD7P1A@mail.gmail.com>
	<673914291.466765.1442846732766.JavaMail.zimbra@u-pem.fr>
	<8F845D19-214F-4FB5-BA6B-0E48BB687AE2@oracle.com>
	<56002C1D.5090403@gmail.com>
Message-ID: <62AC2B53-CD6A-4753-80D5-6739EA189F0F@oracle.com>

On 21 Sep 2015, at 18:11, Peter Levart <peter.levart at gmail.com> wrote:
>> I would be happy to sacrifice the use-case in AbstractStringBuilder for using BiFunction<Integer, Integer, RuntimeException>, and add appropriate constructors or factory methods on the common exception types for method ref usage.
>> 
>> Paul.
> 
> Don't forget that AbstractStringBuilder is used in String concatenation which might be used very early in the life of VM and that lambdas need invokedynamic which initializes java.lang.invoke infrastructure which doesn't work currently if it happens before System class loader is initialized... (same chicken-egg issues as with string concatenation JEP by Alexey Shipilev - they can be solved though, but it would be easier to not need lambdas if possible. They don't make code look any nicer in these cases anyway).
> 

It?s very much on my mind :-) in some cases we cannot use lambdas/method refs.

Paul.


From paul.sandoz at oracle.com  Mon Sep 21 17:18:49 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 21 Sep 2015 19:18:49 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <560027F9.5000806@gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<560020AE.1060707@gmail.com> <560027F9.5000806@gmail.com>
Message-ID: <66F643EC-A6E5-4F09-AB49-B7DD08F64098@oracle.com>

Hi Peter,

You can find some discussion in the comments of https://bugs.openjdk.java.net/browse/JDK-8042997 which may help.

I originally thought we could intrinsify unsigned comparison or have a boolean returning method.

Over a series of discussions i was convinced by the current shape that makes it easier to use in an expression, the result of which may be easier for the JIT to track, no flow control is arguably easier, it encapsulates the throwing logic in a single failure block that is squirrelled away, and potentially reduces the code of callers. Like the inequality checks themselves those things may be easy but one can often make trivial mistakes too.

Paul.

On 21 Sep 2015, at 17:53, Peter Levart <peter.levart at gmail.com> wrote:

> 
> 
> On 09/21/2015 05:22 PM, Peter Levart wrote:
>> Hi Paul,
>> 
>> It seems that all that is needed for performance is to intrinsify static methods Integer.compareUnsigned(int, int) and Long.compareUnsigned(long, long). Or would that not be enough? Then perhaps explicit compare operations would suffice:
>> 
>> public class Integer {
>> ...
>>    public static boolean unsignedLess(int a, int b);
>>    public static boolean unsignedLessOrEqual(int a, int b);
>> 
>> You could still have Arrays.checkIndex methods, but they could be pure bytecode methods with standard exception types / messages. And if one needs special exception types / messages, (s)he can use the intrinsified comparison methods directly and imperative code to throw the exception.
>> 
>> What do you think?
>> 
>> Regards, Peter
> 
> Or,
> 
> ...have intrinsified method(s) in the form of:
> 
> public class Arrays {
> ...
>    public static boolean isIndexValid(int i, int length);
>    public static boolean isFromToIndexValid(int from, int to, int length);
>    ...
> 
> ... and pure bytecode checkXXXIndex methods implemented in terms of above but just for standard exceptions. Code throwing customized exceptions would use isXXXIndexValid methods and imperative code to construct and throw exception.
> 
> The question is whether boolean return from intrinsic method coupled with if statement in bytecode optimizes equally well as if the branch was in the intrinsified method itself.
> 
> 
> Regards, Peter
> 


From Roger.Riggs at oracle.com  Mon Sep 21 17:47:30 2015
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 21 Sep 2015 13:47:30 -0400
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection
	to discard output
In-Reply-To: <644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
References: <55F2F37E.20101@Oracle.com>
	<644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
Message-ID: <560042B2.4090409@oracle.com>

Ping?

Can a Reviewer take a look and comment?

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/


Thanks, Roger


On 09/11/2015 01:11 PM, Remi Forax wrote:
> Great !,
> minor comments,
> nullFile should be NULL_FILE and @since 9 -> @since 1.9
>
> regards,
> R?mi
>
> ----- Mail original -----
>> De: "Roger Riggs" <Roger.Riggs at Oracle.com>
>> ?: "Core-Libs-Dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Vendredi 11 Septembre 2015 17:30:06
>> Objet: RFR: 8132541 : (process) ProcessBuilder support for redirection to	discard output
>>
>> Please review a proposed [1] ProcessBuilder addition to define a
>> Redirect that will discard output.
>> The implementation is to redirect output to /dev/null or NUL on Windows.
>>
>> Please review and comment if there are any unexpected side effects.
>>
>> Webrev:
>>     http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/
>>
>> Issue:
>>     https://bugs.openjdk.java.net/browse/JDK-8132541
>>
>> Thanks, Roger
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034639.html
>>



From uschindler at apache.org  Mon Sep 21 18:03:25 2015
From: uschindler at apache.org (Uwe Schindler)
Date: Mon, 21 Sep 2015 20:03:25 +0200
Subject: RFR: 8132541 : (process) ProcessBuilder support for
	redirection	to discard output
In-Reply-To: <560042B2.4090409@oracle.com>
References: <55F2F37E.20101@Oracle.com>	<644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
	<560042B2.4090409@oracle.com>
Message-ID: <012801d0f497$d1d7e350$7587a9f0$@apache.org>

Hi,

+         * The output is discarded by writing to the operating specific
+         * <em>null</em> file.

Small Javadocs issue, it should be "... operating system specific ..."

Uwe

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> Behalf Of Roger Riggs
> Sent: Monday, September 21, 2015 7:48 PM
> To: Core-Libs-Dev
> Subject: Re: RFR: 8132541 : (process) ProcessBuilder support for redirection
> to discard output
> 
> Ping?
> 
> Can a Reviewer take a look and comment?
> 
> Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/
> 
> 
> Thanks, Roger
> 
> 
> On 09/11/2015 01:11 PM, Remi Forax wrote:
> > Great !,
> > minor comments,
> > nullFile should be NULL_FILE and @since 9 -> @since 1.9
> >
> > regards,
> > R?mi
> >
> > ----- Mail original -----
> >> De: "Roger Riggs" <Roger.Riggs at Oracle.com>
> >> ?: "Core-Libs-Dev" <core-libs-dev at openjdk.java.net>
> >> Envoy?: Vendredi 11 Septembre 2015 17:30:06
> >> Objet: RFR: 8132541 : (process) ProcessBuilder support for redirection to
> 	discard output
> >>
> >> Please review a proposed [1] ProcessBuilder addition to define a
> >> Redirect that will discard output.
> >> The implementation is to redirect output to /dev/null or NUL on
> Windows.
> >>
> >> Please review and comment if there are any unexpected side effects.
> >>
> >> Webrev:
> >>     http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/
> >>
> >> Issue:
> >>     https://bugs.openjdk.java.net/browse/JDK-8132541
> >>
> >> Thanks, Roger
> >>
> >> [1]
> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034639
> >> .html
> >>



From Roger.Riggs at oracle.com  Mon Sep 21 18:14:37 2015
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 21 Sep 2015 14:14:37 -0400
Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr
	in getLastErrorString
In-Reply-To: <5600280C.9040601@oracle.com>
References: <5600280C.9040601@oracle.com>
Message-ID: <5600490D.30000@oracle.com>

Hi Rob,

Some comments:

jdk_strerrror.c/.h:

- It seems like the existing jni_util_md.c getLastErrorString function 
provides the same function
   as jdk_strerror.  Then jdk_strerror could be an internal function and 
not require new files.
   The getLastErrorString is already exported from libjava.
   The Windows version of getLastErrorString is handled separately.
   Perhaps I'm missing some subtle dependency.


- the  "(size_t) 1024"  might be easier to maintain if it was "(sizeof 
tmpbuf)"  (*everywhere*)
   In the case of changing of the buffer size, it would only need to be 
changed in one place.


libjli/java_md_common.c: This edit seems incomplete, there are commented 
out lines.

src/java.base/unix/native/libnet/PlainDatagramSocketImpl.c: has only an 
#include, no code changes

src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c: 
line 2218
     - the difference in the length between 255 and 300 is unmotivated.

Roger


On 09/21/2015 11:53 AM, Rob McKenna wrote:
> Hi folks,
>
> Requesting a review of this change which switches corelibs usages of 
> the thread-unsafe strerror over to strerror_r/strerror_s:
>
> http://cr.openjdk.java.net/~robm/8133249/webrev.01/
>
>     -Rob
>



From brian.burkhalter at oracle.com  Mon Sep 21 18:15:03 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 21 Sep 2015 11:15:03 -0700
Subject: [9] RFR of 5100935: No way to access the 64-bit integer
	multiplication of 64-bit CPUs efficiently
In-Reply-To: <55FDBCC1.8060708@oracle.com>
References: <3B559334-8ED3-4BEA-85E9-7AA9CD57AA91@oracle.com>
	<55FDBCC1.8060708@oracle.com>
Message-ID: <AFAC1F0A-D393-4191-ABDD-C42862A24CED@oracle.com>

Hello, Sergey,

On Sep 19, 2015, at 12:51 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:

> Hello, I have a related question about the adding of methods to the Math class. Some methods **Exact methods were added to the Math class in jdk8, which throws an exceptions in case of overflow. Is it possible to add the similar saturation arithmetic? It would be quite good to realize a full range of these methods, and give the chance to hotspot to use an intrinsic.

If there are particular methods of interest and there are no corresponding issues on file, then one or more issues should be filed in the Java Bug System so that we may consider and track them according to the usual process. As there is currently an attempt to address some of the omissions in the Math area, now would be a good time to get these issues on record. So I suggest that the interested parties do just that. I think that one issue containing several method requests would be sufficient if it concerns the same area of code.

As to the compiler intrinsics, we are looking into adding a few math-related things here as well. This would be tracked by a separate issue which we would file ourselves.

Regards,

Brian

> This is mostly request from the java2d team:
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-December/000954.html
> "I currently use an utility-class heavily for the XRender Java2D
> backend, which performs saturated casts:
> 
> 1.) return (short) (x > Short.MAX_VALUE ? Short.MAX_VALUE : (x <
> Short.MIN_VALUE ? Short.MIN_VALUE : x));
> 2.) return (short) (x > 65535 ? 65535 : (x < 0) ? 0 : x);
> 
> I spent quite some time benchmarking/tuning the
> protocol-generation-methods, and a lot of cycles are spent in those
> saturated casts, even if the utility methods are static.
> E.g. XRenderFillRectangle takes 40 cycles without clamping, but
> already 70 cycles with on my core2duo with hotspot-server/jdk 14.0.
> Hotspot seems to solve the problem always with conditional jumps,
> although well predictable ones.
> 
> Modern processors seem to have support for this kind of operation, in
> x86 there's packssdw in MMX/SSE2.
> I think something like a saturated cast could be quite useful, there
> are already cast-methods in Long/Integer/Short - what do you think
> about adding saturated casts to that API?
> Those could be instrified to use MMX/SSE2 if available.
> 
> If that would be too specific how hard would it be to add this kind of
> optimization to hotspot?
> How far does SIMD support in hotspot go (I read some time ago there've
> been some optimizations), if SIMD would be supported 4 casts could be
> done in a single cycle :)



From jeffhain at rocketmail.com  Mon Sep 21 18:12:05 2015
From: jeffhain at rocketmail.com (Jeff Hain)
Date: Mon, 21 Sep 2015 18:12:05 +0000 (UTC)
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
Message-ID: <1873795519.1580772.1442859125027.JavaMail.yahoo@mail.yahoo.com>


Hi.



In your webrev:

+ if ((length | fromIndex | size) < 0 || size > length - fromIndex)
+?? throw outOfBounds(fromIndex, size, length, oobe);



In Buffer.java (equivalent if adding "| size"):
??? static void checkBounds(int off, int len, int size) { // package-private
??????? if ((off | len | (off + len) | (size - (off + len))) < 0)
??????????? throw new IndexOutOfBoundsException();
??? }



Maybe the second way (only one boolean check) is better for perfs?



-Jeff



From chris.hegarty at oracle.com  Mon Sep 21 18:16:25 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 21 Sep 2015 19:16:25 +0100
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection
	to discard output
In-Reply-To: <560042B2.4090409@oracle.com>
References: <55F2F37E.20101@Oracle.com>
	<644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
	<560042B2.4090409@oracle.com>
Message-ID: <8B5D5E0F-6BD7-426D-9C8B-429F5D031A1F@oracle.com>

On 21 Sep 2015, at 18:47, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Ping?
> 
> Can a Reviewer take a look and comment?

Looks good Roger.

-Chris.

> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/
> 
> 
> Thanks, Roger
> 
> 
> On 09/11/2015 01:11 PM, Remi Forax wrote:
>> Great !,
>> minor comments,
>> nullFile should be NULL_FILE and @since 9 -> @since 1.9
>> 
>> regards,
>> R?mi
>> 
>> ----- Mail original -----
>>> De: "Roger Riggs" <Roger.Riggs at Oracle.com>
>>> ?: "Core-Libs-Dev" <core-libs-dev at openjdk.java.net>
>>> Envoy?: Vendredi 11 Septembre 2015 17:30:06
>>> Objet: RFR: 8132541 : (process) ProcessBuilder support for redirection to	discard output
>>> 
>>> Please review a proposed [1] ProcessBuilder addition to define a
>>> Redirect that will discard output.
>>> The implementation is to redirect output to /dev/null or NUL on Windows.
>>> 
>>> Please review and comment if there are any unexpected side effects.
>>> 
>>> Webrev:
>>>    http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/
>>> 
>>> Issue:
>>>    https://bugs.openjdk.java.net/browse/JDK-8132541
>>> 
>>> Thanks, Roger
>>> 
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034639.html
>>> 
> 



From martinrb at google.com  Mon Sep 21 18:18:01 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 21 Sep 2015 11:18:01 -0700
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection
	to discard output
In-Reply-To: <560042B2.4090409@oracle.com>
References: <55F2F37E.20101@Oracle.com>
	<644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
	<560042B2.4090409@oracle.com>
Message-ID: <CA+kOe09tcvs2N8N=i0k_eqwO8kXyQVD-GiM23vfZC9=vyc-qwQ@mail.gmail.com>

Thanks, I think this will be a popular feature, but...

I'm not sure that all operating systems where Java may run will have such a
"null file" (does OS400?).

If you're sure there is such a "null file", maybe there should be one or
two methods added to File to return the null output and input files.
Speaking of which, one might expect an analogue for "null input", giving
you nothing but EOF, as with "command < /dev/null".  You wouldn't want to
call it DISCARD, though.

If you added File.nullSink(), you could then do a
Redirect.to(File.nullSink())


On Mon, Sep 21, 2015 at 10:47 AM, Roger Riggs <Roger.Riggs at oracle.com>
wrote:

> Ping?
>
> Can a Reviewer take a look and comment?
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/
>
>
> Thanks, Roger
>
>
>
> On 09/11/2015 01:11 PM, Remi Forax wrote:
>
>> Great !,
>> minor comments,
>> nullFile should be NULL_FILE and @since 9 -> @since 1.9
>>
>> regards,
>> R?mi
>>
>> ----- Mail original -----
>>
>>> De: "Roger Riggs" <Roger.Riggs at Oracle.com>
>>> ?: "Core-Libs-Dev" <core-libs-dev at openjdk.java.net>
>>> Envoy?: Vendredi 11 Septembre 2015 17:30:06
>>> Objet: RFR: 8132541 : (process) ProcessBuilder support for redirection
>>> to       discard output
>>>
>>> Please review a proposed [1] ProcessBuilder addition to define a
>>> Redirect that will discard output.
>>> The implementation is to redirect output to /dev/null or NUL on Windows.
>>>
>>> Please review and comment if there are any unexpected side effects.
>>>
>>> Webrev:
>>>     http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/
>>>
>>> Issue:
>>>     https://bugs.openjdk.java.net/browse/JDK-8132541
>>>
>>> Thanks, Roger
>>>
>>> [1]
>>>
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034639.html
>>>
>>>
>


From Roger.Riggs at oracle.com  Mon Sep 21 18:28:57 2015
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 21 Sep 2015 14:28:57 -0400
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection
	to discard output
In-Reply-To: <CA+kOe09tcvs2N8N=i0k_eqwO8kXyQVD-GiM23vfZC9=vyc-qwQ@mail.gmail.com>
References: <55F2F37E.20101@Oracle.com>
	<644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
	<560042B2.4090409@oracle.com>
	<CA+kOe09tcvs2N8N=i0k_eqwO8kXyQVD-GiM23vfZC9=vyc-qwQ@mail.gmail.com>
Message-ID: <56004C69.1010606@oracle.com>

Hi Martin,

On 09/21/2015 02:18 PM, Martin Buchholz wrote:
> Thanks, I think this will be a popular feature, but...
>
> I'm not sure that all operating systems where Java may run will have 
> such a "null file" (does OS400?).
True, but there are multiple ways to discard the output and it need not 
be via the null file,
that's just easy on Unix and Windows.
The Redirect.file() method is allowed to return null and I've updated 
the description to reinforce that for OS's that discard the output some 
other way.

>
> If you're sure there is such a "null file", maybe there should be one 
> or two methods added to File to return the null output and input 
> files.  Speaking of which, one might expect an analogue for "null 
> input", giving you nothing but EOF, as with "command < /dev/null".  
> You wouldn't want to call it DISCARD, though.
The requested function was to discard the output; and it was described 
as easy
to close the InputStream to achieve the null input.
DISCARD can't be used for the null input because its type is 'WRITE'.
>
> If you added File.nullSink(), you could then do a 
> Redirect.to(File.nullSink())
An alternative yes, but then for the input side it should be called 
nullSource().

Roger

>
>
> On Mon, Sep 21, 2015 at 10:47 AM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Ping?
>
>     Can a Reviewer take a look and comment?
>
>     Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/
>     <http://cr.openjdk.java.net/%7Erriggs/webrev-8132541-discard/>
>
>
>     Thanks, Roger
>
>
>
>     On 09/11/2015 01:11 PM, Remi Forax wrote:
>
>         Great !,
>         minor comments,
>         nullFile should be NULL_FILE and @since 9 -> @since 1.9
>
>         regards,
>         R?mi
>
>         ----- Mail original -----
>
>             De: "Roger Riggs" <Roger.Riggs at Oracle.com>
>             ?: "Core-Libs-Dev" <core-libs-dev at openjdk.java.net
>             <mailto:core-libs-dev at openjdk.java.net>>
>             Envoy?: Vendredi 11 Septembre 2015 17:30:06
>             Objet: RFR: 8132541 : (process) ProcessBuilder support for
>             redirection to       discard output
>
>             Please review a proposed [1] ProcessBuilder addition to
>             define a
>             Redirect that will discard output.
>             The implementation is to redirect output to /dev/null or
>             NUL on Windows.
>
>             Please review and comment if there are any unexpected side
>             effects.
>
>             Webrev:
>             http://cr.openjdk.java.net/~rriggs/webrev-8132541-discard/
>             <http://cr.openjdk.java.net/%7Erriggs/webrev-8132541-discard/>
>
>             Issue:
>             https://bugs.openjdk.java.net/browse/JDK-8132541
>
>             Thanks, Roger
>
>             [1]
>             http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/034639.html
>
>
>



From martinrb at google.com  Mon Sep 21 18:34:57 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 21 Sep 2015 11:34:57 -0700
Subject: RFR: jsr166 openjdk9 integration
Message-ID: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>

This is the long-delayed and long-awaited bulk integration for jdk9 from
jsr166 CVS.

Find webrevs here:
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/

Sorry about the extreme size and tardiness of this integration.

As a review convenience, I provided a diff-wbB file that contains all the
jsr166 integration changes using "hg diff -wbB" that ignores whitespace
changes.

We will need JPRT+specdiff+CCC from Oracle folks

All changes are subtasks of:
https://bugs.openjdk.java.net/browse/JDK-8132960


From jason_mehrens at hotmail.com  Mon Sep 21 19:17:10 2015
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Mon, 21 Sep 2015 19:17:10 +0000
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
Message-ID: <BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>

Hi Paul,

Would it make sense to add these methods to the IndexOutOfBoundsException class itself or is there a compatibility worry?  Seems better to use the room in IndexOutOfBoundsException class file and keep these methods out of the Arrays class.  It is also odd that in the future the LinkedList would depend on the Arrays class to check bounds.

Jason

________________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Paul Sandoz <paul.sandoz at oracle.com>
Sent: Monday, September 21, 2015 8:42 AM
To: core-libs-dev
Subject: RFR 8135248: Add utility methods to check indexes and ranges

Hi,

Please review the following which adds methods to Arrays to check indexes and ranges:

  https://bugs.openjdk.java.net/browse/JDK-8135248
  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/

The original motivation was an intrinsic method, Arrays.checkIndex, to check if an index is within bounds. Such an intrinsic guides HotSpot towards better optimisations for bounds checks using one unsigned comparison instead of two signed comparisons, and better eliding of integer to long conversions when an index is used to create an offset for Unsafe access. The end result is more efficient array access especially so from within unrolled loops. The VarHandles work will use Arrays.checkIndex for array access.

A follow up issue [1] will track the intrinsification of Arrays.checkIndex.

We thought it would be opportunistic to support two further common use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
checkFromIndexSize. There is no current plan to intrinsify these methods.

Bounds checking is not difficult but it can be easy to make trivial mistakes. Thus it is advantageous to consolidate such checks not just from an optimization perspective but from a correctness and security/integrity perspective.

There are many areas in the JDK where such checks are performed. A follow up issue [2] will track updates to use the new methods.

The main challenge for these new methods is to design in such a way that

1) existing use-cases can still report the same set of exceptions with the same messages;
2) method byte code size is not unduly increased, thus perturbing inlining; and
3) there is a reasonable path for any future support of long indexes.

Paul.

[1] https://bugs.openjdk.java.net/browse/JDK-8042997
[2] https://bugs.openjdk.java.net/browse/JDK-8135250


From sebastian.sickelmann at gmx.de  Mon Sep 21 19:21:23 2015
From: sebastian.sickelmann at gmx.de (Sebastian Sickelmann)
Date: Mon, 21 Sep 2015 21:21:23 +0200
Subject: JDK-4290274 (timer) java.util.Timer.scheduleAtFixedRate() fails if
	the system time is changed
Message-ID: <560058B3.809@gmx.de>

Hi,

while looking through some bugs in JBS I found this[1] one.

It seems to be that it is already solved. I tried the submitted example
with jdk6,7,8 and
it seems that it works since jdk7.

So maybe the bug can be closed, like the one it relates to
        JDK-5056544 javax.swing.timer stops after changing actual system
time

I created a headless swing based jtreg-test for JDK-4290274 but actually
it would run
only on linux(which can be changed) and must be started by a user that
can change the time.

Is it possible to integrate such a test in openjdk?

-- Sebastian

[0] https://bugs.openjdk.java.net/browse/JDK-4290274


From paul.sandoz at oracle.com  Mon Sep 21 19:21:52 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 21 Sep 2015 21:21:52 +0200
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
Message-ID: <2A64901D-0FEF-4DA4-B99C-E13FC16775E1@oracle.com>

Hi Martin,

Thanks so much for doing this.

Chris and I will cherry pick the appropriate API changes required for CCC, which i believe only apply to the first three sub-tasks of JDK-8132960 (Flow, CompletableFuture, and ForkJoin), but we should need to double check.

We also need to be careful we have not hobbled some required differences needed for the JDK, i believe they are few but can be easy to miss.

I will shepherd the JEP through the process, currently a draft in the submitted state waiting to move to candidate. We can work in parallel to that process, but should only push the changes after it has been targeted.

Paul.

On 21 Sep 2015, at 20:34, Martin Buchholz <martinrb at google.com> wrote:

> This is the long-delayed and long-awaited bulk integration for jdk9 from jsr166 CVS.
> 
> Find webrevs here:
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
> 
> Sorry about the extreme size and tardiness of this integration.
> 
> As a review convenience, I provided a diff-wbB file that contains all the jsr166 integration changes using "hg diff -wbB" that ignores whitespace changes.
> 
> We will need JPRT+specdiff+CCC from Oracle folks
> 
> All changes are subtasks of:
> https://bugs.openjdk.java.net/browse/JDK-8132960



From paul.sandoz at oracle.com  Mon Sep 21 19:29:19 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 21 Sep 2015 21:29:19 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <1873795519.1580772.1442859125027.JavaMail.yahoo@mail.yahoo.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<1873795519.1580772.1442859125027.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <32DE1099-BC5C-4DF9-A648-328FA4CEB53C@oracle.com>

Hi Jeff,

I did wonder about that when i saw that code too. Without looking at generated machine code i do not know.

Paul.

On 21 Sep 2015, at 20:12, Jeff Hain <jeffhain at rocketmail.com> wrote:

> 
> Hi.
> 
> 
> 
> In your webrev:
> 
> + if ((length | fromIndex | size) < 0 || size > length - fromIndex)
> +   throw outOfBounds(fromIndex, size, length, oobe);
> 
> 
> 
> In Buffer.java (equivalent if adding "| size"):
>     static void checkBounds(int off, int len, int size) { // package-private
>         if ((off | len | (off + len) | (size - (off + len))) < 0)
>             throw new IndexOutOfBoundsException();
>     }
> 
> 
> 
> Maybe the second way (only one boolean check) is better for perfs?
> 
> 
> 
> -Jeff
> 



From rob.mckenna at oracle.com  Mon Sep 21 21:38:56 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Mon, 21 Sep 2015 22:38:56 +0100
Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr
	in getLastErrorString
In-Reply-To: <20150921163256.83FD317FDAF@rebar.astron.com>
References: <20150921163256.83FD317FDAF@rebar.astron.com>
Message-ID: <560078F0.80003@oracle.com>

Thanks Christos:

On 21/09/15 17:32, christos at zoulas.com wrote:
> On Sep 21,  4:53pm, rob.mckenna at oracle.com (Rob McKenna) wrote:
> -- Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr
>
> | Hi folks,
> |
> | Requesting a review of this change which switches corelibs usages of the
> | thread-unsafe strerror over to strerror_r/strerror_s:
> |
> | http://cr.openjdk.java.net/~robm/8133249/webrev.01/
>
> I like this change, but in jdk_strerror.c:
>
> 1. Why are you using "errno" instead of "err" in the linux strerror_r()
>     invocation?

Gah. An oversight. Thanks for catching it.

> 2. Isn't the "Unknown error" test going to break on non-english locales?

Unless I'm misreading the gnu implementation appears to hardcode 
"Unknown error" string for strerror_r. (but not strerror_l)

I'll have a new webrev up soon that addresses the first comment and 
Rogers feedback.

	-Rob

>
> Best,
>
> christos
>


From aleksey.shipilev at oracle.com  Mon Sep 21 21:44:19 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Tue, 22 Sep 2015 00:44:19 +0300
Subject: Review: Indify String Concat JEP
In-Reply-To: <55FFE8FB.3090409@oracle.com>
References: <55FC2AF5.5010704@oracle.com> <55FFE8FB.3090409@oracle.com>
Message-ID: <56007A33.5070902@oracle.com>

Hi Alan,

Thanks for taking a look!

On 09/21/2015 02:24 PM, Alan Bateman wrote:
> On 18/09/2015 16:17, Aleksey Shipilev wrote:
>> Please review the submitted "Indify String Concat" JEP. It seems
>> complete to me: with working implementation, testing, and general
>> understanding of an issue. Start here:
>>    https://bugs.openjdk.java.net/browse/JDK-8085796

> On startup overhead then it might be amortized by the initialization of
> the module system as you suggest. It might be something else. We don't
> want to discourage use of lambda expressions or method reference so the
> first use of LF or whatever the initialization cost is will need to be
> worked on anyway.

I finally had time to follow up why default jdk9 regresses on startup
time, and this opened the way to properly re-estimate the startup costs
for Indify String Concat. It indeed points fingers at j.l.invoke, as we
figured a few months ago. See the "Startup considerations" section in
the notes:
  http://cr.openjdk.java.net/~shade/8085796/notes.txt

It might very well mean this is an inherent tax on all j.l.invoke users.
The good news is that this tax is not cumulative, and
only the first user pays for it. See:
  https://bugs.openjdk.java.net/browse/JDK-8086045


> I see the proposal is to exempt java.base. It probably could be finer
> grained than all of java.base but tricky to determine that subset. Even
> if all of java.base is exempt then I think there are initialization
> issues that need to be looked at. 

Our very first prototype was to hack java.lang.invoke to use explicit
StringBuilders instead of implicit concat to avoid the circularity and
see how hard it would be to provide a fine-grained exception rules. I
gave up trying to do this, because it metastasizes very quickly all
around java.base.

Therefore, I thought exempting java.base completely is a sane option.
It's just more hassle-free to let java.lang.invoke use anything
reachable in java.base.


> One other thing is that JEP 261 proposes the -Xoverride option (maybe it
> might be renamed to -Xpatch) for patching/override classes in java.base.
> Anyone using that to override classes used early in the startup would
> need to be careful to use the right javac option.

Okay, this sounds as the argument for -XstringConcat to exist in javac
flags :) Bootclasspathing an alien class into a cohesive module sounds
dangerous anyhow, and the sane thing we can do is to fail predictably.
The init circularities now end up with StackOverflowErrors.


> One other other on exemptions is that it might need to be javac too, at
> least for the JDK build where the newly built compiler runs with the
> boot JDK to compile everything else. I can't quite tell from a first
> read if the proposal is that javac emit indy by default, if not then
> this may be a non-issue.

In current implementation, javac emits "indyStatic" flavor by default,
and -XstringConcat can be used to switch the flavor back. I see little
value to make this future opt-in.

Yes, jdk.compiler also builds with "inline" flavor, that is, the same
current inline StringBuilder::append chains. This is a sample diff:
 http://cr.openjdk.java.net/~shade/8085796/root.patch

Thanks,
-Aleksey




From Roger.Riggs at Oracle.com  Mon Sep 21 22:09:10 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 21 Sep 2015 18:09:10 -0400
Subject: Processes and Windows handles question
Message-ID: <56008006.3000109@Oracle.com>

Hi,

I have a problem that could benefit from more Windows expertise than I 
currently have.

The proposal to use NIO Pipes to provide Selectable Channels as Peter 
Levert proposed in [1]
works fine on Linux.  On Windows, it seems to work ok when the output of 
the process is
handled as a channel but there is an anomaly when trying to use a 
Channel to send input to the process.

The NIO Pipe implemention on Windows conveniently uses a Socket to 
localhost: for the Pipe.
The handles for the underlying ends of the socket are appropriately sent 
to the CreateProcess API
when the process is created.

But the child processes produce errors such as:
  cat: -: Bad Address
or  bad parameter

I suspect that the child process is trying to read from the socket 
handle using an ordinary
file read.

In the other direction in which the output from the child is written to 
the network socket seem to work ok.
But I'm not sure if it is reliable.

Suggestions welcome on ways to setup the Socket so it would work or 
alternatives.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-selectable-4483582/

As Peter proposed, using Selectable channels is optional depending on 
the provider
and OS combinations.  The easy way out is to just say Channels do not 
work for sending
input to a process on Windows.

Thanks, Roger


[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-April/032830.html

[2] Webrev:http://cr.openjdk.java.net/~rriggs/webrev-selectable-4483582/



From joe.darcy at oracle.com  Tue Sep 22 01:22:14 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 21 Sep 2015 18:22:14 -0700
Subject: JDK 9 RFR of JDK-7130085 Port fdlibm hypot to Java
Message-ID: <5600AD46.5080401@oracle.com>

Hello,

Please review the next portion of the port of fdlibm to Java:

     JDK-7130085 Port fdlibm hypot to Java
     http://cr.openjdk.java.net/~darcy/7130085.0/

As before with pow, this isn't necessarily the end state of the code 
we'd like to stop at, but it should be sufficiently idiomatic Java for 
an initial port.

To make comparison against the original C algorithm easier, I listed the 
C version of hypot as the base file to compare FdLibm.java against.

Thanks,

-Joe


From joe.darcy at oracle.com  Tue Sep 22 02:44:44 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 21 Sep 2015 19:44:44 -0700
Subject: JDK 9 RFR of JDK-8134795: Port fdlibm pow to Java
In-Reply-To: <55FB8EA8.6060907@oracle.com>
References: <1142192764.1716914.1442527977806.JavaMail.yahoo@mail.yahoo.com>
	<55FB8EA8.6060907@oracle.com>
Message-ID: <5600C09C.5080207@oracle.com>

PS Bug

     JDK-8136874: Bug in port of fdlibm pow to Java
     https://bugs.openjdk.java.net/browse/JDK-8136874

has been filed and I've started working on a fix.

Thanks,

-Joe

On 9/17/2015 9:10 PM, joe darcy wrote:
> Hi Jeff,
>
> Thanks for the bug report; I'll take a look into this,
>
> -Joe
>
> On 9/17/2015 3:12 PM, Jeff Hain wrote:
>> Hi.
>>
>>
>>
>> >At long last, I've started the port of the C version of FDLIBM (freely
>> >distributable math library) from C to Java, beginning with the pow 
>> method:
>>
>>
>> I ran it through tests of my math lib (jafama),
>> and found the following issue:
>>
>> // ok
>>     StrictMath.pow(1.0000000000000004, 2.1E9) = 1.0000009325877754
>> FdLibm.Pow.compute(1.0000000000000004, 2.1E9) = 1.0000009325877754
>>
>> // overflows early
>>     StrictMath.pow(1.0000000000000004, 2.2E9) = 1.0000009769967388
>> FdLibm.Pow.compute(1.0000000000000004, 2.2E9) = Infinity
>>
>> // actual overflow is much further
>>     StrictMath.pow(1.0000000000000004, 1.59828858065033216E18) = 
>> 1.7976931348621944E308
>>     StrictMath.pow(1.0000000000000004, 1.59828858065033242E18) = Infinity
>>
>>
>>
>> Comparing the behavior of your code with that of Eric Blake's StrictMath
>> (the version I got has other issues, but not that one),
>> it could be corrected by replacing
>>
>> if (x_abs > 1.0) {
>>
>> with
>>
>> if (x_abs >= 1.0000009536743164) {
>>
>>
>>
>> After that modification, tests didn't show any difference with 
>> StrictMath.
>>
>>
>>
>> -Jeff
>>
>



From iris.clark at oracle.com  Tue Sep 22 03:51:56 2015
From: iris.clark at oracle.com (Iris Clark)
Date: Mon, 21 Sep 2015 20:51:56 -0700 (PDT)
Subject: RFR (xxs): Fix @bug in sun/misc/Version/Version.java
Message-ID: <a81bdd58-d70d-46fc-a251-bfe5d1482a7f@default>

Hi.

Please review the following 1 character change to address this bug:

    8136875: Fix @bug in sun/misc/Version/Version.java
    https://bugs.openjdk.java.net/browse/JDK-8136875

When 8134365 was fixed, it inadvertently used a `,` in the list of bugids in the @bug line.  This is the required diff:

--- a/test/sun/misc/Version/Version.java?
+++ b/test/sun/misc/Version/Version.java?
@@ -22,7 +22,7 @@?
??*/?

?/* @test?
- * @bug 6994413, 8134365?
+ * @bug 6994413 8134365?
??* @summary Check the JDK and JVM version returned by sun.misc.Version?
??* matches the versions defined in the system properties.?
??* Should use the API described in?JDK-8136651?when available?

The regression test now passes as expected.

Thanks,
iris


From mandy.chung at oracle.com  Tue Sep 22 03:54:28 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 21 Sep 2015 20:54:28 -0700
Subject: RFR (xxs): Fix @bug in sun/misc/Version/Version.java
In-Reply-To: <a81bdd58-d70d-46fc-a251-bfe5d1482a7f@default>
References: <a81bdd58-d70d-46fc-a251-bfe5d1482a7f@default>
Message-ID: <76AF2CB3-C8F6-434A-AC65-853DC6C0EF0C@oracle.com>


> On Sep 21, 2015, at 8:51 PM, Iris Clark <iris.clark at oracle.com> wrote:
> 
> Hi.
> 
> Please review the following 1 character change to address this bug:
> 
>    8136875: Fix @bug in sun/misc/Version/Version.java
>    https://bugs.openjdk.java.net/browse/JDK-8136875
> 
> When 8134365 was fixed, it inadvertently used a `,` in the list of bugids in the @bug line.  This is the required diff:
> 

Looks good.   Sorry I didn?t catch that in the previous review.

Mandy

> --- a/test/sun/misc/Version/Version.java 
> +++ b/test/sun/misc/Version/Version.java 
> @@ -22,7 +22,7 @@ 
>   */ 
> 
>  /* @test 
> - * @bug 6994413, 8134365 
> + * @bug 6994413 8134365 
>   * @summary Check the JDK and JVM version returned by sun.misc.Version 
>   * matches the versions defined in the system properties. 
>   * Should use the API described in JDK-8136651 when available 
> 
> The regression test now passes as expected.
> 
> Thanks,
> iris



From iris.clark at oracle.com  Tue Sep 22 04:14:05 2015
From: iris.clark at oracle.com (Iris Clark)
Date: Mon, 21 Sep 2015 21:14:05 -0700 (PDT)
Subject: RFR (xxs): Fix @bug in sun/misc/Version/Version.java
In-Reply-To: <76AF2CB3-C8F6-434A-AC65-853DC6C0EF0C@oracle.com>
References: <a81bdd58-d70d-46fc-a251-bfe5d1482a7f@default>
	<76AF2CB3-C8F6-434A-AC65-853DC6C0EF0C@oracle.com>
Message-ID: <5518db6d-16ea-458c-91a1-3deb0de0eb0c@default>

Thanks!
iris

-----Original Message-----
From: Mandy Chung 
Sent: Monday, September 21, 2015 8:54 PM
To: Iris Clark
Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
Subject: Re: RFR (xxs): Fix @bug in sun/misc/Version/Version.java


> On Sep 21, 2015, at 8:51 PM, Iris Clark <iris.clark at oracle.com> wrote:
> 
> Hi.
> 
> Please review the following 1 character change to address this bug:
> 
>    8136875: Fix @bug in sun/misc/Version/Version.java
>    https://bugs.openjdk.java.net/browse/JDK-8136875
> 
> When 8134365 was fixed, it inadvertently used a `,` in the list of bugids in the @bug line.  This is the required diff:
> 

Looks good.   Sorry I didn't catch that in the previous review.

Mandy

> --- a/test/sun/misc/Version/Version.java 
> +++ b/test/sun/misc/Version/Version.java 
> @@ -22,7 +22,7 @@ 
>   */ 
> 
>  /* @test 
> - * @bug 6994413, 8134365 
> + * @bug 6994413 8134365 
>   * @summary Check the JDK and JVM version returned by sun.misc.Version 
>   * matches the versions defined in the system properties. 
>   * Should use the API described in JDK-8136651 when available 
> 
> The regression test now passes as expected.
> 
> Thanks,
> iris



From forax at univ-mlv.fr  Tue Sep 22 06:08:19 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 22 Sep 2015 08:08:19 +0200 (CEST)
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <8F845D19-214F-4FB5-BA6B-0E48BB687AE2@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<CACzrW9B_dKnFUdAv1SCY5nfx_mmYxdSHBtGs5rqdj4JibD7P1A@mail.gmail.com>
	<673914291.466765.1442846732766.JavaMail.zimbra@u-pem.fr>
	<8F845D19-214F-4FB5-BA6B-0E48BB687AE2@oracle.com>
Message-ID: <518782667.635456.1442902099446.JavaMail.zimbra@u-pem.fr>

Hi  Paul, 
to summarize, there are a lot of codes that do bound checking in the JDK that report different kind of exceptions.

A way to retrofit most of then is to use a lambda to let the user code to choose its convention.
But because lambda creations are backed by invokedynamic, you can not retrofit
code that is used before the method handle mechanism is set up during the bootstraping of the JDK.

There are several kinds of bound checking, and i see no gain to force them to use the same function type.
Also, I have use a wildcard instead of a type variable given that it's an unchecked exception for the compiler.

For the simplest form of bound checking, 0 <= index < length, aka checkIndex, because there is only one index to report, i propose:
  public static void checkIndex(int index, int length, IntFunction<? extends RuntimeException> exceptionCreator)

For the form of that uses a size, 0 <= index < size <= length, aka checkFromIndexSize, as you said, let's use a BiFunction<Integer, Integer, ...>,
  public static void checkRange(int index, int size, int length, BiFunction<Integer, Integer, ? extends RuntimeException> exceptionCreator)
  
For the form that uses an offset, 0 <= index <= index + offset < length,
   public static void checkRangeWithOffset(int index, int offset, int length, BiFunction<Integer, Integer, ? extends RuntimeException> exceptionCreator)

Also, the documentation should be clear that if a lambda captures values from the context, the performance will be worst than inlining the check by hand.

regards,
R?mi

----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 21 Septembre 2015 17:46:07
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> 
> 
> On 21 Sep 2015, at 16:45, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> > I agree with Stephen.
> > 
> > Calling the function interface with the name ...Exception seems very wrong
> > to me.
> > 
> 
> Agreed, need to think of a better name. One solution is to remove it all
> together :-) see below.
> 
> 
> > The convention of ArrayIOOBE or StringIOOBE is to just report the bad index
> > with no further info,
> > currently with your code it's not possible to write
> >  checkIndex(index, ArrayIndexOutOuBoundException::new).
> > 
> > so the functional interface for checkIndex should be int -> Object or long
> > -> Object if you change ArrayIOOBE and StringIOOBE to store a long.
> > This functional Interface already exists under the name
> > java.util.function.LongFunction.
> > 
> 
> The friction here is trying to cater for the existing use-cases in the JDK,
> after a cursory 5 minute search you will find many conventions :-)
> 
> From the use-cases i have looked at so far I believe it?s possible to support
> nearly all with BiFunction<Integer, Integer, RuntimeException> (i started
> out with that in mind), in some cases a process of elimination can be used
> for reporting. Other use-cases could be supported with capture.
> 
> There is a use-case in AbstractStringBuilder that requires all three values,
> that is the only one i have found so far in the JDK. I would be interested
> to know if there are others and also if people are doing that in their own
> code too.
> 
> I would be happy to sacrifice the use-case in AbstractStringBuilder for using
> BiFunction<Integer, Integer, RuntimeException>, and add appropriate
> constructors or factory methods on the common exception types for method ref
> usage.
> 
> Paul.
> 
> > For the two other methods that checks several index, again the convention
> > is to report the bad index / size, so a LongFunction is enough too,
> > yes, it means that you can not check several index at once with things like
> > (a < 0) | (b < 0) but because the semantics you propose is different
> > from what is usually done, you will not be alble to use those methods
> > inside the JDK without introducing incompatibilities.
> > 
> > cheers,
> > R?mi
> 
> 


From martinrb at google.com  Tue Sep 22 06:43:32 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 21 Sep 2015 23:43:32 -0700
Subject: JDK-4290274 (timer) java.util.Timer.scheduleAtFixedRate() fails
	if the system time is changed
In-Reply-To: <560058B3.809@gmx.de>
References: <560058B3.809@gmx.de>
Message-ID: <CA+kOe09Z61zO6FYYcGTnOen2RgFOLjDTxsdxjBQR4V_5W9KPOQ@mail.gmail.com>

I added a comment to that bug

"""
There's some serious confusion about the various timer implementations in
the JDK.
The summary and component refer to java.util.Timer, but the test program is
all about javax.swing.Timer! And of course there's
ScheduledThreadPoolExecutor, which inspired fixes to javax.swing.Timer but
java.util.Timer has been left unchanged, still using
System.currentTimeMillis for everything.

Realistically, it's too late to fix java.util.Timer, and javax.swing.Timer
has already been fixed, but Josh's comments from 2004 are still food for
thought, which keeps me from closing this ancient bug.
"""

We cannot have an automated jtreg test so intrusive that the system clock
is changed.
A manual test is barely possible, but it's still pretty weird.



On Mon, Sep 21, 2015 at 12:21 PM, Sebastian Sickelmann <
sebastian.sickelmann at gmx.de> wrote:

> Hi,
>
> while looking through some bugs in JBS I found this[1] one.
>
> It seems to be that it is already solved. I tried the submitted example
> with jdk6,7,8 and
> it seems that it works since jdk7.
>
> So maybe the bug can be closed, like the one it relates to
>         JDK-5056544 javax.swing.timer stops after changing actual system
> time
>
> I created a headless swing based jtreg-test for JDK-4290274 but actually
> it would run
> only on linux(which can be changed) and must be started by a user that
> can change the time.
>
> Is it possible to integrate such a test in openjdk?
>
> -- Sebastian
>
> [0] https://bugs.openjdk.java.net/browse/JDK-4290274
>


From martinrb at google.com  Tue Sep 22 06:52:09 2015
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 21 Sep 2015 23:52:09 -0700
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection
	to discard output
In-Reply-To: <56004C69.1010606@oracle.com>
References: <55F2F37E.20101@Oracle.com>
	<644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
	<560042B2.4090409@oracle.com>
	<CA+kOe09tcvs2N8N=i0k_eqwO8kXyQVD-GiM23vfZC9=vyc-qwQ@mail.gmail.com>
	<56004C69.1010606@oracle.com>
Message-ID: <CA+kOe08dv+U0QKW81Cq1aTVtnno=_ok9DCy=MbZeyGC_hnCTeA@mail.gmail.com>

On Mon, Sep 21, 2015 at 11:28 AM, Roger Riggs <Roger.Riggs at oracle.com>
wrote:

> Hi Martin,
>
> On 09/21/2015 02:18 PM, Martin Buchholz wrote:
>
>
> I'm not sure that all operating systems where Java may run will have such
> a "null file" (does OS400?).
>
> True, but there are multiple ways to discard the output and it need not be
> via the null file,
> that's just easy on Unix and Windows.
> The Redirect.file() method is allowed to return null and I've updated the
> description to reinforce that for OS's that discard the output some other
> way.
>

That seems to contradict what I see here:
 +        /**
+         * Indicates that subprocess output will be discarded.
+         * The output is discarded by writing to the operating specific
+         * <em>null</em> file.
+         *
+         * <p>It will always be true that
+         * <pre> {@code
+         * Redirect.DISCARD.file() the filename appropriate for the
operating system &&
+         * Redirect.DISCARD.type() == Redirect.Type.WRITE &&
+         * Redirect.DISCARD.append() == false
+         * }</pre>
+         * @since 9
+         */
+        public static final Redirect DISCARD = new Redirect() {

I think there will be confusion if the "null file" can be null.


From dawid.weiss at gmail.com  Tue Sep 22 06:51:51 2015
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Tue, 22 Sep 2015 08:51:51 +0200
Subject: JDK 9 RFR of JDK-7130085 Port fdlibm hypot to Java
In-Reply-To: <5600AD46.5080401@oracle.com>
References: <5600AD46.5080401@oracle.com>
Message-ID: <CAM21Rt8jN0WMD7z_VkNZbKcmgkpRmWQM9Ne0Puh4E11R64sTvg@mail.gmail.com>

Not that I understand the math behind it, but out of curiosity I
looked and spotted a typo in:

> muti-precision

(unless it's some kind of complex IEEE-approved jargon for something I
have no idea about :).

Dawid

On Tue, Sep 22, 2015 at 3:22 AM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> Hello,
>
> Please review the next portion of the port of fdlibm to Java:
>
>     JDK-7130085 Port fdlibm hypot to Java
>     http://cr.openjdk.java.net/~darcy/7130085.0/
>
> As before with pow, this isn't necessarily the end state of the code we'd
> like to stop at, but it should be sufficiently idiomatic Java for an initial
> port.
>
> To make comparison against the original C algorithm easier, I listed the C
> version of hypot as the base file to compare FdLibm.java against.
>
> Thanks,
>
> -Joe


From martinrb at google.com  Tue Sep 22 07:06:18 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 22 Sep 2015 00:06:18 -0700
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <2A64901D-0FEF-4DA4-B99C-E13FC16775E1@oracle.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<2A64901D-0FEF-4DA4-B99C-E13FC16775E1@oracle.com>
Message-ID: <CA+kOe08PU3bJp4iHAFwKWs77PQxkN1DTh80zWR9udjSnQPzwyQ@mail.gmail.com>

The latest set of webrevs and bug reports has no known problems.
I tried to find all the "bug dups" that were awaiting this integration.

On Mon, Sep 21, 2015 at 12:21 PM, Paul Sandoz <paul.sandoz at oracle.com>
wrote:

> Hi Martin,
>
> Thanks so much for doing this.
>
> Chris and I will cherry pick the appropriate API changes required for CCC,
> which i believe only apply to the first three sub-tasks of JDK-8132960
> (Flow, CompletableFuture, and ForkJoin), but we should need to double check.
>
> We also need to be careful we have not hobbled some required differences
> needed for the JDK, i believe they are few but can be easy to miss.
>
> I will shepherd the JEP through the process, currently a draft in the
> submitted state waiting to move to candidate. We can work in parallel to
> that process, but should only push the changes after it has been targeted.
>
> Paul.
>
> On 21 Sep 2015, at 20:34, Martin Buchholz <martinrb at google.com> wrote:
>
> > This is the long-delayed and long-awaited bulk integration for jdk9 from
> jsr166 CVS.
> >
> > Find webrevs here:
> >
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
> >
> > Sorry about the extreme size and tardiness of this integration.
> >
> > As a review convenience, I provided a diff-wbB file that contains all
> the jsr166 integration changes using "hg diff -wbB" that ignores whitespace
> changes.
> >
> > We will need JPRT+specdiff+CCC from Oracle folks
> >
> > All changes are subtasks of:
> > https://bugs.openjdk.java.net/browse/JDK-8132960
>
>


From paul.sandoz at oracle.com  Tue Sep 22 08:09:56 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 22 Sep 2015 10:09:56 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <518782667.635456.1442902099446.JavaMail.zimbra@u-pem.fr>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<CACzrW9B_dKnFUdAv1SCY5nfx_mmYxdSHBtGs5rqdj4JibD7P1A@mail.gmail.com>
	<673914291.466765.1442846732766.JavaMail.zimbra@u-pem.fr>
	<8F845D19-214F-4FB5-BA6B-0E48BB687AE2@oracle.com>
	<518782667.635456.1442902099446.JavaMail.zimbra@u-pem.fr>
Message-ID: <F07FDFA6-6A49-4D82-B67C-9CBAB844C5B0@oracle.com>

Hi Remi,

On 22 Sep 2015, at 08:08, Remi Forax <forax at univ-mlv.fr> wrote:
> Hi  Paul,
> to summarize, there are a lot of codes that do bound checking in the JDK that report different kind of exceptions.
> 

Yes, and I suspect it is a similar state of affairs for code outside of the JDK too.


> A way to retrofit most of then is to use a lambda to let the user code to choose its convention.
> But because lambda creations are backed by invokedynamic, you can not retrofit
> code that is used before the method handle mechanism is set up during the bootstraping of the JDK.
> 

We can retrofit, but we will not use lambda expressions or method refs in those cases.


> There are several kinds of bound checking, and i see no gain to force them to use the same function type.
> Also, I have use a wildcard instead of a type variable given that it's an unchecked exception for the compiler.
> 
> For the simplest form of bound checking, 0 <= index < length, aka checkIndex, because there is only one index to report, i propose:
>  public static void checkIndex(int index, int length, IntFunction<? extends RuntimeException> exceptionCreator)
> 

I disagree, we need BiFunction. I have eyeballed a sufficient number of use-cases that report index and length in the exception message.


> For the form of that uses a size, 0 <= index < size <= length, aka checkFromIndexSize, as you said, let's use a BiFunction<Integer, Integer, ...>,
>  public static void checkRange(int index, int size, int length, BiFunction<Integer, Integer, ? extends RuntimeException> exceptionCreator)
> 
> For the form that uses an offset, 0 <= index <= index + offset < length,
>   public static void checkRangeWithOffset(int index, int offset, int length, BiFunction<Integer, Integer, ? extends RuntimeException> exceptionCreator)
> 
> Also, the documentation should be clear that if a lambda captures values from the context, the performance will be worst than inlining the check by hand.
> 

Yes, i can write some api note. FWIW for the sub-range checks it probably matters less as those are often followed by some bulk operation.

Paul.


From paul.sandoz at oracle.com  Tue Sep 22 08:23:50 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 22 Sep 2015 10:23:50 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
Message-ID: <DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>

Hi Jason,

Not a bad idea, after some I tend to agree.

I was hesitating for two reasons, one is that they might be harder to find, and the other is not all reported exceptions will be instances of IndexOutOfBoundsException. However, as you point out not all bound checks are related to arrays and i think that is more so the case than exceptions related to IndexOutOfBoundsException.

Paul.

On 21 Sep 2015, at 21:17, Jason Mehrens <jason_mehrens at hotmail.com> wrote:

> Hi Paul,
> 
> Would it make sense to add these methods to the IndexOutOfBoundsException class itself or is there a compatibility worry?  Seems better to use the room in IndexOutOfBoundsException class file and keep these methods out of the Arrays class.  It is also odd that in the future the LinkedList would depend on the Arrays class to check bounds.
> 
> Jason
> 
> ________________________________________
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Paul Sandoz <paul.sandoz at oracle.com>
> Sent: Monday, September 21, 2015 8:42 AM
> To: core-libs-dev
> Subject: RFR 8135248: Add utility methods to check indexes and ranges
> 
> Hi,
> 
> Please review the following which adds methods to Arrays to check indexes and ranges:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8135248
>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
> 
> The original motivation was an intrinsic method, Arrays.checkIndex, to check if an index is within bounds. Such an intrinsic guides HotSpot towards better optimisations for bounds checks using one unsigned comparison instead of two signed comparisons, and better eliding of integer to long conversions when an index is used to create an offset for Unsafe access. The end result is more efficient array access especially so from within unrolled loops. The VarHandles work will use Arrays.checkIndex for array access.
> 
> A follow up issue [1] will track the intrinsification of Arrays.checkIndex.
> 
> We thought it would be opportunistic to support two further common use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> checkFromIndexSize. There is no current plan to intrinsify these methods.
> 
> Bounds checking is not difficult but it can be easy to make trivial mistakes. Thus it is advantageous to consolidate such checks not just from an optimization perspective but from a correctness and security/integrity perspective.
> 
> There are many areas in the JDK where such checks are performed. A follow up issue [2] will track updates to use the new methods.
> 
> The main challenge for these new methods is to design in such a way that
> 
> 1) existing use-cases can still report the same set of exceptions with the same messages;
> 2) method byte code size is not unduly increased, thus perturbing inlining; and
> 3) there is a reasonable path for any future support of long indexes.
> 
> Paul.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> [2] https://bugs.openjdk.java.net/browse/JDK-8135250



From paul.sandoz at oracle.com  Tue Sep 22 10:40:03 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 22 Sep 2015 12:40:03 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
Message-ID: <0ED64734-7F73-4E8B-9900-7B444E8629C8@oracle.com>

Hi,

Thanks for all the feedback.

Here is a new webrev:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/webrev/

Changes:

- Move check methods to IndexOutOfBoundsException

- Use BiFunction, rather than a specific exception mapping function.

- Add check methods that do not accept an exception mapping function and throw IndexOutOfBoundsException.

- Add 2 argument constructors to Array/String/IndexOutOfBoundsException, thus allowing support for method refs.

Remi, i left the generic signatures as is, i am presuming there is an advantage to naming T, rather than using a wildcard e.g. IDEs could use that information (although IntelliJ does not appear to do so at the moment).

Paul.

On 21 Sep 2015, at 15:42, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:

> Hi,
> 
> Please review the following which adds methods to Arrays to check indexes and ranges:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8135248
>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
> 
> The original motivation was an intrinsic method, Arrays.checkIndex, to check if an index is within bounds. Such an intrinsic guides HotSpot towards better optimisations for bounds checks using one unsigned comparison instead of two signed comparisons, and better eliding of integer to long conversions when an index is used to create an offset for Unsafe access. The end result is more efficient array access especially so from within unrolled loops. The VarHandles work will use Arrays.checkIndex for array access.
> 
> A follow up issue [1] will track the intrinsification of Arrays.checkIndex.
> 
> We thought it would be opportunistic to support two further common use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> checkFromIndexSize. There is no current plan to intrinsify these methods.
> 
> Bounds checking is not difficult but it can be easy to make trivial mistakes. Thus it is advantageous to consolidate such checks not just from an optimization perspective but from a correctness and security/integrity perspective.
> 
> There are many areas in the JDK where such checks are performed. A follow up issue [2] will track updates to use the new methods.
> 
> The main challenge for these new methods is to design in such a way that
> 
> 1) existing use-cases can still report the same set of exceptions with the same messages;
> 2) method byte code size is not unduly increased, thus perturbing inlining; and
> 3) there is a reasonable path for any future support of long indexes.
> 
> Paul.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> [2] https://bugs.openjdk.java.net/browse/JDK-8135250



From Roger.Riggs at Oracle.com  Tue Sep 22 13:27:36 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 22 Sep 2015 09:27:36 -0400
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection
	to discard output
In-Reply-To: <CA+kOe08dv+U0QKW81Cq1aTVtnno=_ok9DCy=MbZeyGC_hnCTeA@mail.gmail.com>
References: <55F2F37E.20101@Oracle.com>
	<644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
	<560042B2.4090409@oracle.com>
	<CA+kOe09tcvs2N8N=i0k_eqwO8kXyQVD-GiM23vfZC9=vyc-qwQ@mail.gmail.com>
	<56004C69.1010606@oracle.com>
	<CA+kOe08dv+U0QKW81Cq1aTVtnno=_ok9DCy=MbZeyGC_hnCTeA@mail.gmail.com>
Message-ID: <56015748.5020504@Oracle.com>

Hi Martin,

Please take another look?
The language has been updated so it does not require discarding using a 
file.

The URI of the webrev changed also:
    http://cr.openjdk.java.net/~rriggs/webrev-discard-8132541/

Thanks, Roger




On 9/22/2015 2:52 AM, Martin Buchholz wrote:
>
>
> On Mon, Sep 21, 2015 at 11:28 AM, Roger Riggs <Roger.Riggs at oracle.com 
> <mailto:Roger.Riggs at oracle.com>> wrote:
>
>     Hi Martin,
>
>     On 09/21/2015 02:18 PM, Martin Buchholz wrote:
>>
>>     I'm not sure that all operating systems where Java may run will
>>     have such a "null file" (does OS400?).
>     True, but there are multiple ways to discard the output and it
>     need not be via the null file,
>     that's just easy on Unix and Windows.
>     The Redirect.file() method is allowed to return null and I've
>     updated the description to reinforce that for OS's that discard
>     the output some other way.
>
>
> That seems to contradict what I see here:
>  +        /**
> +         * Indicates that subprocess output will be discarded.
> +         * The output is discarded by writing to the operating specific
> +         * <em>null</em> file.
> +         *
> +         * <p>It will always be true that
> +         * <pre> {@code
> +         * Redirect.DISCARD.file() the filename appropriate for the 
> operating system &&
> +         * Redirect.DISCARD.type() == Redirect.Type.WRITE &&
> +         * Redirect.DISCARD.append() == false
> +         * }</pre>
> +         * @since 9
> +         */
> +        public static final Redirect DISCARD = new Redirect() {
>
> I think there will be confusion if the "null file" can be null.



From brian.burkhalter at oracle.com  Tue Sep 22 15:22:22 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 22 Sep 2015 08:22:22 -0700
Subject: JDK 9 RFR of JDK-7130085 Port fdlibm hypot to Java
In-Reply-To: <CAM21Rt8jN0WMD7z_VkNZbKcmgkpRmWQM9Ne0Puh4E11R64sTvg@mail.gmail.com>
References: <5600AD46.5080401@oracle.com>
	<CAM21Rt8jN0WMD7z_VkNZbKcmgkpRmWQM9Ne0Puh4E11R64sTvg@mail.gmail.com>
Message-ID: <3C94BDE7-1742-40A2-AEC1-1B33D2534C15@oracle.com>

Dawid,

Multi-precision is one of several more or less interchangeable terms to indicate that the precision of a value is limited by the amount of memory available as opposed to the size of the primitive data type. For example in the case of Java, large integers are represented internally to the BigInteger class by arrays of integral values. See for example [1] for more information and links.

Regards,

Brian

[1] https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic

On Sep 21, 2015, at 11:51 PM, Dawid Weiss <dawid.weiss at gmail.com> wrote:

> Not that I understand the math behind it, but out of curiosity I
> looked and spotted a typo in:
> 
>> muti-precision
> 
> (unless it's some kind of complex IEEE-approved jargon for something I
> have no idea about :).



From joe.darcy at oracle.com  Tue Sep 22 15:40:30 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 22 Sep 2015 08:40:30 -0700
Subject: JDK 9 RFR of JDK-7130085 Port fdlibm hypot to Java
In-Reply-To: <CAM21Rt8jN0WMD7z_VkNZbKcmgkpRmWQM9Ne0Puh4E11R64sTvg@mail.gmail.com>
References: <5600AD46.5080401@oracle.com>
	<CAM21Rt8jN0WMD7z_VkNZbKcmgkpRmWQM9Ne0Puh4E11R64sTvg@mail.gmail.com>
Message-ID: <5601766E.4000504@oracle.com>


On 9/21/2015 11:51 PM, Dawid Weiss wrote:
> Not that I understand the math behind it, but out of curiosity I
> looked and spotted a typo in:
>
>> muti-precision
> (unless it's some kind of complex IEEE-approved jargon for something I
> have no idea about :).

No; just a typo in the original pow sources :-)

Thanks,

-Joe



From martinrb at google.com  Tue Sep 22 16:25:43 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 22 Sep 2015 09:25:43 -0700
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection
	to discard output
In-Reply-To: <56015748.5020504@Oracle.com>
References: <55F2F37E.20101@Oracle.com>
	<644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
	<560042B2.4090409@oracle.com>
	<CA+kOe09tcvs2N8N=i0k_eqwO8kXyQVD-GiM23vfZC9=vyc-qwQ@mail.gmail.com>
	<56004C69.1010606@oracle.com>
	<CA+kOe08dv+U0QKW81Cq1aTVtnno=_ok9DCy=MbZeyGC_hnCTeA@mail.gmail.com>
	<56015748.5020504@Oracle.com>
Message-ID: <CA+kOe08crMUYSrbz3p3R8=CPu0G6KFAx0dLFC-Zi5V+QAatiQQ@mail.gmail.com>

I approve the latest webrev.

But can't-stop-nitpicking Martin would write instead of

+         * The output may be discarded by writing to the operating
system specific
+         * <em>null</em> file.


"""A typical implementation discards the output by writing to an operating
system specific "null file"."""

And I'd have a chat with Alan about File#nullSink().


On Tue, Sep 22, 2015 at 6:27 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Martin,
>
> Please take another look?
> The language has been updated so it does not require discarding using a
> file.
>
> The URI of the webrev changed also:
>    http://cr.openjdk.java.net/~rriggs/webrev-discard-8132541/
>
> Thanks, Roger
>
>
>
>
>
> On 9/22/2015 2:52 AM, Martin Buchholz wrote:
>
>
>
> On Mon, Sep 21, 2015 at 11:28 AM, Roger Riggs <Roger.Riggs at oracle.com>
> wrote:
>
>> Hi Martin,
>>
>> On 09/21/2015 02:18 PM, Martin Buchholz wrote:
>>
>>
>> I'm not sure that all operating systems where Java may run will have such
>> a "null file" (does OS400?).
>>
>> True, but there are multiple ways to discard the output and it need not
>> be via the null file,
>> that's just easy on Unix and Windows.
>> The Redirect.file() method is allowed to return null and I've updated the
>> description to reinforce that for OS's that discard the output some other
>> way.
>>
>
> That seems to contradict what I see here:
>  +        /**
> +         * Indicates that subprocess output will be discarded.
> +         * The output is discarded by writing to the operating specific
> +         * <em>null</em> file.
> +         *
> +         * <p>It will always be true that
> +         * <pre> {@code
> +         * Redirect.DISCARD.file() the filename appropriate for the
> operating system &&
> +         * Redirect.DISCARD.type() == Redirect.Type.WRITE &&
> +         * Redirect.DISCARD.append() == false
> +         * }</pre>
> +         * @since 9
> +         */
> +        public static final Redirect DISCARD = new Redirect() {
>
> I think there will be confusion if the "null file" can be null.
>
>
>


From daniel.fuchs at oracle.com  Tue Sep 22 16:27:32 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 22 Sep 2015 18:27:32 +0200
Subject: RFR: 8033661: readConfiguration does not cleanly reinitialize the
	logging system
In-Reply-To: <EBE38931-6036-4908-8C50-9F7C8B34E729@oracle.com>
References: <55F06497.5010300@oracle.com>
	<1F185ECE-B5B1-4175-ABAA-B86FCD0861EC@oracle.com>
	<55F6F517.8000100@oracle.com>
	<EBE38931-6036-4908-8C50-9F7C8B34E729@oracle.com>
Message-ID: <56018174.1090603@oracle.com>

Hi Mandy,

Here is a new webrev [1] - thanks a lot for all the time you
spent working with me on the API documentation!

As you suggested:

The specification of how readConfiguration uses system
properties to find the configuration has been
moved from the class-level documentation to the method
documentation.
The behaviour of readConfiguration has been clarified,
in particular with respect to what it does (or does not
do) with existing loggers.
The documentation of reset() has also been clarified
with respect to its effect on existing loggers.

[These are only clarification of the spec, there's no behavior
  change]

The specification of the new updateConfiguration has been
improved and made more consistent.

I have also implemented the few internal variable/class/method
renaming you suggested.

[1] webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.02

best regards,

-- daniel

On 17/09/15 06:52, Mandy Chung wrote:
>
>> On Sep 14, 2015, at 9:25 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>> So with that in mind, I have slightly altered the @apiNotes:
>>
>> in readConfiguration():
>>
>>      * @apiNote {@code readConfiguration} is principally useful for
>>      *    establishing the LogManager primordial configuration.
>>      *    <p>
>>      *    Calling this method directly from the application code after the
>>      *    LogManager has been initialized is discouraged.
>>
>
> What about:
>
> This method is intended for LogManager primordial configuration.  Use
> the {@link #updateConfiguration} method to reload configuration after
> the LogManager has been initialized.
>
> I think it?s worth cleaning up the specification about logging configuration - moving the rules about locating the configuration properties from the class javadoc to the specification of the readConfiguration method
>
> for example, move these 3 paragraphs
>    If the "java.util.logging.config.class" property is set, ?..
>    If "java.util.logging.config.class" property is not set, ..
>    If neither of these properties is defined
>
>   to replace "The same rules are used for locating the configuration properties as are used at startup?..?.
>
> Note that readConfiguration() reads from system property.
>
>>
>> The rationale is that an application which needs to establish
>> a custom configuration should probably use the
>> {@code "java.util.logging.config.class"} property, and
>> call LogManager.readConfiguration(InputStream) from there,
>> as hinted in the class-level documentation.
>>
>> in readConfiguration(InputStream):
>
> This will not reinitialize the logging configuration specified in the "java.util.logging.config.class? system property.  So I think moving the rules to locate logging configuration to readConfiguration() method will help.
>
> What does this line do:
>    String names[] = parseClassNames("config?);
>
>
>>
>>      * @apiNote {@code readConfiguration} is principally useful for applications
>>      *    which use the {@code "java.util.logging.config.class"} property
>>      *    to establish their own custom configuration.
>>      *    <p>
>>      *    Calling this method directly from the application code after the
>>      *    LogManager has been initialized is discouraged.
>
> Since it?s not deprecated, instead of a note to discourage using it, it seems to be more useful to describe the behavior of this method and issues with the handler etc after reset.
>
> Then recommend to use the {@link #updateConfiguration} method to reload configuration after
> the LogManager has been initialized.
>
>>
>>>
>>> 1749      * Updates an existing configuration.
>>>
>>> We should specify what ?existing configuration? is.
>>> If ?java.util.logging.config.class? is set and it?s instantiated successfully,
>>> readConfiguration will not read from any configuration file.
>>> updateConfiguration only reads the config file regardless
>>> if ?java.util.logging.config.class? is set.
>>
>> I updated the doc for updateConfiguration(mapper):
>>
>>   :
>>
>
> I think this method should only read the logging config file if the "java.util.logging.config.class? property is not set.  If set, it should be instantiated successfully and that will never read the logging config file.
>
> The spec should say:
>
> Update the logging configuration.  It will read the logging properties file that was read at startup time.
>
> If the "java.util.logging.config.file" system property is set, the logging configuration is read from the path specified in the property value.  If the "java.util.logging.config.file" system property is not set, then the default configuration is used.
>
> Question:
> If ?java.util.logging.config.class? is set, should it throw an exception instead of silently continue or read from the default configuration.
>
> Should it re-read the system property at runtime or cached value?  What if  ?java.util.logging.config.file? is not set at startup but later set at runtime after LogManager was initialized?
>
>>
>>
>>>
>>> 1761      * @param remapper
>>>
>>> ?re? probably not needed here.   I think ?mapper? should work.
>>
>> OK. Should I still use the term of 'remapping function' then?
>> Or does that become 'mapping function' too?
>>
>
> Can it simply refer it as ?a function mapping from a pair of the current value and the new value of a key to the value to be applied"
>
> What about something like this:
>
> mapper - a functional interface that takes a configuration key and returns a function that takes the value in the current configuration and the value in the given configuration as parameters and produces the actual value to be applied. If the mapper is null, or the function the mapper returns is null, then the value in the given configuration will be the new value. A null value passed as parameter to the function indicates that no value was present in the corresponding configuration.
>
> Another way can define some variables to represent all these values and functions so that the specification can refer to these variables instead.  I can work with you on the specification.
>
>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.01/
>>
>
> Implementation side - looks okay.  Some comments:
>
> I found some VisitedLoggers methods unnecessary.  It may help if we can change
>    VisitedLoggers.test(Logger) - name can be obtained from Logger.getName()
>    VisitedLoggers.
>
> Instead of calling VisitedLoggers.of(null), it seems more explicit to call VisitedLogger.NEVER (or FALSE)
>
> Is it useful to have ModType.EQUAL or SAME and non null value guaranteed.
>
> Perhaps time to change LoggerContext.getLoggerNames to return Set<String>.
>
> ConfigurationProperties - it?s an enum, should it be ConfigurationProperty instead?  ConfigProperty might work too.
>
> ConfigurationProperties.isChanging method - would ?compare? and ?equals? work here?  Using some commonly used method names will help readers to understand the code easier.
>
> final List<Logger> tmp = cxs.isEmpty() ?.
> - would ?loggers? work here - anything better than tmp?  It?s actually the list of candidate loggers to be updated with the new configuration properties.
>
> There are several words referenced ?reestablished?, ?reinitialized?, ?update?.  It?d help if the same word is used consistently in the specification and comment.
>
> I haven?t reviewed the tests yet.
> Mandy
>
>



From paul.sandoz at oracle.com  Tue Sep 22 16:30:09 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 22 Sep 2015 18:30:09 +0200
Subject: Array equality, comparison and mismatch
Message-ID: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com>

Hi,

Please review the following which adds methods to Arrays for performing equality, comparison and mismatch:

  https://bugs.openjdk.java.net/browse/JDK-8033148
  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html

The motivation behind this is the use of Unsafe in popular libraries and frameworks to speed up the lexicographical comparison of byte arrays.

This issue focuses on the API and functional implementations. A follow up issue [1] tracks updating the implementations to use a common method that leverages Unsafe to improve performance. A further issue [2] tracks the intrinsification of that common method to support operating on > 64 bits in width and further improve performance. A further issue, yet to be created, will follow up on updating existing JDK code to use the public and/or internal methods where appropriate. Example candidates include String (compareTo, perhaps add a mismatch method and possibly reviewing existing intrinsics, including those for compact Strings), and managed and direct Buffers.

So far i have only documented the new methods operating on byte[], as that will act as the template for the other methods.

Some points:

- Methods operating on Object[] will compare Object elements using Object.equals or associated comparators (as is the case for the existing equals method operating on Object[]).

- Methods operating on float[] or double[] will check such array elements for equality using the IEEE bit layout  (as is the case for the existing equals method operating on float[] or double[]).

- Primitive array element comparison will be performed as if by the boxed primitive type?s compare or compareUnsigned method.

- Range-accepting methods do not support null array values.

- Non-range and range-accepting mismatch methods do not support null array values. (What value should be returned when a mismatch is performed on a null array and an empty array)?

- Speculation: it may be possible that Project Valhalla will enable us to ?compress? down methods of certain groups to one ?template? method. Even if that is not possible i am not overly concerned about the number of methods added, which represents the maximum set. We could reduce them without a fundamental loss of functionality, but that might have a ?semantic? loss requiring developers to roll their own wrappers.

Thanks,
Paul.

[1]  https://bugs.openjdk.java.net/browse/JDK-8136924
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/

[2] https://bugs.openjdk.java.net/browse/JDK-8044082



From michael.haupt at oracle.com  Tue Sep 22 17:10:58 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Tue, 22 Sep 2015 19:10:58 +0200
Subject: RFR(S): 8136931: more fine-grained condition checking for BMH species
	creation
Message-ID: <F1FA637C-6A10-4353-8436-4D42A7BBEA95@oracle.com>

Dear all,

please review this change.
Issue: https://bugs.openjdk.java.net/browse/JDK-8136931
Webrev: http://cr.openjdk.java.net/~mhaupt/8136931/webrev.00

This is actually a change to improve error reporting for identifying the issue causing https://bugs.openjdk.java.net/browse/JDK-8131129, turning assertions into actual checks. As the issue 8131129 is intermittent and cannot be easily reproduced, the scope of additional tracing should be minimal. Enabling all assertions, even for the BoundMethodHandle class, is not helpful.

This patch will be removed once the issue itself has been addressed.

Thanks,

Michael

-- 

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



From sundararajan.athijegannathan at oracle.com  Tue Sep 22 17:15:17 2015
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Tue, 22 Sep 2015 22:45:17 +0530
Subject: RFR(S): 8136931: more fine-grained condition checking for BMH
	species creation
In-Reply-To: <F1FA637C-6A10-4353-8436-4D42A7BBEA95@oracle.com>
References: <F1FA637C-6A10-4353-8436-4D42A7BBEA95@oracle.com>
Message-ID: <56018CA5.9070704@oracle.com>

+1

-Sundar

On 9/22/2015 10:40 PM, Michael Haupt wrote:
> Dear all,
>
> please review this change.
> Issue: https://bugs.openjdk.java.net/browse/JDK-8136931
> Webrev: http://cr.openjdk.java.net/~mhaupt/8136931/webrev.00
>
> This is actually a change to improve error reporting for identifying the issue causing https://bugs.openjdk.java.net/browse/JDK-8131129, turning assertions into actual checks. As the issue 8131129 is intermittent and cannot be easily reproduced, the scope of additional tracing should be minimal. Enabling all assertions, even for the BoundMethodHandle class, is not helpful.
>
> This patch will be removed once the issue itself has been addressed.
>
> Thanks,
>
> Michael
>



From paul.sandoz at oracle.com  Tue Sep 22 17:54:31 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 22 Sep 2015 19:54:31 +0200
Subject: RFR(S): 8136931: more fine-grained condition checking for BMH
	species creation
In-Reply-To: <F1FA637C-6A10-4353-8436-4D42A7BBEA95@oracle.com>
References: <F1FA637C-6A10-4353-8436-4D42A7BBEA95@oracle.com>
Message-ID: <2E9BF040-B751-4C37-A02D-1C3CB367D747@oracle.com>


On 22 Sep 2015, at 19:10, Michael Haupt <michael.haupt at oracle.com> wrote:

> Dear all,
> 
> please review this change.
> Issue: https://bugs.openjdk.java.net/browse/JDK-8136931
> Webrev: http://cr.openjdk.java.net/~mhaupt/8136931/webrev.00
> 
> This is actually a change to improve error reporting for identifying the issue causing https://bugs.openjdk.java.net/browse/JDK-8131129, turning assertions into actual checks. As the issue 8131129 is intermittent and cannot be easily reproduced, the scope of additional tracing should be minimal. Enabling all assertions, even for the BoundMethodHandle class, is not helpful.
> 

Does enabling assertions makes the problem harder to reproduce, and/or you need some more readable output?


> This patch will be removed once the issue itself has been addressed.
> 

+1

Suggest adding a comment to stating this is a temporary property that will be removed:

  54     static final boolean OBSERVE_BMH_SPECIES_CREATION;

Paul.


From kumar.x.srinivasan at oracle.com  Tue Sep 22 20:21:08 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 22 Sep 2015 13:21:08 -0700
Subject: RFR: JDK-8073187: Unexpected side effect in Pack200
Message-ID: <5601B834.60900@oracle.com>

Hello,

Pack200 converts the timestamps to UTC for the pack200 archive format,
  in order to do so,  the default TimeZone was set to UTC, while reading 
and
writing archives. This is problematic in a multi threaded environment.

With the fix for JDK-8075526 in place, the pack200 code is refactored
to use the new Jar/Zip APIs, and eliminates issues arising from pack200
setting the default TimeZone.

http://cr.openjdk.java.net/~ksrini/8073187/webrev.0/

Thanks
Kumar



From michael.haupt at oracle.com  Tue Sep 22 20:43:03 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Tue, 22 Sep 2015 22:43:03 +0200
Subject: RFR(S): 8136931: more fine-grained condition checking for BMH
	species creation
In-Reply-To: <2E9BF040-B751-4C37-A02D-1C3CB367D747@oracle.com>
References: <F1FA637C-6A10-4353-8436-4D42A7BBEA95@oracle.com>
	<2E9BF040-B751-4C37-A02D-1C3CB367D747@oracle.com>
Message-ID: <24DA46F1-B267-48CC-9FB3-F282D5CCDB2E@oracle.com>

Hi Paul,

> Am 22.09.2015 um 19:54 schrieb Paul Sandoz <paul.sandoz at oracle.com>:
>> This is actually a change to improve error reporting for identifying the issue causing https://bugs.openjdk.java.net/browse/JDK-8131129, turning assertions into actual checks. As the issue 8131129 is intermittent and cannot be easily reproduced, the scope of additional tracing should be minimal. Enabling all assertions, even for the BoundMethodHandle class, is not helpful.
> 
> Does enabling assertions makes the problem harder to reproduce, and/or you need some more readable output?

both. I haven't been able to reproduce the problem *at all* (it does turn up every now and then, but never when I want it to), so I would like to expose it to the testing infrastructure to increase the likelihood. I also want to know what precisely went wrong; hence the detailed exception throwing.

>> This patch will be removed once the issue itself has been addressed.
> 
> +1
> 
> Suggest adding a comment to stating this is a temporary property that will be removed:
> 
>  54     static final boolean OBSERVE_BMH_SPECIES_CREATION;

Thank you; I will add this comment before pushing.

Best,

Michael

-- 

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



From mandy.chung at oracle.com  Tue Sep 22 23:02:34 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 22 Sep 2015 16:02:34 -0700
Subject: RFR: 8033661: readConfiguration does not cleanly reinitialize
	the logging system
In-Reply-To: <56018174.1090603@oracle.com>
References: <55F06497.5010300@oracle.com>
	<1F185ECE-B5B1-4175-ABAA-B86FCD0861EC@oracle.com>
	<55F6F517.8000100@oracle.com>
	<EBE38931-6036-4908-8C50-9F7C8B34E729@oracle.com>
	<56018174.1090603@oracle.com>
Message-ID: <5601DE0A.9060707@oracle.com>



On 09/22/2015 09:27 AM, Daniel Fuchs wrote:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.02

Looking quite good.  Thanks for making the change.

Below are mostly javadoc comments and some minor implementation comments.

1474      * which should be in {@linkplain java.util.Properties properties file} format.

Would it be better to state this above in @throws IOException:

IOException if there are problems reading from the stream or
the given stream is not in Properties format

1484      * existing loggers that have a level property specified in the new
1485      * configuration stream

s/the new configuration stream/the given input stream/

1491      * methods instead.

s/methods/method/

updateConfiguration(Function) - slight reorg of the sentences:

      * Updates the logging configuration.
      * <p>
      * If the "java.util.logging.config.file" system property is set,
      * then the property value specifies the properties file to be read
      * as the new configuration. Otherwise, the LogManager default
      * configuration is used.
      * The default configuration is typically loaded from the
      * properties file "{@code conf/logging.properties}" in the Java installation
      * directory.
      * This method reads the new configuration and calls the {@link
      * #updateConfiguration(java.io.InputStream, java.util.function.Function)
      * updateConfiguration(ins, mapper)} method to
      * update the configuration.
      *
      * @apiNote
      * This method updates the logging configuration from reading
      * a properties file and ignores the "java.util.logging.config.class"
      * system property.  The "java.util.logging.config.class" property is
      * only used by the readConfiguration method to load a custom configuration
      * class as an initial configuration.

1774      *   For each configuration key <i>k</i>,
    Could simply be "For each {@code k},"

- do you want italic for all occurrance?  Maybe just the first occurrance
   and @code for the subsequent ones.

1780      *   A {@code null} value for <i>v</i>  indicates that there should be no
1781      *   value associated with <i>k</i> in the resulting configuration.

This sentence can be combined with line 1772-1773 as follows:

returns a function <i>f(o,n)</i> whose returnedvalue will be
applied to the resulting configuration, or {@code null}
to indicate that the property {@code k}  will not be added
in the resulting configuration.

Also @param mapper - need to say "mapper may be null"

Same comment applies to @param in the other updateConfiguration method.


1825      * then <i>v = f(o,n)</i> is the
1826      * resulting value (i.e. the value that will be associated with
1827      * <i>k</i> in the resulting configuration).

Might be something like this:

then <i>v = f(o,n)</i> is the returned  value.
If v is not null, the property k with value v will be added in
the resulting configuration.  Otherwise, it will not be added.

1842      * listener}

Should it be "listener(s)"

2018             // Builds a TreeSet of all (old and new) property names.
2030                         .forEachOrdered(k -> ConfigProperty

Is the ordering matter here?

2071                     if (l == null) continue;
2072                     if (!visited.test(l)) {

Nit: can be combined in one line
    if (l != null && !visited.test(l)) {

ah - I saw that is used in line 2166

New tests: I only skimmed through them. They are good and covers complex 
scenarios.  For new methods like this, I generally like to see simple 
and small unit tests to be added that are easy for readers to 
understand.  For example, some sample properties files and check the 
resulting configuration using LogManager.getProperty. You already have 
many test cases covered.  I didn't want to add more works but it'd be 
really nice to see simple small unit tests.  Maybe refactor 
UpdateConfigurationTest.

Mandy



From forax at univ-mlv.fr  Tue Sep 22 23:18:19 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 23 Sep 2015 01:18:19 +0200 (CEST)
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <0ED64734-7F73-4E8B-9900-7B444E8629C8@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<0ED64734-7F73-4E8B-9900-7B444E8629C8@oracle.com>
Message-ID: <1086772691.995036.1442963899414.JavaMail.zimbra@u-pem.fr>

Hi Paul,



----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 22 Septembre 2015 12:40:03
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> 
> Hi,
> 
> Thanks for all the feedback.
> 
> Here is a new webrev:
> 
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/webrev/
> 
> Changes:
> 
> - Move check methods to IndexOutOfBoundsException
> 
> - Use BiFunction, rather than a specific exception mapping function.
> 
> - Add check methods that do not accept an exception mapping function and
> throw IndexOutOfBoundsException.

I still think that you should not use null as Stephen noticed,
what's wrong with writing checkIndex like this ?

  int checkIndex(int index, int length) throws IndexOutOfBoundsException {
    return checkIndex(index, length, IndexOutOfBoundsException::new);
  }

> 
> - Add 2 argument constructors to Array/String/IndexOutOfBoundsException, thus
> allowing support for method refs.
> 
> Remi, i left the generic signatures as is, i am presuming there is an
> advantage to naming T, rather than using a wildcard e.g. IDEs could use that
> information (although IntelliJ does not appear to do so at the moment).

I don't get it. Why it's important for an IDE to know that a code throws a precise *runtime* exception. Any codes can throw any runtime exceptions.

> 
> Paul.


R?mi

> 
> On 21 Sep 2015, at 15:42, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
> > Hi,
> > 
> > Please review the following which adds methods to Arrays to check indexes
> > and ranges:
> > 
> >  https://bugs.openjdk.java.net/browse/JDK-8135248
> >  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
> > 
> > The original motivation was an intrinsic method, Arrays.checkIndex, to
> > check if an index is within bounds. Such an intrinsic guides HotSpot
> > towards better optimisations for bounds checks using one unsigned
> > comparison instead of two signed comparisons, and better eliding of
> > integer to long conversions when an index is used to create an offset for
> > Unsafe access. The end result is more efficient array access especially so
> > from within unrolled loops. The VarHandles work will use Arrays.checkIndex
> > for array access.
> > 
> > A follow up issue [1] will track the intrinsification of Arrays.checkIndex.
> > 
> > We thought it would be opportunistic to support two further common
> > use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
> > checkFromIndexSize. There is no current plan to intrinsify these methods.
> > 
> > Bounds checking is not difficult but it can be easy to make trivial
> > mistakes. Thus it is advantageous to consolidate such checks not just from
> > an optimization perspective but from a correctness and security/integrity
> > perspective.
> > 
> > There are many areas in the JDK where such checks are performed. A follow
> > up issue [2] will track updates to use the new methods.
> > 
> > The main challenge for these new methods is to design in such a way that
> > 
> > 1) existing use-cases can still report the same set of exceptions with the
> > same messages;
> > 2) method byte code size is not unduly increased, thus perturbing inlining;
> > and
> > 3) there is a reasonable path for any future support of long indexes.
> > 
> > Paul.
> > 
> > [1] https://bugs.openjdk.java.net/browse/JDK-8042997
> > [2] https://bugs.openjdk.java.net/browse/JDK-8135250
> 
> 


From brian.burkhalter at oracle.com  Tue Sep 22 23:20:12 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 22 Sep 2015 16:20:12 -0700
Subject: JDK 9 RFR of JDK-7130085 Port fdlibm hypot to Java
In-Reply-To: <5600AD46.5080401@oracle.com>
References: <5600AD46.5080401@oracle.com>
Message-ID: <C5E440AE-2CD9-4DB9-BA74-4D1D23371B43@oracle.com>

Hi Joe,

Overall this looks good. I only have a couple of minor observations related to internal documentation.

1. FdLibm.java

Lines 158-166: The verbiage in the note might benefit from a little reworking.

2. HypotTests.java

Line 46: ?Commutative? is misspelled.

Thanks,

Brian

On Sep 21, 2015, at 6:22 PM, Joseph D. Darcy <Joe.Darcy at Oracle.Com> wrote:

> Please review the next portion of the port of fdlibm to Java:
> 
>    JDK-7130085 Port fdlibm hypot to Java
>    http://cr.openjdk.java.net/~darcy/7130085.0/
> 
> As before with pow, this isn't necessarily the end state of the code we'd like to stop at, but it should be sufficiently idiomatic Java for an initial port.
> 
> To make comparison against the original C algorithm easier, I listed the C version of hypot as the base file to compare FdLibm.java against.



From christos at zoulas.com  Wed Sep 23 00:43:04 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Tue, 22 Sep 2015 20:43:04 -0400
Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr
	in getLastErrorString
In-Reply-To: <560078F0.80003@oracle.com> from Rob McKenna (Sep 21, 10:38pm)
Message-ID: <20150923004304.91D5417FDAB@rebar.astron.com>

On Sep 21, 10:38pm, rob.mckenna at oracle.com (Rob McKenna) wrote:
-- Subject: Re: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of str

| I'll have a new webrev up soon that addresses the first comment and 
| Rogers feedback.

You know, given the complexity of the strerror_r() hacks to make it behave,
perhaps it is better to just:

#ifdef linux and other posix/xopen/foo
extern int __xpg_strerror_r(int, char *, size_t);
#define strerror_r(a, b, c) __xpg_strerror_r((a), (b), (c))
#endif

and eliminate all the rest of the ugliness, leaving the WIN32 ifdefs.

christos


From amaembo at gmail.com  Wed Sep 23 06:55:20 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Wed, 23 Sep 2015 12:55:20 +0600
Subject: Array equality, comparison and mismatch
In-Reply-To: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com>
References: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com>
Message-ID: <301906662.20150923125520@gmail.com>

Hello!

Quite interesting feature. Isn't it a typo here?
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html

419    if (!Float.isNaN(a[aFromIndex + i]) || !Float.isNaN(b[aFromIndex + i]))
487    if (!Double.isNaN(a[aFromIndex + i]) || !Double.isNaN(b[aFromIndex + i]))

Seems that it should be b[bFromIndex + i], not b[aFromIndex + i] in
both cases.

As for methods like compare(byte[] a, int aFromIndex, int aToIndex,
                            byte[] b, int bFromIndex, int bToIndex)

Is it better to introduce two to-indices instead of single length
argument (like in System.arraycopy)? Six method arguments looks
a little bit crowded.

As for method count, it would be really nice and user-friendly were it
be possible to add methods to the array types themselves, so users can
write:

byte[] b1;
byte[] b2;

int mismatchPos = b1.mismatch(b2);
Comparator<byte[]> cmp = byte[]::compareTo;

This somehow works with clone() method (I guess, there is some very
special code in javac for this). There could be some special abstract
classes like java.lang.ByteArray with private constructor (using
this[idx] to access elements) and all byte[] arrays could extend them,
so JDK developers could add new methods to arrays without modifying
the compiler. Well, that's just my fantasies about the better
world...

With best regards,
Tagir Valeev.

PS> Hi,

PS> Please review the following which adds methods to Arrays for
PS> performing equality, comparison and mismatch:

PS>   https://bugs.openjdk.java.net/browse/JDK-8033148
PS>  
PS> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
PS>  
PS> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html

PS> The motivation behind this is the use of Unsafe in popular
PS> libraries and frameworks to speed up the lexicographical comparison of byte arrays.

PS> This issue focuses on the API and functional implementations. A
PS> follow up issue [1] tracks updating the implementations to use a
PS> common method that leverages Unsafe to improve performance. A
PS> further issue [2] tracks the intrinsification of that common
PS> method to support operating on > 64 bits in width and further
PS> improve performance. A further issue, yet to be created, will
PS> follow up on updating existing JDK code to use the public and/or
PS> internal methods where appropriate. Example candidates include
PS> String (compareTo, perhaps add a mismatch method and possibly
PS> reviewing existing intrinsics, including those for compact
PS> Strings), and managed and direct Buffers.

PS> So far i have only documented the new methods operating on
PS> byte[], as that will act as the template for the other methods.

PS> Some points:

PS> - Methods operating on Object[] will compare Object elements
PS> using Object.equals or associated comparators (as is the case for
PS> the existing equals method operating on Object[]).

PS> - Methods operating on float[] or double[] will check such array
PS> elements for equality using the IEEE bit layout  (as is the case
PS> for the existing equals method operating on float[] or double[]).

PS> - Primitive array element comparison will be performed as if by
PS> the boxed primitive type?s compare or compareUnsigned method.

PS> - Range-accepting methods do not support null array values.

PS> - Non-range and range-accepting mismatch methods do not support
PS> null array values. (What value should be returned when a mismatch
PS> is performed on a null array and an empty array)?

PS> - Speculation: it may be possible that Project Valhalla will
PS> enable us to ?compress? down methods of certain groups to one
PS> ?template? method. Even if that is not possible i am not overly
PS> concerned about the number of methods added, which represents the
PS> maximum set. We could reduce them without a fundamental loss of
PS> functionality, but that might have a ?semantic? loss requiring
PS> developers to roll their own wrappers.

PS> Thanks,
PS> Paul.

PS> [1]  https://bugs.openjdk.java.net/browse/JDK-8136924
PS> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/

PS> [2] https://bugs.openjdk.java.net/browse/JDK-8044082



From paul.sandoz at oracle.com  Wed Sep 23 08:04:22 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 23 Sep 2015 10:04:22 +0200
Subject: Array equality, comparison and mismatch
In-Reply-To: <301906662.20150923125520@gmail.com>
References: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com>
	<301906662.20150923125520@gmail.com>
Message-ID: <86653108-26B7-4036-B9CE-F5CFAF7C9495@oracle.com>

On 23 Sep 2015, at 08:55, Tagir F. Valeev <amaembo at gmail.com> wrote:
> Hello!
> 
> Quite interesting feature. Isn't it a typo here?
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html
> 
> 419    if (!Float.isNaN(a[aFromIndex + i]) || !Float.isNaN(b[aFromIndex + i]))
> 487    if (!Double.isNaN(a[aFromIndex + i]) || !Double.isNaN(b[aFromIndex + i]))
> 
> Seems that it should be b[bFromIndex + i], not b[aFromIndex + i] in
> both cases.
> 

Oops, well spotted, thanks. Testing for NaNs can be tricky, now i need to work out why the tests did not capture that!


> As for methods like compare(byte[] a, int aFromIndex, int aToIndex,
>                            byte[] b, int bFromIndex, int bToIndex)
> 
> Is it better to introduce two to-indices instead of single length
> argument (like in System.arraycopy)?

Because that?s the style of usage in Arrays, and AFAICT the common style used by apps/frameworks that have rolled their own array comparators.


> Six method arguments looks
> a little bit crowded.
> 
> As for method count, it would be really nice and user-friendly were it
> be possible to add methods to the array types themselves, so users can
> write:
> 
> byte[] b1;
> byte[] b2;
> 
> int mismatchPos = b1.mismatch(b2);
> Comparator<byte[]> cmp = byte[]::compareTo;
> 
> This somehow works with clone() method (I guess, there is some very
> special code in javac for this). There could be some special abstract
> classes like java.lang.ByteArray with private constructor (using
> this[idx] to access elements) and all byte[] arrays could extend them,
> so JDK developers could add new methods to arrays without modifying
> the compiler. Well, that's just my fantasies about the better
> world?
> 


Perhaps it?s closer than you think, although further away than you might like :-) There are some experiments in Project Valhalla [1]. We would like all arrays to extend from a common array super type, from which we can then hang off further methods. That?s part of the Arrays 2.0 story.

You correctly guessed there is currently something special going in javac and the VM. I think it might be quite simple to extend javac. The tricky work is more likely in the VM to hook in the array super type and it's methods (perhaps patching into the underlying array class's v/itables).

Paul.

[1] http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/73ae1e2cbb20



From peter.levart at gmail.com  Wed Sep 23 08:09:02 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 23 Sep 2015 10:09:02 +0200
Subject: Array equality, comparison and mismatch
In-Reply-To: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com>
References: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com>
Message-ID: <56025E1E.40009@gmail.com>

Hi Paul,

Just some thoughts about nulls...

Simple compare and compareUnsigned methods (without ranges) accept null 
arrays. They specify that indirectly by stating that they are consistent 
with equals methods that do the same. The equals methods specify that 
two null array references are equal and by equal being an equivalence 
relation it follows that a null array reference is not equal to non-null 
reference (unless all arrays were equal), but compare[Unsigned] methods 
do not specify the ordering of null to non-null array reference. The 
implementation does order null array reference before any non-null 
reference.

With compare methods taking Object[] arrays there is another level of 
nullness to consider - the elements. The Arrays boolean equals(Object[] 
a, Object[] b) method uses the semantics of Objects.equals for comparing 
elements, therefore it allows null elements. So does Arrays <T extends 
Comparable<? super T>> int compare(T[] a, T[] b), which considers null 
element as the lowest value. This seems ok although in TreeMap, for 
example, null keys are not allowed if Comparator is not specified, but 
for consistency with Arrays.equals this is a desired property. But 
Arrays <T> int compare(T[] a, T[] b, Comparator<? super T> cmp) does the 
same - it treats null elements as the lowest value. This is not 
consistent with TreeMap, for example, where all decisions on ordering 
are delegated to Comparator which can order null elements (or reject 
them) as it pleases.

Regards, Peter


On 09/22/2015 06:30 PM, Paul Sandoz wrote:
> Hi,
>
> Please review the following which adds methods to Arrays for performing equality, comparison and mismatch:
>
>    https://bugs.openjdk.java.net/browse/JDK-8033148
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/
>    http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/specdiff/overview-summary.html
>
> The motivation behind this is the use of Unsafe in popular libraries and frameworks to speed up the lexicographical comparison of byte arrays.
>
> This issue focuses on the API and functional implementations. A follow up issue [1] tracks updating the implementations to use a common method that leverages Unsafe to improve performance. A further issue [2] tracks the intrinsification of that common method to support operating on > 64 bits in width and further improve performance. A further issue, yet to be created, will follow up on updating existing JDK code to use the public and/or internal methods where appropriate. Example candidates include String (compareTo, perhaps add a mismatch method and possibly reviewing existing intrinsics, including those for compact Strings), and managed and direct Buffers.
>
> So far i have only documented the new methods operating on byte[], as that will act as the template for the other methods.
>
> Some points:
>
> - Methods operating on Object[] will compare Object elements using Object.equals or associated comparators (as is the case for the existing equals method operating on Object[]).
>
> - Methods operating on float[] or double[] will check such array elements for equality using the IEEE bit layout  (as is the case for the existing equals method operating on float[] or double[]).
>
> - Primitive array element comparison will be performed as if by the boxed primitive type?s compare or compareUnsigned method.
>
> - Range-accepting methods do not support null array values.
>
> - Non-range and range-accepting mismatch methods do not support null array values. (What value should be returned when a mismatch is performed on a null array and an empty array)?
>
> - Speculation: it may be possible that Project Valhalla will enable us to ?compress? down methods of certain groups to one ?template? method. Even if that is not possible i am not overly concerned about the number of methods added, which represents the maximum set. We could reduce them without a fundamental loss of functionality, but that might have a ?semantic? loss requiring developers to roll their own wrappers.
>
> Thanks,
> Paul.
>
> [1]  https://bugs.openjdk.java.net/browse/JDK-8136924
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8044082
>



From paul.sandoz at oracle.com  Wed Sep 23 08:12:09 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 23 Sep 2015 10:12:09 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <1086772691.995036.1442963899414.JavaMail.zimbra@u-pem.fr>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<0ED64734-7F73-4E8B-9900-7B444E8629C8@oracle.com>
	<1086772691.995036.1442963899414.JavaMail.zimbra@u-pem.fr>
Message-ID: <D8ACE863-4234-4E3F-A2BA-795679BBF480@oracle.com>


On 23 Sep 2015, at 01:18, Remi Forax <forax at univ-mlv.fr> wrote:

> Hi Paul,
> 
> 
> 
> ----- Mail original -----
>> De: "Paul Sandoz" <paul.sandoz at oracle.com>
>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Mardi 22 Septembre 2015 12:40:03
>> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
>> 
>> Hi,
>> 
>> Thanks for all the feedback.
>> 
>> Here is a new webrev:
>> 
>>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/webrev/
>> 
>> Changes:
>> 
>> - Move check methods to IndexOutOfBoundsException
>> 
>> - Use BiFunction, rather than a specific exception mapping function.
>> 
>> - Add check methods that do not accept an exception mapping function and
>> throw IndexOutOfBoundsException.
> 
> I still think that you should not use null as Stephen noticed,
> what's wrong with writing checkIndex like this ?
> 
>  int checkIndex(int index, int length) throws IndexOutOfBoundsException {
>    return checkIndex(index, length, IndexOutOfBoundsException::new);
>  }
> 

Because i want to support the simple cases without pulling in indy.


>> 
>> - Add 2 argument constructors to Array/String/IndexOutOfBoundsException, thus
>> allowing support for method refs.
>> 
>> Remi, i left the generic signatures as is, i am presuming there is an
>> advantage to naming T, rather than using a wildcard e.g. IDEs could use that
>> information (although IntelliJ does not appear to do so at the moment).
> 
> I don't get it. Why it's important for an IDE to know that a code throws a precise *runtime* exception. Any codes can throw any runtime exceptions.
> 

It could aid code completion e.g. wrap in try/catch or analysis of what runtime exceptions propagate.

Perhaps this is a rare case, but in general, why loose such information?

Are you concerned that the method signatures look odd in code and in JavaDoc?

Paul.


From paul.sandoz at oracle.com  Wed Sep 23 09:18:20 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 23 Sep 2015 11:18:20 +0200
Subject: Array equality, comparison and mismatch
In-Reply-To: <56025E1E.40009@gmail.com>
References: <79451C0B-DA1A-4FD6-B8F3-97B7BE841006@oracle.com>
	<56025E1E.40009@gmail.com>
Message-ID: <AC59EA07-4AFE-4ADA-A376-9564976C581E@oracle.com>

Hi Peter,

On 23 Sep 2015, at 10:09, Peter Levart <peter.levart at gmail.com> wrote:

> Hi Paul,
> 
> Just some thoughts about nulls...
> 

Thanks, this is helpful.


> Simple compare and compareUnsigned methods (without ranges) accept null arrays.

Yes.


> They specify that indirectly by stating that they are consistent with equals methods that do the same. The equals methods specify that two null array references are equal and by equal being an equivalence relation it follows that a null array reference is not equal to non-null reference (unless all arrays were equal),

Right, i had the indirect specification on both methods, but of course that makes no sense for unsigned comparison, so it was removed.


> but compare[Unsigned] methods do not specify the ordering of null to non-null array reference. The implementation does order null array reference before any non-null reference.

I have clarified the doc the all the byte[] compare/Unsigned methods:

* <p>A {@code null} array reference is considered lexicographically less
* than a non-{@code null} array reference.  Two {@code null} array
* references are considered equal.


> 
> With compare methods taking Object[] arrays there is another level of nullness to consider - the elements.

Yes.


> The Arrays boolean equals(Object[] a, Object[] b) method uses the semantics of Objects.equals for comparing elements, therefore it allows null elements. So does Arrays <T extends Comparable<? super T>> int compare(T[] a, T[] b), which considers null element as the lowest value. This seems ok although in TreeMap, for example, null keys are not allowed if Comparator is not specified, but for consistency with Arrays.equals this is a desired property. But Arrays <T> int compare(T[] a, T[] b, Comparator<? super T> cmp) does the same - it treats null elements as the lowest value. This is not consistent with TreeMap, for example, where all decisions on ordering are delegated to Comparator which can order null elements (or reject them) as it pleases.
> 

A good point. Same applies to mismatch as well. Updated.

There is another inconsistency. Array methods sort and binarySearch do not explicitly declare Comparable and instead this is implied if a null Comparator argument is given. I prefer separate methods for compare, making Comparable explicit, and throwing NPE for a null Comparator. the semantics are slightly different for mismatch where constraining elements to be of of Comparable is not necessary). However, for consistent i might be pushed towards sort/binarySearch pattern.

Thanks,
Paul.


From paul.sandoz at oracle.com  Wed Sep 23 10:16:06 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 23 Sep 2015 12:16:06 +0200
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
Message-ID: <DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>

Hi,

I trawled through the patches and could not find anything obvious that clobbered existing JDK stuff.

In the misc/locks patches there are some classes that might contain spec changes:

  ConcurrentLinkedDeque
  CopyOnWriteArraySet
  ScheduledExecutorService
  ScheduledThreadPoolExecutor

  LockSupport
  ReentrantReadWriteLock

Any opinions? sometimes it?s a fine line between a clarification and a spec update.


There are some new methods we need to track in the following classes:

  LinkedTransferQueue
  SynchronousQueue


In ThreadPoolExecutor there is style used to declare a set of fonts:

 249  * <dd style="font-family:'DejaVu Sans', Arial, Helvetica, sans-serif">
 250  * This class provides {@code protected} overridable
 251  * {@link #beforeExecute(Thread, Runnable)} and

Is that necessary?


In Helpers:

 121     private static String newStringUnsafe(char[] chars) {
 122         // If porting to a JDK where sun.misc.SharedSecrets is not
 123         // available, modify the code below to simply:
 124         // return new String(chars);
 125         // TODO: Can we do this more portably?
 126         return sun.misc.SharedSecrets.getJavaLangAccess().newStringUnsafe(chars);
 127     }

Yes, you can do this more portably *and* safely by not using it! :-)

Do we really really need to use SharedSecrets? IMO this unsafe dependency should be removed in the JDK patch.

Paul.


On 21 Sep 2015, at 20:34, Martin Buchholz <martinrb at google.com> wrote:

> This is the long-delayed and long-awaited bulk integration for jdk9 from jsr166 CVS.
> 
> Find webrevs here:
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
> 
> Sorry about the extreme size and tardiness of this integration.
> 
> As a review convenience, I provided a diff-wbB file that contains all the jsr166 integration changes using "hg diff -wbB" that ignores whitespace changes.
> 
> We will need JPRT+specdiff+CCC from Oracle folks
> 
> All changes are subtasks of:
> https://bugs.openjdk.java.net/browse/JDK-8132960



From ivan.gerasimov at oracle.com  Wed Sep 23 13:14:23 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 23 Sep 2015 16:14:23 +0300
Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr
	in getLastErrorString
In-Reply-To: <5600280C.9040601@oracle.com>
References: <5600280C.9040601@oracle.com>
Message-ID: <5602A5AF.6030409@oracle.com>

Hi Rob!

On 21.09.2015 18:53, Rob McKenna wrote:
> Hi folks,
>
> Requesting a review of this change which switches corelibs usages of 
> the thread-unsafe strerror over to strerror_r/strerror_s:
>
> http://cr.openjdk.java.net/~robm/8133249/webrev.01/
>

I think it would be better to have  jdk_strerror(errno, tmpbuf, 
sizeof(tmpbuf))  instead of  jdk_strerror(errno, tmpbuf, (size_t) 1024), 
just for the sake of avoiding constant duplication.
I don't see the return code of jdk_strerror() is ever used. I suggest 
using it in ProcessImpl_md.c (see below), or just making this function 
return void.

jni_util_md.c:
- why can't we just call  jdk_strerror(errno, buf, len)  and get rid of 
the temp buffer?

java_md_common.c:
- commented out #include @ line 26
- the change in JLI_ReportErrorMessageSys() looks incomplete

ProcessImpl_md.c:
- would it make sense to check if jdk_strerror() == EINVAL instead of 
comparing the strings?

PlainDatagramSocketImpl.c:
- #include added, but no other changes were made.

TwoStacksPlainDatagramSocketImpl.c:
- buf is declared to be char[1024], but only up to 255 chars are used.
- would be better to move the buf declaration closer to its use, maybe 
next to char errmsg[300] line?

jdk_strerror.c:
- minor nit: extra space after strerror_r at lines 46 and 63.

Sincerely yours,
Ivan



From ivan.gerasimov at oracle.com  Wed Sep 23 13:43:44 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 23 Sep 2015 16:43:44 +0300
Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr
	in getLastErrorString
In-Reply-To: <5602A5AF.6030409@oracle.com>
References: <5600280C.9040601@oracle.com> <5602A5AF.6030409@oracle.com>
Message-ID: <5602AC90.6050004@oracle.com>

Oops, I missed the reply from Roger Riggs, which already covered many of 
these concerns.

Sincerely yours,
Ivan

On 23.09.2015 16:14, Ivan Gerasimov wrote:
> Hi Rob!
>
> On 21.09.2015 18:53, Rob McKenna wrote:
>> Hi folks,
>>
>> Requesting a review of this change which switches corelibs usages of 
>> the thread-unsafe strerror over to strerror_r/strerror_s:
>>
>> http://cr.openjdk.java.net/~robm/8133249/webrev.01/
>>
>
> I think it would be better to have  jdk_strerror(errno, tmpbuf, 
> sizeof(tmpbuf))  instead of  jdk_strerror(errno, tmpbuf, (size_t) 
> 1024), just for the sake of avoiding constant duplication.
> I don't see the return code of jdk_strerror() is ever used. I suggest 
> using it in ProcessImpl_md.c (see below), or just making this function 
> return void.
>
> jni_util_md.c:
> - why can't we just call  jdk_strerror(errno, buf, len)  and get rid 
> of the temp buffer?
>
> java_md_common.c:
> - commented out #include @ line 26
> - the change in JLI_ReportErrorMessageSys() looks incomplete
>
> ProcessImpl_md.c:
> - would it make sense to check if jdk_strerror() == EINVAL instead of 
> comparing the strings?
>
> PlainDatagramSocketImpl.c:
> - #include added, but no other changes were made.
>
> TwoStacksPlainDatagramSocketImpl.c:
> - buf is declared to be char[1024], but only up to 255 chars are used.
> - would be better to move the buf declaration closer to its use, maybe 
> next to char errmsg[300] line?
>
> jdk_strerror.c:
> - minor nit: extra space after strerror_r at lines 46 and 63.
>
> Sincerely yours,
> Ivan
>
>



From daniel.fuchs at oracle.com  Wed Sep 23 14:50:40 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 23 Sep 2015 16:50:40 +0200
Subject: RFR: 8033661: readConfiguration does not cleanly reinitialize the
	logging system
In-Reply-To: <5601DE0A.9060707@oracle.com>
References: <55F06497.5010300@oracle.com>
	<1F185ECE-B5B1-4175-ABAA-B86FCD0861EC@oracle.com>
	<55F6F517.8000100@oracle.com>
	<EBE38931-6036-4908-8C50-9F7C8B34E729@oracle.com>
	<56018174.1090603@oracle.com> <5601DE0A.9060707@oracle.com>
Message-ID: <5602BC40.6060308@oracle.com>

Hi Mandy,

On 23/09/15 01:02, Mandy Chung wrote:
> On 09/22/2015 09:27 AM, Daniel Fuchs wrote:
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.02
>
> Looking quite good.  Thanks for making the change.
>
> Below are mostly javadoc comments and some minor implementation comments.
>
> 1474      * which should be in {@linkplain java.util.Properties
> properties file} format.
>
> Would it be better to state this above in @throws IOException:
>
> IOException if there are problems reading from the stream or
> the given stream is not in Properties format

Done.

> 1484      * existing loggers that have a level property specified in the
> new
> 1485      * configuration stream
>
> s/the new configuration stream/the given input stream/
>
> 1491      * methods instead.
>
> s/methods/method/

Done.

>
> updateConfiguration(Function) - slight reorg of the sentences:
>
>       * Updates the logging configuration.
>       * <p>
>       * If the "java.util.logging.config.file" system property is set,
>       * then the property value specifies the properties file to be read
>       * as the new configuration. Otherwise, the LogManager default
>       * configuration is used.
>       * The default configuration is typically loaded from the
>       * properties file "{@code conf/logging.properties}" in the Java
> installation
>       * directory.
>       * This method reads the new configuration and calls the {@link
>       * #updateConfiguration(java.io.InputStream,
> java.util.function.Function)
>       * updateConfiguration(ins, mapper)} method to
>       * update the configuration.
>       *
>       * @apiNote
>       * This method updates the logging configuration from reading
>       * a properties file and ignores the "java.util.logging.config.class"
>       * system property.  The "java.util.logging.config.class" property is
>       * only used by the readConfiguration method to load a custom
> configuration
>       * class as an initial configuration.
>
> 1774      *   For each configuration key <i>k</i>,
>     Could simply be "For each {@code k},"

Done.

> - do you want italic for all occurrance?  Maybe just the first occurrance
>    and @code for the subsequent ones.

Mixing italics and {@code } was a bit confusing to me. When I generated
the javadoc and looked at the specdiff, it looked as if {@code k} was a 
different thing than the <i>k</i> we had discussed earlier.
So I choose to use italics for formal concepts/hypothetical variables
and {@code } for actual code and @param names.

> 1780      *   A {@code null} value for <i>v</i>  indicates that there
> should be no
> 1781      *   value associated with <i>k</i> in the resulting
> configuration.
>
> This sentence can be combined with line 1772-1773 as follows:
>
> returns a function <i>f(o,n)</i> whose returnedvalue will be
> applied to the resulting configuration, or {@code null}
> to indicate that the property {@code k}  will not be added
> in the resulting configuration.

OK - but it would be better to break the sentence:

returns a function <i>f(o,n)</i> whose returned
value will be applied to the resulting configuration.
The function <i>f</i> may return {@code null} to indicate
that the property <i>k</i> should not be added to the
resulting configuration.


> Also @param mapper - need to say "mapper may be null"
>
> Same comment applies to @param in the other updateConfiguration method.

right.


> 1825      * then <i>v = f(o,n)</i> is the
> 1826      * resulting value (i.e. the value that will be associated with
> 1827      * <i>k</i> in the resulting configuration).
>
> Might be something like this:
>
> then <i>v = f(o,n)</i> is the returned  value.
> If v is not null, the property k with value v will be added in
> the resulting configuration.  Otherwise, it will not be added.

then <i>v = f(o,n)</i> is the resulting value.
If <i>v</i> is not {@code null}, then a property
<i>k</i> with value <i>v</i> will be added to the resulting 
configuration. Otherwise, it will be omitted.

>
> 1842      * listener}
>
> Should it be "listener(s)"

OK.

> 2018             // Builds a TreeSet of all (old and new) property names.
> 2030                         .forEachOrdered(k -> ConfigProperty
>
> Is the ordering matter here?

Not really. It does matter later - we want to handle
parent loggers before child loggers to optimize the
processing but we use a TreeMap for that.
TreeSet is probably a remnant from an earlier prototype.


> 2071                     if (l == null) continue;
> 2072                     if (!visited.test(l)) {
>
> Nit: can be combined in one line
>     if (l != null && !visited.test(l)) {

Done.

>
> ah - I saw that is used in line 2166
>
> New tests: I only skimmed through them. They are good and covers complex
> scenarios.  For new methods like this, I generally like to see simple
> and small unit tests to be added that are easy for readers to
> understand.  For example, some sample properties files and check the
> resulting configuration using LogManager.getProperty. You already have
> many test cases covered.  I didn't want to add more works but it'd be
> really nice to see simple small unit tests.  Maybe refactor
> UpdateConfigurationTest.

OK - I will add a simple test. I think I'll probably use the
mapper examples from the documentation as my test cases :-)

I'll send a new webrev when ready.

-- daniel

>
> Mandy
>



From Roger.Riggs at Oracle.com  Wed Sep 23 15:21:31 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 23 Sep 2015 11:21:31 -0400
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection
	to discard output
In-Reply-To: <CA+kOe08crMUYSrbz3p3R8=CPu0G6KFAx0dLFC-Zi5V+QAatiQQ@mail.gmail.com>
References: <55F2F37E.20101@Oracle.com>
	<644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
	<560042B2.4090409@oracle.com>
	<CA+kOe09tcvs2N8N=i0k_eqwO8kXyQVD-GiM23vfZC9=vyc-qwQ@mail.gmail.com>
	<56004C69.1010606@oracle.com>
	<CA+kOe08dv+U0QKW81Cq1aTVtnno=_ok9DCy=MbZeyGC_hnCTeA@mail.gmail.com>
	<56015748.5020504@Oracle.com>
	<CA+kOe08crMUYSrbz3p3R8=CPu0G6KFAx0dLFC-Zi5V+QAatiQQ@mail.gmail.com>
Message-ID: <5602C37B.7050103@Oracle.com>

Hi Martin,

ok, that reads a bit better.
The webrev has been updated and I will push later today.

   http://cr.openjdk.java.net/~rriggs/webrev-discard-8132541/

Thanks, Roger

On 9/22/2015 12:25 PM, Martin Buchholz wrote:
> A typical implementation discards the output by writing to an 
> operating system specific "null file".



From forax at univ-mlv.fr  Wed Sep 23 16:11:09 2015
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Wed, 23 Sep 2015 16:11:09 +0000
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <D8ACE863-4234-4E3F-A2BA-795679BBF480@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<0ED64734-7F73-4E8B-9900-7B444E8629C8@oracle.com>
	<1086772691.995036.1442963899414.JavaMail.zimbra@u-pem.fr>
	<D8ACE863-4234-4E3F-A2BA-795679BBF480@oracle.com>
Message-ID: <4E159761-DDA7-4849-9816-18037FC53D33@univ-mlv.fr>



Le 23 septembre 2015 10:12:09 CEST, Paul Sandoz <paul.sandoz at oracle.com> a ?crit :
>
>On 23 Sep 2015, at 01:18, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> Hi Paul,
>> 
>> 
>> 
>> ----- Mail original -----
>>> De: "Paul Sandoz" <paul.sandoz at oracle.com>
>>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>> Envoy?: Mardi 22 Septembre 2015 12:40:03
>>> Objet: Re: RFR 8135248: Add utility methods to check indexes and
>ranges
>>> 
>>> Hi,
>>> 
>>> Thanks for all the feedback.
>>> 
>>> Here is a new webrev:
>>> 
>>> 
>http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/webrev/
>>> 
>>> Changes:
>>> 
>>> - Move check methods to IndexOutOfBoundsException
>>> 
>>> - Use BiFunction, rather than a specific exception mapping function.
>>> 
>>> - Add check methods that do not accept an exception mapping function
>and
>>> throw IndexOutOfBoundsException.
>> 
>> I still think that you should not use null as Stephen noticed,
>> what's wrong with writing checkIndex like this ?
>> 
>>  int checkIndex(int index, int length) throws
>IndexOutOfBoundsException {
>>    return checkIndex(index, length, IndexOutOfBoundsException::new);
>>  }
>> 
>
>Because i want to support the simple cases without pulling in indy.

and what about using an anonymous class instead ?

I suppose that the other solution is to special case invokedynamic if the method handle is a constant to avoid to awake the lambda form beast :)

>
>
>>> 
>>> - Add 2 argument constructors to
>Array/String/IndexOutOfBoundsException, thus
>>> allowing support for method refs.
>>> 
>>> Remi, i left the generic signatures as is, i am presuming there is
>an
>>> advantage to naming T, rather than using a wildcard e.g. IDEs could
>use that
>>> information (although IntelliJ does not appear to do so at the
>moment).
>> 
>> I don't get it. Why it's important for an IDE to know that a code
>throws a precise *runtime* exception. Any codes can throw any runtime
>exceptions.
>> 
>
>It could aid code completion e.g. wrap in try/catch or analysis of what
>runtime exceptions propagate.
>
>Perhaps this is a rare case, but in general, why loose such
>information?

Wrapping runtime exceptions in a try/catch is usually a bad idea. Runtime exceptions are raised because of developer mistakes.
In my dream world, you can replace all runtime exceptions by one single RTFM exception without introducing any bugs in your programs :)

And any analysis will fall short because you don't have to propagate runtime exceptions.

>
>Are you concerned that the method signatures look odd in code and in
>JavaDoc?

yes, reading a signature with a wildcard is easier than a signature with a type variable, half of my students just pretend '?' doesn't exist ...

>
>Paul.

R?mi



From martinrb at google.com  Wed Sep 23 16:35:36 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 23 Sep 2015 09:35:36 -0700
Subject: RFR: 8132541 : (process) ProcessBuilder support for redirection
	to discard output
In-Reply-To: <5602C37B.7050103@Oracle.com>
References: <55F2F37E.20101@Oracle.com>
	<644336522.2110058.1441991465621.JavaMail.zimbra@u-pem.fr>
	<560042B2.4090409@oracle.com>
	<CA+kOe09tcvs2N8N=i0k_eqwO8kXyQVD-GiM23vfZC9=vyc-qwQ@mail.gmail.com>
	<56004C69.1010606@oracle.com>
	<CA+kOe08dv+U0QKW81Cq1aTVtnno=_ok9DCy=MbZeyGC_hnCTeA@mail.gmail.com>
	<56015748.5020504@Oracle.com>
	<CA+kOe08crMUYSrbz3p3R8=CPu0G6KFAx0dLFC-Zi5V+QAatiQQ@mail.gmail.com>
	<5602C37B.7050103@Oracle.com>
Message-ID: <CA+kOe0-w6X+91C+CX+oURvAH-ntjsGZtPvOFCb2vcOUjQfZEKQ@mail.gmail.com>

Ship it!

On Wed, Sep 23, 2015 at 8:21 AM, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Hi Martin,
>
> ok, that reads a bit better.
> The webrev has been updated and I will push later today.
>
>   http://cr.openjdk.java.net/~rriggs/webrev-discard-8132541/
>
> Thanks, Roger
>
> On 9/22/2015 12:25 PM, Martin Buchholz wrote:
>
> A typical implementation discards the output by writing to an operating
> system specific "null file".
>
>
>


From kumar.x.srinivasan at oracle.com  Wed Sep 23 17:42:14 2015
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 23 Sep 2015 10:42:14 -0700
Subject: RFR: JDK-8073187: Unexpected side effect in Pack200
In-Reply-To: <5601B834.60900@oracle.com>
References: <5601B834.60900@oracle.com>
Message-ID: <5602E476.3060309@oracle.com>

Hi John, Sherman,

I noticed a flaw in my fix, ie. in a section of the logic that is present
but unused,  and reserved for future use, fixed it here anyway, for
correctness.

The full webrev:
http://cr.openjdk.java.net/~ksrini/8073187/webrev.1/

The delta changes:
http://cr.openjdk.java.net/~ksrini/8073187/webrev.1/webrev.delta/index.html

Thanks
Kumar

> Hello,
>
> Pack200 converts the timestamps to UTC for the pack200 archive format,
>  in order to do so,  the default TimeZone was set to UTC, while 
> reading and
> writing archives. This is problematic in a multi threaded environment.
>
> With the fix for JDK-8075526 in place, the pack200 code is refactored
> to use the new Jar/Zip APIs, and eliminates issues arising from pack200
> setting the default TimeZone.
>
> http://cr.openjdk.java.net/~ksrini/8073187/webrev.0/
>
> Thanks
> Kumar
>



From mark.reinhold at oracle.com  Wed Sep 23 17:49:05 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 23 Sep 2015 10:49:05 -0700 (PDT)
Subject: JEP 266: More Concurrency Updates
Message-ID: <20150923174905.620527A227@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/266

- Mark


From martinrb at google.com  Wed Sep 23 19:33:47 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 23 Sep 2015 12:33:47 -0700
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>
Message-ID: <CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>

On Wed, Sep 23, 2015 at 3:16 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> I trawled through the patches and could not find anything obvious that
> clobbered existing JDK stuff.
>
> In the misc/locks patches there are some classes that might contain spec
> changes:
>
>   ConcurrentLinkedDeque
>   CopyOnWriteArraySet
>   ScheduledExecutorService
>   ScheduledThreadPoolExecutor
>
>   LockSupport
>   ReentrantReadWriteLock
>
> Any opinions? sometimes it?s a fine line between a clarification and a
> spec update.
>
>
Right. jsr166 bulk updates generally contain so many diverse changes that I
always just assume a CCC would be required (in the past, this was done via
a single request instead of split up as we are doing here).

If you generate a public specdiff (as I believe only Oracle folks can), it
would be easier for all of us to review the spec changes.



>
> There are some new methods we need to track in the following classes:
>
>   LinkedTransferQueue
>   SynchronousQueue
>
>
Those aren't "really" new methods - just new drop-in implementations of
existing interface methods like toString(), with no new real spec content.
But yeah, a grey area.


>
> In ThreadPoolExecutor there is style used to declare a set of fonts:
>
>  249  * <dd style="font-family:'DejaVu Sans', Arial, Helvetica,
> sans-serif">
>  250  * This class provides {@code protected} overridable
>  251  * {@link #beforeExecute(Thread, Runnable)} and
>
> Is that necessary?
>
>
Compare and contrast:
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/ThreadPoolExecutor.html
http://download.java.net/jdk9/docs/api/java/util/concurrent/ThreadPoolExecutor.html

This is a workaround for
https://bugs.openjdk.java.net/browse/JDK-8136434
javadoc should not use a monotype font for <dd> elements


>
> In Helpers:
>
>  121     private static String newStringUnsafe(char[] chars) {
>  122         // If porting to a JDK where sun.misc.SharedSecrets is not
>  123         // available, modify the code below to simply:
>  124         // return new String(chars);
>  125         // TODO: Can we do this more portably?
>  126         return
> sun.misc.SharedSecrets.getJavaLangAccess().newStringUnsafe(chars);
>  127     }
>
> Yes, you can do this more portably *and* safely by not using it! :-)
>
> Do we really really need to use SharedSecrets? IMO this unsafe dependency
> should be removed in the JDK patch.


Of course, this is "just" a (relatively unimportant) performance
optimization.
Should only classes in java.lang get to use the constructor  String(char[]
value, boolean share)?
Will there be a jigsaw-blessed way of creating Strings this way from
"trusted" modules?
More generally, will there be a blessed way to provide relatively unsafe
access to code you trust?
Will hotspot be smart enough to elide the allocation by proving the input
array is never used again?


From chris.hegarty at oracle.com  Wed Sep 23 20:05:59 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 23 Sep 2015 21:05:59 +0100
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>
	<CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>
Message-ID: <5D166E5C-FDED-41AC-ABD1-ACA3AEA3709B@oracle.com>


> On 23 Sep 2015, at 20:33, Martin Buchholz <martinrb at google.com> wrote:
> 
> On Wed, Sep 23, 2015 at 3:16 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> 
>> Hi,
>> 
>> I trawled through the patches and could not find anything obvious that
>> clobbered existing JDK stuff.
>> 
>> In the misc/locks patches there are some classes that might contain spec
>> changes:
>> 
>>  ConcurrentLinkedDeque
>>  CopyOnWriteArraySet
>>  ScheduledExecutorService
>>  ScheduledThreadPoolExecutor
>> 
>>  LockSupport
>>  ReentrantReadWriteLock
>> 
>> Any opinions? sometimes it?s a fine line between a clarification and a
>> spec update.
>> 
>> 
> Right. jsr166 bulk updates generally contain so many diverse changes that I
> always just assume a CCC would be required (in the past, this was done via
> a single request instead of split up as we are doing here).

For 8 we separated out the tasks into several subtasks ( and CCC?s ) as being done here. This worked well, at least from my point of view. See  https://bugs.openjdk.java.net/browse/JDK-8001566 <https://bugs.openjdk.java.net/browse/JDK-8001566>


> If you generate a public specdiff (as I believe only Oracle folks can), it
> would be easier for all of us to review the spec changes.
> 
> 
> 
>> 
>> There are some new methods we need to track in the following classes:
>> 
>>  LinkedTransferQueue
>>  SynchronousQueue
>> 
>> 
> Those aren't "really" new methods - just new drop-in implementations of
> existing interface methods like toString(), with no new real spec content.
> But yeah, a grey area.

Should not require a CCC then.

> 
>> 
>> In ThreadPoolExecutor there is style used to declare a set of fonts:
>> 
>> 249  * <dd style="font-family:'DejaVu Sans', Arial, Helvetica,
>> sans-serif">
>> 250  * This class provides {@code protected} overridable
>> 251  * {@link #beforeExecute(Thread, Runnable)} and
>> 
>> Is that necessary?
>> 
>> 
> Compare and contrast:
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/ThreadPoolExecutor.html <http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/ThreadPoolExecutor.html>
> http://download.java.net/jdk9/docs/api/java/util/concurrent/ThreadPoolExecutor.html <http://download.java.net/jdk9/docs/api/java/util/concurrent/ThreadPoolExecutor.html>
> 
> This is a workaround for
> https://bugs.openjdk.java.net/browse/JDK-8136434 <https://bugs.openjdk.java.net/browse/JDK-8136434>
> javadoc should not use a monotype font for <dd> elements
> 
> 
>> 
>> In Helpers:
>> 
>> 121     private static String newStringUnsafe(char[] chars) {
>> 122         // If porting to a JDK where sun.misc.SharedSecrets is not
>> 123         // available, modify the code below to simply:
>> 124         // return new String(chars);
>> 125         // TODO: Can we do this more portably?
>> 126         return
>> sun.misc.SharedSecrets.getJavaLangAccess().newStringUnsafe(chars);
>> 127     }
>> 
>> Yes, you can do this more portably *and* safely by not using it! :-)
>> 
>> Do we really really need to use SharedSecrets? IMO this unsafe dependency
>> should be removed in the JDK patch.
> 
> 
> Of course, this is "just" a (relatively unimportant) performance
> optimization.
> Should only classes in java.lang get to use the constructor  String(char[]
> value, boolean share)?
> Will there be a jigsaw-blessed way of creating Strings this way from
> "trusted" modules?
> More generally, will there be a blessed way to provide relatively unsafe
> access to code you trust?
> Will hotspot be smart enough to elide the allocation by proving the input
> array is never used again?

-Chris.



From daniel.fuchs at oracle.com  Wed Sep 23 20:23:52 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 23 Sep 2015 22:23:52 +0200
Subject: RFR: 8033661: readConfiguration does not cleanly reinitialize the
	logging system
In-Reply-To: <5602BC40.6060308@oracle.com>
References: <55F06497.5010300@oracle.com>
	<1F185ECE-B5B1-4175-ABAA-B86FCD0861EC@oracle.com>
	<55F6F517.8000100@oracle.com>
	<EBE38931-6036-4908-8C50-9F7C8B34E729@oracle.com>
	<56018174.1090603@oracle.com> <5601DE0A.9060707@oracle.com>
	<5602BC40.6060308@oracle.com>
Message-ID: <56030A58.7000403@oracle.com>

On 23/09/15 16:50, Daniel Fuchs wrote:
> I'll send a new webrev when ready.

Here it is:

http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.03/

There are two new tests:

SimpleUpdateConfigurationTest
SimpleUpdateConfigWithInputStreamTest

They are basically the same tests, except that the first
one spits the configuration in a file and then sets the
java.util.logging.config.file property before calling
updateConfiguration(Function), whereas the second
creates an InputStream from a Property object and
then calls updateConfiguration(InputStream, Function).

best regards,

-- daniel


From joe.darcy at oracle.com  Wed Sep 23 20:31:58 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 23 Sep 2015 13:31:58 -0700
Subject: JDK 9 RFR of JDK-7130085 Port fdlibm hypot to Java
In-Reply-To: <C5E440AE-2CD9-4DB9-BA74-4D1D23371B43@oracle.com>
References: <5600AD46.5080401@oracle.com>
	<C5E440AE-2CD9-4DB9-BA74-4D1D23371B43@oracle.com>
Message-ID: <56030C3E.1060904@oracle.com>

Hi Brian,

Thanks for the review; I plan to push a slightly amended version later 
today. The new version

* rewords the paragraph you suggested
* declares the method strictfp
* fixes a comparison that mixes integer and floating-point values
* add more test cases near the subnormal threshold

Diff of patches below.

Cheers,

-Joe
# FdLibm.java

77c97
< +        public static double compute(double x, double y) {
---
 > +        public static strictfp double compute(double x, double y) {
99,107c119,134
< +            // Note: the uses of ha and hb in hypot could be
< +            // eliminated by changing the relative magnitude
< +            // comparison below to either a floating-point divide or a
< +            // comparison of getExponent results coupled initializing
< +            // t1 and t2 using a split generated by floating-point
< +            // operations. The range filtering and exponent
< +            // adjustments already done by hypot implies should a
< +            // split would not need to worry about overflow or
< +            // underflow cases.
---
 > +            // Note: the ha and hb variables are the high-order
 > +            // 32-bits of a and b stored as integer values. The ha and
 > +            // hb values are used first for a rough magnitude
 > +            // comparison of a and b and second for simulating higher
 > +            // precision by allowing a and b, respectively, to be
 > +            // decomposed into non-overlapping portions. Both of these
 > +            // uses could be eliminated. The magnitude comparison
 > +            // could be eliminated by extracting and comparing the
 > +            // exponents of a and b or just be performing a
 > +            // floating-point divide.  Splitting a floating-point
 > +            // number into non-overlapping portions can be
 > +            // accomplished by judicious use of multiplies and
 > +            // additions. For details see T. J. Dekker, A Floating
 > +            // Point Technique for Extending the Available Precision ,
 > +            // Numerische Mathematik, vol. 18, 1971, pp.224-242 and
 > +            // subsequent work.
127c154
< +                if (hb <= Double.MIN_NORMAL) {      // subnormal b or 
0 */
---
 > +                if (b < Double.MIN_NORMAL) {      // subnormal b or 0 */
169a197,205
 > @@ -97,7 +239,7 @@
 >       *      1. Compute and return log2(x) in two pieces:
 >       *              log2(x) = w1 + w2,
 >       *         where w1 has 53 - 24 = 29 bit trailing zeros.
 > -     *      2. Perform y*log2(x) = n+y' by simulating muti-precision
 > +     *      2. Perform y*log2(x) = n+y' by simulating multi-precision
 >       *         arithmetic, where |y'| <= 0.5.
 >       *      3. Return x**y = 2**n*exp(y'*log2)
 >       *

# HypotTests.java

452,460c488,496
< +            {0x1.0p500,             0x1.0p440, 0x1.0p500},
< +            {0x1.0000000000001p500, 0x1.0p440, 0x1.0000000000001p500},
< +            {0x1.0p500,             0x1.0p439, 0x1.0p500},
< +            {0x1.0000000000001p500, 0x1.0p439, 0x1.0000000000001p500},
< +
< +            {0x1.0p-450,             0x1.0p-500, 0x1.0p-450},
< +            {0x1.0000000000001p-450, 0x1.0p-500, 0x1.0000000000001p-450},
< +            {0x1.0p-450,             0x1.fffffffffffffp-499, 0x1.0p-450},
< +            {0x1.0000000000001p-450, 0x1.fffffffffffffp-499, 
0x1.0000000000001p-450},
---
 > +            {0x1.0p500,               0x1.0p440, 0x1.0p500},
 > +            {0x1.0000000000001p500,   0x1.0p440, 0x1.0000000000001p500},
 > +            {0x1.0p500,               0x1.0p439, 0x1.0p500},
 > +            {0x1.0000000000001p500,   0x1.0p439, 0x1.0000000000001p500},
 > +
 > +            {0x1.0p-450,              0x1.0p-500, 0x1.0p-450},
 > +            {0x1.0000000000001p-450,  0x1.0p-500, 
0x1.0000000000001p-450},
 > +            {0x1.0p-450,              0x1.fffffffffffffp-499, 
0x1.0p-450},
 > +            {0x1.0000000000001p-450,  0x1.fffffffffffffp-499, 
0x1.0000000000001p-450},
473a510,518
 > +
 > +            {0x1.0000000000000p-1022, 0x0.fffffffffffffp-1022, 
0x1.6a09e667f3bccp-1022},
 > +            {0x1.0000000000000p-1021, 0x0.fffffffffffffp-1022, 
0x1.1e3779b97f4a8p-1021},
 > +            {0x1.0000000000000p-1020, 0x0.fffffffffffffp-1022, 
0x1.07e0f66afed07p-1020},
 > +
 > +            // 0x0.0000000000001P-1022 is MIN_VALUE (smallest 
nonzero number)
 > +            {0x0.0000000000001p-1022, 0x0.0000000000001p-1022, 
0x0.0000000000001p-1022},
 > +            {0x0.0000000000002p-1022, 0x0.0000000000001p-1022, 
0x0.0000000000002p-1022},
 > +            {0x0.0000000000003p-1022, 0x0.0000000000002p-1022, 
0x0.0000000000004p-1022},


-Joe

On 9/22/2015 4:20 PM, Brian Burkhalter wrote:
> Hi Joe,
>
> Overall this looks good. I only have a couple of minor observations 
> related to internal documentation.
>
> 1. FdLibm.java
>
> Lines 158-166: The verbiage in the note might benefit from a little 
> reworking.
>
> 2. HypotTests.java
>
> Line 46: ?Commutative? is misspelled.
>
> Thanks,
>
> Brian
>
> On Sep 21, 2015, at 6:22 PM, Joseph D. Darcy <Joe.Darcy at Oracle.Com 
> <mailto:Joe.Darcy at Oracle.Com>> wrote:
>
>> Please review the next portion of the port of fdlibm to Java:
>>
>>    JDK-7130085 Port fdlibm hypot to Java
>> http://cr.openjdk.java.net/~darcy/7130085.0/ 
>> <http://cr.openjdk.java.net/%7Edarcy/7130085.0/>
>>
>> As before with pow, this isn't necessarily the end state of the code 
>> we'd like to stop at, but it should be sufficiently idiomatic Java 
>> for an initial port.
>>
>> To make comparison against the original C algorithm easier, I listed 
>> the C version of hypot as the base file to compare FdLibm.java against.
>



From brian.burkhalter at oracle.com  Wed Sep 23 20:45:16 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 23 Sep 2015 13:45:16 -0700
Subject: JDK 9 RFR of JDK-7130085 Port fdlibm hypot to Java
In-Reply-To: <56030C3E.1060904@oracle.com>
References: <5600AD46.5080401@oracle.com>
	<C5E440AE-2CD9-4DB9-BA74-4D1D23371B43@oracle.com>
	<56030C3E.1060904@oracle.com>
Message-ID: <CE2CDF52-C402-45D3-A42C-CBF2920C8A86@oracle.com>

Hi Joe,

This looks fine.

Brian

On Sep 23, 2015, at 1:31 PM, joe darcy <joe.darcy at oracle.com> wrote:

> Thanks for the review; I plan to push a slightly amended version later today. The new version
> 
> * rewords the paragraph you suggested
> * declares the method strictfp
> * fixes a comparison that mixes integer and floating-point values
> * add more test cases near the subnormal threshold
> 
> Diff of patches below.



From mandy.chung at oracle.com  Wed Sep 23 21:31:35 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 23 Sep 2015 14:31:35 -0700
Subject: RFR: 8033661: readConfiguration does not cleanly reinitialize the
	logging system
In-Reply-To: <56030A58.7000403@oracle.com>
References: <55F06497.5010300@oracle.com>
	<1F185ECE-B5B1-4175-ABAA-B86FCD0861EC@oracle.com>
	<55F6F517.8000100@oracle.com>
	<EBE38931-6036-4908-8C50-9F7C8B34E729@oracle.com>
	<56018174.1090603@oracle.com> <5601DE0A.9060707@oracle.com>
	<5602BC40.6060308@oracle.com> <56030A58.7000403@oracle.com>
Message-ID: <33B916D3-5248-4F01-A261-D06E663FE00A@oracle.com>


> On Sep 23, 2015, at 1:23 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8033661/webrev.03/


Thanks.  Looks good.

Minor comments that you can fix before you push.  No need to send a new webrev:

This statement occurs in a couple places:
   "The function f may return null to indicate that the property k should not be added to the resulting configuration."

s/should/will

"LogManager properties are updated with the resulting value in the resulting configuration.? is in the middle of specifying the details of the mapper.   Maybe moving it to before ?The registered configuration listeners?.?.

Mandy

From paul.sandoz at oracle.com  Wed Sep 23 21:41:15 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 23 Sep 2015 23:41:15 +0200
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>
	<CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>
Message-ID: <F57BEACF-282F-41C6-B5CA-5BA9A09BF2C4@oracle.com>

On 23 Sep 2015, at 21:33, Martin Buchholz <martinrb at google.com> wrote:

> 
> 
> On Wed, Sep 23, 2015 at 3:16 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Hi,
> 
> I trawled through the patches and could not find anything obvious that clobbered existing JDK stuff.
> 
> In the misc/locks patches there are some classes that might contain spec changes:
> 
>   ConcurrentLinkedDeque
>   CopyOnWriteArraySet
>   ScheduledExecutorService
>   ScheduledThreadPoolExecutor
> 
>   LockSupport
>   ReentrantReadWriteLock
> 
> Any opinions? sometimes it?s a fine line between a clarification and a spec update.
> 
> 
> Right. jsr166 bulk updates generally contain so many diverse changes that I always just assume a CCC would be required (in the past, this was done via a single request instead of split up as we are doing here).
> 
> If you generate a public specdiff (as I believe only Oracle folks can), it would be easier for all of us to review the spec changes.
> 

Yes, Roger also suggested the same to me off list. May happen tomorrow.


> 
> 
> There are some new methods we need to track in the following classes:
> 
>   LinkedTransferQueue
>   SynchronousQueue
> 
> 
> Those aren't "really" new methods - just new drop-in implementations of existing interface methods like toString(), with no new real spec content.  But yeah, a grey area.

Ok.


> 
> 
> In ThreadPoolExecutor there is style used to declare a set of fonts:
> 
>  249  * <dd style="font-family:'DejaVu Sans', Arial, Helvetica, sans-serif">
>  250  * This class provides {@code protected} overridable
>  251  * {@link #beforeExecute(Thread, Runnable)} and
> 
> Is that necessary?
> 
> 
> Compare and contrast:
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/ThreadPoolExecutor.html
> http://download.java.net/jdk9/docs/api/java/util/concurrent/ThreadPoolExecutor.html
> 
> This is a workaround for
> https://bugs.openjdk.java.net/browse/JDK-8136434
> javadoc should not use a monotype font for <dd> elements
> 

Thanks, i changed that issue from an enhancement to a bug. I have also noticed some rendering issues with the @apiNote etc. Ideally i wish we could just fix the javadoc generation rather than having to work around them.


> 
> In Helpers:
> 
>  121     private static String newStringUnsafe(char[] chars) {
>  122         // If porting to a JDK where sun.misc.SharedSecrets is not
>  123         // available, modify the code below to simply:
>  124         // return new String(chars);
>  125         // TODO: Can we do this more portably?
>  126         return sun.misc.SharedSecrets.getJavaLangAccess().newStringUnsafe(chars);
>  127     }
> 
> Yes, you can do this more portably *and* safely by not using it! :-)
> 
> Do we really really need to use SharedSecrets? IMO this unsafe dependency should be removed in the JDK patch.
> 
> Of course, this is "just" a (relatively unimportant) performance optimization.

Keeping focus, i think the first question to be asked is whether for a particular use-case unsafe String construction is really necessary, and in this case i strongly suspect the answer is no.

Paul.

> Should only classes in java.lang get to use the constructor  String(char[] value, boolean share)?
> Will there be a jigsaw-blessed way of creating Strings this way from "trusted" modules?
> More generally, will there be a blessed way to provide relatively unsafe access to code you trust?
> Will hotspot be smart enough to elide the allocation by proving the input array is never used again?
> 




From martinrb at google.com  Wed Sep 23 21:55:46 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 23 Sep 2015 14:55:46 -0700
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <5D166E5C-FDED-41AC-ABD1-ACA3AEA3709B@oracle.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>
	<CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>
	<5D166E5C-FDED-41AC-ABD1-ACA3AEA3709B@oracle.com>
Message-ID: <CA+kOe0-BTPOvY8uBgASVtjDaPGkTRy0dObZQFzHxxvtj=eNM-A@mail.gmail.com>

On Wed, Sep 23, 2015 at 1:05 PM, Chris Hegarty <chris.hegarty at oracle.com>
wrote:

>
> Right. jsr166 bulk updates generally contain so many diverse changes that I
> always just assume a CCC would be required (in the past, this was done via
> a single request instead of split up as we are doing here).
>
>
> For 8 we separated out the tasks into several subtasks ( and CCC?s ) as
> being done here. This worked well, at least from my point of view. See
> https://bugs.openjdk.java.net/browse/JDK-8001566
>
>
Sorry, you're right.  My faulty memory was probably recalling my own
efforts in jdk6 or jdk7.

Looking more closely at the jdk8 jsr166 integration ...
The upstream integration of the code itself looks complete, but ...
- some tests didn't make it, e.g. ArrayBlockingQueue.java was integrated,
but the accompanying test ArrayBlockingQueue/IteratorConsistency.java is
only now being integrated.
- some changes made upstream weren't merged downstream (I tried to find all
such for this integration)


From martinrb at google.com  Wed Sep 23 22:22:11 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 23 Sep 2015 15:22:11 -0700
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <F57BEACF-282F-41C6-B5CA-5BA9A09BF2C4@oracle.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>
	<CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>
	<F57BEACF-282F-41C6-B5CA-5BA9A09BF2C4@oracle.com>
Message-ID: <CA+kOe0_JJZQUGXswunt0AMj-YFPnp5_nWFN8cGr-XMogVeSEzw@mail.gmail.com>

On Wed, Sep 23, 2015 at 2:41 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> On 23 Sep 2015, at 21:33, Martin Buchholz <martinrb at google.com> wrote:
>
>
>>
>> In Helpers:
>>
>>  121     private static String newStringUnsafe(char[] chars) {
>>  122         // If porting to a JDK where sun.misc.SharedSecrets is not
>>  123         // available, modify the code below to simply:
>>  124         // return new String(chars);
>>  125         // TODO: Can we do this more portably?
>>  126         return
>> sun.misc.SharedSecrets.getJavaLangAccess().newStringUnsafe(chars);
>>  127     }
>>
>> Yes, you can do this more portably *and* safely by not using it! :-)
>>
>> Do we really really need to use SharedSecrets? IMO this unsafe dependency
>> should be removed in the JDK patch.
>
>
> Of course, this is "just" a (relatively unimportant) performance
> optimization.
>
>
> Keeping focus, i think the first question to be asked is whether for a
> particular use-case unsafe String construction is really necessary, and in
> this case i strongly suspect the answer is no.
>
>
We're maintaining a low-level library, with great attention to
performance.  You never know if there's a user who's printing/logging bound.

Anyways, you feel  strongly about this, so ... they're gone!  Webrevs
updated.


From mark.reinhold at oracle.com  Wed Sep 23 23:39:00 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 23 Sep 2015 16:39:00 -0700 (PDT)
Subject: JEP 268: XML Catalogs
Message-ID: <20150923233900.7913B7A314@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/268

- Mark


From mark.reinhold at oracle.com  Thu Sep 24 00:02:17 2015
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 23 Sep 2015 17:02:17 -0700 (PDT)
Subject: JEP 269: Convenience Factory Methods for Collections
Message-ID: <20150924000217.D476B7A327@eggemoggin.niobe.net>

New JEP Candidate: http://openjdk.java.net/jeps/269

- Mark


From martinrb at google.com  Thu Sep 24 03:10:03 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 23 Sep 2015 20:10:03 -0700
Subject: RFR [9] 8133651: replace some <tt> tags (obsolete in html5) in
	core-libs docs
In-Reply-To: <55FD69F6.7080009@oracle.com>
References: <55FD69F6.7080009@oracle.com>
Message-ID: <CA+kOe096bz9coWnJc+cB5wPDjmV53n88GXDSmMGDXSvo6PCx4Q@mail.gmail.com>

On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov <
alexander.v.stepanov at oracle.com> wrote:

> Hello,
>
> Could you please review the following fix
> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/
> http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html
> for
> https://bugs.openjdk.java.net/browse/JDK-8133651
>
> Just another portion of deprecated <tt> (and <xmp>) tags replaced with
> {@code }. Some misprints were also fixed.
>

I'm biased of course, but I like the approach I took with
blessed-modifier-order:
- make the change completely automated
- leave "human editing" for a separate change
- publish the code used to make the automated change (in my case, typically
a perl one-liner)


>
> The following (expected) changes were detected by specdiff:
> - removed needless dashes in java.util.Locale,
> - removed needless curly brace in xml.bind.annotation.XmlElementRef
>

I would do a separate automated "removed needless dashes" changeset.


> Please let me know if the following changes are desirable or not:
>
> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html


This is an actual change to the behavior of this code - the maintainers of
jconsole need to approve it.  It's probably correct, but I would have left
it out of this change. If you remove it, then I approve this change.


From paul.sandoz at oracle.com  Thu Sep 24 07:40:20 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 24 Sep 2015 09:40:20 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <4E159761-DDA7-4849-9816-18037FC53D33@univ-mlv.fr>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<0ED64734-7F73-4E8B-9900-7B444E8629C8@oracle.com>
	<1086772691.995036.1442963899414.JavaMail.zimbra@u-pem.fr>
	<D8ACE863-4234-4E3F-A2BA-795679BBF480@oracle.com>
	<4E159761-DDA7-4849-9816-18037FC53D33@univ-mlv.fr>
Message-ID: <EF6119C1-3369-40CA-89A6-BF71C5E46EFC@oracle.com>

On 23 Sep 2015, at 18:11, R?mi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Because i want to support the simple cases without pulling in indy.
> 
> and what about using an anonymous class instead ?
> 

Not an anonymous one, but i think i know what you mean :-)

Also, i don?t want to impose a null check of the exception mapping function for every call, which would push the null check to when the values are out of bounds, and throwing an NPE in such cases seems mean when one can easily throw IOOBE instead.


> I suppose that the other solution is to special case invokedynamic if the method handle is a constant to avoid to awake the lambda form beast :)
> 
>> 
>> 
>>>> 
>>>> - Add 2 argument constructors to
>> Array/String/IndexOutOfBoundsException, thus
>>>> allowing support for method refs.
>>>> 
>>>> Remi, i left the generic signatures as is, i am presuming there is
>> an
>>>> advantage to naming T, rather than using a wildcard e.g. IDEs could
>> use that
>>>> information (although IntelliJ does not appear to do so at the
>> moment).
>>> 
>>> I don't get it. Why it's important for an IDE to know that a code
>> throws a precise *runtime* exception. Any codes can throw any runtime
>> exceptions.
>>> 
>> 
>> It could aid code completion e.g. wrap in try/catch or analysis of what
>> runtime exceptions propagate.
>> 
>> Perhaps this is a rare case, but in general, why loose such
>> information?
> 
> Wrapping runtime exceptions in a try/catch is usually a bad idea.

It?s not just wrapping but also knowing that such exceptions propagate. For example, a tool might signal that a public method using checkIndex might want also to document the throwing of IOOBE etc.


> Runtime exceptions are raised because of developer mistakes.
> In my dream world, you can replace all runtime exceptions by one single RTFM exception without introducing any bugs in your programs :)
> 

Good luck!


> And any analysis will fall short because you don't have to propagate runtime exceptions.
> 
>> 
>> Are you concerned that the method signatures look odd in code and in
>> JavaDoc?
> 
> yes, reading a signature with a wildcard is easier than a signature with a type variable, half of my students just pretend '?' doesn't exist ?
> 

I tend to prefer the explicit naming (FWIW Valhalla might push us more in that direction), they look fine in source code, it?s the JavaDoc that looks odd to me and that could be fixed.

My main motivation here was not to loose static information. However, as you point out that is of less importance with runtime exceptions. Hmm...

Paul.


From paul.sandoz at oracle.com  Thu Sep 24 08:35:55 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 24 Sep 2015 10:35:55 +0200
Subject: specdiff <was> Re: RFR: jsr166 openjdk9 integration
In-Reply-To: <F57BEACF-282F-41C6-B5CA-5BA9A09BF2C4@oracle.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>
	<CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>
	<F57BEACF-282F-41C6-B5CA-5BA9A09BF2C4@oracle.com>
Message-ID: <6C860453-A0EB-46FB-AB75-CB57FA4E82FE@oracle.com>

On 23 Sep 2015, at 23:41, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>> If you generate a public specdiff (as I believe only Oracle folks can), it would be easier for all of us to review the spec changes.
>> 
> 
> Yes, Roger also suggested the same to me off list. May happen tomorrow.
> 

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8132960-166-updates/specdiff/overview-summary.html

Paul.


From chris.hegarty at oracle.com  Thu Sep 24 09:06:36 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 24 Sep 2015 10:06:36 +0100
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <EF6119C1-3369-40CA-89A6-BF71C5E46EFC@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<0ED64734-7F73-4E8B-9900-7B444E8629C8@oracle.com>
	<1086772691.995036.1442963899414.JavaMail.zimbra@u-pem.fr>
	<D8ACE863-4234-4E3F-A2BA-795679BBF480@oracle.com>
	<4E159761-DDA7-4849-9816-18037FC53D33@univ-mlv.fr>
	<EF6119C1-3369-40CA-89A6-BF71C5E46EFC@oracle.com>
Message-ID: <234E0B3D-CBDB-4278-A070-8ACFD70DA1F6@oracle.com>

On 24 Sep 2015, at 08:40, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> On 23 Sep 2015, at 18:11, R?mi Forax <forax at univ-mlv.fr> wrote:
>>> 
>>> Because i want to support the simple cases without pulling in indy.
>> 
>> and what about using an anonymous class instead ?
>> 
> 
> Not an anonymous one, but i think i know what you mean :-)
> 
> Also, i don?t want to impose a null check of the exception mapping function for every call, which would push the null check to when the values are out of bounds, and throwing an NPE in such cases seems mean when one can easily throw IOOBE instead.

This does seem to be one of the rare cases where accepting null is the lesser of two evils, given the expected usage of the API.

A few other minor comments:

 1)  ?.. are provided for the convenience of checking if values
       corresponding TO indexes and sub-ranges are out of bounds.?

 2) @since 9 ?? Is this the expected release value given Verona.

 3) Trailing DOT
     77      * @param a the first out of bound valueDOT
     78      * @param b the second out of bound valueDOT

 4) "MapS out of bounds values to a runtime exceptionS."

 5) "CheckS if the {@code index} is within?"

 6) ArrayIndexOutOfBoundsException
     "Constructs ? CLASS WITH WITH ?"

-Chris.

From paul.sandoz at oracle.com  Thu Sep 24 09:30:22 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 24 Sep 2015 11:30:22 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <234E0B3D-CBDB-4278-A070-8ACFD70DA1F6@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<0ED64734-7F73-4E8B-9900-7B444E8629C8@oracle.com>
	<1086772691.995036.1442963899414.JavaMail.zimbra@u-pem.fr>
	<D8ACE863-4234-4E3F-A2BA-795679BBF480@oracle.com>
	<4E159761-DDA7-4849-9816-18037FC53D33@univ-mlv.fr>
	<EF6119C1-3369-40CA-89A6-BF71C5E46EFC@oracle.com>
	<234E0B3D-CBDB-4278-A070-8ACFD70DA1F6@oracle.com>
Message-ID: <520B4A4D-61AF-4598-B662-88A9A04C15EB@oracle.com>


On 24 Sep 2015, at 11:06, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 24 Sep 2015, at 08:40, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
>> On 23 Sep 2015, at 18:11, R?mi Forax <forax at univ-mlv.fr> wrote:
>>>> 
>>>> Because i want to support the simple cases without pulling in indy.
>>> 
>>> and what about using an anonymous class instead ?
>>> 
>> 
>> Not an anonymous one, but i think i know what you mean :-)
>> 
>> Also, i don?t want to impose a null check of the exception mapping function for every call, which would push the null check to when the values are out of bounds, and throwing an NPE in such cases seems mean when one can easily throw IOOBE instead.
> 
> This does seem to be one of the rare cases where accepting null is the lesser of two evils, given the expected usage of the API.
> 
> A few other minor comments:
> 
> 1)  ?.. are provided for the convenience of checking if values
>       corresponding TO indexes and sub-ranges are out of bounds.?
> 

> 2) @since 9 ?? Is this the expected release value given Verona.
> 

Yes, i was anticipating that.


> 3) Trailing DOT
>     77      * @param a the first out of bound valueDOT
>     78      * @param b the second out of bound valueDOT
> 
> 4) "MapS out of bounds values to a runtime exceptionS."
> 
> 5) "CheckS if the {@code index} is within?"
> 
> 6) ArrayIndexOutOfBoundsException
>     "Constructs ? CLASS WITH WITH ??
> 

Updated (test also moved to a more appropriate location):

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/webrev/

Thanks,
Paul.


From alexander.v.stepanov at oracle.com  Thu Sep 24 12:06:03 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Thu, 24 Sep 2015 15:06:03 +0300
Subject: RFR [9] 8133651: replace some <tt> tags (obsolete in html5) in
	core-libs docs
In-Reply-To: <CA+kOe096bz9coWnJc+cB5wPDjmV53n88GXDSmMGDXSvo6PCx4Q@mail.gmail.com>
References: <55FD69F6.7080009@oracle.com>
	<CA+kOe096bz9coWnJc+cB5wPDjmV53n88GXDSmMGDXSvo6PCx4Q@mail.gmail.com>
Message-ID: <5603E72B.2000506@oracle.com>

Hello Martin,

Thank you for review and for the notes!

 > I'm biased of course, but I like the approach I took with 
blessed-modifier-order:
 > - make the change completely automated
 > - leave "human editing" for a separate change
 > - publish the code used to make the automated change (in my case, 
typically a perl one-liner)

Automated replacement has an obvious advantage: it is fast and massive. 
But there are some disadvantages at the same time (just IMHO).

Using script it is quite easy to miss some not very trivial cases, e.g.:
- remove unnecessary linebreaks, like
  * <tt>someCode
  * </tt>
(which would be better to replace with single-line {@code someCode};
- joining of successive terms, like "<tt>ONE</tt>, <tt>TWO</tt>, 
<tt>THREE</tt>" -> "{@code ONE, TWO, THREE}";
- errors like extra or missing "&lt;" or "&gt;": * <tt>Collection 
&lt;T></tt>", - there were a lot of them;
- some cases when <tt></tt> should be replaced with <code></code>, not 
{@code } (e.g. because of unicode characters inside of code etc.);
- extra tags inside of <tt> or <code> which should be moved outside of 
{@code }, like <tt><i>someCode</i></tt> or <tt><b>someCode</b></tt>;
- simple removing of needless tags, like "<tt>{@link ...}</tt>" -> 
"{@link ...}";
- replace HTML codes with symbols ('<', '>', '@', ...)
- etc.
- plus some other formatting changes and fixes for misprints which would 
be omitted during the automated replacement (and wouldn't be done in 
future manually because there is no motivation for repeated processing).

So sometimes it may be difficult to say where is the border between 
"trivial" and "human-editing" cases (and the portion of "non-trivial 
cases" is definitely not minor); moreover, even the automated 
replacement requires the subsequent careful review before publishing of 
webrev (as well as by reviewers who probably wouldn't be happy to review 
hundreds of files at the same time) and iterative checks/corrections. 
specdiff is very useful for this task but also cannot fully cover the 
diffs (as some changes are situated in the internal com/... sun/... 
packages).

Moreover, I'm sure that some reviewers would be annoyed with the fact 
that some (quite simple) changes were postponed because they are "not 
too trivial to be fixed just now" (because they will suspect they would 
be postponed forever). So the patch creator would (probably) receive 
some advices during the review like "please fix also fix this and that" 
(which is normal, of course).

So my preference was to make the changes package by package (in some 
reasonable amount of files) not postponing part of the changes for the 
future (sorry for these boring repeating review requests). Please note 
that all the above mentioned is *rather explanation of my motivation 
than objection* :) (and of course I used some text editor replace 
automation which is surely not so advanced as Perl).

 > It's probably correct, but I would have left it out of this change
Yes, I see. Reverted (please update the web page):
http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html

Thanks,
Alexander

P.S. The <tt> replacement job is mostly (I guess, ~80%) complete. But 
probably this approach should be used if some similar replacement task 
for, e.g., <code></code> tags would be planned in future (there are 
thousands of them).


On 9/24/2015 6:10 AM, Martin Buchholz wrote:
>
>
> On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov 
> <alexander.v.stepanov at oracle.com 
> <mailto:alexander.v.stepanov at oracle.com>> wrote:
>
>     Hello,
>
>     Could you please review the following fix
>     http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/
>     <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/>
>     http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html
>     <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html>
>     for
>     https://bugs.openjdk.java.net/browse/JDK-8133651
>
>     Just another portion of deprecated <tt> (and <xmp>) tags replaced
>     with {@code }. Some misprints were also fixed.
>
>
> I'm biased of course, but I like the approach I took with 
> blessed-modifier-order:
> - make the change completely automated
> - leave "human editing" for a separate change
> - publish the code used to make the automated change (in my case, 
> typically a perl one-liner)
>
>
>     The following (expected) changes were detected by specdiff:
>     - removed needless dashes in java.util.Locale,
>     - removed needless curly brace in xml.bind.annotation.XmlElementRef
>
>
> I would do a separate automated "removed needless dashes" changeset.
>
>
>     Please let me know if the following changes are desirable or not:
>     http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html
>     <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html>
>
>
> This is an actual change to the behavior of this code - the 
> maintainers of jconsole need to approve it.  It's probably correct, 
> but I would have left it out of this change. If you remove it, then I 
> approve this change.



From paul.sandoz at oracle.com  Thu Sep 24 12:43:17 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 24 Sep 2015 14:43:17 +0200
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
Message-ID: <D9982CCF-0F8F-4E85-8DCD-4463DBDA933A@oracle.com>

I ran the patches through JPRT.

I am noticing one test failure that i cannot reproduce locally but reproduces on some test machines.

java.lang.Exception: Stack trace
	at java.lang.Thread.dumpStack(Thread.java:1335)
	at FlakyThreadFactory.fail(FlakyThreadFactory.java:93)
	at FlakyThreadFactory.check(FlakyThreadFactory.java:96)
	at FlakyThreadFactory.test(FlakyThreadFactory.java:81)
	at FlakyThreadFactory.test(FlakyThreadFactory.java:49)
	at FlakyThreadFactory.instanceMain(FlakyThreadFactory.java:103)
	at FlakyThreadFactory.main(FlakyThreadFactory.java:101)
	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:519)
	at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:218)
	at java.lang.Thread.run(Thread.java:746)
java.lang.AssertionError: Some tests failed
	at FlakyThreadFactory.instanceMain(FlakyThreadFactory.java:105)
	at FlakyThreadFactory.main(FlakyThreadFactory.java:101)
	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:519)
	at com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:218)
	at java.lang.Thread.run(Thread.java:746)

That is related to this test:

test(OutOfMemoryError.class,
     new ThreadFactory() {
        public Thread newThread(Runnable r) {
            // "guarantee" OutOfMemoryError
            return new Thread(null, r, "bloated", 1L << 60);
        }});

Where the submission of tasks succeeds and it such cases it expects that the expected exception is null, rather than OutOfMemoryError.

The stackSize parameter on the Thread constructor seems more of a hint and can be processed in a platform specific way, so i am not sure it can be relied upon to produce an OutOfMemoryError, e.g. on Thread:

* <p>The virtual machine is free to treat the {@code stackSize}
* parameter as a suggestion.  If the specified value is unreasonably low
* for the platform, the virtual machine may instead use some
* platform-specific minimum value; if the specified value is unreasonably
* high, the virtual machine may instead use some platform-specific
* maximum.  Likewise, the virtual machine is free to round the specified
* value up or down as it sees fit (or to ignore it completely).

Paul.

On 21 Sep 2015, at 20:34, Martin Buchholz <martinrb at google.com> wrote:

> This is the long-delayed and long-awaited bulk integration for jdk9 from jsr166 CVS.
> 
> Find webrevs here:
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
> 
> Sorry about the extreme size and tardiness of this integration.
> 
> As a review convenience, I provided a diff-wbB file that contains all the jsr166 integration changes using "hg diff -wbB" that ignores whitespace changes.
> 
> We will need JPRT+specdiff+CCC from Oracle folks
> 
> All changes are subtasks of:
> https://bugs.openjdk.java.net/browse/JDK-8132960



From Roger.Riggs at Oracle.com  Thu Sep 24 13:23:20 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 24 Sep 2015 09:23:20 -0400
Subject: RFR 9: 8129744 : Documentation in Month refers to quarters
Message-ID: <5603F948.4030606@Oracle.com>

Please review two java.time editorial changes:
   - 8129744: a trivial editorial change in java.time.Month javadoc.
   - 8129556: TemporalAdjusters dayOfWeekInMonth wrongly says "in the 
same month"

Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-months-8129744/

Issue:
   https://bugs.openjdk.java.net/browse/JDK-8129744

Thanks, Roger



From miroslav.kos at oracle.com  Thu Sep 24 13:57:33 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Thu, 24 Sep 2015 15:57:33 +0200
Subject: [9] RFR: 8061466 - RELAX NG API visible but not accessible
Message-ID: <5604014D.6040700@oracle.com>

Hi everybody,

I'd like to ask for review of following fix:

RELAX NG API visible but not accessible
JBS: https://bugs.openjdk.java.net/browse/JDK-8061466
webrev: http://cr.openjdk.java.net/~mkos/8061466/jaxws.01/index.html

- org.relaxng.* classes in jdk.xml.bind module are not repackaged, but 
those are not exported so they are not usable outside of module (jdk) anyway
- processing RelaxNG schemas with JAX-B's declared as 
experimental/unsupported, but removing these classes is not easy since 
several other packages within JAX-B depend on those ...

This patch repackages these classes from org.relaxng.* to 
com.sun.xml.internal.org.relaxng.* + removes loading RelaxNG runtime in 
xjc (+ removing related messages).

Testing: snadalone JAX-B/WS tests, JAX-WS JCK, jtreg, no regressions.

Thanks
Miran




From chris.hegarty at oracle.com  Thu Sep 24 14:09:17 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 24 Sep 2015 15:09:17 +0100
Subject: [9] RFR: 8061466 - RELAX NG API visible but not accessible
In-Reply-To: <5604014D.6040700@oracle.com>
References: <5604014D.6040700@oracle.com>
Message-ID: <E2108DAA-57EC-45FA-9D3F-9D8385EBCE4F@oracle.com>

Miran,

Did you use 'hg mv?? if so, then webrev ( without a file.list ) typically
picks up that the file has moved and only highlights the differences.
This typically helps with the review.

-Chris.

On 24 Sep 2015, at 14:57, Miroslav Kos <miroslav.kos at oracle.com> wrote:

> Hi everybody,
> 
> I'd like to ask for review of following fix:
> 
> RELAX NG API visible but not accessible
> JBS: https://bugs.openjdk.java.net/browse/JDK-8061466
> webrev: http://cr.openjdk.java.net/~mkos/8061466/jaxws.01/index.html
> 
> - org.relaxng.* classes in jdk.xml.bind module are not repackaged, but those are not exported so they are not usable outside of module (jdk) anyway
> - processing RelaxNG schemas with JAX-B's declared as experimental/unsupported, but removing these classes is not easy since several other packages within JAX-B depend on those ...
> 
> This patch repackages these classes from org.relaxng.* to com.sun.xml.internal.org.relaxng.* + removes loading RelaxNG runtime in xjc (+ removing related messages).
> 
> Testing: snadalone JAX-B/WS tests, JAX-WS JCK, jtreg, no regressions.
> 
> Thanks
> Miran
> 
> 



From rob.mckenna at oracle.com  Thu Sep 24 14:10:45 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 24 Sep 2015 15:10:45 +0100
Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr
	in getLastErrorString
In-Reply-To: <5602A5AF.6030409@oracle.com>
References: <5600280C.9040601@oracle.com> <5602A5AF.6030409@oracle.com>
Message-ID: <56040465.10403@oracle.com>

Hi folks,

Uploaded a newer version:

http://cr.openjdk.java.net/~robm/8133249/webrev.02/

To address Rogers question, this needed to be separate from 
getLastErrorString because of the return type and the err arg, but I 
like the idea of avoiding the creation of a new file. Also, all of the 
files that require the new function (now called getErrorString) already 
include jni_util.c so it makes sense to put this in jni_util_md.c with 
getLastErrorString.

As per Christos' suggestion I've mapped strerr_r to __xpg_strerror_r 
instead of using the gnu strerror_r. I'd be interested to hear feedback 
on this change.

I've corrected the oversights around the jli sources and 
PlainDatagramSocket. The jli stuff shouldn't have been there in the 
first place.

Ivan, I've kept the return type. As you note, I should have been using 
it in ProcessImpl_md.c and the extra information from the return is 
potentially useful.

	-Rob

On 23/09/15 14:14, Ivan Gerasimov wrote:
> Hi Rob!
>
> On 21.09.2015 18:53, Rob McKenna wrote:
>> Hi folks,
>>
>> Requesting a review of this change which switches corelibs usages of
>> the thread-unsafe strerror over to strerror_r/strerror_s:
>>
>> http://cr.openjdk.java.net/~robm/8133249/webrev.01/
>>
>
> I think it would be better to have  jdk_strerror(errno, tmpbuf,
> sizeof(tmpbuf))  instead of  jdk_strerror(errno, tmpbuf, (size_t) 1024),
> just for the sake of avoiding constant duplication.
> I don't see the return code of jdk_strerror() is ever used. I suggest
> using it in ProcessImpl_md.c (see below), or just making this function
> return void.
>
> jni_util_md.c:
> - why can't we just call  jdk_strerror(errno, buf, len)  and get rid of
> the temp buffer?
>
> java_md_common.c:
> - commented out #include @ line 26
> - the change in JLI_ReportErrorMessageSys() looks incomplete
>
> ProcessImpl_md.c:
> - would it make sense to check if jdk_strerror() == EINVAL instead of
> comparing the strings?
>
> PlainDatagramSocketImpl.c:
> - #include added, but no other changes were made.
>
> TwoStacksPlainDatagramSocketImpl.c:
> - buf is declared to be char[1024], but only up to 255 chars are used.
> - would be better to move the buf declaration closer to its use, maybe
> next to char errmsg[300] line?
>
> jdk_strerror.c:
> - minor nit: extra space after strerror_r at lines 46 and 63.
>
> Sincerely yours,
> Ivan
>


From chris.hegarty at oracle.com  Thu Sep 24 14:16:39 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 24 Sep 2015 15:16:39 +0100
Subject: RFR [9] 8137056: Move SharedSecrets and interface friends out of
	sun.misc
Message-ID: <5938CBAC-F63C-429A-8258-E4A5D02C3142@oracle.com>

In preparation for JEP 260 "Encapsulate Most Internal APIs? [1],
SharedSecrets and friend interfaces should be moved out of
'sun.misc? [2] and located in a truly private package. This is so that
they are not part of the proposed to be exported ?sun.misc'
package.

http://cr.openjdk.java.net/~chegar/8137056.00/

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8132928
[2] https://bugs.openjdk.java.net/browse/JDK-8137056

From chris.hegarty at oracle.com  Thu Sep 24 14:19:53 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 24 Sep 2015 15:19:53 +0100
Subject: RFR 9: 8129744 : Documentation in Month refers to quarters
In-Reply-To: <5603F948.4030606@Oracle.com>
References: <5603F948.4030606@Oracle.com>
Message-ID: <CFA7D062-8D22-4724-A341-96C39E529AD1@oracle.com>

The changes look good to me Roger.

-Chris.

On 24 Sep 2015, at 14:23, Roger Riggs <Roger.Riggs at oracle.com> wrote:

> Please review two java.time editorial changes:
>  - 8129744: a trivial editorial change in java.time.Month javadoc.
>  - 8129556: TemporalAdjusters dayOfWeekInMonth wrongly says "in the same month"
> 
> Webrev:
>  http://cr.openjdk.java.net/~rriggs/webrev-months-8129744/
> 
> Issue:
>  https://bugs.openjdk.java.net/browse/JDK-8129744
> 
> Thanks, Roger
> 



From Alan.Bateman at oracle.com  Thu Sep 24 14:20:51 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 24 Sep 2015 15:20:51 +0100
Subject: [9] RFR: 8061466 - RELAX NG API visible but not accessible
In-Reply-To: <5604014D.6040700@oracle.com>
References: <5604014D.6040700@oracle.com>
Message-ID: <560406C3.4020001@oracle.com>

On 24/09/2015 14:57, Miroslav Kos wrote:
> Hi everybody,
>
> I'd like to ask for review of following fix:
>
> RELAX NG API visible but not accessible
> JBS: https://bugs.openjdk.java.net/browse/JDK-8061466
> webrev: http://cr.openjdk.java.net/~mkos/8061466/jaxws.01/index.html
>
> - org.relaxng.* classes in jdk.xml.bind module are not repackaged, but 
> those are not exported so they are not usable outside of module (jdk) 
> anyway
> - processing RelaxNG schemas with JAX-B's declared as 
> experimental/unsupported, but removing these classes is not easy since 
> several other packages within JAX-B depend on those ...
>
> This patch repackages these classes from org.relaxng.* to 
> com.sun.xml.internal.org.relaxng.* + removes loading RelaxNG runtime 
> in xjc (+ removing related messages).
Good to see these classes being renamed. I agree with Chris that this 
should be hg mv so that the history is preserved.

The proposed package name seems okay to me, if only because the internal 
classes in this area are already using com.sun.xml.internal. If this 
wasn't the case then the jdk or jdk.internal tree would have been 
appropriate.

-Alan.


From Roger.Riggs at Oracle.com  Thu Sep 24 14:34:20 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 24 Sep 2015 10:34:20 -0400
Subject: RFR [9] 8137056: Move SharedSecrets and interface friends out of
	sun.misc
In-Reply-To: <5938CBAC-F63C-429A-8258-E4A5D02C3142@oracle.com>
References: <5938CBAC-F63C-429A-8258-E4A5D02C3142@oracle.com>
Message-ID: <560409EC.9050608@Oracle.com>

Hi Chris,

Looks ok.

Roger


On 9/24/2015 10:16 AM, Chris Hegarty wrote:
> In preparation for JEP 260 "Encapsulate Most Internal APIs? [1],
> SharedSecrets and friend interfaces should be moved out of
> 'sun.misc? [2] and located in a truly private package. This is so that
> they are not part of the proposed to be exported ?sun.misc'
> package.
>
> http://cr.openjdk.java.net/~chegar/8137056.00/
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8132928
> [2] https://bugs.openjdk.java.net/browse/JDK-8137056



From Alan.Bateman at oracle.com  Thu Sep 24 14:37:54 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 24 Sep 2015 15:37:54 +0100
Subject: RFR [9] 8137056: Move SharedSecrets and interface friends out
	of sun.misc
In-Reply-To: <5938CBAC-F63C-429A-8258-E4A5D02C3142@oracle.com>
References: <5938CBAC-F63C-429A-8258-E4A5D02C3142@oracle.com>
Message-ID: <56040AC2.4080302@oracle.com>

On 24/09/2015 15:16, Chris Hegarty wrote:
> In preparation for JEP 260 "Encapsulate Most Internal APIs? [1],
> SharedSecrets and friend interfaces should be moved out of
> 'sun.misc? [2] and located in a truly private package. This is so that
> they are not part of the proposed to be exported ?sun.misc'
> package.
>
> http://cr.openjdk.java.net/~chegar/8137056.00/
>
This looks okay to me, just a minor nit in PresentationManager where 
you've introduced a raw type. If we can drop the building of the interim 
CORBA then this code could be cleaned up to not use core reflection.

-Alan.


From scolebourne at joda.org  Thu Sep 24 14:37:44 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 24 Sep 2015 15:37:44 +0100
Subject: RFR 9: 8129744 : Documentation in Month refers to quarters
In-Reply-To: <5603F948.4030606@Oracle.com>
References: <5603F948.4030606@Oracle.com>
Message-ID: <CACzrW9AUHvHws6rvgnJSrRYj6_kN7F2HVxR+BXPd-Nad5LQstA@mail.gmail.com>

+1
Stephen

On 24 September 2015 at 14:23, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Please review two java.time editorial changes:
>   - 8129744: a trivial editorial change in java.time.Month javadoc.
>   - 8129556: TemporalAdjusters dayOfWeekInMonth wrongly says "in the same
> month"
>
> Webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-months-8129744/
>
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8129744
>
> Thanks, Roger
>


From chris.hegarty at oracle.com  Thu Sep 24 14:56:37 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 24 Sep 2015 15:56:37 +0100
Subject: RFR [9] 8137056: Move SharedSecrets and interface friends out of
	sun.misc
In-Reply-To: <56040AC2.4080302@oracle.com>
References: <5938CBAC-F63C-429A-8258-E4A5D02C3142@oracle.com>
	<56040AC2.4080302@oracle.com>
Message-ID: <E88291C2-722D-4849-BC6A-D321E9A2CD7F@oracle.com>

On 24 Sep 2015, at 15:37, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 24/09/2015 15:16, Chris Hegarty wrote:
>> In preparation for JEP 260 "Encapsulate Most Internal APIs? [1],
>> SharedSecrets and friend interfaces should be moved out of
>> 'sun.misc? [2] and located in a truly private package. This is so that
>> they are not part of the proposed to be exported ?sun.misc'
>> package.
>> 
>> http://cr.openjdk.java.net/~chegar/8137056.00/
>> 
> This looks okay to me, just a minor nit in PresentationManager where you've introduced a raw type. If we can drop the building of the interim CORBA then this code could be cleaned up to not use core reflection.

Ah ha, good catch. Fixed and webrev updated in-place.

Offline, Paul queried whether the modules now using jdk.internal.misc
still require access to sun.misc. They do, all but one java.sql. I updated
the modules.xml to reflect this.

Worth noting, is that this change includes a workaround for 8137017:
Remove JDK internal API dependency from jrt-fs.jar [1], in 
jdk/internal/jimage/ImageNativeSubstrate.java

-Chris.

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

From rob.mckenna at oracle.com  Thu Sep 24 15:03:19 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Thu, 24 Sep 2015 16:03:19 +0100
Subject: RFR: 8135124 - com/sun/jndi/ldap/LdapTimeoutTest.java failed
	intermittently
Message-ID: <560410B7.1070800@oracle.com>

Hi folks,

I'd like to comment the ReadTimeoutTest part of this test for now as it 
appears to be causing intermittent failures. (on the understanding that 
these failures will be investigated separately)

http://cr.openjdk.java.net/~robm/8135124/webrev.01/

	-Rob


From christos at zoulas.com  Thu Sep 24 15:10:08 2015
From: christos at zoulas.com (Christos Zoulas)
Date: Thu, 24 Sep 2015 11:10:08 -0400
Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr
	in getLastErrorString
In-Reply-To: <56040465.10403@oracle.com> from Rob McKenna (Sep 24,  3:10pm)
Message-ID: <20150924151008.DBD4417FDAB@rebar.astron.com>

On Sep 24,  3:10pm, rob.mckenna at oracle.com (Rob McKenna) wrote:
-- Subject: Re: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of str

| Hi folks,
| 
| Uploaded a newer version:
| 
| http://cr.openjdk.java.net/~robm/8133249/webrev.02/
| 
| To address Rogers question, this needed to be separate from 
| getLastErrorString because of the return type and the err arg, but I 
| like the idea of avoiding the creation of a new file. Also, all of the 
| files that require the new function (now called getErrorString) already 
| include jni_util.c so it makes sense to put this in jni_util_md.c with 
| getLastErrorString.
| 
| As per Christos' suggestion I've mapped strerr_r to __xpg_strerror_r 
| instead of using the gnu strerror_r. I'd be interested to hear feedback 
| on this change.
| 
| I've corrected the oversights around the jli sources and 
| PlainDatagramSocket. The jli stuff shouldn't have been there in the 
| first place.
| 
| Ivan, I've kept the return type. As you note, I should have been using 
| it in ProcessImpl_md.c and the extra information from the return is 
| potentially useful.

LGTM.
In src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c
shouldn't the sprintf() get changed to jio_snprintf() or at least
snprintf()/_snprintf()? It would be nice if someone went and killed all the
sprintfs()...

christos


From Alan.Bateman at oracle.com  Thu Sep 24 15:28:13 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 24 Sep 2015 16:28:13 +0100
Subject: RFR [9] 8137056: Move SharedSecrets and interface friends out
	of sun.misc
In-Reply-To: <E88291C2-722D-4849-BC6A-D321E9A2CD7F@oracle.com>
References: <5938CBAC-F63C-429A-8258-E4A5D02C3142@oracle.com>
	<56040AC2.4080302@oracle.com>
	<E88291C2-722D-4849-BC6A-D321E9A2CD7F@oracle.com>
Message-ID: <5604168D.2040601@oracle.com>



On 24/09/2015 15:56, Chris Hegarty wrote:
> :
> Ah ha, good catch. Fixed and webrev updated in-place.
Looks okay.

>
> Offline, Paul queried whether the modules now using jdk.internal.misc
> still require access to sun.misc. They do, all but one java.sql. I updated
> the modules.xml to reflect this.
This looks okay too.


>
> Worth noting, is that this change includes a workaround for 8137017:
> Remove JDK internal API dependency from jrt-fs.jar [1], in
> jdk/internal/jimage/ImageNativeSubstrate.java
>
>
Ugly but okay on a temporary basis until jrt-fs/jimage is fixed.

-Alan


From ivan.gerasimov at oracle.com  Thu Sep 24 15:31:56 2015
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 24 Sep 2015 18:31:56 +0300
Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr
	in getLastErrorString
In-Reply-To: <56040465.10403@oracle.com>
References: <5600280C.9040601@oracle.com> <5602A5AF.6030409@oracle.com>
	<56040465.10403@oracle.com>
Message-ID: <5604176C.3050103@oracle.com>

Thanks Rob!

The webrev looks cleaner.

jni_util.h:
Wouldn't it be better to move this block directly to the jni_util_md.c file?
  390 #if defined(LINUX) && (defined(_GNU_SOURCE) || \
  391          (defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE < 200112L \
  392              && defined(_XOPEN_SOURCE) && _XOPEN_SOURCE < 600))
  393 extern int __xpg_strerror_r(int, char *, size_t);
  394 #endif
I don't see the __xpg_strerror_r() function used anywhere outside that 
.c file anyway.


TwoStacksPlainDatagramSocketImpl.c:
It wasn't introduced by your fix, but it seems that a new-line isn't 
necessary here:
2218         sprintf(errmsg, "error getting socket option: %s\n", tmpbuf);

In all other places JNU_ThrowByName() uses non-new-line-terminated messages.

Sincerely yours,
Ivan

On 24.09.2015 17:10, Rob McKenna wrote:
> Hi folks,
>
> Uploaded a newer version:
>
> http://cr.openjdk.java.net/~robm/8133249/webrev.02/
>
> To address Rogers question, this needed to be separate from 
> getLastErrorString because of the return type and the err arg, but I 
> like the idea of avoiding the creation of a new file. Also, all of the 
> files that require the new function (now called getErrorString) 
> already include jni_util.c so it makes sense to put this in 
> jni_util_md.c with getLastErrorString.
>
> As per Christos' suggestion I've mapped strerr_r to __xpg_strerror_r 
> instead of using the gnu strerror_r. I'd be interested to hear 
> feedback on this change.
>
> I've corrected the oversights around the jli sources and 
> PlainDatagramSocket. The jli stuff shouldn't have been there in the 
> first place.
>
> Ivan, I've kept the return type. As you note, I should have been using 
> it in ProcessImpl_md.c and the extra information from the return is 
> potentially useful.
>
>     -Rob
>
> On 23/09/15 14:14, Ivan Gerasimov wrote:
>> Hi Rob!
>>
>> On 21.09.2015 18:53, Rob McKenna wrote:
>>> Hi folks,
>>>
>>> Requesting a review of this change which switches corelibs usages of
>>> the thread-unsafe strerror over to strerror_r/strerror_s:
>>>
>>> http://cr.openjdk.java.net/~robm/8133249/webrev.01/
>>>
>>
>> I think it would be better to have  jdk_strerror(errno, tmpbuf,
>> sizeof(tmpbuf))  instead of  jdk_strerror(errno, tmpbuf, (size_t) 1024),
>> just for the sake of avoiding constant duplication.
>> I don't see the return code of jdk_strerror() is ever used. I suggest
>> using it in ProcessImpl_md.c (see below), or just making this function
>> return void.
>>
>> jni_util_md.c:
>> - why can't we just call  jdk_strerror(errno, buf, len)  and get rid of
>> the temp buffer?
>>
>> java_md_common.c:
>> - commented out #include @ line 26
>> - the change in JLI_ReportErrorMessageSys() looks incomplete
>>
>> ProcessImpl_md.c:
>> - would it make sense to check if jdk_strerror() == EINVAL instead of
>> comparing the strings?
>>
>> PlainDatagramSocketImpl.c:
>> - #include added, but no other changes were made.
>>
>> TwoStacksPlainDatagramSocketImpl.c:
>> - buf is declared to be char[1024], but only up to 255 chars are used.
>> - would be better to move the buf declaration closer to its use, maybe
>> next to char errmsg[300] line?
>>
>> jdk_strerror.c:
>> - minor nit: extra space after strerror_r at lines 46 and 63.
>>
>> Sincerely yours,
>> Ivan
>>
>



From Roger.Riggs at Oracle.com  Thu Sep 24 15:55:57 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 24 Sep 2015 11:55:57 -0400
Subject: RFR: 8135124 - com/sun/jndi/ldap/LdapTimeoutTest.java failed
	intermittently
In-Reply-To: <560410B7.1070800@oracle.com>
References: <560410B7.1070800@oracle.com>
Message-ID: <56041D0D.3080004@Oracle.com>

+1

On 9/24/2015 11:03 AM, Rob McKenna wrote:
> Hi folks,
>
> I'd like to comment the ReadTimeoutTest part of this test for now as 
> it appears to be causing intermittent failures. (on the understanding 
> that these failures will be investigated separately)
>
> http://cr.openjdk.java.net/~robm/8135124/webrev.01/
>
>     -Rob



From paul.sandoz at oracle.com  Thu Sep 24 15:57:38 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 24 Sep 2015 17:57:38 +0200
Subject: RFR [9] 8137056: Move SharedSecrets and interface friends out of
	sun.misc
In-Reply-To: <5938CBAC-F63C-429A-8258-E4A5D02C3142@oracle.com>
References: <5938CBAC-F63C-429A-8258-E4A5D02C3142@oracle.com>
Message-ID: <9A355BC4-A2AB-49F0-BD8E-A7A2A8089218@oracle.com>


On 24 Sep 2015, at 16:16, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> In preparation for JEP 260 "Encapsulate Most Internal APIs? [1],
> SharedSecrets and friend interfaces should be moved out of
> 'sun.misc? [2] and located in a truly private package. This is so that
> they are not part of the proposed to be exported ?sun.misc'
> package.
> 
> http://cr.openjdk.java.net/~chegar/8137056.00/
> 

+1

Paul.

> -Chris.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8132928
> [2] https://bugs.openjdk.java.net/browse/JDK-8137056



From paul.sandoz at oracle.com  Thu Sep 24 16:09:31 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 24 Sep 2015 18:09:31 +0200
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <CA+kOe0_JJZQUGXswunt0AMj-YFPnp5_nWFN8cGr-XMogVeSEzw@mail.gmail.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>
	<CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>
	<F57BEACF-282F-41C6-B5CA-5BA9A09BF2C4@oracle.com>
	<CA+kOe0_JJZQUGXswunt0AMj-YFPnp5_nWFN8cGr-XMogVeSEzw@mail.gmail.com>
Message-ID: <260BF09F-3814-404A-8E1F-84B509B0CD2A@oracle.com>

On 24 Sep 2015, at 00:22, Martin Buchholz <martinrb at google.com> wrote:
> 
> On Wed, Sep 23, 2015 at 2:41 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> On 23 Sep 2015, at 21:33, Martin Buchholz <martinrb at google.com> wrote:
>> 
>> 
>> In Helpers:
>> 
>>  121     private static String newStringUnsafe(char[] chars) {
>>  122         // If porting to a JDK where sun.misc.SharedSecrets is not
>>  123         // available, modify the code below to simply:
>>  124         // return new String(chars);
>>  125         // TODO: Can we do this more portably?
>>  126         return sun.misc.SharedSecrets.getJavaLangAccess().newStringUnsafe(chars);
>>  127     }
>> 
>> Yes, you can do this more portably *and* safely by not using it! :-)
>> 
>> Do we really really need to use SharedSecrets? IMO this unsafe dependency should be removed in the JDK patch.
>> 
>> Of course, this is "just" a (relatively unimportant) performance optimization.
> 
> Keeping focus, i think the first question to be asked is whether for a particular use-case unsafe String construction is really necessary, and in this case i strongly suspect the answer is no.
> 
> 
> We're maintaining a low-level library, with great attention to performance.  You never know if there's a user who's printing/logging bound.
> 
> Anyways, you feel  strongly about this, so ... they're gone!  Webrevs updated.
> 

Thanks! You may notice some churn in this area with Chris?s patch.

Still this does not absolve us from exploring preferably safe and more efficient construction solutions in the future. Sorry that i sidestepped your other important questions early on. My hope is we can improve hotspot to better recognise that the char[] array does not escape (and in addition it is frozen before it is assigned to the associated field in String)

Paul.


From martinrb at google.com  Thu Sep 24 17:57:08 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 24 Sep 2015 10:57:08 -0700
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <D9982CCF-0F8F-4E85-8DCD-4463DBDA933A@oracle.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<D9982CCF-0F8F-4E85-8DCD-4463DBDA933A@oracle.com>
Message-ID: <CA+kOe0_P+PzTvJrOtxVxMF7RnzWkOKLp089NTVghGWVVX+DbMQ@mail.gmail.com>

FlakyThreadFactory fixed:
(It would be nice if hotspot was consistent about the way it failed,
regardless of platform)
"Write once, fail anywhere"

Index:
src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java,v
retrieving revision 1.1
diff -u -r1.1 FlakyThreadFactory.java
---
src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java 24
Dec 2011 02:13:42 -0000 1.1
+++
src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java 24
Sep 2015 17:52:27 -0000
@@ -22,8 +22,10 @@
         test(OutOfMemoryError.class,
              new ThreadFactory() {
                 public Thread newThread(Runnable r) {
-                    // "guarantee" OutOfMemoryError
-                    return new Thread(null, r, "bloated", 1L << 60);
+                    new Thread(null, r, "a natural OOME", 1L << 60);
+                    // """On some platforms, the value of the stackSize
+                    // parameter may have no effect whatsoever."""
+                    throw new OutOfMemoryError("artificial OOME");
                 }});
         test(null,
              new ThreadFactory() {


On Thu, Sep 24, 2015 at 5:43 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> I ran the patches through JPRT.
>
> I am noticing one test failure that i cannot reproduce locally but
> reproduces on some test machines.
>
> java.lang.Exception: Stack trace
>         at java.lang.Thread.dumpStack(Thread.java:1335)
>         at FlakyThreadFactory.fail(FlakyThreadFactory.java:93)
>         at FlakyThreadFactory.check(FlakyThreadFactory.java:96)
>         at FlakyThreadFactory.test(FlakyThreadFactory.java:81)
>         at FlakyThreadFactory.test(FlakyThreadFactory.java:49)
>         at FlakyThreadFactory.instanceMain(FlakyThreadFactory.java:103)
>         at FlakyThreadFactory.main(FlakyThreadFactory.java:101)
>         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:519)
>         at
> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:218)
>         at java.lang.Thread.run(Thread.java:746)
> java.lang.AssertionError: Some tests failed
>         at FlakyThreadFactory.instanceMain(FlakyThreadFactory.java:105)
>         at FlakyThreadFactory.main(FlakyThreadFactory.java:101)
>         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:519)
>         at
> com.sun.javatest.regtest.agent.MainActionHelper$SameVMRunnable.run(MainActionHelper.java:218)
>         at java.lang.Thread.run(Thread.java:746)
>
> That is related to this test:
>
> test(OutOfMemoryError.class,
>      new ThreadFactory() {
>         public Thread newThread(Runnable r) {
>             // "guarantee" OutOfMemoryError
>             return new Thread(null, r, "bloated", 1L << 60);
>         }});
>
> Where the submission of tasks succeeds and it such cases it expects that
> the expected exception is null, rather than OutOfMemoryError.
>
> The stackSize parameter on the Thread constructor seems more of a hint and
> can be processed in a platform specific way, so i am not sure it can be
> relied upon to produce an OutOfMemoryError, e.g. on Thread:
>
> * <p>The virtual machine is free to treat the {@code stackSize}
> * parameter as a suggestion.  If the specified value is unreasonably low
> * for the platform, the virtual machine may instead use some
> * platform-specific minimum value; if the specified value is unreasonably
> * high, the virtual machine may instead use some platform-specific
> * maximum.  Likewise, the virtual machine is free to round the specified
> * value up or down as it sees fit (or to ignore it completely).
>
> Paul.
>
> On 21 Sep 2015, at 20:34, Martin Buchholz <martinrb at google.com> wrote:
>
> > This is the long-delayed and long-awaited bulk integration for jdk9 from
> jsr166 CVS.
> >
> > Find webrevs here:
> >
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
> >
> > Sorry about the extreme size and tardiness of this integration.
> >
> > As a review convenience, I provided a diff-wbB file that contains all
> the jsr166 integration changes using "hg diff -wbB" that ignores whitespace
> changes.
> >
> > We will need JPRT+specdiff+CCC from Oracle folks
> >
> > All changes are subtasks of:
> > https://bugs.openjdk.java.net/browse/JDK-8132960
>
>


From martinrb at google.com  Thu Sep 24 21:47:38 2015
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 24 Sep 2015 14:47:38 -0700
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <CA+kOe0_P+PzTvJrOtxVxMF7RnzWkOKLp089NTVghGWVVX+DbMQ@mail.gmail.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<D9982CCF-0F8F-4E85-8DCD-4463DBDA933A@oracle.com>
	<CA+kOe0_P+PzTvJrOtxVxMF7RnzWkOKLp089NTVghGWVVX+DbMQ@mail.gmail.com>
Message-ID: <CA+kOe0_-sxzYp_dWLXt4VYVEsuTdBKvZVSNR_gN_KQF66MM_VQ@mail.gmail.com>

I changed my export script to also publish my mercurial queues patches
directory.
Find it at
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/patches/


From sesuncedu at gmail.com  Thu Sep 24 22:01:57 2015
From: sesuncedu at gmail.com (Simon Spero)
Date: Thu, 24 Sep 2015 18:01:57 -0400
Subject: JEP 254: Compact Strings thoughts: character ranges outside ASCII +
	EASCII blocks
Message-ID: <CADE8KM6QJSvPc2KQ=PMh20ztgUMZ6frtb1gjhrfcDem5nSLx4g@mail.gmail.com>

[Some of this is may simple or prohibitively tricksy depending on alignment
constraints (even though it's restricted to Prime Multilingual Plane :-) ]

For some not un-realistic use cases, the most significant bytes for all the
characters in a string are identical, even if the string is non-latin. For
example, all the characters may be in the range U+0400--U+04FF, or
U+0500--U+05FF.
In these cases, it may be feasible to save the upper byte, then splat it
into place when reconstituting the UTF-16 chars.

Because of the assignment of unicode code-points, this technique is not as
big as win as it might have been. Unlike (e.g.) 8859-5 or 8859-8, there are
no punctuation marks, digits, or whitespace characters, which restricts use
cases to very short strings (the lack of whitespace is the biggest
problem). For the 254-like coding system I was experimenting with,  for the
cases were I didn't fall back to UTF-16, the savings were overwhelmed by
the cost of  header words and padding.

It is possible to handle some of these mixtures, on some architectures,
without resorting to LUTs or branches, but that's well in to  non-goal
territory for JEP-254. There might be some useful win just from being able
to have an offset to be added to the packed value based if the  high-bit is
set or not.  Anyone here from ???????

Simon
p.s.
   As part of the replacement for sun.misc.Unsafe, could we get a
jdk.infernal/...ABitDodgy, which would allow the full set of SIMD
instructions to be generated in an architecture independent fashion? (By
architecture independent I mean if you ask for a NEON instruction on an
amd64, or an SSE 4.2 string primitive on SPARC, that's what gets emitted).


From peter.levart at gmail.com  Fri Sep 25 06:46:06 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 25 Sep 2015 08:46:06 +0200
Subject: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure
	initialization
Message-ID: <5604EDAE.7080501@gmail.com>

Hi,

I propose a simple fix for two initialization issues described/linked in:

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

The patch is here:

http://cr.openjdk.java.net/~plevart/jdk9-dev/8136893_MethodType.fromDescriptor/webrev.01/

The 1st issue is the method: MetodType.fromMethodDescriptorString(String 
descriptor, ClassLoader loader)

This method is specified to treat null ClassLoader parameter as the 
system class loader. When lava.lang.invoke infrastructure is initialized 
before system class loader has been set, we get exceptions:

http://mail.openjdk.java.net/pipermail/mlvm-dev/2015-March/006386.html

java.lang.invoke initialization should not need to use system class 
loader as all types it must resolve during initialization are resolvable 
by bootstrap loader. Above method is public API and we can't change it's 
behavior, but can introduce another internal method that behaves a 
little differently - treating null ClassLoader as bootstrap class 
loader. All internal usages are rerouted to this internal method.

The 2nd issue is a little utility method: 
TypeConvertingMethodAdapter.boxingDescriptor(Wrapper w)

It uses String.format() to format a method type descriptor from two 
components. This unnecessarily brings in the Locale infrastructure which 
needs system class loader to locate providers:

http://mail.openjdk.java.net/pipermail/mlvm-dev/2015-March/006387.html

The fix is to replace String.format with simple string concatenation.

I have run the tests in java.lang.invoke and only have a problem with 1 
test which seems to be related to the test or jtreg itself and happens 
also without my patch applied:

#Test Results (version 2)
#Tue Sep 22 09:48:38 CEST 2015
#-----testdescription-----
$file=/home/peter/work/hg/jdk9-dev/jdk/test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
$root=/home/peter/work/hg/jdk9-dev/jdk/test
author=kshefov
error=Parse Exception\: `@library' must appear before first `@run'
keywords=bug8046703 randomness othervm ignore
run=USER_SPECIFIED ignore 8078602\nUSER_SPECIFIED build 
TestMethods\nUSER_SPECIFIED build LambdaFormTestCase\nUSER_SPECIFIED 
build LFGarbageCollectedTest\nUSER_SPECIFIED main/othervm -Xmx64m 
-XX\:SoftRefLRUPolicyMSPerMB\=0 -XX\:+HeapDumpOnOutOfMemoryError 
-DHEAP_DUMP\=false LFGarbageCollectedTest\n
source=LFGarbageCollectedTest.java
title=Test verifies that lambda forms are garbage collected

#-----environment-----

#-----testresult-----
description=file\:/home/peter/work/hg/jdk9-dev/jdk/test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
elapsed=2 0\:00\:00.002
end=Tue Sep 22 09\:48\:38 CEST 2015
environment=regtest
execStatus=Error. Parse Exception\: `@library' must appear before first 
`@run'
harnessLoaderMode=Classpath Loader
harnessVariety=Full Bundle
hostname=peterl.marand.si
javatestOS=Linux 4.1.5-100.fc21.x86_64 (amd64)
javatestVersion=4.6
jtregVersion=jtreg 4.2.0 dev tip
script=com.sun.javatest.regtest.RegressionScript
sections=script_messages
start=Tue Sep 22 09\:48\:38 CEST 2015
test=java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
totalTime=2
user.name=peter
work=/home/peter/work/hg/jdk9-dev/jdk/JTwork/java/lang/invoke/LFCaching

#section:script_messages
----------messages:(0/0)----------


test result: Error. Parse Exception: `@library' must appear before first 
`@run'



Regards, Peter



From paul.sandoz at oracle.com  Fri Sep 25 07:22:09 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 25 Sep 2015 09:22:09 +0200
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <CA+kOe0_-sxzYp_dWLXt4VYVEsuTdBKvZVSNR_gN_KQF66MM_VQ@mail.gmail.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<D9982CCF-0F8F-4E85-8DCD-4463DBDA933A@oracle.com>
	<CA+kOe0_P+PzTvJrOtxVxMF7RnzWkOKLp089NTVghGWVVX+DbMQ@mail.gmail.com>
	<CA+kOe0_-sxzYp_dWLXt4VYVEsuTdBKvZVSNR_gN_KQF66MM_VQ@mail.gmail.com>
Message-ID: <792EADCF-0E6F-4ED8-950A-E6D6D2921C90@oracle.com>

On 24 Sep 2015, at 23:47, Martin Buchholz <martinrb at google.com> wrote:
> I changed my export script to also publish my mercurial queues patches directory.
> Find it at
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/patches/


Thanks, most helpful,
Paul.


From forax at univ-mlv.fr  Fri Sep 25 07:32:39 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 25 Sep 2015 09:32:39 +0200 (CEST)
Subject: JEP 269: Convenience Factory Methods for Collections
In-Reply-To: <20150924000217.D476B7A327@eggemoggin.niobe.net>
References: <20150924000217.D476B7A327@eggemoggin.niobe.net>
Message-ID: <139037209.2264037.1443166359717.JavaMail.zimbra@u-pem.fr>

Hi Mark, hi Stuart, hi all,

for Map, i think a version with a builder will be cool too,
something like:

  public interface EntryBuilder<K, V> {
    public EntryBuilder<K,V> entry(K key, V value);
  }

and by example for HashMap:

  public static <K, V> HashMap<K, V> fromBuilder(Consumer<? super EntryBuilder<K,V>> consumer) {
    HashMap<K,V> map = new HashMap<>();
    consumer.accept(new EntryBuilder<>() {
      public EntryBuilder<K,V> entry(K key, V value) {
        map.put(key, value);
        return this;
      }
    });
    return map;
  } 

  ...
  HashMap<String, Integer> map = HashMap.fromBuilder(b -> b
    .entry("foo", 1)
    .entry("bar", 2));

The builder pattern let us to avoid to create intermediary entry objects.

regards,
R?mi

----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> ?: "stuart marks" <stuart.marks at oracle.com>
> Cc: core-libs-dev at openjdk.java.net
> Envoy?: Jeudi 24 Septembre 2015 02:02:17
> Objet: JEP 269: Convenience Factory Methods for Collections
> 
> New JEP Candidate: http://openjdk.java.net/jeps/269
> 
> - Mark
> 


From forax at univ-mlv.fr  Fri Sep 25 07:39:24 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 25 Sep 2015 09:39:24 +0200 (CEST)
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <234E0B3D-CBDB-4278-A070-8ACFD70DA1F6@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<0ED64734-7F73-4E8B-9900-7B444E8629C8@oracle.com>
	<1086772691.995036.1442963899414.JavaMail.zimbra@u-pem.fr>
	<D8ACE863-4234-4E3F-A2BA-795679BBF480@oracle.com>
	<4E159761-DDA7-4849-9816-18037FC53D33@univ-mlv.fr>
	<EF6119C1-3369-40CA-89A6-BF71C5E46EFC@oracle.com>
	<234E0B3D-CBDB-4278-A070-8ACFD70DA1F6@oracle.com>
Message-ID: <743210245.2276470.1443166764598.JavaMail.zimbra@u-pem.fr>

Hi Paul, hi chris,

----- Mail original -----
> De: "Chris Hegarty" <chris.hegarty at oracle.com>
> ?: "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Jeudi 24 Septembre 2015 11:06:36
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> 
> On 24 Sep 2015, at 08:40, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> > On 23 Sep 2015, at 18:11, R?mi Forax <forax at univ-mlv.fr> wrote:
> >>> 
> >>> Because i want to support the simple cases without pulling in indy.
> >> 
> >> and what about using an anonymous class instead ?
> >> 
> > 
> > Not an anonymous one, but i think i know what you mean :-)

it can be an anonymous one:
  private static final BiFunction<Integer, Integer, IOOBE> DEFAULT = new BiFunction<>() { ... };

anyway ...

> > 
> > Also, i don?t want to impose a null check of the exception mapping function
> > for every call, which would push the null check to when the values are out
> > of bounds, and throwing an NPE in such cases seems mean when one can
> > easily throw IOOBE instead.
> 
> This does seem to be one of the rare cases where accepting null is the lesser
> of two evils, given the expected usage of the API.

yes, i agree, it's a kind of ugly but it seems a necessary evil.

[...]

> 
> -Chris.

R?mi


From paul.sandoz at oracle.com  Fri Sep 25 07:49:08 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 25 Sep 2015 09:49:08 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <743210245.2276470.1443166764598.JavaMail.zimbra@u-pem.fr>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<0ED64734-7F73-4E8B-9900-7B444E8629C8@oracle.com>
	<1086772691.995036.1442963899414.JavaMail.zimbra@u-pem.fr>
	<D8ACE863-4234-4E3F-A2BA-795679BBF480@oracle.com>
	<4E159761-DDA7-4849-9816-18037FC53D33@univ-mlv.fr>
	<EF6119C1-3369-40CA-89A6-BF71C5E46EFC@oracle.com>
	<234E0B3D-CBDB-4278-A070-8ACFD70DA1F6@oracle.com>
	<743210245.2276470.1443166764598.JavaMail.zimbra@u-pem.fr>
Message-ID: <B05EDC21-60D1-49C1-89A2-1CE9E4402A91@oracle.com>

On 25 Sep 2015, at 09:39, Remi Forax <forax at univ-mlv.fr> wrote:
> Hi Paul, hi chris,
> 
> ----- Mail original -----
>> De: "Chris Hegarty" <chris.hegarty at oracle.com>
>> ?: "Paul Sandoz" <paul.sandoz at oracle.com>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Jeudi 24 Septembre 2015 11:06:36
>> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
>> 
>> On 24 Sep 2015, at 08:40, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>>> On 23 Sep 2015, at 18:11, R?mi Forax <forax at univ-mlv.fr> wrote:
>>>>> 
>>>>> Because i want to support the simple cases without pulling in indy.
>>>> 
>>>> and what about using an anonymous class instead ?
>>>> 
>>> 
>>> Not an anonymous one, but i think i know what you mean :-)
> 
> it can be an anonymous one:
>  private static final BiFunction<Integer, Integer, IOOBE> DEFAULT = new BiFunction<>() { ... };
> 
> anyway ?
> 

Oh yes, sorry, i mentally read it as  ?anonymous inner?.

Paul.


From miroslav.kos at oracle.com  Fri Sep 25 09:36:16 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Fri, 25 Sep 2015 11:36:16 +0200
Subject: [9] RFR: 8061466 - RELAX NG API visible but not accessible
In-Reply-To: <560406C3.4020001@oracle.com>
References: <5604014D.6040700@oracle.com> <560406C3.4020001@oracle.com>
Message-ID: <56051590.5020906@oracle.com>

On 24/09/15 16:20, Alan Bateman wrote:
> On 24/09/2015 14:57, Miroslav Kos wrote:
>> Hi everybody,
>>
>> I'd like to ask for review of following fix:
>>
>> RELAX NG API visible but not accessible
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8061466
>> webrev: http://cr.openjdk.java.net/~mkos/8061466/jaxws.01/index.html
>>
>> - org.relaxng.* classes in jdk.xml.bind module are not repackaged, 
>> but those are not exported so they are not usable outside of module 
>> (jdk) anyway
>> - processing RelaxNG schemas with JAX-B's declared as 
>> experimental/unsupported, but removing these classes is not easy 
>> since several other packages within JAX-B depend on those ...
>>
>> This patch repackages these classes from org.relaxng.* to 
>> com.sun.xml.internal.org.relaxng.* + removes loading RelaxNG runtime 
>> in xjc (+ removing related messages).
> Good to see these classes being renamed. I agree with Chris that this 
> should be hg mv so that the history is preserved.
>
> The proposed package name seems okay to me, if only because the 
> internal classes in this area are already using com.sun.xml.internal. 
> If this wasn't the case then the jdk or jdk.internal tree would have 
> been appropriate.
>
> -Alan.
Hi,
I prepared the webrev again with hg move:
http://cr.openjdk.java.net/~mkos/8061466/jaxws.02/index.html

For sure, jprt built again and all tests rerun.

Thanks
Miran




From Alan.Bateman at oracle.com  Fri Sep 25 09:46:14 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 25 Sep 2015 10:46:14 +0100
Subject: [9] RFR: 8061466 - RELAX NG API visible but not accessible
In-Reply-To: <56051590.5020906@oracle.com>
References: <5604014D.6040700@oracle.com> <560406C3.4020001@oracle.com>
	<56051590.5020906@oracle.com>
Message-ID: <560517E6.7090202@oracle.com>


On 25/09/2015 10:36, Miroslav Kos wrote:
> Hi,
> I prepared the webrev again with hg move:
> http://cr.openjdk.java.net/~mkos/8061466/jaxws.02/index.html
>
> For sure, jprt built again and all tests rerun.
The move and re-packaging looks good to me.

However I see there is more to this as it drops the -relaxng and 
-relaxng-compat command options so we'll need to make sure that this is 
tracked (even though these command-line options seems to have always 
been reported as unsupported and experimental).

I see the localized versions of the properties have also been changed 
and re-formatted. At one point then the rule was to not touch localized 
files because they are generated/changed by translation tools. I don't 
know know if the master version of these files is in the jaxws repo or 
maintained somewhere upstream.

-Alan


From miroslav.kos at oracle.com  Fri Sep 25 10:46:40 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Fri, 25 Sep 2015 12:46:40 +0200
Subject: [9] RFR: 8061466 - RELAX NG API visible but not accessible
In-Reply-To: <560517E6.7090202@oracle.com>
References: <5604014D.6040700@oracle.com> <560406C3.4020001@oracle.com>
	<56051590.5020906@oracle.com> <560517E6.7090202@oracle.com>
Message-ID: <56052610.8010309@oracle.com>



On 25/09/15 11:46, Alan Bateman wrote:
>
> On 25/09/2015 10:36, Miroslav Kos wrote:
>> Hi,
>> I prepared the webrev again with hg move:
>> http://cr.openjdk.java.net/~mkos/8061466/jaxws.02/index.html
>>
>> For sure, jprt built again and all tests rerun.
> The move and re-packaging looks good to me.
>
> However I see there is more to this as it drops the -relaxng and 
> -relaxng-compat command options so we'll need to make sure that this 
> is tracked (even though these command-line options seems to have 
> always been reported as unsupported and experimental). 
If it is necessary, I can file a CCC. Is it? If it is, I suppose it 
should address just change in tool (xjc) options - the implementation is 
in jdk.xml.bind, not java.xml.bind
>
> I see the localized versions of the properties have also been changed 
> and re-formatted. At one point then the rule was to not touch 
> localized files because they are generated/changed by translation 
> tools. I don't know know if the master version of these files is in 
> the jaxws repo or maintained somewhere upstream.
The localized properties are in standalone repo, so I suppose it is 
master(?)

Even if CCC required, it doesn't block us from pushing this, does it? If 
it was an issue, I can split the changeset into two (repackaging + 
removing options)

Thanks
Miran
>
> -Alan



From paul.sandoz at oracle.com  Fri Sep 25 10:58:06 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 25 Sep 2015 12:58:06 +0200
Subject: RFR 8080418 Add Optional.or()
Message-ID: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>

Hi,

Please review this change to add a method Optional.or that allows one to better compose optionals:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/

I also took the opportunity to clear up the JavaDoc, it was a little inconsistent and i personally found it harder to read in source code.

?

Separately while we are on the topic of Optional i would be interested in opinions on the following changes:

  http://cr.openjdk.java.net/~psandoz/jdk9/optional-prims-filter-map/webrev/

1) add methods that were missing on the primitive specializations; and

2) add to all variants a mapOrElseGet (otherwise known as a ?fold?), which is the equivalent of map(mapper).orElseGet(supplier). That is arguably less mind-bending to use when transforming from Optional<T> to Optional<U>.

Paul.


From Alan.Bateman at oracle.com  Fri Sep 25 11:04:34 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 25 Sep 2015 12:04:34 +0100
Subject: [9] RFR: 8061466 - RELAX NG API visible but not accessible
In-Reply-To: <56052610.8010309@oracle.com>
References: <5604014D.6040700@oracle.com> <560406C3.4020001@oracle.com>
	<56051590.5020906@oracle.com> <560517E6.7090202@oracle.com>
	<56052610.8010309@oracle.com>
Message-ID: <56052A42.1080901@oracle.com>



On 25/09/2015 11:46, Miroslav Kos wrote:
> :
>
> On 25/09/15 11:46, Alan Bateman wrote:
>>
>> On 25/09/2015 10:36, Miroslav Kos wrote:
>>> Hi,
>>> I prepared the webrev again with hg move:
>>> http://cr.openjdk.java.net/~mkos/8061466/jaxws.02/index.html
>>>
>>> For sure, jprt built again and all tests rerun.
>> The move and re-packaging looks good to me.
>>
>> However I see there is more to this as it drops the -relaxng and 
>> -relaxng-compat command options so we'll need to make sure that this 
>> is tracked (even though these command-line options seems to have 
>> always been reported as unsupported and experimental). 
> If it is necessary, I can file a CCC. Is it? If it is, I suppose it 
> should address just change in tool (xjc) options - the implementation 
> is in jdk.xml.bind, not java.xml.bind
>>
>> I see the localized versions of the properties have also been changed 
>> and re-formatted. At one point then the rule was to not touch 
>> localized files because they are generated/changed by translation 
>> tools. I don't know know if the master version of these files is in 
>> the jaxws repo or maintained somewhere upstream.
> The localized properties are in standalone repo, so I suppose it is 
> master(?)
>
> Even if CCC required, it doesn't block us from pushing this, does it? 
> If it was an issue, I can split the changeset into two (repackaging + 
> removing options)
I think the main compatibility issue is that people may be relying on 
these classes being present and not realizing it. That is, they might 
have tools.jar but not relaxng.jar on the class path and will only 
notice the issue when they try on JDK 9. So I think that point should be 
tracked for the release notes. I agree that the command-line options 
aren't too interesting but they can be mentioned too.

-Alan





From chris.hegarty at oracle.com  Fri Sep 25 11:04:51 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 25 Sep 2015 12:04:51 +0100
Subject: [9] RFR: 8061466 - RELAX NG API visible but not accessible
In-Reply-To: <56052610.8010309@oracle.com>
References: <5604014D.6040700@oracle.com> <560406C3.4020001@oracle.com>
	<56051590.5020906@oracle.com> <560517E6.7090202@oracle.com>
	<56052610.8010309@oracle.com>
Message-ID: <56052A53.5030903@oracle.com>



On 25/09/15 11:46, Miroslav Kos wrote:
>
>
> On 25/09/15 11:46, Alan Bateman wrote:
>>
>> On 25/09/2015 10:36, Miroslav Kos wrote:
>>> Hi,
>>> I prepared the webrev again with hg move:
>>> http://cr.openjdk.java.net/~mkos/8061466/jaxws.02/index.html
>>>
>>> For sure, jprt built again and all tests rerun.
>> The move and re-packaging looks good to me.
>>
>> However I see there is more to this as it drops the -relaxng and
>> -relaxng-compat command options so we'll need to make sure that this
>> is tracked (even though these command-line options seems to have
>> always been reported as unsupported and experimental).
> If it is necessary, I can file a CCC. Is it? If it is, I suppose it
> should address just change in tool (xjc) options - the implementation is
> in jdk.xml.bind, not java.xml.bind
>>
>> I see the localized versions of the properties have also been changed
>> and re-formatted. At one point then the rule was to not touch
>> localized files because they are generated/changed by translation
>> tools. I don't know know if the master version of these files is in
>> the jaxws repo or maintained somewhere upstream.
> The localized properties are in standalone repo, so I suppose it is
> master(?)
>
> Even if CCC required, it doesn't block us from pushing this, does it? If
> it was an issue, I can split the changeset into two (repackaging +
> removing options)

Up to you Miran if you want to split this.

The repackaging changes look ok to me.

-Chris.

> Thanks
> Miran
>>
>> -Alan
>


From amaembo at gmail.com  Fri Sep 25 12:00:11 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Fri, 25 Sep 2015 18:00:11 +0600
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
Message-ID: <248664718.20150925180011@gmail.com>

Hello!

Quite interesting and long awaited features (at least according to
StackOverflow questions). Isn't it a good idea to provide also a way
to transfer between Optional types like "mapToInt", "mapToObj", etc.,
like it's done in Stream API?

PS> 2) add to all variants a mapOrElseGet (otherwise known as a
PS> ?fold?), which is the equivalent of
PS> map(mapper).orElseGet(supplier). That is arguably less
PS> mind-bending to use when transforming from Optional<T> to Optional<U>.

The proposed implementation is the following:

    public<U> U mapOrElseGet(Function<? super T, ? extends U> mapper,
                             Supplier<? extends U> supplier) {
        if (!isPresent()) {
            return supplier.get();
        } else {
            return mapper.apply(value);
        }
    }

It documents that:

     * @throws NullPointerException if the mapping function or the supplying
     *         function is {@code null}

However in fact it throws not always. For example, this call will not
throw:

  Optional.empty().mapOrElseGet(null, () -> "x");

To me it seems that this should be fixed (possibly adding
requireNonNull checks) as it could become the source of silent bugs.
Also you say that it's equivalent to the map().orElseGet() chain.
However this one throws:

  Optional.empty().<String>map(null).orElseGet(() -> "x");

There's also another problem. The orElseGet(null) is documented to
work to work fine for non-empty optional (why on the Earth it was
specified this way?). So there's good question whether the "supplier"
argument of "mapOrElseGet" should be allowed to be null for non-empty
optional (to conform with "orElseGet") or should not be allowed (to
conform with "mapper" argument).

With best regards,
Tagir Valeev.



From aleksey.shipilev at oracle.com  Fri Sep 25 12:29:26 2015
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 25 Sep 2015 15:29:26 +0300
Subject: JEP 254: Compact Strings thoughts: character ranges outside ASCII
	+ EASCII blocks
In-Reply-To: <CADE8KM6QJSvPc2KQ=PMh20ztgUMZ6frtb1gjhrfcDem5nSLx4g@mail.gmail.com>
References: <CADE8KM6QJSvPc2KQ=PMh20ztgUMZ6frtb1gjhrfcDem5nSLx4g@mail.gmail.com>
Message-ID: <56053E26.4080204@oracle.com>

Hi Simon,

On 09/25/2015 01:01 AM, Simon Spero wrote:
> [Some of this is may simple or prohibitively tricksy depending on alignment
> constraints (even though it's restricted to Prime Multilingual Plane :-) ]
> 
> For some not un-realistic use cases, the most significant bytes for all the
> characters in a string are identical, even if the string is non-latin. For
> example, all the characters may be in the range U+0400--U+04FF, or
> U+0500--U+05FF.
> In these cases, it may be feasible to save the upper byte, then splat it
> into place when reconstituting the UTF-16 chars.
> 
> Because of the assignment of unicode code-points, this technique is not as
> big as win as it might have been. Unlike (e.g.) 8859-5 or 8859-8, there are
> no punctuation marks, digits, or whitespace characters, which restricts use
> cases to very short strings (the lack of whitespace is the biggest
> problem). For the 254-like coding system I was experimenting with,  for the
> cases were I didn't fall back to UTF-16, the savings were overwhelmed by
> the cost of  header words and padding.
> 
> It is possible to handle some of these mixtures, on some architectures,
> without resorting to LUTs or branches, but that's well in to  non-goal
> territory for JEP-254. There might be some useful win just from being able
> to have an offset to be added to the packed value based if the  high-bit is
> set or not.  Anyone here from ???????

Sure, many theoretical constructions may be devised. Not many of them
are practical.

JEP-254 wins big time exactly because many strings *are* single-byte
storeable in ASCII/8859-1, *especially* those with long lengths. So, the
very first thing you have to do is prove that an alternative scheme
successfully encodes a fair amount of real strings. Otherwise, it does
not worth exploring any further. As you say, a lack of "usual"
characters like whitespace may be the deal breaker.

Adding an alternative coder is easy, but making sure it does not regress
the prevailing cases of 8859-1/UTF16 strings is much harder. Think about
branching costs, eliminating the bit tricks that are employed now with
binary 0/1 coder, etc.

Thanks,
-Aleksey




From paul.sandoz at oracle.com  Fri Sep 25 12:30:46 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 25 Sep 2015 14:30:46 +0200
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <248664718.20150925180011@gmail.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
	<248664718.20150925180011@gmail.com>
Message-ID: <D94F57D3-8C81-496C-8880-791A310C1D51@oracle.com>


On 25 Sep 2015, at 14:00, Tagir F. Valeev <amaembo at gmail.com> wrote:

> Hello!
> 
> Quite interesting and long awaited features (at least according to
> StackOverflow questions).

All of them? or just the first?


> Isn't it a good idea to provide also a way
> to transfer between Optional types like "mapToInt", "mapToObj", etc.,
> like it's done in Stream API?
> 

I don?t wanna go there, my response is transform Optional* into a *Stream. An argument for adding mapOrElseGet (notice that the primitive variants return U) is that other functionality can be composed from it.


> PS> 2) add to all variants a mapOrElseGet (otherwise known as a
> PS> ?fold?), which is the equivalent of
> PS> map(mapper).orElseGet(supplier). That is arguably less
> PS> mind-bending to use when transforming from Optional<T> to Optional<U>.
> 
> The proposed implementation is the following:
> 
>    public<U> U mapOrElseGet(Function<? super T, ? extends U> mapper,
>                             Supplier<? extends U> supplier) {
>        if (!isPresent()) {
>            return supplier.get();
>        } else {
>            return mapper.apply(value);
>        }
>    }
> 
> It documents that:
> 
>     * @throws NullPointerException if the mapping function or the supplying
>     *         function is {@code null}
> 

Thanks, yes, i need to update that to be consistent with the existing functional accepting termination methods.


> However in fact it throws not always. For example, this call will not
> throw:
> 
>  Optional.empty().mapOrElseGet(null, () -> "x");
> 
> To me it seems that this should be fixed (possibly adding
> requireNonNull checks) as it could become the source of silent bugs.
> Also you say that it's equivalent to the map().orElseGet() chain.
> However this one throws:
> 
>  Optional.empty().<String>map(null).orElseGet(() -> "x");
> 
> There's also another problem. The orElseGet(null) is documented to
> work to work fine for non-empty optional

> (why on the Earth it was specified this way?).

Arguably it was a mistake that we did not catch in the frenzy of Java 8 feature freeze. I would like to revert it but existing code might already be reliant on it :-(

Paul.

> So there's good question whether the "supplier"
> argument of "mapOrElseGet" should be allowed to be null for non-empty
> optional (to conform with "orElseGet") or should not be allowed (to
> conform with "mapper" argument).
> 
> With best regards,
> Tagir Valeev.
> 



From paul.sandoz at oracle.com  Fri Sep 25 12:50:44 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 25 Sep 2015 14:50:44 +0200
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <CA+kOe0_P+PzTvJrOtxVxMF7RnzWkOKLp089NTVghGWVVX+DbMQ@mail.gmail.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<D9982CCF-0F8F-4E85-8DCD-4463DBDA933A@oracle.com>
	<CA+kOe0_P+PzTvJrOtxVxMF7RnzWkOKLp089NTVghGWVVX+DbMQ@mail.gmail.com>
Message-ID: <8B922221-91F0-4FAC-8326-6FBE11724442@oracle.com>

On 24 Sep 2015, at 19:57, Martin Buchholz <martinrb at google.com> wrote:
> FlakyThreadFactory fixed:

Thanks, verified.

Paul.

> (It would be nice if hotspot was consistent about the way it failed, regardless of platform)
> "Write once, fail anywhere"
> 
> Index: src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java
> ===================================================================
> RCS file: /export/home/jsr166/jsr166/jsr166/src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java,v
> retrieving revision 1.1
> diff -u -r1.1 FlakyThreadFactory.java
> --- src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java	24 Dec 2011 02:13:42 -0000	1.1
> +++ src/test/jtreg/util/concurrent/ThreadPoolExecutor/FlakyThreadFactory.java	24 Sep 2015 17:52:27 -0000
> @@ -22,8 +22,10 @@
>          test(OutOfMemoryError.class,
>               new ThreadFactory() {
>                  public Thread newThread(Runnable r) {
> -                    // "guarantee" OutOfMemoryError
> -                    return new Thread(null, r, "bloated", 1L << 60);
> +                    new Thread(null, r, "a natural OOME", 1L << 60);
> +                    // """On some platforms, the value of the stackSize
> +                    // parameter may have no effect whatsoever."""
> +                    throw new OutOfMemoryError("artificial OOME");
>                  }});
>          test(null,
>               new ThreadFactory() {



From scolebourne at joda.org  Fri Sep 25 13:06:54 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 25 Sep 2015 14:06:54 +0100
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
Message-ID: <CACzrW9B1w-vVDWpzmD8LCej9QNNk9npCXkWNABDDZ2O27hZ9qg@mail.gmail.com>

On 25 September 2015 at 11:58, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> Please review this change to add a method Optional.or that allows one to better compose optionals:
>
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/

New method seems fine.

> Separately while we are on the topic of Optional i would be interested in opinions on the following changes:
>
>   http://cr.openjdk.java.net/~psandoz/jdk9/optional-prims-filter-map/webrev/
>
> 1) add methods that were missing on the primitive specializations; and

Seems fine, although I think a good case can be made for mapToObj() -
while going via a stream is possible, it is non-intuitive. I don't
think mapToInt() or mapToLong() are necessary on OptionalDouble (and
so on), but not being able to reach Object will be restrictive..

> 2) add to all variants a mapOrElseGet (otherwise known as a ?fold?), which is the equivalent of map(mapper).orElseGet(supplier). That is arguably less mind-bending to use when transforming from Optional<T> to Optional<U>.

To me, this is pointless, and makes the API more confusing. Chaining
methods is a way of life in Java 8, and developers have to be able to
think that way.

Stephen


From erik.joelsson at oracle.com  Fri Sep 25 13:08:51 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 25 Sep 2015 15:08:51 +0200
Subject: RFR: JDK-8137088: Drop building of interim_java.corba
Message-ID: <56054763.6070901@oracle.com>

Hello,

Please review this change to the build of JDK 9, which drops building of 
interim-corba.

The interim build of java.corba has historically been needed for rmic 
-iiop but it is no longer needed in the build since the JMX remote API 
dropped support for the IIOP transport (JDK-8043937).

Bug: https://bugs.openjdk.java.net/browse/JDK-8137088
Webrev: http://cr.openjdk.java.net/~erikj/8137088/webrev.01/

/Erik


From Alan.Bateman at oracle.com  Fri Sep 25 13:13:50 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 25 Sep 2015 14:13:50 +0100
Subject: RFR: JDK-8137088: Drop building of interim_java.corba
In-Reply-To: <56054763.6070901@oracle.com>
References: <56054763.6070901@oracle.com>
Message-ID: <5605488E.10800@oracle.com>

On 25/09/2015 14:08, Erik Joelsson wrote:
> Hello,
>
> Please review this change to the build of JDK 9, which drops building 
> of interim-corba.
>
> The interim build of java.corba has historically been needed for rmic 
> -iiop but it is no longer needed in the build since the JMX remote API 
> dropped support for the IIOP transport (JDK-8043937).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8137088
> Webrev: http://cr.openjdk.java.net/~erikj/8137088/webrev.01/
Looks good to me, happy to see this go as it allows for clean-up in many 
areas.

-Alan.


From chris.hegarty at oracle.com  Fri Sep 25 13:16:25 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 25 Sep 2015 14:16:25 +0100
Subject: RFR: JDK-8137088: Drop building of interim_java.corba
In-Reply-To: <56054763.6070901@oracle.com>
References: <56054763.6070901@oracle.com>
Message-ID: <56054929.6000009@oracle.com>

On 25/09/15 14:08, Erik Joelsson wrote:
> Hello,
>
> Please review this change to the build of JDK 9, which drops building of
> interim-corba.
>
> The interim build of java.corba has historically been needed for rmic
> -iiop but it is no longer needed in the build since the JMX remote API
> dropped support for the IIOP transport (JDK-8043937).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8137088
> Webrev: http://cr.openjdk.java.net/~erikj/8137088/webrev.01/

Thanks for doing this Erik. We can now statically reference JDK 9 types 
from corba!

-Chris.


From rob.mckenna at oracle.com  Fri Sep 25 13:27:53 2015
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 25 Sep 2015 14:27:53 +0100
Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr
	in getLastErrorString
In-Reply-To: <5604176C.3050103@oracle.com>
References: <5600280C.9040601@oracle.com> <5602A5AF.6030409@oracle.com>
	<56040465.10403@oracle.com> <5604176C.3050103@oracle.com>
Message-ID: <56054BD9.1030700@oracle.com>

Thanks Ivan, I'll push with these changes.

	-Rob

On 24/09/15 16:31, Ivan Gerasimov wrote:
> Thanks Rob!
>
> The webrev looks cleaner.
>
> jni_util.h:
> Wouldn't it be better to move this block directly to the jni_util_md.c
> file?
>   390 #if defined(LINUX) && (defined(_GNU_SOURCE) || \
>   391          (defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE < 200112L \
>   392              && defined(_XOPEN_SOURCE) && _XOPEN_SOURCE < 600))
>   393 extern int __xpg_strerror_r(int, char *, size_t);
>   394 #endif
> I don't see the __xpg_strerror_r() function used anywhere outside that
> .c file anyway.
>
>
> TwoStacksPlainDatagramSocketImpl.c:
> It wasn't introduced by your fix, but it seems that a new-line isn't
> necessary here:
> 2218         sprintf(errmsg, "error getting socket option: %s\n", tmpbuf);
>
> In all other places JNU_ThrowByName() uses non-new-line-terminated
> messages.
>
> Sincerely yours,
> Ivan
>
> On 24.09.2015 17:10, Rob McKenna wrote:
>> Hi folks,
>>
>> Uploaded a newer version:
>>
>> http://cr.openjdk.java.net/~robm/8133249/webrev.02/
>>
>> To address Rogers question, this needed to be separate from
>> getLastErrorString because of the return type and the err arg, but I
>> like the idea of avoiding the creation of a new file. Also, all of the
>> files that require the new function (now called getErrorString)
>> already include jni_util.c so it makes sense to put this in
>> jni_util_md.c with getLastErrorString.
>>
>> As per Christos' suggestion I've mapped strerr_r to __xpg_strerror_r
>> instead of using the gnu strerror_r. I'd be interested to hear
>> feedback on this change.
>>
>> I've corrected the oversights around the jli sources and
>> PlainDatagramSocket. The jli stuff shouldn't have been there in the
>> first place.
>>
>> Ivan, I've kept the return type. As you note, I should have been using
>> it in ProcessImpl_md.c and the extra information from the return is
>> potentially useful.
>>
>>     -Rob
>>
>> On 23/09/15 14:14, Ivan Gerasimov wrote:
>>> Hi Rob!
>>>
>>> On 21.09.2015 18:53, Rob McKenna wrote:
>>>> Hi folks,
>>>>
>>>> Requesting a review of this change which switches corelibs usages of
>>>> the thread-unsafe strerror over to strerror_r/strerror_s:
>>>>
>>>> http://cr.openjdk.java.net/~robm/8133249/webrev.01/
>>>>
>>>
>>> I think it would be better to have  jdk_strerror(errno, tmpbuf,
>>> sizeof(tmpbuf))  instead of  jdk_strerror(errno, tmpbuf, (size_t) 1024),
>>> just for the sake of avoiding constant duplication.
>>> I don't see the return code of jdk_strerror() is ever used. I suggest
>>> using it in ProcessImpl_md.c (see below), or just making this function
>>> return void.
>>>
>>> jni_util_md.c:
>>> - why can't we just call  jdk_strerror(errno, buf, len)  and get rid of
>>> the temp buffer?
>>>
>>> java_md_common.c:
>>> - commented out #include @ line 26
>>> - the change in JLI_ReportErrorMessageSys() looks incomplete
>>>
>>> ProcessImpl_md.c:
>>> - would it make sense to check if jdk_strerror() == EINVAL instead of
>>> comparing the strings?
>>>
>>> PlainDatagramSocketImpl.c:
>>> - #include added, but no other changes were made.
>>>
>>> TwoStacksPlainDatagramSocketImpl.c:
>>> - buf is declared to be char[1024], but only up to 255 chars are used.
>>> - would be better to move the buf declaration closer to its use, maybe
>>> next to char errmsg[300] line?
>>>
>>> jdk_strerror.c:
>>> - minor nit: extra space after strerror_r at lines 46 and 63.
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>
>


From paul.sandoz at oracle.com  Fri Sep 25 13:29:36 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 25 Sep 2015 15:29:36 +0200
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <CACzrW9B1w-vVDWpzmD8LCej9QNNk9npCXkWNABDDZ2O27hZ9qg@mail.gmail.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
	<CACzrW9B1w-vVDWpzmD8LCej9QNNk9npCXkWNABDDZ2O27hZ9qg@mail.gmail.com>
Message-ID: <C800BC5E-1191-4B1F-BD9C-D2CA62F094E7@oracle.com>


On 25 Sep 2015, at 15:06, Stephen Colebourne <scolebourne at joda.org> wrote:

> On 25 September 2015 at 11:58, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> Please review this change to add a method Optional.or that allows one to better compose optionals:
>> 
>>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/
> 
> New method seems fine.

Thanks.


> 
>> Separately while we are on the topic of Optional i would be interested in opinions on the following changes:
>> 
>>  http://cr.openjdk.java.net/~psandoz/jdk9/optional-prims-filter-map/webrev/
>> 
>> 1) add methods that were missing on the primitive specializations; and
> 
> Seems fine, although I think a good case can be made for mapToObj() -
> while going via a stream is possible, it is non-intuitive. I don't
> think mapToInt() or mapToLong() are necessary on OptionalDouble (and
> so on), but not being able to reach Object will be restrictive..
> 

I doubt that such operations are so very common to justify a spread of "box/unbox" methods transforming between the optional variants. Also I don?t want to pollute Optional with Optional*, especially looking forward when the primitive variations can be deprecated.

It?s also possible to do so via map.orElseGet or a ?fold?.


>> 2) add to all variants a mapOrElseGet (otherwise known as a ?fold?), which is the equivalent of map(mapper).orElseGet(supplier). That is arguably less mind-bending to use when transforming from Optional<T> to Optional<U>.
> 
> To me, this is pointless, and makes the API more confusing. Chaining
> methods is a way of life in Java 8, and developers have to be able to
> think that way.

It?s not about chaining it?s having to reason about Optional<Optional<>>, which is one reason for ?Optional.or? e.g.:

  Optional<String> a = Optional.of("A");
  OptionalInt c = a.map(s -> OptionalInt.of(s.length())). // Optional<OptionalInt>
          orElseGet(OptionalInt::empty);

The ?fold? is essentially a core building block.

Paul.


From michael.haupt at oracle.com  Fri Sep 25 13:37:03 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Fri, 25 Sep 2015 15:37:03 +0200
Subject: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure
	initialization
In-Reply-To: <5604EDAE.7080501@gmail.com>
References: <5604EDAE.7080501@gmail.com>
Message-ID: <79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com>

Hi Peter,

thanks for this changeset. Note I'm not a Reviewer (with a capital R); please read this review in lower-case. ;-)

One question about MethodType: would you mind doing something about the naming of the newly introduced fromDescriptor() method? Its name does not suggest in any way that it chooses the class loader differently. The name is subtly different from that of fromDescriptorString(), and the signature is identical - it's probably really easy to confuse the two when working at the core libs level. Unfortunately, the only proposal for a name I can make, fromDescriptorStringBootCL(), is clunky. Maybe that's acceptable for a low-level method only visible at package level.

> Am 25.09.2015 um 08:46 schrieb Peter Levart <peter.levart at gmail.com>:
> I have run the tests in java.lang.invoke and only have a problem with 1 test which seems to be related to the test or jtreg itself and happens also without my patch applied:
> 
> #Test Results (version 2)
> #Tue Sep 22 09:48:38 CEST 2015
> ...
> #section:script_messages
> ----------messages:(0/0)----------
> 
> 
> test result: Error. Parse Exception: `@library' must appear before first `@run'

Yes. The test is also marked as ignored until another issue is fixed, so that can be ignored.

Other than the above remark/suggestion, this looks fine. I'll defer to an upper-case Reviewer, though.

Best,

Michael

-- 

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



From forax at univ-mlv.fr  Fri Sep 25 13:42:54 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 25 Sep 2015 15:42:54 +0200 (CEST)
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <C800BC5E-1191-4B1F-BD9C-D2CA62F094E7@oracle.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
	<CACzrW9B1w-vVDWpzmD8LCej9QNNk9npCXkWNABDDZ2O27hZ9qg@mail.gmail.com>
	<C800BC5E-1191-4B1F-BD9C-D2CA62F094E7@oracle.com>
Message-ID: <1438992492.2522829.1443188574408.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 25 Septembre 2015 15:29:36
> Objet: Re: RFR 8080418 Add Optional.or()
> 
> 
> On 25 Sep 2015, at 15:06, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> > On 25 September 2015 at 11:58, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> >> Please review this change to add a method Optional.or that allows one to
> >> better compose optionals:
> >> 
> >>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/
> > 
> > New method seems fine.
> 
> Thanks.

yes, or() is Ok !

[...]

> 
> >> 2) add to all variants a mapOrElseGet (otherwise known as a ?fold?), which
> >> is the equivalent of map(mapper).orElseGet(supplier). That is arguably
> >> less mind-bending to use when transforming from Optional<T> to
> >> Optional<U>.
> > 
> > To me, this is pointless, and makes the API more confusing. Chaining
> > methods is a way of life in Java 8, and developers have to be able to
> > think that way.
> 
> It?s not about chaining it?s having to reason about Optional<Optional<>>,
> which is one reason for ?Optional.or? e.g.:
> 
>   Optional<String> a = Optional.of("A");
>   OptionalInt c = a.map(s -> OptionalInt.of(s.length())). // Optional<OptionalInt>
>           orElseGet(OptionalInt::empty);
> 
> The ?fold? is essentially a core building block.

maybe you should add a note in ifPresentOrElse() noticing that the non 'void' version is called orElseGet(),

> 
> Paul.
> 

R?mi


From paul.sandoz at oracle.com  Fri Sep 25 14:07:46 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 25 Sep 2015 16:07:46 +0200
Subject: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure
	initialization
In-Reply-To: <79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com>
References: <5604EDAE.7080501@gmail.com>
	<79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com>
Message-ID: <D3AE591C-FF34-4337-8932-6990322F32C5@oracle.com>

Hi,

This looks like a partial dup of https://bugs.openjdk.java.net/browse/JDK-8076596

The changes look ok, but I am concerned post initialization there may be code paths taken that require the system class loader to be used but instead the boot stream class loader is used instead. Is that a legitimate concern?

Paul.

On 25 Sep 2015, at 15:37, Michael Haupt <michael.haupt at oracle.com> wrote:

> Hi Peter,
> 
> thanks for this changeset. Note I'm not a Reviewer (with a capital R); please read this review in lower-case. ;-)
> 
> One question about MethodType: would you mind doing something about the naming of the newly introduced fromDescriptor() method? Its name does not suggest in any way that it chooses the class loader differently. The name is subtly different from that of fromDescriptorString(), and the signature is identical - it's probably really easy to confuse the two when working at the core libs level. Unfortunately, the only proposal for a name I can make, fromDescriptorStringBootCL(), is clunky. Maybe that's acceptable for a low-level method only visible at package level.
> 
>> Am 25.09.2015 um 08:46 schrieb Peter Levart <peter.levart at gmail.com>:
>> I have run the tests in java.lang.invoke and only have a problem with 1 test which seems to be related to the test or jtreg itself and happens also without my patch applied:
>> 
>> #Test Results (version 2)
>> #Tue Sep 22 09:48:38 CEST 2015
>> ...
>> #section:script_messages
>> ----------messages:(0/0)----------
>> 
>> 
>> test result: Error. Parse Exception: `@library' must appear before first `@run'
> 
> Yes. The test is also marked as ignored until another issue is fixed, so that can be ignored.
> 
> Other than the above remark/suggestion, this looks fine. I'll defer to an upper-case Reviewer, though.
> 
> Best,
> 
> Michael
> 
> --
> 
> <http://www.oracle.com/>
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> Oracle Java Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
> <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment
> 



From peter.levart at gmail.com  Fri Sep 25 14:11:43 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 25 Sep 2015 16:11:43 +0200
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <D94F57D3-8C81-496C-8880-791A310C1D51@oracle.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
	<248664718.20150925180011@gmail.com>
	<D94F57D3-8C81-496C-8880-791A310C1D51@oracle.com>
Message-ID: <5605561F.301@gmail.com>



On 09/25/2015 02:30 PM, Paul Sandoz wrote:
>> >There's also another problem. The orElseGet(null) is documented to
>> >work to work fine for non-empty optional
>> >(why on the Earth it was specified this way?).
> Arguably it was a mistake that we did not catch in the frenzy of Java 8 feature freeze. I would like to revert it but existing code might already be reliant on it:-(
>
> Paul.
>

It would be of no use if it was specified to throw on non-empty 
Optional. Usually this method is meant to be called on the result of 
another method returning Optional to compose a fluent call chain.

Regards, Peter



From magnus.ihse.bursie at oracle.com  Fri Sep 25 14:28:22 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 25 Sep 2015 16:28:22 +0200
Subject: RFR: JDK-8137088: Drop building of interim_java.corba
In-Reply-To: <56054763.6070901@oracle.com>
References: <56054763.6070901@oracle.com>
Message-ID: <56055A06.30305@oracle.com>

On 2015-09-25 15:08, Erik Joelsson wrote:
> Hello,
>
> Please review this change to the build of JDK 9, which drops building 
> of interim-corba.
>
> The interim build of java.corba has historically been needed for rmic 
> -iiop but it is no longer needed in the build since the JMX remote API 
> dropped support for the IIOP transport (JDK-8043937).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8137088
> Webrev: http://cr.openjdk.java.net/~erikj/8137088/webrev.01/

Looks good to me.

Observant of you to note that we could remove this.

/Magnus


From peter.levart at gmail.com  Fri Sep 25 15:19:02 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 25 Sep 2015 17:19:02 +0200
Subject: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure
	initialization
In-Reply-To: <D3AE591C-FF34-4337-8932-6990322F32C5@oracle.com>
References: <5604EDAE.7080501@gmail.com>
	<79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com>
	<D3AE591C-FF34-4337-8932-6990322F32C5@oracle.com>
Message-ID: <560565E6.7090000@gmail.com>

Hi Paul,

Thanks for looking into this.

On 09/25/2015 04:07 PM, Paul Sandoz wrote:
> Hi,
>
> This looks like a partial dup of https://bugs.openjdk.java.net/browse/JDK-8076596

Ah, sorry, I wasn't aware this has already been registered in JIRA. I 
have linked the two issues together as DUPs.

>
> The changes look ok, but I am concerned post initialization there may be code paths taken that require the system class loader to be used but instead the boot stream class loader is used instead. Is that a legitimate concern?

It is legitimate, but I have inspected usages and:

- In java.lang.invoke.BoundMethodHandle.Factory#makeCbmhCtor, null is 
passed explicitly and this method is used only from 
java.lang.invoke.BoundMethodHandle.Factory#makeCtors which is used from 
java.lang.invoke.BoundMethodHandle.SpeciesData#initForBootstrap and 
java.lang.invoke.BoundMethodHandle.SpeciesData#SpeciesData(java.lang.String, 
java.lang.Class<? extends java.lang.invoke.BoundMethodHandle>). These 
usages only deal with erased MH types (Object, long, int, double, float).

- In java.lang.invoke.MemberName#getMethodType, the result of 
MemberName.getClassLoader() is passed to the method. This is the class 
loader of the member's declaring class. Any types referenced from the 
member declaration should be resolvable from this class loader. A member 
declared by a bootstrap class (MemberName.getClassLoader() returns null) 
can only reference types resolvable from bootstrap loader.

- In java.lang.invoke.MemberName#getFieldType, the result of 
MemberName.getClassLoader() is passed to the method. Similar applies as 
above.

- In java.lang.invoke.MethodHandleNatives#fixMethodType(Class<?> 
callerClass, Object type), the callerClass.getClassLoader() is passed to 
the method. This is invoked from:
  java.lang.invoke.MethodHandleNatives#linkMethodImpl(
                                      Class<?> callerClass, int refKind,
                                      Class<?> defc, String name, Object 
type,
                                      Object[] appendixResult)
which is called from 
java.lang.invoke.MethodHandleNatives#linkMethod(same args)

I suppose this is an upcall from VM to link a call to the 
@PolymorphicSignature method and callerClass is the class in which the 
invocation bytecodes are executed. Am I right? The reasoning is as 
follows: if callerClass.getClassLoader() is sufficient for resolving 
types that appear at the call site in a non-bootstrap callerClass, then 
bootstrap classloader should be sufficient to resolve types that appear 
at the call site in a bootstrap callerClass. Does anybody have any other 
opinion?

- sun.invoke.util.BytecodeDescriptor#parseMethod(java.lang.String, 
java.lang.ClassLoader) is only used from the newly introduced 
java.lang.invoke.MethodType#fromDescriptor


Regards, Peter

>
> Paul.
>
> On 25 Sep 2015, at 15:37, Michael Haupt <michael.haupt at oracle.com> wrote:
>
>> Hi Peter,
>>
>> thanks for this changeset. Note I'm not a Reviewer (with a capital R); please read this review in lower-case. ;-)
>>
>> One question about MethodType: would you mind doing something about the naming of the newly introduced fromDescriptor() method? Its name does not suggest in any way that it chooses the class loader differently. The name is subtly different from that of fromDescriptorString(), and the signature is identical - it's probably really easy to confuse the two when working at the core libs level. Unfortunately, the only proposal for a name I can make, fromDescriptorStringBootCL(), is clunky. Maybe that's acceptable for a low-level method only visible at package level.
>>
>>> Am 25.09.2015 um 08:46 schrieb Peter Levart <peter.levart at gmail.com>:
>>> I have run the tests in java.lang.invoke and only have a problem with 1 test which seems to be related to the test or jtreg itself and happens also without my patch applied:
>>>
>>> #Test Results (version 2)
>>> #Tue Sep 22 09:48:38 CEST 2015
>>> ...
>>> #section:script_messages
>>> ----------messages:(0/0)----------
>>>
>>>
>>> test result: Error. Parse Exception: `@library' must appear before first `@run'
>> Yes. The test is also marked as ignored until another issue is fixed, so that can be ignored.
>>
>> Other than the above remark/suggestion, this looks fine. I'll defer to an upper-case Reviewer, though.
>>
>> Best,
>>
>> Michael
>>
>> --
>>
>> <http://www.oracle.com/>
>> Dr. Michael Haupt | Principal Member of Technical Staff
>> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
>> Oracle Java Platform Group | LangTools Team | Nashorn
>> Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
>> <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment
>>



From peter.levart at gmail.com  Fri Sep 25 15:32:08 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 25 Sep 2015 17:32:08 +0200
Subject: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure
	initialization
In-Reply-To: <79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com>
References: <5604EDAE.7080501@gmail.com>
	<79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com>
Message-ID: <560568F8.10805@gmail.com>

Hi Michael,

On 09/25/2015 03:37 PM, Michael Haupt wrote:
> Hi Peter,
>
> thanks for this changeset. Note I'm not a Reviewer (with a capital R); please read this review in lower-case. ;-)
>
> One question about MethodType: would you mind doing something about the naming of the newly introduced fromDescriptor() method? Its name does not suggest in any way that it chooses the class loader differently. The name is subtly different from that of fromDescriptorString(), and the signature is identical - it's probably really easy to confuse the two when working at the core libs level. Unfortunately, the only proposal for a name I can make, fromDescriptorStringBootCL(), is clunky. Maybe that's acceptable for a low-level method only visible at package level.

Well, the correct self-describing name would then be 
fromDescriptorStringNullIsBootstrapCL()...

Perhaps a note in the javadoc that this is the preferred method for 
internal use would be sufficient? We can't make a reference from public 
method to the package-private one in javadoc though.

Another option would be to create new method as public API and 
@Deprecate the old one. There is a convention that null means bootstrap 
loader in other public APIs as well (for example: Class.forName(String 
name, boolean initialize, ClassLoader loader); ) although passing null 
from user code is rarely needed if at all. This is usually just for 
internal use.

Regards, Peter

>
>> Am 25.09.2015 um 08:46 schrieb Peter Levart <peter.levart at gmail.com>:
>> I have run the tests in java.lang.invoke and only have a problem with 1 test which seems to be related to the test or jtreg itself and happens also without my patch applied:
>>
>> #Test Results (version 2)
>> #Tue Sep 22 09:48:38 CEST 2015
>> ...
>> #section:script_messages
>> ----------messages:(0/0)----------
>>
>>
>> test result: Error. Parse Exception: `@library' must appear before first `@run'
> Yes. The test is also marked as ignored until another issue is fixed, so that can be ignored.
>
> Other than the above remark/suggestion, this looks fine. I'll defer to an upper-case Reviewer, though.
>
> Best,
>
> Michael
>



From kevinb at google.com  Fri Sep 25 15:33:02 2015
From: kevinb at google.com (Kevin Bourrillion)
Date: Fri, 25 Sep 2015 08:33:02 -0700
Subject: JEP 269: Convenience Factory Methods for Collections
In-Reply-To: <20150924000217.D476B7A327@eggemoggin.niobe.net>
References: <20150924000217.D476B7A327@eggemoggin.niobe.net>
Message-ID: <CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com>

I don't think the proposal is bad, but for whatever it's worth to you... we
wouldn't use it. And would probably advise all Guava users not to, either.
In most cases new JDK functionality that replaces old Guava functionality
comes out anywhere from "slightly" to "a lot" better, and in all these
cases we advise switching to your stuff. But not this time, for at least
one key reason.

Guava's immutable collections are very useful as *types*, not just as
implementations. That is, while specific implementation classes are not
exposed, abstract types like ImmutableList and ImmutableSortedSet are
public (these should be thought of as "interfaces" in every logical sense
except that they cannot be implemented outside the package).

When advising how to chose, say, a method return type, our advice is "use
the most general type that still carries all the relevant semantic
guarantees your caller should be able to depend on." The additional
semantic information carried by our ImmutableSet type is that it (a) is a
thread-safe immutable snapshot, (b) will never contain null, and (c)
iterates in a deterministic order. Almost always, users do consider those
semantic guarantees to be highly relevant. If the method could not return
ImmutableSet, they would have to stuff a whole bunch of loose verbiage into
their javadoc about it (which is effectively nearly equivalent to that
information being lost).

Another example of the usefulness of types is that by making a field of
type ImmutableMap, then if my constructor accepts a plain Map I *can't
accidentally forget* to make a defensive copy. Another example is that if
anyone does try to call .add(), we can issue an IDE warning.

We could have a debate over just *how* important this is (we've become
solidly convinced over the years), but then, I'm not sure we see what the
upside of using this (for anyone able to use Guava) would be anyway.

(If, and somehow I feel this is unlikely, you were willing to add this
fleet of immutable types as abstract classes, you could go with a more
streamlined name than ours, like ImList. People would get used to it.)

Other quick comments:

Note that without permitting nulls, Map.of(key, Optional.of(value)) will
become reasonably common, and that fact you can't serialize that will
become even more strange than it already is.

I think the example of "double-brace initialization" should be even more
clearly labeled as pure evil. :-) You could also mention all the horrible
consequences if anyone ever serializes such a collection.



On Wed, Sep 23, 2015 at 5:02 PM, <mark.reinhold at oracle.com> wrote:

> New JEP Candidate: http://openjdk.java.net/jeps/269
>
> - Mark
>



-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com


From mandy.chung at oracle.com  Fri Sep 25 15:49:02 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 25 Sep 2015 08:49:02 -0700
Subject: RFR [9] 8137056: Move SharedSecrets and interface friends out of
	sun.misc
In-Reply-To: <5938CBAC-F63C-429A-8258-E4A5D02C3142@oracle.com>
References: <5938CBAC-F63C-429A-8258-E4A5D02C3142@oracle.com>
Message-ID: <84B3F99E-0586-4F43-8ACD-806ABE832463@oracle.com>


> On Sep 24, 2015, at 7:16 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> In preparation for JEP 260 "Encapsulate Most Internal APIs? [1],
> SharedSecrets and friend interfaces should be moved out of
> 'sun.misc? [2] and located in a truly private package. This is so that
> they are not part of the proposed to be exported ?sun.misc'
> package.
> 
> http://cr.openjdk.java.net/~chegar/8137056.00/

Looked at the updated version.  Looks good to me.

Mandy

From joe.darcy at oracle.com  Fri Sep 25 17:33:19 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 25 Sep 2015 10:33:19 -0700
Subject: JDK 9 RFR of JDK-8136874: Bug in port of fdlibm pow to Java
Message-ID: <5605855F.7070907@oracle.com>

Hello,

After a good amount of staring at the code, I was able to figure out the 
cause of the previously reported problem in the initial port of FDLIBM 
pow to Java:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035276.html

In brief, I had replaced some magnitude comparisons based directly on 
the high-order 32-bits of a floating-point value with comparisons of the 
64-bit floating-point value instead. In some cases, the trailing 32-bit 
need to be accounted for as well.

For the problematic cases in this bug:

Original fdlibm code where iy and ix and the high-order 32-bits of the 
absolute values of y and x, respectively:

  201     /* |y| is huge */
  202         if(iy>0x41e00000) { /* if |y| > 2**31 */
[snip]       // Not relevant here
  207         /* over/underflow if x is not close to one */
  208             if(ix<0x3fefffff) return (hy<0)? s*huge*huge:s*tiny*tiny;
  209             if(ix>0x3ff00000) return (hy>0)? s*huge*huge:s*tiny*tiny;

Code in corrected port:

  354             // |y| is huge
  355             if (y_abs > 0x1.00000_ffff_ffffp31) { // if |y| > ~2**31
[snip]          // Not relevant here
  360                 // Over/underflow if x is not close to one
  361                 if (x_abs < 0x1.fffff_0000_0000p-1) // |x| < 
~0.9999995231628418
  362                     return (y < 0.0) ? s * INFINITY : s * 0.0;
  363                 if (x_abs > 0x1.00000_ffff_ffffp0) // |x| > ~1.0
  364                     return (y > 0.0) ? s * INFINITY : s * 0.0;

In the end, only two lines of code were meaningfully changed, the ones 
with a greater-than comparison:

              // |y| is huge
-            if (y_abs > 0x1.0p31) { // if |y| > 2**31
+            if (y_abs > 0x1.00000_ffff_ffffp31) { // if |y| > ~2**31
                  final double INV_LN2   =  0x1.7154_7652_b82fep0; //  
1.44269504088896338700e+00 = 1/ln2
                  final double INV_LN2_H =  0x1.715476p0; //  
1.44269502162933349609e+00 = 24 bits of 1/ln2
                  final double INV_LN2_L =  0x1.4ae0_bf85_ddf44p-26; //  
1.92596299112661746887e-08 = 1/ln2 tail

                  // Over/underflow if x is not close to one
-                if (x_abs < 0x1.fffffp-1) // |x| < 0.9999995231628418
+                if (x_abs < 0x1.fffff_0000_0000p-1) // |x| < 
~0.9999995231628418
                      return (y < 0.0) ? s * INFINITY : s * 0.0;
-                if (x_abs > 1.0)         // |x| > 1.0
+                if (x_abs > 0x1.00000_ffff_ffffp0)         // |x| > ~1.0
                      return (y > 0.0) ? s * INFINITY : s * 0.0;
                  /*
                   * now |1-x| is tiny <= 2**-20, sufficient to compute
                   * log(x) by x - x^2/2 + x^3/3 - x^4/4
                   */

In the hex floating-point notation, the first five digits of the 
significant align with the high-order 32-bits. For example, the 
floating-point values with the high-order bits corresponding to 
0x1.00000p31 range over

     0x1.00000_0000_0000p31
     0x1.00000_0000_0001p31
      ...
     0x1.00000_ffff_fffep31
     0x1.00000_ffff_ffffp31

Therefore, when the original sources used

     ix>0x3ff00000

this is equivalent to

     x_abs > 0x1.00000_ffff_ffffp31

since that is the largest value whose high-order 32 bits are 0x3ff00000.

Full webrev of the changes up at

     JDK-8136874: Bug in port of fdlibm pow to Java - Java Bug System
     http://cr.openjdk.java.net/~darcy/8136874.0/

The bulk of the changeset is a new battery of tests including the 
failing values reported earlier.

I checked the other replacements of ix in the pow code and they seem 
okay, but I wouldn't mind another pair of eyes looking over it; webrev 
of the initial port is at http://cr.openjdk.java.net/~darcy/8134795.6/.

I'll review the port of hypot for analogous problems.

Thanks again to Jeff Hain for the reporting the incorrect behavior of 
the port.

Cheers,

-Joe


From forax at univ-mlv.fr  Fri Sep 25 19:20:16 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 25 Sep 2015 21:20:16 +0200 (CEST)
Subject: JEP 269: Convenience Factory Methods for Collections
In-Reply-To: <CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com>
References: <20150924000217.D476B7A327@eggemoggin.niobe.net>
	<CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com>
Message-ID: <1548646383.2640105.1443208816341.JavaMail.zimbra@u-pem.fr>

Hi Kevin,

----- Mail original -----
> De: "Kevin Bourrillion" <kevinb at google.com>
> ?: "Core Libs Dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 25 Septembre 2015 17:33:02
> Objet: Re: JEP 269: Convenience Factory Methods for Collections
> 
> I don't think the proposal is bad, but for whatever it's worth to you... we
> wouldn't use it. And would probably advise all Guava users not to, either.
> In most cases new JDK functionality that replaces old Guava functionality
> comes out anywhere from "slightly" to "a lot" better, and in all these
> cases we advise switching to your stuff. But not this time, for at least
> one key reason.
> 
> Guava's immutable collections are very useful as *types*, not just as
> implementations. That is, while specific implementation classes are not
> exposed, abstract types like ImmutableList and ImmutableSortedSet are
> public (these should be thought of as "interfaces" in every logical sense
> except that they cannot be implemented outside the package).
> 
> When advising how to chose, say, a method return type, our advice is "use
> the most general type that still carries all the relevant semantic
> guarantees your caller should be able to depend on." The additional
> semantic information carried by our ImmutableSet type is that it (a) is a
> thread-safe immutable snapshot, (b) will never contain null, and (c)
> iterates in a deterministic order. Almost always, users do consider those
> semantic guarantees to be highly relevant. If the method could not return
> ImmutableSet, they would have to stuff a whole bunch of loose verbiage into
> their javadoc about it (which is effectively nearly equivalent to that
> information being lost).
> 
> Another example of the usefulness of types is that by making a field of
> type ImmutableMap, then if my constructor accepts a plain Map I *can't
> accidentally forget* to make a defensive copy. Another example is that if
> anyone does try to call .add(), we can issue an IDE warning.
> 
> We could have a debate over just *how* important this is (we've become
> solidly convinced over the years), but then, I'm not sure we see what the
> upside of using this (for anyone able to use Guava) would be anyway.

This proposal could be split in two parts, one is the introduction of static factory methods for common implementations, ArrayList, HashMap, etc,
the other is the introduction of immutable implementations for factory methods in interface.

I agree with you that having a way to express immutable collection types is big improvement for Java knowing that currently there is no way to enforce that a class is immutable, you just express that in the Javadoc. That said, i think that using an interface (or worst an abstract class) to represent an immutable collection type is not a good and flexible way to express those kind of types.
We have annotation on types since 8, having an annotation like @Immutable (with the IGJ checker framework by example) is IMO far better.
Unlike an interface, an annotation on type let you retrofit existing code by introducing the annotation without breaking existing code and reports as you said an error when you use a method that mutate the object.
The main drawback is that the annotation checker is something optional so you have to have your CI script correctly configured, not something that hard but still an issue.

> 
> (If, and somehow I feel this is unlikely, you were willing to add this
> fleet of immutable types as abstract classes, you could go with a more
> streamlined name than ours, like ImList. People would get used to it.)
> 
> Other quick comments:
> 
> Note that without permitting nulls, Map.of(key, Optional.of(value)) will
> become reasonably common, and that fact you can't serialize that will
> become even more strange than it already is.

Please don't do that, if you have a mapping between a key and something that doesn't exist, the best is to not have that mapping,
this is the semantics of java.util.concurrent (with null instead of Optional) and this is the only sane semantics.
Optional should never appear in collections/maps, it makes the code that deal with this kind of beast stupidly harder to read/write for no benefit.

> 
> I think the example of "double-brace initialization" should be even more
> clearly labeled as pure evil. :-) You could also mention all the horrible
> consequences if anyone ever serializes such a collection.

I fully agree, it also makes callsite megamorphic for no reason.

best,
R?mi

> 
> 
> 
> On Wed, Sep 23, 2015 at 5:02 PM, <mark.reinhold at oracle.com> wrote:
> 
> > New JEP Candidate: http://openjdk.java.net/jeps/269
> >
> > - Mark
> >
> 
> 
> 
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
> 


From huizhe.wang at oracle.com  Fri Sep 25 19:41:00 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 25 Sep 2015 12:41:00 -0700
Subject: RFR (JAXP) 8135283: DOM API update: Element Traversal Specification
Message-ID: <5605A34C.2070001@oracle.com>

Hi,

Please review the DOM update to include the Element Traversal 
Specification. ElementTraversal is an interface which allows the author 
to restrict navigation to Element nodes.

The implementation is the result of a merge with the upper Xerces 
source. The new methods implementation starts at line 1173 if you want 
to avoid the lot of formatting changes due to a NetBeans Source Format.

https://bugs.openjdk.java.net/browse/JDK-8135283
http://cr.openjdk.java.net/~joehw/jdk9/8135283/webrev/

Thanks,
Joe



From lance.andersen at oracle.com  Fri Sep 25 20:15:09 2015
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 25 Sep 2015 16:15:09 -0400
Subject: RFR (JAXP) 8135283: DOM API update: Element Traversal
	Specification
In-Reply-To: <5605A34C.2070001@oracle.com>
References: <5605A34C.2070001@oracle.com>
Message-ID: <268C0C73-4916-4C01-8A37-C4457552D3CC@oracle.com>

Hi Joe,

The change and the test looks overall.

One minor suggestion on the javadocs, I might change <i> </i> to @{code} on line 177

Best
Lance


On Sep 25, 2015, at 3:41 PM, huizhe wang <huizhe.wang at oracle.com> wrote:

> Hi,
> 
> Please review the DOM update to include the Element Traversal Specification. ElementTraversal is an interface which allows the author to restrict navigation to Element nodes.
> 
> The implementation is the result of a merge with the upper Xerces source. The new methods implementation starts at line 1173 if you want to avoid the lot of formatting changes due to a NetBeans Source Format.
> 
> https://bugs.openjdk.java.net/browse/JDK-8135283
> http://cr.openjdk.java.net/~joehw/jdk9/8135283/webrev/
> 
> Thanks,
> Joe
> 



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





From huizhe.wang at oracle.com  Fri Sep 25 20:44:54 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 25 Sep 2015 13:44:54 -0700
Subject: RFR (JAXP) 8135283: DOM API update: Element Traversal
	Specification
In-Reply-To: <268C0C73-4916-4C01-8A37-C4457552D3CC@oracle.com>
References: <5605A34C.2070001@oracle.com>
	<268C0C73-4916-4C01-8A37-C4457552D3CC@oracle.com>
Message-ID: <5605B246.5060401@oracle.com>


On 9/25/2015 1:15 PM, Lance Andersen wrote:
> Hi Joe,
>
> The change and the test looks overall.

Thanks Lance!
>
> One minor suggestion on the javadocs, I might change <i> </i> to 
> @{code} on line 177

Sure, changed. Makes me feel like we could use a @emphasize @em tag :-)

Best,
Joe

>
> Best
> Lance
>
>
> On Sep 25, 2015, at 3:41 PM, huizhe wang <huizhe.wang at oracle.com 
> <mailto:huizhe.wang at oracle.com>> wrote:
>
>> Hi,
>>
>> Please review the DOM update to include the Element Traversal 
>> Specification. ElementTraversal is an interface which allows the 
>> author to restrict navigation to Element nodes.
>>
>> The implementation is the result of a merge with the upper Xerces 
>> source. The new methods implementation starts at line 1173 if you 
>> want to avoid the lot of formatting changes due to a NetBeans Source 
>> Format.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8135283
>> http://cr.openjdk.java.net/~joehw/jdk9/8135283/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 mandy.chung at oracle.com  Fri Sep 25 21:18:11 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 25 Sep 2015 14:18:11 -0700
Subject: RFR (JAXP) 8135283: DOM API update: Element Traversal
	Specification
In-Reply-To: <5605A34C.2070001@oracle.com>
References: <5605A34C.2070001@oracle.com>
Message-ID: <5605BA13.3030609@oracle.com>


On 09/25/2015 12:41 PM, huizhe wang wrote:
> Hi,
>
> Please review the DOM update to include the Element Traversal 
> Specification. ElementTraversal is an interface which allows the 
> author to restrict navigation to Element nodes.
>
> The implementation is the result of a merge with the upper Xerces 
> source. The new methods implementation starts at line 1173 if you want 
> to avoid the lot of formatting changes due to a NetBeans Source Format.
> https://bugs.openjdk.java.net/browse/JDK-8135283
> http://cr.openjdk.java.net/~joehw/jdk9/8135283/webrev/

Thanks for doing this.

With this application/libraries used to put xml-apis-2.11.0.jar on the 
endorsed/ext directory or classpath no longer needs to do that because 
org.w3c.dom.ElementTraversal was not part of the DOM API endorsed by 
JAXP in JDK 8.

I skimmed through the change that looks okay.

214                         URI _uri = new URI(uri, true);

This change removed the catching of MalformedURLException that will fall 
back to use parentBaseURI. i.e. now it won't fall back to use 
parentBaseURI if line 214 throws MUE.  Is that intentional?

ElementTraveral.java

   52  * See also the

This can use @see instead

Mandy



From huizhe.wang at oracle.com  Fri Sep 25 21:38:54 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 25 Sep 2015 14:38:54 -0700
Subject: RFR (JAXP) 8135283: DOM API update: Element Traversal
	Specification
In-Reply-To: <5605BA13.3030609@oracle.com>
References: <5605A34C.2070001@oracle.com> <5605BA13.3030609@oracle.com>
Message-ID: <5605BEEE.4070302@oracle.com>


On 9/25/2015 2:18 PM, Mandy Chung wrote:
>
> On 09/25/2015 12:41 PM, huizhe wang wrote:
>> Hi,
>>
>> Please review the DOM update to include the Element Traversal 
>> Specification. ElementTraversal is an interface which allows the 
>> author to restrict navigation to Element nodes.
>>
>> The implementation is the result of a merge with the upper Xerces 
>> source. The new methods implementation starts at line 1173 if you 
>> want to avoid the lot of formatting changes due to a NetBeans Source 
>> Format.
>> https://bugs.openjdk.java.net/browse/JDK-8135283
>> http://cr.openjdk.java.net/~joehw/jdk9/8135283/webrev/
>
> Thanks for doing this.

Yay, finally got around to get this done!
>
> With this application/libraries used to put xml-apis-2.11.0.jar on the 
> endorsed/ext directory or classpath no longer needs to do that because 
> org.w3c.dom.ElementTraversal was not part of the DOM API endorsed by 
> JAXP in JDK 8.
>
> I skimmed through the change that looks okay.
>
> 214                         URI _uri = new URI(uri, true);
>
> This change removed the catching of MalformedURLException that will 
> fall back to use parentBaseURI. i.e. now it won't fall back to use 
> parentBaseURI if line 214 throws MUE.  Is that intentional?

Yes. It was a performance improvement, quote:

Reduce MalformedURIExceptions thrown while
resolving xml:base. The URI class previously only accepted
absolute URIs so at least one exception was always being
thrown for relative URIs.

>
> ElementTraveral.java
>
>   52  * See also the
>
> This can use @see instead

Fixed.

Thanks,
Joe

>
> Mandy
>



From mandy.chung at oracle.com  Fri Sep 25 22:40:26 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 25 Sep 2015 15:40:26 -0700
Subject: RFR (JAXP) 8135283: DOM API update: Element Traversal
	Specification
In-Reply-To: <5605BEEE.4070302@oracle.com>
References: <5605A34C.2070001@oracle.com> <5605BA13.3030609@oracle.com>
	<5605BEEE.4070302@oracle.com>
Message-ID: <5605CD5A.9050806@oracle.com>


On 09/25/2015 02:38 PM, huizhe wang wrote:
>
>>
>> With this application/libraries used to put xml-apis-2.11.0.jar on 
>> the endorsed/ext directory or classpath no longer needs to do that 
>> because org.w3c.dom.ElementTraversal was not part of the DOM API 
>> endorsed by JAXP in JDK 8.
>>
>> I skimmed through the change that looks okay.
>>
>> 214                         URI _uri = new URI(uri, true);
>>
>> This change removed the catching of MalformedURLException that will 
>> fall back to use parentBaseURI. i.e. now it won't fall back to use 
>> parentBaseURI if line 214 throws MUE.  Is that intentional?
>
> Yes. It was a performance improvement, quote:
>
> Reduce MalformedURIExceptions thrown while
> resolving xml:base. The URI class previously only accepted
> absolute URIs so at least one exception was always being
> thrown for relative URIs.

Okay.  Sounds good.

Mandy


From huizhe.wang at oracle.com  Fri Sep 25 23:43:35 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 25 Sep 2015 16:43:35 -0700
Subject: RFR (JAXP) 8135283: DOM API update: Element Traversal
	Specification
In-Reply-To: <5605CD5A.9050806@oracle.com>
References: <5605A34C.2070001@oracle.com> <5605BA13.3030609@oracle.com>
	<5605BEEE.4070302@oracle.com> <5605CD5A.9050806@oracle.com>
Message-ID: <5605DC27.7030401@oracle.com>

Thanks Mandy and Lance for the review!  Changes pushed.

-Joe

On 9/25/2015 3:40 PM, Mandy Chung wrote:
>
> On 09/25/2015 02:38 PM, huizhe wang wrote:
>>
>>>
>>> With this application/libraries used to put xml-apis-2.11.0.jar on 
>>> the endorsed/ext directory or classpath no longer needs to do that 
>>> because org.w3c.dom.ElementTraversal was not part of the DOM API 
>>> endorsed by JAXP in JDK 8.
>>>
>>> I skimmed through the change that looks okay.
>>>
>>> 214                         URI _uri = new URI(uri, true);
>>>
>>> This change removed the catching of MalformedURLException that will 
>>> fall back to use parentBaseURI. i.e. now it won't fall back to use 
>>> parentBaseURI if line 214 throws MUE.  Is that intentional?
>>
>> Yes. It was a performance improvement, quote:
>>
>> Reduce MalformedURIExceptions thrown while
>> resolving xml:base. The URI class previously only accepted
>> absolute URIs so at least one exception was always being
>> thrown for relative URIs.
>
> Okay.  Sounds good.
>
> Mandy



From amaembo at gmail.com  Sat Sep 26 08:32:49 2015
From: amaembo at gmail.com (Tagir F. Valeev)
Date: Sat, 26 Sep 2015 14:32:49 +0600
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <D94F57D3-8C81-496C-8880-791A310C1D51@oracle.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com> 
	<248664718.20150925180011@gmail.com>
	<D94F57D3-8C81-496C-8880-791A310C1D51@oracle.com>
Message-ID: <1086977314.20150926143249@gmail.com>

Hello!

>> Quite interesting and long awaited features (at least according to
>> StackOverflow questions).

PS> All of them? or just the first?

The first one is definitely the most requested feature. However,
additional methods for primitive optionals were requested at least
twice:
http://stackoverflow.com/q/29104968/4856258
http://stackoverflow.com/q/23414903/4856258

Something like mapOrElseGet was implicitly requested here
(though it's more look like ifPresentOrElse)
http://stackoverflow.com/q/23773024/4856258

>> Isn't it a good idea to provide also a way
>> to transfer between Optional types like "mapToInt", "mapToObj", etc.,
>> like it's done in Stream API?
>> 

PS> I don?t wanna go there, my response is transform Optional* into a
PS> *Stream. An argument for adding mapOrElseGet (notice that the
PS> primitive variants return U) is that other functionality can be composed from it.

Probably then it's better instead of adding map, filter, etc. just add
single "boxed()" method to convert OptionalDouble to Optional<Double>,
etc.? So if somebody really wants to chain optional calls, let them do
the boxing and use the features of normal Optional.

With best regards,
Tagir Valeev.



From michael.haupt at oracle.com  Sat Sep 26 13:55:13 2015
From: michael.haupt at oracle.com (Michael Haupt)
Date: Sat, 26 Sep 2015 15:55:13 +0200
Subject: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure
	initialization
In-Reply-To: <560568F8.10805@gmail.com>
References: <5604EDAE.7080501@gmail.com>
	<79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com>
	<560568F8.10805@gmail.com>
Message-ID: <FE1A1A82-5B3D-405F-899E-78F83CA71AA4@oracle.com>

Hi Peter,

> Am 25.09.2015 um 17:32 schrieb Peter Levart <peter.levart at gmail.com>:
>> One question about MethodType: would you mind doing something about the naming of the newly introduced fromDescriptor() method? Its name does not suggest in any way that it chooses the class loader differently. The name is subtly different from that of fromDescriptorString(), and the signature is identical - it's probably really easy to confuse the two when working at the core libs level. Unfortunately, the only proposal for a name I can make, fromDescriptorStringBootCL(), is clunky. Maybe that's acceptable for a low-level method only visible at package level.
> 
> Well, the correct self-describing name would then be fromDescriptorStringNullIsBootstrapCL()...

yes ... or the entire source code in camel case. ;-) I see your point, and wasn't happy with my original proposal either.

> Perhaps a note in the javadoc that this is the preferred method for internal use would be sufficient? We can't make a reference from public method to the package-private one in javadoc though.

That's a good idea.

Best,

Michael

-- 

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



From sven.reimers at gmail.com  Sat Sep 26 16:41:51 2015
From: sven.reimers at gmail.com (Sven Reimers)
Date: Sat, 26 Sep 2015 18:41:51 +0200
Subject: Implementing https://bugs.openjdk.java.net/browse/JDK-5071718
Message-ID: <CAP+Jvx5wD8SWBkxTPEcouCo-pVzMWe8EVdrkzkGBFS3QTvdWxQ@mail.gmail.com>

Hi all,

what would it take to get JDK-5071718 into 9?

I thought about something like this;

/**
 Creates a new byte buffer whose content is a shared subsequence of this
buffer's content.

The content of the new buffer will start at the given position. The
capacity and limit of the new buffer will be the given length. Changes to
this buffer's content will be visible in the new buffer, and vice versa;
the two buffers' position, limit, and mark values will be independent.

The new buffer's position will be zero, and its mark will be undefined. The
new buffer will be direct if, and only if, this buffer is direct, and it
will be read-only if, and only if, this buffer is read-only.
Returns:The new byte buffer
 **/
public abstract ByteBuffer slice(int start, int length)


Probably should emit some exception in case start or start+length are
greater than the underlying buffer length. Any further ideas for required
checks?

Seems I need to modify the templates to get this distributed to all the
variants existing - not only ByteBuffer.

Anyone able to guide me and help me get this through - I am willing to
provide implementation and tests if I know where to look for obstacles and
challenges?

Thanks

Sven
-- 
Sven Reimers

* Senior Expert Software Architect
* Java Champion
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* Community Leader  NetBeans: http://community.java.net/netbeans
                              Desktop Java:
http://community.java.net/javadesktop
* JUG Leader JUG Bodensee: http://www.jug-bodensee.de
* Duke's Choice Award Winner 2009
* Blog: https://www.java.net//blog/sven


From chris.hegarty at oracle.com  Sat Sep 26 19:36:17 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 26 Sep 2015 20:36:17 +0100
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
Message-ID: <AA79068E-DD99-49D8-AB85-28FD9F86DEB0@oracle.com>


> On 25 Sep 2015, at 11:58, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi,
> 
> Please review this change to add a method Optional.or that allows one to better compose optionals:
> 
>  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/
> 
> I also took the opportunity to clear up the JavaDoc, it was a little inconsistent and i personally found it harder to read in source code.

The new method and code cleanup look good.

Not related to your changes, but I noticed when reviewing the clean up, typo ?OptionAL.empty()"

  L80 * {@code Option.empty()}. There is no guarantee that it is a singleton.

-Chris.

From alexander.v.stepanov at oracle.com  Sun Sep 27 13:52:28 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Sun, 27 Sep 2015 06:52:28 -0700 (PDT)
Subject: P.S.: RFR [9] 8133651: automated replacing of old-style tags in docs
Message-ID: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default>

Hello Martin,

Here is some simple app. to replace <code></code> tags with a new-style {@code } one (which is definitely not so elegant as the Perl one-liners):
http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java

Corresponding patch for jdk and replacement log (~62k of the tag changes):
http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log
(sorry, I have to check the correctness of the patch with specdiff yet, so this is rather demo at the moment).

Don't know if these changes (cosmetic by nature) are desired for now or not. Moreover, probably some part of them should go to another repos (e.g., awt, swing -> "client" instead of "dev").

Regards,
Alexander



----- ???????? ????????? -----
??: alexander.v.stepanov at oracle.com
????: martinrb at google.com
?????: core-libs-dev at openjdk.java.net
????????????: ???????, 24 ???????? 2015 ? 16:06:56 GMT +03:00 ??????, ?????-?????????, ?????????
????: Re: RFR [9] 8133651: replace some <tt> tags (obsolete in html5) in core-libs docs

Hello Martin,

Thank you for review and for the notes!

 > I'm biased of course, but I like the approach I took with 
blessed-modifier-order:
 > - make the change completely automated
 > - leave "human editing" for a separate change
 > - publish the code used to make the automated change (in my case, 
typically a perl one-liner)

Automated replacement has an obvious advantage: it is fast and massive. 
But there are some disadvantages at the same time (just IMHO).

Using script it is quite easy to miss some not very trivial cases, e.g.:
- remove unnecessary linebreaks, like
  * <tt>someCode
  * </tt>
(which would be better to replace with single-line {@code someCode};
- joining of successive terms, like "<tt>ONE</tt>, <tt>TWO</tt>, 
<tt>THREE</tt>" -> "{@code ONE, TWO, THREE}";
- errors like extra or missing "&lt;" or "&gt;": * <tt>Collection 
&lt;T></tt>", - there were a lot of them;
- some cases when <tt></tt> should be replaced with <code></code>, not 
{@code } (e.g. because of unicode characters inside of code etc.);
- extra tags inside of <tt> or <code> which should be moved outside of 
{@code }, like <tt><i>someCode</i></tt> or <tt><b>someCode</b></tt>;
- simple removing of needless tags, like "<tt>{@link ...}</tt>" -> 
"{@link ...}";
- replace HTML codes with symbols ('<', '>', '@', ...)
- etc.
- plus some other formatting changes and fixes for misprints which would 
be omitted during the automated replacement (and wouldn't be done in 
future manually because there is no motivation for repeated processing).

So sometimes it may be difficult to say where is the border between 
"trivial" and "human-editing" cases (and the portion of "non-trivial 
cases" is definitely not minor); moreover, even the automated 
replacement requires the subsequent careful review before publishing of 
webrev (as well as by reviewers who probably wouldn't be happy to review 
hundreds of files at the same time) and iterative checks/corrections. 
specdiff is very useful for this task but also cannot fully cover the 
diffs (as some changes are situated in the internal com/... sun/... 
packages).

Moreover, I'm sure that some reviewers would be annoyed with the fact 
that some (quite simple) changes were postponed because they are "not 
too trivial to be fixed just now" (because they will suspect they would 
be postponed forever). So the patch creator would (probably) receive 
some advices during the review like "please fix also fix this and that" 
(which is normal, of course).

So my preference was to make the changes package by package (in some 
reasonable amount of files) not postponing part of the changes for the 
future (sorry for these boring repeating review requests). Please note 
that all the above mentioned is *rather explanation of my motivation 
than objection* :) (and of course I used some text editor replace 
automation which is surely not so advanced as Perl).

 > It's probably correct, but I would have left it out of this change
Yes, I see. Reverted (please update the web page):
http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html

Thanks,
Alexander

P.S. The <tt> replacement job is mostly (I guess, ~80%) complete. But 
probably this approach should be used if some similar replacement task 
for, e.g., <code></code> tags would be planned in future (there are 
thousands of them).


On 9/24/2015 6:10 AM, Martin Buchholz wrote:
>
>
> On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov 
> <alexander.v.stepanov at oracle.com 
> <mailto:alexander.v.stepanov at oracle.com>> wrote:
>
>     Hello,
>
>     Could you please review the following fix
>     http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/
>     <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/>
>     http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html
>     <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html>
>     for
>     https://bugs.openjdk.java.net/browse/JDK-8133651
>
>     Just another portion of deprecated <tt> (and <xmp>) tags replaced
>     with {@code }. Some misprints were also fixed.
>
>
> I'm biased of course, but I like the approach I took with 
> blessed-modifier-order:
> - make the change completely automated
> - leave "human editing" for a separate change
> - publish the code used to make the automated change (in my case, 
> typically a perl one-liner)
>
>
>     The following (expected) changes were detected by specdiff:
>     - removed needless dashes in java.util.Locale,
>     - removed needless curly brace in xml.bind.annotation.XmlElementRef
>
>
> I would do a separate automated "removed needless dashes" changeset.
>
>
>     Please let me know if the following changes are desirable or not:
>     http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html
>     <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html>
>
>
> This is an actual change to the behavior of this code - the 
> maintainers of jconsole need to approve it.  It's probably correct, 
> but I would have left it out of this change. If you remove it, then I 
> approve this change.



From paul.sandoz at oracle.com  Mon Sep 28 08:27:10 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 28 Sep 2015 10:27:10 +0200
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <1086977314.20150926143249@gmail.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
	<248664718.20150925180011@gmail.com>
	<D94F57D3-8C81-496C-8880-791A310C1D51@oracle.com>
	<1086977314.20150926143249@gmail.com>
Message-ID: <00882528-B543-4027-B5A7-D21AC1CF8F82@oracle.com>


> On 26 Sep 2015, at 10:32, Tagir F. Valeev <amaembo at gmail.com> wrote:
> 
> Hello!
> 
>>> Quite interesting and long awaited features (at least according to
>>> StackOverflow questions).
> 
> PS> All of them? or just the first?
> 
> The first one is definitely the most requested feature. However,
> additional methods for primitive optionals were requested at least
> twice:
> http://stackoverflow.com/q/29104968/4856258
> http://stackoverflow.com/q/23414903/4856258
> 

> Something like mapOrElseGet was implicitly requested here
> (though it's more look like ifPresentOrElse)
> http://stackoverflow.com/q/23773024/4856258
> 

Thanks.


>>> Isn't it a good idea to provide also a way
>>> to transfer between Optional types like "mapToInt", "mapToObj", etc.,
>>> like it's done in Stream API?
>>> 
> 
> PS> I don?t wanna go there, my response is transform Optional* into a
> PS> *Stream. An argument for adding mapOrElseGet (notice that the
> PS> primitive variants return U) is that other functionality can be composed from it.
> 
> Probably then it's better instead of adding map, filter, etc. just add
> single "boxed()" method to convert OptionalDouble to Optional<Double>,
> etc.? So if somebody really wants to chain optional calls, let them do
> the boxing and use the features of normal Optional.
> 

Some degree of parity will i think avoid confusion, but I was also pondering a boxed method, independent of the map/filter etc, if the more general usage (map.orElseGet, mapOrElseGet/fold) proves too difficult.

I think it?s fine to to pollute OptionalInt etc with Optional but i want to avoid it for the other direction.

Paul.


From paul.sandoz at oracle.com  Mon Sep 28 09:24:35 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 28 Sep 2015 11:24:35 +0200
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <AA79068E-DD99-49D8-AB85-28FD9F86DEB0@oracle.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
	<AA79068E-DD99-49D8-AB85-28FD9F86DEB0@oracle.com>
Message-ID: <E1C2B27E-25F0-4020-9D9A-616E5B398F0A@oracle.com>


> On 26 Sep 2015, at 21:36, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> 
>> On 25 Sep 2015, at 11:58, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Please review this change to add a method Optional.or that allows one to better compose optionals:
>> 
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/
>> 
>> I also took the opportunity to clear up the JavaDoc, it was a little inconsistent and i personally found it harder to read in source code.
> 
> The new method and code cleanup look good.
> 
> Not related to your changes, but I noticed when reviewing the clean up, typo ?OptionAL.empty()"
> 
>  L80 * {@code Option.empty()}. There is no guarantee that it is a singleton.
> 

Thanks, updated,
Paul.


From paul.sandoz at oracle.com  Mon Sep 28 10:01:13 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 28 Sep 2015 12:01:13 +0200
Subject: Implementing https://bugs.openjdk.java.net/browse/JDK-5071718
In-Reply-To: <CAP+Jvx5wD8SWBkxTPEcouCo-pVzMWe8EVdrkzkGBFS3QTvdWxQ@mail.gmail.com>
References: <CAP+Jvx5wD8SWBkxTPEcouCo-pVzMWe8EVdrkzkGBFS3QTvdWxQ@mail.gmail.com>
Message-ID: <9336F7E1-2195-4141-B2A3-B987BDB2CB9F@oracle.com>

Hi Sven,

Your intuition is right, you need to modify associated templates e.g.:

  jdk/src/java.base/share/classes/java/nio/*-X-Buffer.java.template

The best thing to do is pick an existing method common to all buffers (such as the existing slice method), work out how it is implemented and then copy the pattern. Looking at the generated source will also help, especially from an IDE, where you can see what generated classes implement and overrides e.g see:

  build/macosx-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBuffer.java

There is likely a similar pattern to follow for the tests.

Paul.


> On 26 Sep 2015, at 18:41, Sven Reimers <sven.reimers at gmail.com> wrote:
> 
> Hi all,
> 
> what would it take to get JDK-5071718 into 9?
> 
> I thought about something like this;
> 
> /**
> Creates a new byte buffer whose content is a shared subsequence of this
> buffer's content.
> 
> The content of the new buffer will start at the given position. The
> capacity and limit of the new buffer will be the given length. Changes to
> this buffer's content will be visible in the new buffer, and vice versa;
> the two buffers' position, limit, and mark values will be independent.
> 
> The new buffer's position will be zero, and its mark will be undefined. The
> new buffer will be direct if, and only if, this buffer is direct, and it
> will be read-only if, and only if, this buffer is read-only.
> Returns:The new byte buffer
> **/
> public abstract ByteBuffer slice(int start, int length)
> 
> 
> Probably should emit some exception in case start or start+length are
> greater than the underlying buffer length. Any further ideas for required
> checks?
> 
> Seems I need to modify the templates to get this distributed to all the
> variants existing - not only ByteBuffer.
> 
> Anyone able to guide me and help me get this through - I am willing to
> provide implementation and tests if I know where to look for obstacles and
> challenges?
> 
> Thanks
> 
> Sven
> --
> Sven Reimers
> 
> * Senior Expert Software Architect
> * Java Champion
> * NetBeans Dream Team Member: http://dreamteam.netbeans.org
> * Community Leader  NetBeans: http://community.java.net/netbeans
>                              Desktop Java:
> http://community.java.net/javadesktop
> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de
> * Duke's Choice Award Winner 2009
> * Blog: https://www.java.net//blog/sven



From amy.lu at oracle.com  Mon Sep 28 10:58:39 2015
From: amy.lu at oracle.com (Amy Lu)
Date: Mon, 28 Sep 2015 18:58:39 +0800
Subject: JDK 9 RFR of JDK-8137232: Mark 3 more core-libs tests as
	intermittently failing
Message-ID: <56091D5F.4080705@oracle.com>

Below tests are known to fail intermittently:

java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java
java/net/NetworkInterface/NetworkInterfaceStreamTest.java
javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java

This patch is to mark them accordingly with keyword 'intermittent'.

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

Thanks,
Amy

--- old/test/java/net/NetworkInterface/NetworkInterfaceStreamTest.java 
  2015-09-28 15:25:27.000000000 +0800
+++ new/test/java/net/NetworkInterface/NetworkInterfaceStreamTest.java 
  2015-09-28 15:25:27.000000000 +0800
@@ -28,6 +28,7 @@
   * @build java.util.stream.OpTestCase
   * @run testng/othervm NetworkInterfaceStreamTest
   * @run testng/othervm -Djava.net.preferIPv4Stack=true 
NetworkInterfaceStreamTest
+ * @key intermittent
   */

  import org.testng.annotations.Test;
--- 
old/test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java 
  2015-09-28 15:25:28.000000000 +0800
+++ 
new/test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java 
  2015-09-28 15:25:28.000000000 +0800
@@ -36,6 +36,7 @@
   *          java.rmi/sun.rmi.transport.tcp
   * @build TestLibrary RMID ActivationLibrary
   * @run main/othervm/timeout=240 InheritedChannelNotServerSocket
+ * @key intermittent
   */

  import java.io.IOException;
--- old/test/javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java 
  2015-09-28 15:25:29.000000000 +0800
+++ new/test/javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java 
  2015-09-28 15:25:29.000000000 +0800
@@ -29,6 +29,7 @@
   * @build jdk.testlibrary.*
   * @build Test HelloInterface HelloServer HelloClient HelloImpl 
_HelloImpl_Tie _HelloInterface_Stub ConcurrentHashMapTest
   * @run main/othervm -Djava.naming.provider.url=iiop://localhost:1050 
-Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory 
ConcurrentHashMapTest
+ * @key intermittent
   */







From chris.hegarty at oracle.com  Mon Sep 28 12:11:26 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 28 Sep 2015 13:11:26 +0100
Subject: JDK 9 RFR of JDK-8137232: Mark 3 more core-libs tests as
	intermittently failing
In-Reply-To: <56091D5F.4080705@oracle.com>
References: <56091D5F.4080705@oracle.com>
Message-ID: <56092E6E.6000704@oracle.com>

Looks fine Amy.

-Chris.

On 28/09/15 11:58, Amy Lu wrote:
> Below tests are known to fail intermittently:
>
> java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java
>
> java/net/NetworkInterface/NetworkInterfaceStreamTest.java
> javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java
>
> This patch is to mark them accordingly with keyword 'intermittent'.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8137232
> webrev: http://cr.openjdk.java.net/~amlu/8137232/webrev.00/
>
> Thanks,
> Amy
>
> --- old/test/java/net/NetworkInterface/NetworkInterfaceStreamTest.java
>   2015-09-28 15:25:27.000000000 +0800
> +++ new/test/java/net/NetworkInterface/NetworkInterfaceStreamTest.java
>   2015-09-28 15:25:27.000000000 +0800
> @@ -28,6 +28,7 @@
>    * @build java.util.stream.OpTestCase
>    * @run testng/othervm NetworkInterfaceStreamTest
>    * @run testng/othervm -Djava.net.preferIPv4Stack=true
> NetworkInterfaceStreamTest
> + * @key intermittent
>    */
>
>   import org.testng.annotations.Test;
> ---
> old/test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java
>   2015-09-28 15:25:28.000000000 +0800
> +++
> new/test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java
>   2015-09-28 15:25:28.000000000 +0800
> @@ -36,6 +36,7 @@
>    *          java.rmi/sun.rmi.transport.tcp
>    * @build TestLibrary RMID ActivationLibrary
>    * @run main/othervm/timeout=240 InheritedChannelNotServerSocket
> + * @key intermittent
>    */
>
>   import java.io.IOException;
> --- old/test/javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java
>   2015-09-28 15:25:29.000000000 +0800
> +++ new/test/javax/rmi/PortableRemoteObject/ConcurrentHashMapTest.java
>   2015-09-28 15:25:29.000000000 +0800
> @@ -29,6 +29,7 @@
>    * @build jdk.testlibrary.*
>    * @build Test HelloInterface HelloServer HelloClient HelloImpl
> _HelloImpl_Tie _HelloInterface_Stub ConcurrentHashMapTest
>    * @run main/othervm -Djava.naming.provider.url=iiop://localhost:1050
> -Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory
> ConcurrentHashMapTest
> + * @key intermittent
>    */
>
>
>
>
>


From vyom.tewari at oracle.com  Mon Sep 28 15:46:12 2015
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Mon, 28 Sep 2015 21:16:12 +0530
Subject: RFR 8038075 : JNI warnings in
	jdk/src/share/native/sun/misc/VMSupport.c
Message-ID: <560960C4.8020201@oracle.com>

Hi All,

Please review my changes for below bug.

Bug:             JDK-8038075 : JNI warnings in 
jdk/src/share/native/sun/misc/VMSupport.c
Webrev: http://cr.openjdk.java.net/~dfuchs/vyom/8038075/webrev.00/ 
<http://cr.openjdk.java.net/%7Edfuchs/vyom/8038075/webrev.00/>

This change ensure that there is no jni pending exception.

Thanks,
Vyom


From Roger.Riggs at Oracle.com  Mon Sep 28 16:03:16 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 28 Sep 2015 12:03:16 -0400
Subject: RFR 8038075 : JNI warnings in
	jdk/src/share/native/sun/misc/VMSupport.c
In-Reply-To: <560960C4.8020201@oracle.com>
References: <560960C4.8020201@oracle.com>
Message-ID: <560964C4.5030704@Oracle.com>

Hi Vyom,

Looks fine.

Roger

On 9/28/2015 11:46 AM, Vyom Tewari wrote:
> Hi All,
>
> Please review my changes for below bug.
>
> Bug:             JDK-8038075 : JNI warnings in 
> jdk/src/share/native/sun/misc/VMSupport.c
> Webrev: http://cr.openjdk.java.net/~dfuchs/vyom/8038075/webrev.00/ 
> <http://cr.openjdk.java.net/%7Edfuchs/vyom/8038075/webrev.00/>
>
> This change ensure that there is no jni pending exception.
>
> Thanks,
> Vyom



From spliterator at gmail.com  Mon Sep 28 17:45:10 2015
From: spliterator at gmail.com (Stefan Zobel)
Date: Mon, 28 Sep 2015 19:45:10 +0200
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
Message-ID: <CAPkkuScqziNGWO1q2iJkXhO4Xy49pQV9AxRg-Bvgnc21sosgag@mail.gmail.com>

Hi Paul,

is it a good idea to add the "{@inheritDoc}" to the toString() Javadoc of
Optional (and to retain it in OptionalDouble/Int/Long)?

As Stuart Marks has observed in the Double/Int/LongSummaryStatistics case
the inherited Object.toString() doc is "mostly irrelevant"
(see
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034282.html)

So the {@inheritDoc} got removed from Double/Int/LongSummaryStatistics in
JDK-8080450. I feel this would also be better for Optional.


Stefan


2015-09-25 12:58 GMT+02:00 Paul Sandoz <paul.sandoz at oracle.com>:

> Hi,
>
> Please review this change to add a method Optional.or that allows one to
> better compose optionals:
>
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/
>
> I also took the opportunity to clear up the JavaDoc, it was a little
> inconsistent and i personally found it harder to read in source code.
>
> ?
>
> Separately while we are on the topic of Optional i would be interested in
> opinions on the following changes:
>
>
> http://cr.openjdk.java.net/~psandoz/jdk9/optional-prims-filter-map/webrev/
>
> 1) add methods that were missing on the primitive specializations; and
>
> 2) add to all variants a mapOrElseGet (otherwise known as a ?fold?), which
> is the equivalent of map(mapper).orElseGet(supplier). That is arguably less
> mind-bending to use when transforming from Optional<T> to Optional<U>.
>
> Paul.
>


From spliterator at gmail.com  Mon Sep 28 18:00:38 2015
From: spliterator at gmail.com (Stefan Zobel)
Date: Mon, 28 Sep 2015 20:00:38 +0200
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <E1C2B27E-25F0-4020-9D9A-616E5B398F0A@oracle.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
	<AA79068E-DD99-49D8-AB85-28FD9F86DEB0@oracle.com>
	<E1C2B27E-25F0-4020-9D9A-616E5B398F0A@oracle.com>
Message-ID: <CAPkkuSfaCUv2Z4HGtG7zPXWMtacm94V0Pmcnxq2d9S5cx_PaYQ@mail.gmail.com>

In the OptionalDouble/Int/Long Javadoc of method "empty()"


* {@code Optional.empty()}. There is no guarantee that it is a singleton.


should be


* {@code OptionalDouble.empty()}.  There is no guarantee that it is a
singleton.

and so on.


Stefan


2015-09-28 11:24 GMT+02:00 Paul Sandoz <paul.sandoz at oracle.com>:

>
> > On 26 Sep 2015, at 21:36, Chris Hegarty <chris.hegarty at oracle.com>
> wrote:
> >
> >
> >> On 25 Sep 2015, at 11:58, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> >>
> >> Hi,
> >>
> >> Please review this change to add a method Optional.or that allows one
> to better compose optionals:
> >>
> >>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/
> >>
> >> I also took the opportunity to clear up the JavaDoc, it was a little
> inconsistent and i personally found it harder to read in source code.
> >
> > The new method and code cleanup look good.
> >
> > Not related to your changes, but I noticed when reviewing the clean up,
> typo ?OptionAL.empty()"
> >
> >  L80 * {@code Option.empty()}. There is no guarantee that it is a
> singleton.
> >
>
> Thanks, updated,
> Paul.
>


From marcins at microsoft.com  Mon Sep 28 18:09:44 2015
From: marcins at microsoft.com (Martin Sawicki)
Date: Mon, 28 Sep 2015 18:09:44 +0000
Subject: RFR 8124977 cmdline encoding challenges on Windows
In-Reply-To: <558C017A.2020708@oracle.com>
References: <BL2PR03MB129E41BE390D9817942125D9FA10@BL2PR03MB129.namprd03.prod.outlook.com>
	<BL2PR03MB1291795A4A5B1004915B8609FA10@BL2PR03MB129.namprd03.prod.outlook.com>
	<558C017A.2020708@oracle.com>
Message-ID: <BLUPR03MB4408297D06531A2E10E0DF3A84F0@BLUPR03MB440.namprd03.prod.outlook.com>

Hi all
Here's an updated webrev attempting to take into account the various pieces of feedback we have received:

Issue:
  https://bugs.openjdk.java.net/browse/JDK-8124977
Webrev:
  http://cr.openjdk.java.net/~kshoop/8124977/webrev.03/

(Vladimir Shcherbakov is now working on this from our side)

Looking forward to any other feedback.
Thanks

-----Original Message-----
From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Kumar Srinivasan
Sent: Thursday, June 25, 2015 6:26 AM
To: Kirk Shoop (MS OPEN TECH) <Kirk.Shoop at microsoft.com>
Cc: Valery Kopylov (Akvelon) <v-valkop at microsoft.com>; core-libs-dev Libs <core-libs-dev at openjdk.java.net>
Subject: Re: RFR 8124977 cmdline encoding challenges on Windows

Hi Kirk,

Thanks for proposing this change.

If you notice all the posix calls are wrapped in JLI_* this  gives us the ability to use "W" functions.  I almost got it done, several years ago, but we upgraded to VS2010 and my work based on VS2003 keeled over, meanwhile my focus was  "shifted" to something else.

main.c: is really envisioned to be a stub  compiled by the tool launchers, like java, javac, javah, jar etc. I prefer to see all the heavy logic in this file moved to the platform specific file windows/java_md.*

For the reason specified above we need to move fprintf or any naked posix calls to JLI_* indirections.

I don't see any tests ? The tests must be written in java and placed in jdk/test/tools/launcher, there is a helper framework TestHelper.java.

There are other changes in nio, charsets etc, this will be reviewed by my colleague specializing in that area (Sherman) cc'ed.


Thanks

Kumar






On 6/22/2015 2:01 PM, Kirk Shoop (MS OPEN TECH) wrote:
> Hi,
>
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8124977
>
> Webrev:
>    http://cr.openjdk.java.net/~kshoop/8124977/
>
> This webrev intends to address interaction between Windows console and java apps.
>
> Two switches were added that change the behavior of the launcher. The defaults do not change the launcher behavior.
>
>    -Dwindows.UnicodeConsole=true - switches on Unicode support in the Windows console. This optional switch causes the launcher to call GetCommandLineW() and parse the arguments in unicode. It also modifies how the codepage for console output is selected.
>
>    -Dfile.encoding.unicode="UTF-8" - identifies Unicode charset to use; If not specified, UTF-8 is used by default. Ignored when windows.UnicodeConsole is not set to true. When the first switch is used, this optional switch allows the codepage for console output to be controlled.
>
> I would like to get feedback on the approach here and any additional work that is required solve these particular Unicode issues on Windows.
>
> Kirk



From joe.darcy at oracle.com  Tue Sep 29 00:10:44 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 28 Sep 2015 17:10:44 -0700
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
	<DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
Message-ID: <5609D704.4050707@oracle.com>

Hello,

Joining this thread late, I think the range checking methods would have 
a happier life where they are more often found and used if the they live 
somewhere other than the exception classes.

The class java.util.Objects is not an ideal host for these methods, 
since they don't deal directly with objects per se, but the scope of 
Objects could be expanded to include these utilities as well.

-Joe

On 9/22/2015 1:23 AM, Paul Sandoz wrote:
> Hi Jason,
>
> Not a bad idea, after some I tend to agree.
>
> I was hesitating for two reasons, one is that they might be harder to find, and the other is not all reported exceptions will be instances of IndexOutOfBoundsException. However, as you point out not all bound checks are related to arrays and i think that is more so the case than exceptions related to IndexOutOfBoundsException.
>
> Paul.
>
> On 21 Sep 2015, at 21:17, Jason Mehrens <jason_mehrens at hotmail.com> wrote:
>
>> Hi Paul,
>>
>> Would it make sense to add these methods to the IndexOutOfBoundsException class itself or is there a compatibility worry?  Seems better to use the room in IndexOutOfBoundsException class file and keep these methods out of the Arrays class.  It is also odd that in the future the LinkedList would depend on the Arrays class to check bounds.
>>
>> Jason
>>
>> ________________________________________
>> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Paul Sandoz <paul.sandoz at oracle.com>
>> Sent: Monday, September 21, 2015 8:42 AM
>> To: core-libs-dev
>> Subject: RFR 8135248: Add utility methods to check indexes and ranges
>>
>> Hi,
>>
>> Please review the following which adds methods to Arrays to check indexes and ranges:
>>
>>   https://bugs.openjdk.java.net/browse/JDK-8135248
>>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/
>>
>> The original motivation was an intrinsic method, Arrays.checkIndex, to check if an index is within bounds. Such an intrinsic guides HotSpot towards better optimisations for bounds checks using one unsigned comparison instead of two signed comparisons, and better eliding of integer to long conversions when an index is used to create an offset for Unsafe access. The end result is more efficient array access especially so from within unrolled loops. The VarHandles work will use Arrays.checkIndex for array access.
>>
>> A follow up issue [1] will track the intrinsification of Arrays.checkIndex.
>>
>> We thought it would be opportunistic to support two further common use-cases for sub-range checks, Arrays.checkFromToIndex and Arrays.
>> checkFromIndexSize. There is no current plan to intrinsify these methods.
>>
>> Bounds checking is not difficult but it can be easy to make trivial mistakes. Thus it is advantageous to consolidate such checks not just from an optimization perspective but from a correctness and security/integrity perspective.
>>
>> There are many areas in the JDK where such checks are performed. A follow up issue [2] will track updates to use the new methods.
>>
>> The main challenge for these new methods is to design in such a way that
>>
>> 1) existing use-cases can still report the same set of exceptions with the same messages;
>> 2) method byte code size is not unduly increased, thus perturbing inlining; and
>> 3) there is a reasonable path for any future support of long indexes.
>>
>> Paul.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8042997
>> [2] https://bugs.openjdk.java.net/browse/JDK-8135250



From brian.burkhalter at oracle.com  Tue Sep 29 01:06:40 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 28 Sep 2015 18:06:40 -0700
Subject: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact
	methods for java.lang.Math
Message-ID: <604C9A0D-D55D-4962-A007-D188E9077063@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8023217
Patch:	http://cr.openjdk.java.net/~bpb/8023217/webrev.00/

Summary:
Add some additional methods of the same name as existing methods but with the commonly used parameter signature ?long,int?:

long multiplyExact(long,int)
long floorDiv(long,int)
int floorDiv(long,int)

These methods also provide hooks for potential intrinsics. There might be room for improvement in their Java implementations.

The modifications to the java.time classes are to fix warnings about ?redundant cast to int.? 

Thanks,

Brian

From joe.darcy at oracle.com  Tue Sep 29 02:17:46 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Mon, 28 Sep 2015 19:17:46 -0700
Subject: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact
	methods for java.lang.Math
In-Reply-To: <604C9A0D-D55D-4962-A007-D188E9077063@oracle.com>
References: <604C9A0D-D55D-4962-A007-D188E9077063@oracle.com>
Message-ID: <5609F4CA.2010605@oracle.com>

Hi Brian,

Do you think any tests are needed here, at least for a quick sanity check?

Thanks,

-Joe

On 9/28/2015 6:06 PM, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8023217
> Patch:	http://cr.openjdk.java.net/~bpb/8023217/webrev.00/
>
> Summary:
> Add some additional methods of the same name as existing methods but with the commonly used parameter signature ?long,int?:
>
> long multiplyExact(long,int)
> long floorDiv(long,int)
> int floorDiv(long,int)
>
> These methods also provide hooks for potential intrinsics. There might be room for improvement in their Java implementations.
>
> The modifications to the java.time classes are to fix warnings about ?redundant cast to int.?
>
> Thanks,
>
> Brian



From john.r.rose at oracle.com  Tue Sep 29 04:48:37 2015
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 28 Sep 2015 21:48:37 -0700
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <5609D704.4050707@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
	<DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
	<5609D704.4050707@oracle.com>
Message-ID: <B6E72165-91C2-451A-9929-F5C4CC6440CB@oracle.com>

On Sep 28, 2015, at 5:10 PM, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> 
> Joining this thread late, I think the range checking methods would have a happier life where they are more often found and used if the they live somewhere other than the exception classes.
> 
> The class java.util.Objects is not an ideal host for these methods, since they don't deal directly with objects per se, but the scope of Objects could be expanded to include these utilities as well.

You have a point, that's probably a better bikeshed.

Since the key operation is an integer compare, putting it on Integer (near compare) would also be defensible.

(The new factory methods for exceptions make sense on the exceptions themselves, of course.)

? John

From paul.sandoz at oracle.com  Tue Sep 29 07:39:08 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 29 Sep 2015 09:39:08 +0200
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <CAPkkuScqziNGWO1q2iJkXhO4Xy49pQV9AxRg-Bvgnc21sosgag@mail.gmail.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
	<CAPkkuScqziNGWO1q2iJkXhO4Xy49pQV9AxRg-Bvgnc21sosgag@mail.gmail.com>
Message-ID: <F5E42131-6749-48AA-A081-62402F5B51A4@oracle.com>


> On 28 Sep 2015, at 19:45, Stefan Zobel <spliterator at gmail.com> wrote:
> 
> Hi Paul,
> 
> is it a good idea to add the "{@inheritDoc}" to the toString() Javadoc of
> Optional (and to retain it in OptionalDouble/Int/Long)?
> 
> As Stuart Marks has observed in the Double/Int/LongSummaryStatistics case
> the inherited Object.toString() doc is "mostly irrelevant"
> (see
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034282.html)
> 
> So the {@inheritDoc} got removed from Double/Int/LongSummaryStatistics in
> JDK-8080450. I feel this would also be better for Optional.
> 

Done.


> On 28 Sep 2015, at 20:00, Stefan Zobel <spliterator at gmail.com> wrote:
> 
> In the OptionalDouble/Int/Long Javadoc of method "empty()"
> 
> 
> * {@code Optional.empty()}. There is no guarantee that it is a singleton.
> 
> 
> should be
> 
> 
> * {@code OptionalDouble.empty()}.  There is no guarantee that it is a
> singleton.
> 
> and so on.

Done.

Thanks,
Paul.


From daniel.fuchs at oracle.com  Tue Sep 29 08:25:19 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 29 Sep 2015 10:25:19 +0200
Subject: RFR 8038075 : JNI warnings in
	jdk/src/share/native/sun/misc/VMSupport.c
In-Reply-To: <560964C4.5030704@Oracle.com>
References: <560960C4.8020201@oracle.com> <560964C4.5030704@Oracle.com>
Message-ID: <560A4AEF.4090208@oracle.com>

Hi Vyom,

I will sponsor your change and push the fix for you.

best regards,

-- daniel

On 28/09/15 18:03, Roger Riggs wrote:
> Hi Vyom,
>
> Looks fine.
>
> Roger
>
> On 9/28/2015 11:46 AM, Vyom Tewari wrote:
>> Hi All,
>>
>> Please review my changes for below bug.
>>
>> Bug:             JDK-8038075 : JNI warnings in
>> jdk/src/share/native/sun/misc/VMSupport.c
>> Webrev: http://cr.openjdk.java.net/~dfuchs/vyom/8038075/webrev.00/
>> <http://cr.openjdk.java.net/%7Edfuchs/vyom/8038075/webrev.00/>
>>
>> This change ensure that there is no jni pending exception.
>>
>> Thanks,
>> Vyom
>



From paul.sandoz at oracle.com  Tue Sep 29 08:44:20 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 29 Sep 2015 10:44:20 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <B6E72165-91C2-451A-9929-F5C4CC6440CB@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
	<DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
	<5609D704.4050707@oracle.com>
	<B6E72165-91C2-451A-9929-F5C4CC6440CB@oracle.com>
Message-ID: <9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>


> On 29 Sep 2015, at 06:48, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Sep 28, 2015, at 5:10 PM, Joseph D. Darcy <joe.darcy at oracle.com <mailto:joe.darcy at oracle.com>> wrote:
>> 
>> Joining this thread late, I think the range checking methods would have a happier life where they are more often found and used if the they live somewhere other than the exception classes.
>> 
>> The class java.util.Objects is not an ideal host for these methods, since they don't deal directly with objects per se, but the scope of Objects could be expanded to include these utilities as well.
> 
> You have a point, that's probably a better bikeshed.
> 

No objections :-) I think it?s a better location to find such methods. Moved, and i also tweaked to class doc of Objects to include static methods for ?checking certain conditions before operation?.


> Since the key operation is an integer compare, putting it on Integer (near compare) would also be defensible.
> 
> (The new factory methods for exceptions make sense on the exceptions themselves, of course.)
> 

I clarified the exception constructors that access one to two out of band values to say they are included in the exception detail message (without actually specifying the presentation format of that message).

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/webrev/>
  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/specdiff/overview-summary.html <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/specdiff/overview-summary.html>

Paul.


From spliterator at gmail.com  Tue Sep 29 09:16:20 2015
From: spliterator at gmail.com (Stefan Zobel)
Date: Tue, 29 Sep 2015 11:16:20 +0200
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <F5E42131-6749-48AA-A081-62402F5B51A4@oracle.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
	<CAPkkuScqziNGWO1q2iJkXhO4Xy49pQV9AxRg-Bvgnc21sosgag@mail.gmail.com>
	<F5E42131-6749-48AA-A081-62402F5B51A4@oracle.com>
Message-ID: <CAPkkuSdti0+Wks4aipmky=cD+C4Ydh31n5ne39P7dRQy_EJ24A@mail.gmail.com>

Looks good. One more nitpicking. "ifPresent() " in OptionalDouble/Int/Long
still uses the old wording


 * If a value is present, perform the given action with the value,
 * otherwise do nothing.


whereas in Optional you have the better


 * If a value is present, performS the given action with the value,
 * otherwise doES nothing.


Stefan


2015-09-29 9:39 GMT+02:00 Paul Sandoz <paul.sandoz at oracle.com>:

>
> > On 28 Sep 2015, at 19:45, Stefan Zobel <spliterator at gmail.com> wrote:
> >
> > Hi Paul,
> >
> > is it a good idea to add the "{@inheritDoc}" to the toString() Javadoc of
> > Optional (and to retain it in OptionalDouble/Int/Long)?
> >
> > As Stuart Marks has observed in the Double/Int/LongSummaryStatistics case
> > the inherited Object.toString() doc is "mostly irrelevant"
> > (see
> >
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034282.html
> )
> >
> > So the {@inheritDoc} got removed from Double/Int/LongSummaryStatistics in
> > JDK-8080450. I feel this would also be better for Optional.
> >
>
> Done.
>
>
> > On 28 Sep 2015, at 20:00, Stefan Zobel <spliterator at gmail.com> wrote:
> >
> > In the OptionalDouble/Int/Long Javadoc of method "empty()"
> >
> >
> > * {@code Optional.empty()}. There is no guarantee that it is a singleton.
> >
> >
> > should be
> >
> >
> > * {@code OptionalDouble.empty()}.  There is no guarantee that it is a
> > singleton.
> >
> > and so on.
>
> Done.
>
> Thanks,
> Paul.
>


From alexander.v.stepanov at oracle.com  Tue Sep 29 10:21:28 2015
From: alexander.v.stepanov at oracle.com (Alexander Stepanov)
Date: Tue, 29 Sep 2015 13:21:28 +0300
Subject: P.S.: RFR [9] 8133651: automated replacing of old-style tags in
	docs
In-Reply-To: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default>
References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default>
Message-ID: <560A6628.5010807@oracle.com>

Updated: a few manual corrections were made (as @linkplain tags displays 
nested {@code } literally):
http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
-checked with specdiff (which of course does not cover documentation for 
internal packages), no unexpected diffs detected.

Regards,
Alexander

On 9/27/2015 4:52 PM, Alexander Stepanov wrote:
> Hello Martin,
>
> Here is some simple app. to replace <code></code> tags with a new-style {@code } one (which is definitely not so elegant as the Perl one-liners):
> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java
>
> Corresponding patch for jdk and replacement log (~62k of the tag changes):
> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log
> (sorry, I have to check the correctness of the patch with specdiff yet, so this is rather demo at the moment).
>
> Don't know if these changes (cosmetic by nature) are desired for now or not. Moreover, probably some part of them should go to another repos (e.g., awt, swing -> "client" instead of "dev").
>
> Regards,
> Alexander
>
>
>
> ----- ???????? ????????? -----
> ??: alexander.v.stepanov at oracle.com
> ????: martinrb at google.com
> ?????: core-libs-dev at openjdk.java.net
> ????????????: ???????, 24 ???????? 2015 ? 16:06:56 GMT +03:00 ??????, ?????-?????????, ?????????
> ????: Re: RFR [9] 8133651: replace some <tt> tags (obsolete in html5) in core-libs docs
>
> Hello Martin,
>
> Thank you for review and for the notes!
>
>   > I'm biased of course, but I like the approach I took with
> blessed-modifier-order:
>   > - make the change completely automated
>   > - leave "human editing" for a separate change
>   > - publish the code used to make the automated change (in my case,
> typically a perl one-liner)
>
> Automated replacement has an obvious advantage: it is fast and massive.
> But there are some disadvantages at the same time (just IMHO).
>
> Using script it is quite easy to miss some not very trivial cases, e.g.:
> - remove unnecessary linebreaks, like
>    * <tt>someCode
>    * </tt>
> (which would be better to replace with single-line {@code someCode};
> - joining of successive terms, like "<tt>ONE</tt>, <tt>TWO</tt>,
> <tt>THREE</tt>" -> "{@code ONE, TWO, THREE}";
> - errors like extra or missing "&lt;" or "&gt;": * <tt>Collection
> &lt;T></tt>", - there were a lot of them;
> - some cases when <tt></tt> should be replaced with <code></code>, not
> {@code } (e.g. because of unicode characters inside of code etc.);
> - extra tags inside of <tt> or <code> which should be moved outside of
> {@code }, like <tt><i>someCode</i></tt> or <tt><b>someCode</b></tt>;
> - simple removing of needless tags, like "<tt>{@link ...}</tt>" ->
> "{@link ...}";
> - replace HTML codes with symbols ('<', '>', '@', ...)
> - etc.
> - plus some other formatting changes and fixes for misprints which would
> be omitted during the automated replacement (and wouldn't be done in
> future manually because there is no motivation for repeated processing).
>
> So sometimes it may be difficult to say where is the border between
> "trivial" and "human-editing" cases (and the portion of "non-trivial
> cases" is definitely not minor); moreover, even the automated
> replacement requires the subsequent careful review before publishing of
> webrev (as well as by reviewers who probably wouldn't be happy to review
> hundreds of files at the same time) and iterative checks/corrections.
> specdiff is very useful for this task but also cannot fully cover the
> diffs (as some changes are situated in the internal com/... sun/...
> packages).
>
> Moreover, I'm sure that some reviewers would be annoyed with the fact
> that some (quite simple) changes were postponed because they are "not
> too trivial to be fixed just now" (because they will suspect they would
> be postponed forever). So the patch creator would (probably) receive
> some advices during the review like "please fix also fix this and that"
> (which is normal, of course).
>
> So my preference was to make the changes package by package (in some
> reasonable amount of files) not postponing part of the changes for the
> future (sorry for these boring repeating review requests). Please note
> that all the above mentioned is *rather explanation of my motivation
> than objection* :) (and of course I used some text editor replace
> automation which is surely not so advanced as Perl).
>
>   > It's probably correct, but I would have left it out of this change
> Yes, I see. Reverted (please update the web page):
> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html
>
> Thanks,
> Alexander
>
> P.S. The <tt> replacement job is mostly (I guess, ~80%) complete. But
> probably this approach should be used if some similar replacement task
> for, e.g., <code></code> tags would be planned in future (there are
> thousands of them).
>
>
> On 9/24/2015 6:10 AM, Martin Buchholz wrote:
>>
>> On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov
>> <alexander.v.stepanov at oracle.com
>> <mailto:alexander.v.stepanov at oracle.com>> wrote:
>>
>>      Hello,
>>
>>      Could you please review the following fix
>>      http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/
>>      <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/>
>>      http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html
>>      <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html>
>>      for
>>      https://bugs.openjdk.java.net/browse/JDK-8133651
>>
>>      Just another portion of deprecated <tt> (and <xmp>) tags replaced
>>      with {@code }. Some misprints were also fixed.
>>
>>
>> I'm biased of course, but I like the approach I took with
>> blessed-modifier-order:
>> - make the change completely automated
>> - leave "human editing" for a separate change
>> - publish the code used to make the automated change (in my case,
>> typically a perl one-liner)
>>
>>
>>      The following (expected) changes were detected by specdiff:
>>      - removed needless dashes in java.util.Locale,
>>      - removed needless curly brace in xml.bind.annotation.XmlElementRef
>>
>>
>> I would do a separate automated "removed needless dashes" changeset.
>>
>>
>>      Please let me know if the following changes are desirable or not:
>>      http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html
>>      <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html>
>>
>>
>> This is an actual change to the behavior of this code - the
>> maintainers of jconsole need to approve it.  It's probably correct,
>> but I would have left it out of this change. If you remove it, then I
>> approve this change.



From scolebourne at joda.org  Tue Sep 29 10:49:23 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 29 Sep 2015 11:49:23 +0100
Subject: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact
	methods for java.lang.Math
In-Reply-To: <5609F4CA.2010605@oracle.com>
References: <604C9A0D-D55D-4962-A007-D188E9077063@oracle.com>
	<5609F4CA.2010605@oracle.com>
Message-ID: <CACzrW9DLvBk1B7dhwLCmJFZvMLGkSE0NQfsQfkkcFLZaWPmmpA@mail.gmail.com>

Good to see this happen.

I agree a test would be good to demonstrate edge cases.

1)
I think the code for floorMod(long x, int y); cannot actually
overflow. As such, the result could just be cast without the if and
throw.


2)
My preferred algorithm for floorMod is:

return ((a % b) + b) % b;

as it contains no Java-side branches, although tests would be needed
to prove performance.

This also allows an algorithm for floorDiv with no Java-side branches:

int mod = ((a % b) + b) % b;
return (a - mod) / b;


3)
While making changes, this code could be changed to avoid the local
variable (just return):
public static int floorMod(int x, int y) {
  int r = x - floorDiv(x, y) * y;
  return r;
}

Stephen


On 29 September 2015 at 03:17, Joseph D. Darcy <joe.darcy at oracle.com> wrote:
> Hi Brian,
>
> Do you think any tests are needed here, at least for a quick sanity check?
>
> Thanks,
>
> -Joe
>
>
> On 9/28/2015 6:06 PM, Brian Burkhalter wrote:
>>
>> Please review at your convenience.
>>
>> Issue:  https://bugs.openjdk.java.net/browse/JDK-8023217
>> Patch:  http://cr.openjdk.java.net/~bpb/8023217/webrev.00/
>>
>> Summary:
>> Add some additional methods of the same name as existing methods but with
>> the commonly used parameter signature ?long,int?:
>>
>> long multiplyExact(long,int)
>> long floorDiv(long,int)
>> int floorDiv(long,int)
>>
>> These methods also provide hooks for potential intrinsics. There might be
>> room for improvement in their Java implementations.
>>
>> The modifications to the java.time classes are to fix warnings about
>> ?redundant cast to int.?
>>
>> Thanks,
>>
>> Brian
>
>


From scolebourne at joda.org  Tue Sep 29 10:57:02 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 29 Sep 2015 11:57:02 +0100
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
	<DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
	<5609D704.4050707@oracle.com>
	<B6E72165-91C2-451A-9929-F5C4CC6440CB@oracle.com>
	<9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>
Message-ID: <CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com>

Just to note that an ideal location for this would be on a new class,
one that has been discussed before, an "argument checker class".

See Guava Preconditions:
https://github.com/google/guava/blob/master/guava/src/com/google/common/base/Preconditions.java

See Commons Lang Validate:
https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/Validate.html

See OpenGamma ArgChecker:
http://opengamma.github.io/StrataDocs/apidocs/com/opengamma/strata/collect/ArgChecker.html
https://github.com/OpenGamma/Strata/blob/master/modules/collect/src/main/java/com/opengamma/strata/collect/ArgChecker.java

This was discussed when Objects.requiresNotNull was discussed IIRC. I
still think it would be a great addition to the JDK (as every project
has something similar). This issue could be the start, although it
would need a few more methods, guided by the examples above.

Stephen



On 29 September 2015 at 09:44, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>> On 29 Sep 2015, at 06:48, John Rose <john.r.rose at oracle.com> wrote:
>>
>> On Sep 28, 2015, at 5:10 PM, Joseph D. Darcy <joe.darcy at oracle.com <mailto:joe.darcy at oracle.com>> wrote:
>>>
>>> Joining this thread late, I think the range checking methods would have a happier life where they are more often found and used if the they live somewhere other than the exception classes.
>>>
>>> The class java.util.Objects is not an ideal host for these methods, since they don't deal directly with objects per se, but the scope of Objects could be expanded to include these utilities as well.
>>
>> You have a point, that's probably a better bikeshed.
>>
>
> No objections :-) I think it?s a better location to find such methods. Moved, and i also tweaked to class doc of Objects to include static methods for ?checking certain conditions before operation?.
>
>
>> Since the key operation is an integer compare, putting it on Integer (near compare) would also be defensible.
>>
>> (The new factory methods for exceptions make sense on the exceptions themselves, of course.)
>>
>
> I clarified the exception constructors that access one to two out of band values to say they are included in the exception detail message (without actually specifying the presentation format of that message).
>
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/webrev/ <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/webrev/>
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/specdiff/overview-summary.html <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-ioobe-check-index-range/specdiff/overview-summary.html>
>
> Paul.


From paul.sandoz at oracle.com  Tue Sep 29 13:55:57 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 29 Sep 2015 15:55:57 +0200
Subject: RFR 8080418 Add Optional.or()
In-Reply-To: <CAPkkuSdti0+Wks4aipmky=cD+C4Ydh31n5ne39P7dRQy_EJ24A@mail.gmail.com>
References: <2C9C9A31-7AA0-47CC-B17A-35A7188F4F8B@oracle.com>
	<CAPkkuScqziNGWO1q2iJkXhO4Xy49pQV9AxRg-Bvgnc21sosgag@mail.gmail.com>
	<F5E42131-6749-48AA-A081-62402F5B51A4@oracle.com>
	<CAPkkuSdti0+Wks4aipmky=cD+C4Ydh31n5ne39P7dRQy_EJ24A@mail.gmail.com>
Message-ID: <FFE19F4A-3BF1-452F-B558-A17D48C75EF9@oracle.com>


> On 29 Sep 2015, at 11:16, Stefan Zobel <spliterator at gmail.com> wrote:
> 
> Looks good. One more nitpicking. "ifPresent() " in OptionalDouble/Int/Long
> still uses the old wording
> 
> 
> * If a value is present, perform the given action with the value,
> * otherwise do nothing.
> 
> 
> whereas in Optional you have the better
> 
> 
> * If a value is present, performS the given action with the value,
> * otherwise doES nothing.
> 

Thanks, updated,
Paul.


From brian.burkhalter at oracle.com  Tue Sep 29 15:00:11 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 29 Sep 2015 08:00:11 -0700
Subject: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact
	methods for java.lang.Math
In-Reply-To: <5609F4CA.2010605@oracle.com>
References: <604C9A0D-D55D-4962-A007-D188E9077063@oracle.com>
	<5609F4CA.2010605@oracle.com>
Message-ID: <C81EB541-5C2A-4AEF-9F6F-0DA12C76DE31@oracle.com>

Hi Joe,

Yes, I wanted to clear the conceptual portion first.

Thanks,

Brian

On Sep 28, 2015, at 7:17 PM, Joseph D. Darcy <Joe.Darcy at Oracle.Com> wrote:

> Do you think any tests are needed here, at least for a quick sanity check?



From brian.burkhalter at oracle.com  Tue Sep 29 15:02:19 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 29 Sep 2015 08:02:19 -0700
Subject: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact
	methods for java.lang.Math
In-Reply-To: <CACzrW9DLvBk1B7dhwLCmJFZvMLGkSE0NQfsQfkkcFLZaWPmmpA@mail.gmail.com>
References: <604C9A0D-D55D-4962-A007-D188E9077063@oracle.com>
	<5609F4CA.2010605@oracle.com>
	<CACzrW9DLvBk1B7dhwLCmJFZvMLGkSE0NQfsQfkkcFLZaWPmmpA@mail.gmail.com>
Message-ID: <836DC71E-B3E6-45DE-BDA4-39617AC4CAC4@oracle.com>

Hi Stephen,

On Sep 29, 2015, at 3:49 AM, Stephen Colebourne <scolebourne at joda.org> wrote:

> Good to see this happen.

Glad to hear it.

> I agree a test would be good to demonstrate edge cases.

I?ll add something.

> 1)
> I think the code for floorMod(long x, int y); cannot actually
> overflow. As such, the result could just be cast without the if and
> throw.

I?ll investigate further.

> 2)
> My preferred algorithm for floorMod is:
> 
> return ((a % b) + b) % b;
> 
> as it contains no Java-side branches, although tests would be needed
> to prove performance.
> 
> This also allows an algorithm for floorDiv with no Java-side branches:
> 
> int mod = ((a % b) + b) % b;
> return (a - mod) / b;

I tested the code which was in the original issue description and found some discrepancies. I?ll need to revisit this to see what happened.

> 
> 3)
> While making changes, this code could be changed to avoid the local
> variable (just return):
> public static int floorMod(int x, int y) {
>  int r = x - floorDiv(x, y) * y;
>  return r;
> }

I agree. I saw that myself but left it as-is.

Thanks,

Brian

From scolebourne at joda.org  Tue Sep 29 15:05:45 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 29 Sep 2015 16:05:45 +0100
Subject: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact
	methods for java.lang.Math
In-Reply-To: <836DC71E-B3E6-45DE-BDA4-39617AC4CAC4@oracle.com>
References: <604C9A0D-D55D-4962-A007-D188E9077063@oracle.com>
	<5609F4CA.2010605@oracle.com>
	<CACzrW9DLvBk1B7dhwLCmJFZvMLGkSE0NQfsQfkkcFLZaWPmmpA@mail.gmail.com>
	<836DC71E-B3E6-45DE-BDA4-39617AC4CAC4@oracle.com>
Message-ID: <CACzrW9AFj4B4-pbVjajJFh55C2Y1ZaV9+gdbTsyS=d90FvX9dQ@mail.gmail.com>

On 29 September 2015 at 16:02, Brian Burkhalter
<brian.burkhalter at oracle.com> wrote:
> 2)
> My preferred algorithm for floorMod is:
>
> return ((a % b) + b) % b;
>
> as it contains no Java-side branches, although tests would be needed
> to prove performance.
>
> This also allows an algorithm for floorDiv with no Java-side branches:
>
> int mod = ((a % b) + b) % b;
> return (a - mod) / b;
>
>
> I tested the code which was in the original issue description and found some
> discrepancies. I?ll need to revisit this to see what happened.

Yes, the code in the issue for floorDiv() fails when the divisor is
negative. The one in my email today works though.
Stephen


From brian.burkhalter at oracle.com  Tue Sep 29 15:16:22 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 29 Sep 2015 08:16:22 -0700
Subject: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact
	methods for java.lang.Math
In-Reply-To: <CACzrW9AFj4B4-pbVjajJFh55C2Y1ZaV9+gdbTsyS=d90FvX9dQ@mail.gmail.com>
References: <604C9A0D-D55D-4962-A007-D188E9077063@oracle.com>
	<5609F4CA.2010605@oracle.com>
	<CACzrW9DLvBk1B7dhwLCmJFZvMLGkSE0NQfsQfkkcFLZaWPmmpA@mail.gmail.com>
	<836DC71E-B3E6-45DE-BDA4-39617AC4CAC4@oracle.com>
	<CACzrW9AFj4B4-pbVjajJFh55C2Y1ZaV9+gdbTsyS=d90FvX9dQ@mail.gmail.com>
Message-ID: <108C6774-3965-4340-A448-033B3651E263@oracle.com>


On Sep 29, 2015, at 8:05 AM, Stephen Colebourne <scolebourne at joda.org> wrote:

>> I tested the code which was in the original issue description and found some
>> discrepancies. I?ll need to revisit this to see what happened.
> 
> Yes, the code in the issue for floorDiv() fails when the divisor is
> negative. The one in my email today works though.

Excellent! I?ll double check it as part of the ?fit and finish."

Thanks,

Brian

From paul.sandoz at oracle.com  Tue Sep 29 16:05:53 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 29 Sep 2015 18:05:53 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
	<DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
	<5609D704.4050707@oracle.com>
	<B6E72165-91C2-451A-9929-F5C4CC6440CB@oracle.com>
	<9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>
	<CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com>
Message-ID: <4B8AD5A1-376F-406B-8A50-44C199CB3471@oracle.com>


> On 29 Sep 2015, at 12:57, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> Just to note that an ideal location for this would be on a new class,
> one that has been discussed before, an "argument checker class".
> 
> See Guava Preconditions:
> https://github.com/google/guava/blob/master/guava/src/com/google/common/base/Preconditions.java
> 
> See Commons Lang Validate:
> https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/Validate.html
> 
> See OpenGamma ArgChecker:
> http://opengamma.github.io/StrataDocs/apidocs/com/opengamma/strata/collect/ArgChecker.html
> https://github.com/OpenGamma/Strata/blob/master/modules/collect/src/main/java/com/opengamma/strata/collect/ArgChecker.java
> 
> This was discussed when Objects.requiresNotNull was discussed IIRC.

FTR here is the discussion:

http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=6797535&sort=date <http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=6797535&sort=date>

AFAICT there was no objection in principle to such classes. I sense that the objection to going that route was due to an increase in scope and as such it would overrun it's budget.


> I
> still think it would be a great addition to the JDK (as every project
> has something similar). This issue could be the start, although it
> would need a few more methods, guided by the examples above.
> 

Just a few *more* bike sheds to paint :-) I am concerned i will never finish this nor other un/related tasks.

For now I am ok with Objects being that "argument checker class? simply because it already has a gravitational pull due to the mass of the existing check methods [*].

Paul.

[*] I believe it is a backwards compatible to change Objects to extends from Preconditions and move the existing static check methods to Preconditions. That seems like a sleazy trick though.


From steve.drach at oracle.com  Tue Sep 29 18:13:40 2015
From: steve.drach at oracle.com (Steve Drach)
Date: Tue, 29 Sep 2015 11:13:40 -0700
Subject: RFR - 8132734: java.util.jar.* changes to support multi-release jar
	files
Message-ID: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com>

Hi,

Please review the following webrev that adds support for multi-release jars as specified in JEP-238.

Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 <https://bugs.openjdk.java.net/browse/JDK-8132734>
JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 <https://bugs.openjdk.java.net/browse/JDK-8047305>
Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ <http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/>

A multi-release jar file is a jar file that contains a manifest with a main attribute named "Multi-Release", and also contains a directory "META-INF/versions" with subdirectories that contain versioned entries segregated by the major version of Java platform releases. A versioned entry, with a version n, in the "META-INF/versions/{n}" directory overrides the unversioned root entry as well as any entry with a version number i  where i < n.
 
The changes in this webrev implement an aliasing mechanism in JarEntry so that when a JarFile client retrieves a JarEntry, the data from the entry pointed to by the alias is returned.  There are methods to configure whether or not aliasing is enabled, and if it is, which version of an entry the alias points to.

When a JarFile is used by a class loader to load class resources, the default version retrieved is the runtime version of the Java platform (i.e. a version 9 entry is returned when the platform is JDK 9).  This mechanism can be configured by System properties.

Thanks,
Steve

From daniel.fuchs at oracle.com  Tue Sep 29 18:15:57 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 29 Sep 2015 20:15:57 +0200
Subject: RFR: 8137289: java/util/logging/DrainFindDeadlockTest.java hangs
Message-ID: <560AD55D.8080009@oracle.com>

Hi,

Please find below a fix for:
8137289: java/util/logging/DrainFindDeadlockTest.java hangs
https://bugs.openjdk.java.net/browse/JDK-8137289

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8137289/webrev.00/

There are in fact two failures reports under similar configuration:
(slow machines?) - fastdebug build - -Xcomp -server -Xcomp

The first thread dump in the bug shows that the test is killed
while the test main class is still initializing.
The test hasn't even started yet.

The second thread dump shows the main class waiting to join
the DeadlockChecker.
The other threads created by the test are nowhere to be seen.

In view of theses two stacks, my analysis is that this is most
probably an issue caused by the timeout=10 parameter on the @run
line.

I'm proposing to remove this timeout and default to jtreg's
timeout. I have also added some additionally prints to show
when threads created by the test terminate...

We will see if that solves the issue...

best regards,

-- daniel


From Alan.Bateman at oracle.com  Tue Sep 29 18:29:45 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 29 Sep 2015 19:29:45 +0100
Subject: RFR - 8132734: java.util.jar.* changes to support multi-release
	jar files
In-Reply-To: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com>
References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com>
Message-ID: <560AD899.2020903@oracle.com>

On 29/09/2015 19:13, Steve Drach wrote:
> Hi,
>
> Please review the following webrev that adds support for multi-release jars as specified in JEP-238.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 <https://bugs.openjdk.java.net/browse/JDK-8132734>
> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 <https://bugs.openjdk.java.net/browse/JDK-8047305>
> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ <http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/>
>
> A multi-release jar file is a jar file that contains a manifest with a main attribute named "Multi-Release", and also contains a directory "META-INF/versions" with subdirectories that contain versioned entries segregated by the major version of Java platform releases. A versioned entry, with a version n, in the "META-INF/versions/{n}" directory overrides the unversioned root entry as well as any entry with a version number i  where i < n.
>   
> The changes in this webrev implement an aliasing mechanism in JarEntry so that when a JarFile client retrieves a JarEntry, the data from the entry pointed to by the alias is returned.  There are methods to configure whether or not aliasing is enabled, and if it is, which version of an entry the alias points to.
>
> When a JarFile is used by a class loader to load class resources, the default version retrieved is the runtime version of the Java platform (i.e. a version 9 entry is returned when the platform is JDK 9).  This mechanism can be configured by System properties.
>
Steve - is the webrev complete, just wondering as I don't see any tests.

-Alan


From daniel.fuchs at oracle.com  Tue Sep 29 18:40:37 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 29 Sep 2015 20:40:37 +0200
Subject: JEP 264: Platform Logging API and Service
In-Reply-To: <55FEB898.6050106@gmail.com>
References: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
	<55FEB898.6050106@gmail.com>
Message-ID: <560ADB25.801@oracle.com>

On 20/09/15 15:46, Peter Levart wrote:
>
>
> On 09/18/2015 06:17 PM, mark.reinhold at oracle.com wrote:
>> New JEP Candidate:http://openjdk.java.net/jeps/264
>>
>> - Mark
>
> Hi,
>
> What is the purpose of exposing a factory for loggers in the generally
> exported package (java.lang) and making it standard Java API as opposed
> to keeping it internal API as it is now
> (sun.util.logging.PlatformLogger)? Is this going to become an official
> front-end for JDK-internal and applications use, available in the
> platform itself?

Hi Peter,

sun.util.logging.PlatformLogger is a module private API in
java.base, yet it is used by other modules in the JDK - and
this requires qualified exports to the modules that use it.
Having a public API that JDK modules could use would simplify
the module graph in this respect.

In time, I'd hope to see sun.util.logging.PlatformLogger disappear
in favor of the public API.

> Otherwise I think it's good to add support for interfacing other
> backends (besides JDK14 Logging and stderr) to platform logger. If one
> wants to interface some other backend to platform logger now, it's
> actually doable, but only via the intermediate JDK14 Logging API, like this:
>
> PlatformLogger -> j.u.l.Logger -> jul-to-slf4j -> slf4j-WHATEVER-BACKEND
>
> Adding support to skip JDK14 Logging would simplify configuration and
> make it more lightweight.

Yes - the goal of the LoggerFinder service API is to make it possible
for applications - or frameworks - to provide their own implementation.

best regards,

-- daniel

>
> Regards, Peter
>



From daniel.fuchs at oracle.com  Tue Sep 29 18:40:44 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 29 Sep 2015 20:40:44 +0200
Subject: JEP 264: Platform Logging API and Service
In-Reply-To: <075935D9-57E4-4417-B7A3-F6408998804A@dslextreme.com>
References: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
	<075935D9-57E4-4417-B7A3-F6408998804A@dslextreme.com>
Message-ID: <560ADB2C.9040209@oracle.com>

Hi Ralph,

On 20/09/15 07:54, Ralph Goers wrote:
> I do have some questions on this.
>
> Would anyone realistically be able to use SLF4J/Logback or Log4j 2 as the implementation?  The logging implementation needs to be able to configure itself before logging can realistically be performed. If logging initialization happens too soon the application?s configuration may not be able to be located.

Bootstraping issues is one of the points that the implementation
of this JEP will need to address. We have already some experience
in that with java.util.logging and the s.u.l.PlatformLogger, but
it's possible that the provider of the concrete LoggerFinder
service implementation will need to play a role as well - depending
on the requirements of the underlying implementation it provides.

The logger returned by System.getLogger may not be directly
a logger obtained from the LoggerFinder service, but a wrapper
that will deal with possible bootstrap issue - for instance by
delaying the creation of the actual logger until such time where
it is actually used.

> Also, to do this would SLF4J/Logback or Log4j 2 have to be added to the boot classpath for them to be used for this?

I believe that the appropriate thing to do is to load
the implementation of the service with the ServiceLoader
from the System ClassLoader.

I also believe that a ServiceConfigurationError should be thrown
if more than one implementation of the service is found.

best regards,

-- daniel

>
> Ralph
>
>> On Sep 18, 2015, at 9:17 AM, mark.reinhold at oracle.com wrote:
>>
>> New JEP Candidate: http://openjdk.java.net/jeps/264
>>
>> - Mark
>>
>
>



From chris.hegarty at oracle.com  Tue Sep 29 18:56:06 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 29 Sep 2015 19:56:06 +0100
Subject: RFR: 8137289: java/util/logging/DrainFindDeadlockTest.java hangs
In-Reply-To: <560AD55D.8080009@oracle.com>
References: <560AD55D.8080009@oracle.com>
Message-ID: <322E66CA-617B-4EEB-816C-DB085657B2EE@oracle.com>

On 29 Sep 2015, at 19:15, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Hi,
> 
> Please find below a fix for:
> 8137289: java/util/logging/DrainFindDeadlockTest.java hangs
> https://bugs.openjdk.java.net/browse/JDK-8137289
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8137289/webrev.00/
> 
> There are in fact two failures reports under similar configuration:
> (slow machines?) - fastdebug build - -Xcomp -server -Xcomp
> 
> The first thread dump in the bug shows that the test is killed
> while the test main class is still initializing.
> The test hasn't even started yet.
> 
> The second thread dump shows the main class waiting to join
> the DeadlockChecker.
> The other threads created by the test are nowhere to be seen.
> 
> In view of theses two stacks, my analysis is that this is most
> probably an issue caused by the timeout=10 parameter on the @run
> line.
> 
> I'm proposing to remove this timeout and default to jtreg's
> timeout.

Removing the timeout is the right thing to do. It serves no purpose, other than to timeout the test if the bug ever exists, which if it does should be fixed ;-) Looks good.

-Chris.

> I have also added some additionally prints to show
> when threads created by the test terminate...
> 
> We will see if that solves the issue...
> 
> best regards,
> 
> -- daniel



From peter.levart at gmail.com  Tue Sep 29 19:24:30 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 29 Sep 2015 21:24:30 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <4B8AD5A1-376F-406B-8A50-44C199CB3471@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
	<DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
	<5609D704.4050707@oracle.com>
	<B6E72165-91C2-451A-9929-F5C4CC6440CB@oracle.com>
	<9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>
	<CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com>
	<4B8AD5A1-376F-406B-8A50-44C199CB3471@oracle.com>
Message-ID: <560AE56E.1020808@gmail.com>



On 09/29/2015 06:05 PM, Paul Sandoz wrote:
>> On 29 Sep 2015, at 12:57, Stephen Colebourne <scolebourne at joda.org> wrote:
>>
>> Just to note that an ideal location for this would be on a new class,
>> one that has been discussed before, an "argument checker class".
>>
>> See Guava Preconditions:
>> https://github.com/google/guava/blob/master/guava/src/com/google/common/base/Preconditions.java
>>
>> See Commons Lang Validate:
>> https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/Validate.html
>>
>> See OpenGamma ArgChecker:
>> http://opengamma.github.io/StrataDocs/apidocs/com/opengamma/strata/collect/ArgChecker.html
>> https://github.com/OpenGamma/Strata/blob/master/modules/collect/src/main/java/com/opengamma/strata/collect/ArgChecker.java
>>
>> This was discussed when Objects.requiresNotNull was discussed IIRC.
> FTR here is the discussion:
>
> http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=6797535&sort=date <http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=6797535&sort=date>
>
> AFAICT there was no objection in principle to such classes. I sense that the objection to going that route was due to an increase in scope and as such it would overrun it's budget.
>
>
>> I
>> still think it would be a great addition to the JDK (as every project
>> has something similar). This issue could be the start, although it
>> would need a few more methods, guided by the examples above.
>>
> Just a few *more* bike sheds to paint :-) I am concerned i will never finish this nor other un/related tasks.
>
> For now I am ok with Objects being that "argument checker class? simply because it already has a gravitational pull due to the mass of the existing check methods [*].
>
> Paul.
>
> [*] I believe it is a backwards compatible to change Objects to extends from Preconditions and move the existing static check methods to Preconditions. That seems like a sleazy trick though.

Yes, but the same could be achieved by just re-implementing those 3 
methods in Preconditions or delegating from Preconditions to Objects - 
without strange subtyping.

I think it's worth introducing Preconditions class. checkNotNull 
overloads are equally well suited for Objects as they are for 
Preconditions, so it's not wrong to have them in both, while checkIndex 
and friends don't really suit any of the existing classes. If I would 
have to search for them in among existing classes, Arrays would be the 
place to look first. List interface the 2nd. IndexOutOfBoundsException 
wouldn't come to my mind, as Exception(s) are usually not homes for 
logic, neither would Integer which is to abstract to mentally associate 
it with array or list index checks.

Regards, Peter




From pbenedict at apache.org  Tue Sep 29 19:29:09 2015
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 29 Sep 2015 14:29:09 -0500
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <560AE56E.1020808@gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
	<DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
	<5609D704.4050707@oracle.com>
	<B6E72165-91C2-451A-9929-F5C4CC6440CB@oracle.com>
	<9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>
	<CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com>
	<4B8AD5A1-376F-406B-8A50-44C199CB3471@oracle.com>
	<560AE56E.1020808@gmail.com>
Message-ID: <CABLGb9xENfTVDWE9bvwB2Tv6cmGgwS8j4pj=FhezuDstezNMOQ@mail.gmail.com>

It would be nice to introduce a Preconditions class (although I am not
opposed to continue maturing Objects). I was waiting for the right time for
this to be mentioned again (as it was mentioned in the past). Checking
indices aren't the only thing we could add; another thing would be a method
that throws ISE on failing a check. Lots of code in the wild does that
patten: if (!condition) throw new IllegalStateException();


Cheers,
Paul

On Tue, Sep 29, 2015 at 2:24 PM, Peter Levart <peter.levart at gmail.com>
wrote:

>
>
> On 09/29/2015 06:05 PM, Paul Sandoz wrote:
>
>> On 29 Sep 2015, at 12:57, Stephen Colebourne <scolebourne at joda.org>
>>> wrote:
>>>
>>> Just to note that an ideal location for this would be on a new class,
>>> one that has been discussed before, an "argument checker class".
>>>
>>> See Guava Preconditions:
>>>
>>> https://github.com/google/guava/blob/master/guava/src/com/google/common/base/Preconditions.java
>>>
>>> See Commons Lang Validate:
>>>
>>> https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/Validate.html
>>>
>>> See OpenGamma ArgChecker:
>>>
>>> http://opengamma.github.io/StrataDocs/apidocs/com/opengamma/strata/collect/ArgChecker.html
>>>
>>> https://github.com/OpenGamma/Strata/blob/master/modules/collect/src/main/java/com/opengamma/strata/collect/ArgChecker.java
>>>
>>> This was discussed when Objects.requiresNotNull was discussed IIRC.
>>>
>> FTR here is the discussion:
>>
>>
>> http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=6797535&sort=date
>> <
>> http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2&query=6797535&sort=date
>> >
>>
>> AFAICT there was no objection in principle to such classes. I sense that
>> the objection to going that route was due to an increase in scope and as
>> such it would overrun it's budget.
>>
>>
>> I
>>> still think it would be a great addition to the JDK (as every project
>>> has something similar). This issue could be the start, although it
>>> would need a few more methods, guided by the examples above.
>>>
>>> Just a few *more* bike sheds to paint :-) I am concerned i will never
>> finish this nor other un/related tasks.
>>
>> For now I am ok with Objects being that "argument checker class? simply
>> because it already has a gravitational pull due to the mass of the existing
>> check methods [*].
>>
>> Paul.
>>
>> [*] I believe it is a backwards compatible to change Objects to extends
>> from Preconditions and move the existing static check methods to
>> Preconditions. That seems like a sleazy trick though.
>>
>
> Yes, but the same could be achieved by just re-implementing those 3
> methods in Preconditions or delegating from Preconditions to Objects -
> without strange subtyping.
>
> I think it's worth introducing Preconditions class. checkNotNull overloads
> are equally well suited for Objects as they are for Preconditions, so it's
> not wrong to have them in both, while checkIndex and friends don't really
> suit any of the existing classes. If I would have to search for them in
> among existing classes, Arrays would be the place to look first. List
> interface the 2nd. IndexOutOfBoundsException wouldn't come to my mind, as
> Exception(s) are usually not homes for logic, neither would Integer which
> is to abstract to mentally associate it with array or list index checks.
>
> Regards, Peter
>
>
>


From paul.sandoz at oracle.com  Tue Sep 29 20:01:52 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 29 Sep 2015 22:01:52 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <560AE56E.1020808@gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
	<DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
	<5609D704.4050707@oracle.com>
	<B6E72165-91C2-451A-9929-F5C4CC6440CB@oracle.com>
	<9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>
	<CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com>
	<4B8AD5A1-376F-406B-8A50-44C199CB3471@oracle.com>
	<560AE56E.1020808@gmail.com>
Message-ID: <8385037B-FB27-4885-802C-00CCE2556FC2@oracle.com>


> On 29 Sep 2015, at 21:24, Peter Levart <peter.levart at gmail.com> wrote:
>> Just a few *more* bike sheds to paint :-) I am concerned i will never finish this nor other un/related tasks.
>> 
>> For now I am ok with Objects being that "argument checker class? simply because it already has a gravitational pull due to the mass of the existing check methods [*].
>> 
>> Paul.
>> 
>> [*] I believe it is a backwards compatible to change Objects to extends from Preconditions and move the existing static check methods to Preconditions. That seems like a sleazy trick though.
> 
> Yes, but the same could be achieved by just re-implementing those 3 methods in Preconditions or delegating from Preconditions to Objects - without strange subtyping.
> 

I know :-)


> I think it's worth introducing Preconditions class. checkNotNull overloads are equally well suited for Objects as they are for Preconditions, so it's not wrong to have them in both, while checkIndex and friends don't really suit any of the existing classes. If I would have to search for them in among existing classes, Arrays would be the place to look first. List interface the 2nd. IndexOutOfBoundsException wouldn't come to my mind, as Exception(s) are usually not homes for logic, neither would Integer which is to abstract to mentally associate it with array or list index checks.
> 

The concern i have is once Preconditions is let loose the scope expands with proposals for ?just one more method? (there is even the opportunity to bike shed over the names checkNotNull or requiresNotNull etc. etc.)  I don?t want to discuss such additional methods right now otherwise i will never make progress with the current set.

A way forward is to initially include Preconditions with *only* the check index methods, and in subsequent proposals selectively add more. At the moment i am still leaning towards Objects.

Paul.



From steve.drach at oracle.com  Tue Sep 29 20:46:39 2015
From: steve.drach at oracle.com (Steve Drach)
Date: Tue, 29 Sep 2015 13:46:39 -0700
Subject: RFR - 8132734: java.util.jar.* changes to support multi-release
	jar files
In-Reply-To: <560AD899.2020903@oracle.com>
References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com>
	<560AD899.2020903@oracle.com>
Message-ID: <991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com>

>> Please review the following webrev that adds support for multi-release jars as specified in JEP-238.
>> 
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 <https://bugs.openjdk.java.net/browse/JDK-8132734>
>> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 <https://bugs.openjdk.java.net/browse/JDK-8047305>
>> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ <http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/>
>> ?

> Steve - is the webrev complete, just wondering as I don't see any tests.

Yes it is complete.  Oracle SQE has done the tests, and have tested the changes.  They will integrate the tests after this webrev is integrated.  I?ve been told that this is the way it?s done for new features.

From ralph.goers at dslextreme.com  Tue Sep 29 21:17:25 2015
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Tue, 29 Sep 2015 14:17:25 -0700
Subject: JEP 264: Platform Logging API and Service
In-Reply-To: <560ADB25.801@oracle.com>
References: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
	<55FEB898.6050106@gmail.com> <560ADB25.801@oracle.com>
Message-ID: <9A09A754-31CE-4658-8F5B-8DD524729267@dslextreme.com>

FWIW, I considered using the ServiceLoader to bind the Log4j API to the implementation. However, Log4j also includes the API version and only looks for bindings that implement that version. We also include a ?priority? - the binding with the highest priority wins - at the moment. At some future time we might consider supporting multiple bindings.

It would have been nice if ServlceLoader could be extended by the user to do these sort of checks instead of not being able to use it at all.

Ralph

> On Sep 29, 2015, at 11:40 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> On 20/09/15 15:46, Peter Levart wrote:
>> 
>> 
>> On 09/18/2015 06:17 PM, mark.reinhold at oracle.com wrote:
>>> New JEP Candidate:http://openjdk.java.net/jeps/264
>>> 
>>> - Mark
>> 
>> Hi,
>> 
>> What is the purpose of exposing a factory for loggers in the generally
>> exported package (java.lang) and making it standard Java API as opposed
>> to keeping it internal API as it is now
>> (sun.util.logging.PlatformLogger)? Is this going to become an official
>> front-end for JDK-internal and applications use, available in the
>> platform itself?
> 
> Hi Peter,
> 
> sun.util.logging.PlatformLogger is a module private API in
> java.base, yet it is used by other modules in the JDK - and
> this requires qualified exports to the modules that use it.
> Having a public API that JDK modules could use would simplify
> the module graph in this respect.
> 
> In time, I'd hope to see sun.util.logging.PlatformLogger disappear
> in favor of the public API.
> 
>> Otherwise I think it's good to add support for interfacing other
>> backends (besides JDK14 Logging and stderr) to platform logger. If one
>> wants to interface some other backend to platform logger now, it's
>> actually doable, but only via the intermediate JDK14 Logging API, like this:
>> 
>> PlatformLogger -> j.u.l.Logger -> jul-to-slf4j -> slf4j-WHATEVER-BACKEND
>> 
>> Adding support to skip JDK14 Logging would simplify configuration and
>> make it more lightweight.
> 
> Yes - the goal of the LoggerFinder service API is to make it possible
> for applications - or frameworks - to provide their own implementation.
> 
> best regards,
> 
> -- daniel
> 
>> 
>> Regards, Peter
>> 
> 
> 




From martinrb at google.com  Tue Sep 29 21:23:41 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 29 Sep 2015 14:23:41 -0700
Subject: P.S.: RFR [9] 8133651: automated replacing of old-style tags in
	docs
In-Reply-To: <560A6628.5010807@oracle.com>
References: <740a3bdd-3a72-44ec-b51f-83c98cac07ca@default>
	<560A6628.5010807@oracle.com>
Message-ID: <CA+kOe0_RoiEvvquZ-5aJ401b1oePuDG+7vd0ufzgctpFhUfaLA@mail.gmail.com>

Hi Alexander,

your change looks good.  It's OK to have manual corrections for automated
mega-changes like this, as long as they all revert changes.

Random comments:

Should you publish your specdiff?  I guess not - it would be empty!

            while((s = br.readLine()) != null) {

by matching only one line at a time, you lose the ability to make
replacements that span lines.  Perlers like to "slurp" in the entire file
as a single string.

        s = s.replace( "<CODE>", tag1);
        s = s.replace( "<Code>", tag1);
        s = s.replace("</CODE>", tag2);
        s = s.replace("</Code>", tag2);

Why not use case-insensitive regex?

Here's an emacs-lisp one-liner I've been known to use:

(defun tt-code ()
  (interactive)
  (query-replace-regexp "<\\(tt\\|code\\)>\\([^&<>\\\\]+\\)</\\1>" "{@code
\\2}"))

With more work, one can automate transformation of embedded things like &lt;

But of course, it's not even possible to transform ALL uses of <code> to
{@code, if there was imaginative use of nested html tags.


On Tue, Sep 29, 2015 at 3:21 AM, Alexander Stepanov <
alexander.v.stepanov at oracle.com> wrote:

> Updated: a few manual corrections were made (as @linkplain tags displays
> nested {@code } literally):
> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
> -checked with specdiff (which of course does not cover documentation for
> internal packages), no unexpected diffs detected.
>
> Regards,
> Alexander
>
>
> On 9/27/2015 4:52 PM, Alexander Stepanov wrote:
>
>> Hello Martin,
>>
>> Here is some simple app. to replace <code></code> tags with a new-style
>> {@code } one (which is definitely not so elegant as the Perl one-liners):
>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/SimpleTagEditor.java
>>
>> Corresponding patch for jdk and replacement log (~62k of the tag changes):
>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/jdk.patch
>> http://cr.openjdk.java.net/~avstepan/tmp/codeTags/replace.log
>> (sorry, I have to check the correctness of the patch with specdiff yet,
>> so this is rather demo at the moment).
>>
>> Don't know if these changes (cosmetic by nature) are desired for now or
>> not. Moreover, probably some part of them should go to another repos (e.g.,
>> awt, swing -> "client" instead of "dev").
>>
>> Regards,
>> Alexander
>>
>>
>>
>> ----- ???????? ????????? -----
>> ??: alexander.v.stepanov at oracle.com
>> ????: martinrb at google.com
>> ?????: core-libs-dev at openjdk.java.net
>> ????????????: ???????, 24 ???????? 2015 ? 16:06:56 GMT +03:00 ??????,
>> ?????-?????????, ?????????
>> ????: Re: RFR [9] 8133651: replace some <tt> tags (obsolete in html5) in
>> core-libs docs
>>
>> Hello Martin,
>>
>> Thank you for review and for the notes!
>>
>>   > I'm biased of course, but I like the approach I took with
>> blessed-modifier-order:
>>   > - make the change completely automated
>>   > - leave "human editing" for a separate change
>>   > - publish the code used to make the automated change (in my case,
>> typically a perl one-liner)
>>
>> Automated replacement has an obvious advantage: it is fast and massive.
>> But there are some disadvantages at the same time (just IMHO).
>>
>> Using script it is quite easy to miss some not very trivial cases, e.g.:
>> - remove unnecessary linebreaks, like
>>    * <tt>someCode
>>    * </tt>
>> (which would be better to replace with single-line {@code someCode};
>> - joining of successive terms, like "<tt>ONE</tt>, <tt>TWO</tt>,
>> <tt>THREE</tt>" -> "{@code ONE, TWO, THREE}";
>> - errors like extra or missing "&lt;" or "&gt;": * <tt>Collection
>> &lt;T></tt>", - there were a lot of them;
>> - some cases when <tt></tt> should be replaced with <code></code>, not
>> {@code } (e.g. because of unicode characters inside of code etc.);
>> - extra tags inside of <tt> or <code> which should be moved outside of
>> {@code }, like <tt><i>someCode</i></tt> or <tt><b>someCode</b></tt>;
>> - simple removing of needless tags, like "<tt>{@link ...}</tt>" ->
>> "{@link ...}";
>> - replace HTML codes with symbols ('<', '>', '@', ...)
>> - etc.
>> - plus some other formatting changes and fixes for misprints which would
>> be omitted during the automated replacement (and wouldn't be done in
>> future manually because there is no motivation for repeated processing).
>>
>> So sometimes it may be difficult to say where is the border between
>> "trivial" and "human-editing" cases (and the portion of "non-trivial
>> cases" is definitely not minor); moreover, even the automated
>> replacement requires the subsequent careful review before publishing of
>> webrev (as well as by reviewers who probably wouldn't be happy to review
>> hundreds of files at the same time) and iterative checks/corrections.
>> specdiff is very useful for this task but also cannot fully cover the
>> diffs (as some changes are situated in the internal com/... sun/...
>> packages).
>>
>> Moreover, I'm sure that some reviewers would be annoyed with the fact
>> that some (quite simple) changes were postponed because they are "not
>> too trivial to be fixed just now" (because they will suspect they would
>> be postponed forever). So the patch creator would (probably) receive
>> some advices during the review like "please fix also fix this and that"
>> (which is normal, of course).
>>
>> So my preference was to make the changes package by package (in some
>> reasonable amount of files) not postponing part of the changes for the
>> future (sorry for these boring repeating review requests). Please note
>> that all the above mentioned is *rather explanation of my motivation
>> than objection* :) (and of course I used some text editor replace
>> automation which is surely not so advanced as Perl).
>>
>>   > It's probably correct, but I would have left it out of this change
>> Yes, I see. Reverted (please update the web page):
>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/index.html
>>
>> Thanks,
>> Alexander
>>
>> P.S. The <tt> replacement job is mostly (I guess, ~80%) complete. But
>> probably this approach should be used if some similar replacement task
>> for, e.g., <code></code> tags would be planned in future (there are
>> thousands of them).
>>
>>
>> On 9/24/2015 6:10 AM, Martin Buchholz wrote:
>>
>>>
>>> On Sat, Sep 19, 2015 at 6:58 AM, Alexander Stepanov
>>> <alexander.v.stepanov at oracle.com
>>> <mailto:alexander.v.stepanov at oracle.com>> wrote:
>>>
>>>      Hello,
>>>
>>>      Could you please review the following fix
>>>      http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/
>>>      <http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/>
>>>      http://cr.openjdk.java.net/~avstepan/8133651/jaxws.00/index.html
>>>      <http://cr.openjdk.java.net/%7Eavstepan/8133651/jaxws.00/index.html
>>> >
>>>      for
>>>      https://bugs.openjdk.java.net/browse/JDK-8133651
>>>
>>>      Just another portion of deprecated <tt> (and <xmp>) tags replaced
>>>      with {@code }. Some misprints were also fixed.
>>>
>>>
>>> I'm biased of course, but I like the approach I took with
>>> blessed-modifier-order:
>>> - make the change completely automated
>>> - leave "human editing" for a separate change
>>> - publish the code used to make the automated change (in my case,
>>> typically a perl one-liner)
>>>
>>>
>>>      The following (expected) changes were detected by specdiff:
>>>      - removed needless dashes in java.util.Locale,
>>>      - removed needless curly brace in xml.bind.annotation.XmlElementRef
>>>
>>>
>>> I would do a separate automated "removed needless dashes" changeset.
>>>
>>>
>>>      Please let me know if the following changes are desirable or not:
>>>
>>> http://cr.openjdk.java.net/~avstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html
>>>      <
>>> http://cr.openjdk.java.net/%7Eavstepan/8133651/jdk.00/src/jdk.jconsole/share/classes/sun/tools/jconsole/Formatter.java.udiff.html
>>> >
>>>
>>>
>>> This is an actual change to the behavior of this code - the
>>> maintainers of jconsole need to approve it.  It's probably correct,
>>> but I would have left it out of this change. If you remove it, then I
>>> approve this change.
>>>
>>
>


From scolebourne at joda.org  Tue Sep 29 21:28:07 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 29 Sep 2015 22:28:07 +0100
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <8385037B-FB27-4885-802C-00CCE2556FC2@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
	<DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
	<5609D704.4050707@oracle.com>
	<B6E72165-91C2-451A-9929-F5C4CC6440CB@oracle.com>
	<9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>
	<CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com>
	<4B8AD5A1-376F-406B-8A50-44C199CB3471@oracle.com>
	<560AE56E.1020808@gmail.com>
	<8385037B-FB27-4885-802C-00CCE2556FC2@oracle.com>
Message-ID: <CACzrW9AspZKzqv-b4EmoSH+mWbfjRuB6QqHZE0jUOBt=u-4c2Q@mail.gmail.com>

On 29 September 2015 at 21:01, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> The concern i have is once Preconditions is let loose the scope expands with proposals for ?just one more method? (there is even the opportunity to bike shed over the names checkNotNull or requiresNotNull etc. etc.)  I don?t want to discuss such additional methods right now otherwise i will never make progress with the current set.
>
> A way forward is to initially include Preconditions with *only* the check index methods, and in subsequent proposals selectively add more. At the moment i am still leaning towards Objects.

As you say, there is lots to discuss:
- the class name
- any IllegalStateException methods? Or two classes, one for args and
one for state?
- design for static import or not
- message formatting
- complete messages, or ones where only the argument name is specified
- nonNull() vs notNull()
- IllegalArgException vs NPE for notNull

The first three points are key and set the tone of the class, As such,
it is hard to just create it. (For example Guava Preconditions is
stylistically different to Commons Validate or OpenGamma ArgChecker)

If you need to move on, then add the methods to Objects, and see if
separately agreement can be got on a new class, potentially moving the
methods before 9 is released.

Stephen


From joe.darcy at oracle.com  Tue Sep 29 22:11:17 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 29 Sep 2015 15:11:17 -0700
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <CACzrW9AspZKzqv-b4EmoSH+mWbfjRuB6QqHZE0jUOBt=u-4c2Q@mail.gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
	<DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
	<5609D704.4050707@oracle.com>
	<B6E72165-91C2-451A-9929-F5C4CC6440CB@oracle.com>
	<9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>
	<CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com>
	<4B8AD5A1-376F-406B-8A50-44C199CB3471@oracle.com>
	<560AE56E.1020808@gmail.com>
	<8385037B-FB27-4885-802C-00CCE2556FC2@oracle.com>
	<CACzrW9AspZKzqv-b4EmoSH+mWbfjRuB6QqHZE0jUOBt=u-4c2Q@mail.gmail.com>
Message-ID: <560B0C85.1020700@oracle.com>

On 9/29/2015 2:28 PM, Stephen Colebourne wrote:
> On 29 September 2015 at 21:01, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> The concern i have is once Preconditions is let loose the scope expands with proposals for ?just one more method? (there is even the opportunity to bike shed over the names checkNotNull or requiresNotNull etc. etc.)  I don?t want to discuss such additional methods right now otherwise i will never make progress with the current set.
>>
>> A way forward is to initially include Preconditions with *only* the check index methods, and in subsequent proposals selectively add more. At the moment i am still leaning towards Objects.
> As you say, there is lots to discuss:
> - the class name
> - any IllegalStateException methods? Or two classes, one for args and
> one for state?
> - design for static import or not
> - message formatting
> - complete messages, or ones where only the argument name is specified
> - nonNull() vs notNull()
> - IllegalArgException vs NPE for notNull
>
> The first three points are key and set the tone of the class, As such,
> it is hard to just create it. (For example Guava Preconditions is
> stylistically different to Commons Validate or OpenGamma ArgChecker)
>
> If you need to move on, then add the methods to Objects, and see if
> separately agreement can be got on a new class, potentially moving the
> methods before 9 is released.

Yes, my preference would be to push the methods first to 
java.util.Objects and then move them to a checker / validator class if 
such a utility class is added to the JDK later in JDK 9.

-Joe



From mandy.chung at oracle.com  Tue Sep 29 22:14:37 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 29 Sep 2015 15:14:37 -0700
Subject: RFR - 8132734: java.util.jar.* changes to support multi-release
	jar files
In-Reply-To: <991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com>
References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com>
	<560AD899.2020903@oracle.com>
	<991FA3D3-851A-4912-8C71-80FD13C74496@oracle.com>
Message-ID: <79E2D51F-B1E5-4D75-B599-C7A7F47918F4@oracle.com>

On Sep 29, 2015, at 1:46 PM, Steve Drach <steve.drach at oracle.com> wrote:
> 
>>> Please review the following webrev that adds support for multi-release jars as specified in JEP-238.
>>> 
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 <https://bugs.openjdk.java.net/browse/JDK-8132734>
>>> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 <https://bugs.openjdk.java.net/browse/JDK-8047305>
>>> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ <http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/>
>>> ?
> 
>> Steve - is the webrev complete, just wondering as I don't see any tests.
> 
> Yes it is complete.  Oracle SQE has done the tests, and have tested the changes.  They will integrate the tests after this webrev is integrated.  I?ve been told that this is the way it?s done for new features.

For core-libs, unit tests are required to be integrated together with the feature.  You should include the unit tests in this review.

Mandy

From martinrb at google.com  Tue Sep 29 22:59:19 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 29 Sep 2015 15:59:19 -0700
Subject: RFR: jsr166 openjdk9 integration
In-Reply-To: <8B922221-91F0-4FAC-8326-6FBE11724442@oracle.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<D9982CCF-0F8F-4E85-8DCD-4463DBDA933A@oracle.com>
	<CA+kOe0_P+PzTvJrOtxVxMF7RnzWkOKLp089NTVghGWVVX+DbMQ@mail.gmail.com>
	<8B922221-91F0-4FAC-8326-6FBE11724442@oracle.com>
Message-ID: <CA+kOe0-56O56z2DpVm0zQfuQiCtu0KsRxCxmsQfNjxaLwvBuUQ@mail.gmail.com>

I added MOAT.java to the integration.

We noticed very rare failures testing WeakHashMap if the GC intervened at
just the wrong time.
(There's also changes to make the test portable to jdk8, since we still
test against that)

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/miscellaneous/test/java/util/Collection/MOAT.java.udiff.html


From brian.burkhalter at oracle.com  Wed Sep 30 00:49:34 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 29 Sep 2015 17:49:34 -0700
Subject: [9] RFR of 8023217: Additional floorDiv/floorMod/multiplyExact
	methods for java.lang.Math
In-Reply-To: <108C6774-3965-4340-A448-033B3651E263@oracle.com>
References: <604C9A0D-D55D-4962-A007-D188E9077063@oracle.com>
	<5609F4CA.2010605@oracle.com>
	<CACzrW9DLvBk1B7dhwLCmJFZvMLGkSE0NQfsQfkkcFLZaWPmmpA@mail.gmail.com>
	<836DC71E-B3E6-45DE-BDA4-39617AC4CAC4@oracle.com>
	<CACzrW9AFj4B4-pbVjajJFh55C2Y1ZaV9+gdbTsyS=d90FvX9dQ@mail.gmail.com>
	<108C6774-3965-4340-A448-033B3651E263@oracle.com>
Message-ID: <C6AA2B7F-6C23-451E-8D7C-13BD8EA98110@oracle.com>

I revised floorMod(long x, int y) not to check explicitly check for integer overflow as it does not look as if this is even possible. I also updated the appropriate tests for these versions of the three methods at issue.

In testing I still found discrepancies between the existing implementations and the ones suggested earlier in this thread. Therefore those implementations have not been used. If it is desired to move to different implementations at a later date a separate enhancement issue may be filed.

The updated webrev is here:

http://cr.openjdk.java.net/~bpb/8023217/webrev.01/

Thanks,

Brian

On Sep 29, 2015, at 8:16 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> On Sep 29, 2015, at 8:05 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
>>> I tested the code which was in the original issue description and found some
>>> discrepancies. I?ll need to revisit this to see what happened.
>> 
>> Yes, the code in the issue for floorDiv() fails when the divisor is
>> negative. The one in my email today works though.
> 
> Excellent! I?ll double check it as part of the ?fit and finish."



From martinrb at google.com  Wed Sep 30 02:16:19 2015
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 29 Sep 2015 19:16:19 -0700
Subject: specdiff <was> Re: RFR: jsr166 openjdk9 integration
In-Reply-To: <6C860453-A0EB-46FB-AB75-CB57FA4E82FE@oracle.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>
	<CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>
	<F57BEACF-282F-41C6-B5CA-5BA9A09BF2C4@oracle.com>
	<6C860453-A0EB-46FB-AB75-CB57FA4E82FE@oracle.com>
Message-ID: <CA+kOe08sjbwSVvjRg-=q-xnSdi8EcdBo3pqihoR6uFbdS5afdQ@mail.gmail.com>

Thanks for the specdiff - much easier to review for javadoc changes!.  I
went through it.  There were a small number of minor mistakes, which are
now corrected.  Now would be a good time to regenerate the specdiff.

On Thu, Sep 24, 2015 at 1:35 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8132960-166-updates/specdiff/overview-summary.html
>
> Paul.
>


From mandy.chung at oracle.com  Wed Sep 30 02:31:43 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 29 Sep 2015 19:31:43 -0700
Subject: RFR: 8137289: java/util/logging/DrainFindDeadlockTest.java hangs
In-Reply-To: <560AD55D.8080009@oracle.com>
References: <560AD55D.8080009@oracle.com>
Message-ID: <CE592624-7AE5-495B-933B-6CDEA790668D@oracle.com>


> On Sep 29, 2015, at 11:15 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> Please find below a fix for:
> 8137289: java/util/logging/DrainFindDeadlockTest.java hangs
> https://bugs.openjdk.java.net/browse/JDK-8137289
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8137289/webrev.00/
> 
> There are in fact two failures reports under similar configuration:
> (slow machines?) - fastdebug build - -Xcomp -server -Xcomp
> 
> The first thread dump in the bug shows that the test is killed
> while the test main class is still initializing.
> The test hasn't even started yet.
> 
> The second thread dump shows the main class waiting to join
> the DeadlockChecker.
> The other threads created by the test are nowhere to be seen.
> 
> In view of theses two stacks, my analysis is that this is most
> probably an issue caused by the timeout=10 parameter on the @run
> line.
> 
> I'm proposing to remove this timeout and default to jtreg's
> timeout. I have also added some additionally prints to show
> when threads created by the test terminate?

This looks fine to me.

Mandy



From stuart.marks at oracle.com  Wed Sep 30 02:35:46 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 29 Sep 2015 19:35:46 -0700
Subject: JEP 269: Convenience Factory Methods for Collections
In-Reply-To: <CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com>
References: <20150924000217.D476B7A327@eggemoggin.niobe.net>
	<CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com>
Message-ID: <560B4A82.50506@oracle.com>

Hi all, I've been on vacation for a few days. Did anything happen while I was 
away? :-)

I see this JEP was posted as a Candidate, and Kevin and Remi had some comments. 
I'll reply to Kevin's comments here and to Remi's separately.

Kevin,

I'm glad you don't think the proposal is bad. :-)

I definitely see the value in having immutability in the type system. If your 
application is using Guava's immutable types, then it would certainly be a step 
backwards to stop using them in favor of the factories proposed here.

However, I don't see this JEP as being in opposition to immutable collection 
types. This JEP isn't specifically about immutable collections; it's about 
convenience APIs (some of which create collection instances that happen to be 
immutable). Immutable collection types could be added later without too much 
difficulty. I'd be interested in seeing and even possibly working on such a 
proposal in the future.

> Note that without permitting nulls, Map.of(key, Optional.of(value)) will become
> reasonably common, and that fact you can't serialize that will become even more
> strange than it already is.

Interesting. Given that Guava's Maps disallow null values, do you see a lot of 
use of Optional for Map values in Guava? For the JDK, do you think it would be 
preferable to allow null values in Maps, or to make Optional serializable? (Note 
to readers: Guava's Optional is serializable but the JDK's is not.) Or is this 
one of those problems where all the solutions suck?

> I think the example of "double-brace initialization" should be even more clearly
> labeled as pure evil. :-) You could also mention all the horrible consequences
> if anyone ever serializes such a collection.

I'm not sure if one is allowed to say "evil" in a JEP, but I agree that the 
"double brace" "idiom" is definitely evil! I did mention the potential for 
memory leaks in the JEP, but you have a good point about serialization, not only 
of the enclosing instance, but also of all captured references.

s'marks



From stuart.marks at oracle.com  Wed Sep 30 03:03:06 2015
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 29 Sep 2015 20:03:06 -0700
Subject: JEP 269: Convenience Factory Methods for Collections
In-Reply-To: <139037209.2264037.1443166359717.JavaMail.zimbra@u-pem.fr>
References: <20150924000217.D476B7A327@eggemoggin.niobe.net>
	<139037209.2264037.1443166359717.JavaMail.zimbra@u-pem.fr>
Message-ID: <560B50EA.1090408@oracle.com>

Hi R?mi,

Thanks for looking at the proposal.

We did consider this style of builder as one of the alternatives to what's in 
the JEP. The concern I have about builders such as this is that the number of 
entries isn't available at the time the map is to be built.

For HashMap, this means that a default size has to be chosen. It can either be 
too big, meaning space is wasted, or too small, which means that it has to be 
resized while being built.

For an unmodifiable map, in practical terms it means that the keys and values 
have to be accumulated in a temporary structure before the result map can be 
built. The reason is that we might want to choose different map implementations 
based on the size of the map.

(An additional, though unrelated issue is that in this example, the builder 
holds a reference to the map being constructed. If malicious code were to store 
this builder somewhere, it could be used to modify the result map at unforeseen 
times, leading to misbehavior. Careful coding could avoid such problems, 
possibly at the cost of making defensive copies.)

None of these problems are insurmountable, but it doesn't seem clear to me that 
this or similar builder approaches necessarily have any advantage over the 
varargs-of-entries approach outlined in the JEP. The varargs-of-entries approach 
of course has its own overhead. There is the possibility of the entry objects 
being replaced by value types in a future JDK (at least, Brian thinks this might 
be possible!) so that's what tipped us toward that approach.

s'marks

On 9/25/15 12:32 AM, Remi Forax wrote:
> Hi Mark, hi Stuart, hi all,
>
> for Map, i think a version with a builder will be cool too,
> something like:
>
>    public interface EntryBuilder<K, V> {
>      public EntryBuilder<K,V> entry(K key, V value);
>    }
>
> and by example for HashMap:
>
>    public static <K, V> HashMap<K, V> fromBuilder(Consumer<? super EntryBuilder<K,V>> consumer) {
>      HashMap<K,V> map = new HashMap<>();
>      consumer.accept(new EntryBuilder<>() {
>        public EntryBuilder<K,V> entry(K key, V value) {
>          map.put(key, value);
>          return this;
>        }
>      });
>      return map;
>    }
>
>    ...
>    HashMap<String, Integer> map = HashMap.fromBuilder(b -> b
>      .entry("foo", 1)
>      .entry("bar", 2));
>
> The builder pattern let us to avoid to create intermediary entry objects.
>
> regards,
> R?mi
>
> ----- Mail original -----
>> De: "mark reinhold" <mark.reinhold at oracle.com>
>> ?: "stuart marks" <stuart.marks at oracle.com>
>> Cc: core-libs-dev at openjdk.java.net
>> Envoy?: Jeudi 24 Septembre 2015 02:02:17
>> Objet: JEP 269: Convenience Factory Methods for Collections
>>
>> New JEP Candidate: http://openjdk.java.net/jeps/269
>>
>> - Mark
>>


From weijun.wang at oracle.com  Wed Sep 30 03:12:50 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 30 Sep 2015 11:12:50 +0800
Subject: RFR - 8132734: java.util.jar.* changes to support multi-release
	jar files
In-Reply-To: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com>
References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com>
Message-ID: <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com>

Can you describe if there is any effect on signed jars? Including:

1. Will jarsigner be able to sign such a jar? Are all items inside signed? If you sign a jar using jarsigner from different versions of JDK, will there be any difference?

2. Will jarsigner be able to verify such a jar? Will it only verify entries for the current version or all? Will jarsigner from an old JDK verify the new jar?

3. As I know, JarFile has 2 ways to verify a jar file, one using public APIs. One through SharedSecrets.setJavaUtilJarAccess() which can call more methods. Have you confirmed both work?

Yes, I'd also like some tests on these.

Thanks
Max

> On 2015?9?30?, at ??2:13, Steve Drach <steve.drach at oracle.com> wrote:
> 
> Hi,
> 
> Please review the following webrev that adds support for multi-release jars as specified in JEP-238.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8132734 <https://bugs.openjdk.java.net/browse/JDK-8132734>
> JEP 238: https://bugs.openjdk.java.net/browse/JDK-8047305 <https://bugs.openjdk.java.net/browse/JDK-8047305>
> Webrev: http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/ <http://cr.openjdk.java.net/~psandoz/multiversion-jar/jar-webrev/>
> 
> A multi-release jar file is a jar file that contains a manifest with a main attribute named "Multi-Release", and also contains a directory "META-INF/versions" with subdirectories that contain versioned entries segregated by the major version of Java platform releases. A versioned entry, with a version n, in the "META-INF/versions/{n}" directory overrides the unversioned root entry as well as any entry with a version number i  where i < n.
> 
> The changes in this webrev implement an aliasing mechanism in JarEntry so that when a JarFile client retrieves a JarEntry, the data from the entry pointed to by the alias is returned.  There are methods to configure whether or not aliasing is enabled, and if it is, which version of an entry the alias points to.
> 
> When a JarFile is used by a class loader to load class resources, the default version retrieved is the runtime version of the Java platform (i.e. a version 9 entry is returned when the platform is JDK 9).  This mechanism can be configured by System properties.
> 
> Thanks,
> Steve



From scolebourne at joda.org  Wed Sep 30 06:32:33 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 30 Sep 2015 07:32:33 +0100
Subject: JEP 269: Convenience Factory Methods for Collections
In-Reply-To: <560B4A82.50506@oracle.com>
References: <20150924000217.D476B7A327@eggemoggin.niobe.net>
	<CAGKkBks7CKsJngvagV15C47E6zncdS-ag2m2OOKGoTtm-+YFFw@mail.gmail.com>
	<560B4A82.50506@oracle.com>
Message-ID: <CACzrW9BeVsgk7Oj6hW_oma3y6DFF+VvaTyRucPGraV=SSALHCg@mail.gmail.com>

In my view, the proposal is pretty good. I too use Guava's immutable
classes as types, because of the extra value obtained. But that does
not mean these methods should not be in the JDK. (Not every project
uses Guava).

I'd argue for two changes to the JEP.

Map.fromEntries() -> Map.ofEntries()
In JSR-310, we reserve "from" for factories with a high chance of
failure due to performing some kind of conversion, and use "of" for
factories that only fail if doing something stupid. It also means that
IDE users will easily see both choices when auto-completing, thus
easily learn how to go beyond the hard coded 6 entry factory.

Map.Entry.entry() -> Map.entry()
This would allow static imports to be focussed just on Map, and not
needing Map.Entry as well (helpful in Eclipse at least). If the method
were on Map.Entry, I'd expect it to be of(), whereas on Map itself,
entry() is a good name. There might be a case for having both
Map.entry() and Map.Entry.of().

Stephen



On 30 September 2015 at 03:35, Stuart Marks <stuart.marks at oracle.com> wrote:
> Hi all, I've been on vacation for a few days. Did anything happen while I
> was away? :-)
>
> I see this JEP was posted as a Candidate, and Kevin and Remi had some
> comments. I'll reply to Kevin's comments here and to Remi's separately.
>
> Kevin,
>
> I'm glad you don't think the proposal is bad. :-)
>
> I definitely see the value in having immutability in the type system. If
> your application is using Guava's immutable types, then it would certainly
> be a step backwards to stop using them in favor of the factories proposed
> here.
>
> However, I don't see this JEP as being in opposition to immutable collection
> types. This JEP isn't specifically about immutable collections; it's about
> convenience APIs (some of which create collection instances that happen to
> be immutable). Immutable collection types could be added later without too
> much difficulty. I'd be interested in seeing and even possibly working on
> such a proposal in the future.
>
>> Note that without permitting nulls, Map.of(key, Optional.of(value)) will
>> become
>> reasonably common, and that fact you can't serialize that will become even
>> more
>> strange than it already is.
>
>
> Interesting. Given that Guava's Maps disallow null values, do you see a lot
> of use of Optional for Map values in Guava? For the JDK, do you think it
> would be preferable to allow null values in Maps, or to make Optional
> serializable? (Note to readers: Guava's Optional is serializable but the
> JDK's is not.) Or is this one of those problems where all the solutions
> suck?
>
>> I think the example of "double-brace initialization" should be even more
>> clearly
>> labeled as pure evil. :-) You could also mention all the horrible
>> consequences
>> if anyone ever serializes such a collection.
>
>
> I'm not sure if one is allowed to say "evil" in a JEP, but I agree that the
> "double brace" "idiom" is definitely evil! I did mention the potential for
> memory leaks in the JEP, but you have a good point about serialization, not
> only of the enclosing instance, but also of all captured references.
>
> s'marks
>


From peter.levart at gmail.com  Wed Sep 30 07:34:11 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 30 Sep 2015 09:34:11 +0200
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <8385037B-FB27-4885-802C-00CCE2556FC2@oracle.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
	<DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
	<5609D704.4050707@oracle.com>
	<B6E72165-91C2-451A-9929-F5C4CC6440CB@oracle.com>
	<9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>
	<CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com>
	<4B8AD5A1-376F-406B-8A50-44C199CB3471@oracle.com>
	<560AE56E.1020808@gmail.com>
	<8385037B-FB27-4885-802C-00CCE2556FC2@oracle.com>
Message-ID: <560B9073.3060507@gmail.com>



On 09/29/2015 10:01 PM, Paul Sandoz wrote:
>> >I think it's worth introducing Preconditions class. checkNotNull overloads are equally well suited for Objects as they are for Preconditions, so it's not wrong to have them in both, while checkIndex and friends don't really suit any of the existing classes. If I would have to search for them in among existing classes, Arrays would be the place to look first. List interface the 2nd. IndexOutOfBoundsException wouldn't come to my mind, as Exception(s) are usually not homes for logic, neither would Integer which is to abstract to mentally associate it with array or list index checks.
>> >
> The concern i have is once Preconditions is let loose the scope expands with proposals for ?just one more method? (there is even the opportunity to bike shed over the names checkNotNull or requiresNotNull etc. etc.)  I don?t want to discuss such additional methods right now otherwise i will never make progress with the current set.
>
> A way forward is to initially include Preconditions with*only*  the check index methods, and in subsequent proposals selectively add more. At the moment i am still leaning towards Objects.
>
> Paul.
>

I promise I won't discuss any other methods - just checkIndex and 
friends (small steps...)
But having them in Objects would be very strange. Indexes are not 
objects - they are values.


Regards, Peter


From peter.levart at gmail.com  Wed Sep 30 07:46:56 2015
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 30 Sep 2015 09:46:56 +0200
Subject: JEP 264: Platform Logging API and Service
In-Reply-To: <9A09A754-31CE-4658-8F5B-8DD524729267@dslextreme.com>
References: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
	<55FEB898.6050106@gmail.com> <560ADB25.801@oracle.com>
	<9A09A754-31CE-4658-8F5B-8DD524729267@dslextreme.com>
Message-ID: <560B9370.2080307@gmail.com>



On 09/29/2015 11:17 PM, Ralph Goers wrote:
> FWIW, I considered using the ServiceLoader to bind the Log4j API to the implementation. However, Log4j also includes the API version and only looks for bindings that implement that version. We also include a ?priority? - the binding with the highest priority wins - at the moment. At some future time we might consider supporting multiple bindings.
>
> It would have been nice if ServlceLoader could be extended by the user to do these sort of checks instead of not being able to use it at all.
>
> Ralph

Hi Ralph,

ServiceLoader can be used to load all services that implement a 
particular type (it's an Iterable). So you can decide which one(s) to 
use in your own logic. You just have to design the service type in a way 
where it's implementations expose some attributes that are relevant for 
selection and initialize the underlying service lazily, after selection 
is done. This would usually mean that the service interface/abstract 
class implements a factory for the real service and exposes some 
properties such as version, priority, etc...

Would that work for Log4j?

Regards, Peter

>
>> On Sep 29, 2015, at 11:40 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>
>> On 20/09/15 15:46, Peter Levart wrote:
>>>
>>> On 09/18/2015 06:17 PM, mark.reinhold at oracle.com wrote:
>>>> New JEP Candidate:http://openjdk.java.net/jeps/264
>>>>
>>>> - Mark
>>> Hi,
>>>
>>> What is the purpose of exposing a factory for loggers in the generally
>>> exported package (java.lang) and making it standard Java API as opposed
>>> to keeping it internal API as it is now
>>> (sun.util.logging.PlatformLogger)? Is this going to become an official
>>> front-end for JDK-internal and applications use, available in the
>>> platform itself?
>> Hi Peter,
>>
>> sun.util.logging.PlatformLogger is a module private API in
>> java.base, yet it is used by other modules in the JDK - and
>> this requires qualified exports to the modules that use it.
>> Having a public API that JDK modules could use would simplify
>> the module graph in this respect.
>>
>> In time, I'd hope to see sun.util.logging.PlatformLogger disappear
>> in favor of the public API.
>>
>>> Otherwise I think it's good to add support for interfacing other
>>> backends (besides JDK14 Logging and stderr) to platform logger. If one
>>> wants to interface some other backend to platform logger now, it's
>>> actually doable, but only via the intermediate JDK14 Logging API, like this:
>>>
>>> PlatformLogger -> j.u.l.Logger -> jul-to-slf4j -> slf4j-WHATEVER-BACKEND
>>>
>>> Adding support to skip JDK14 Logging would simplify configuration and
>>> make it more lightweight.
>> Yes - the goal of the LoggerFinder service API is to make it possible
>> for applications - or frameworks - to provide their own implementation.
>>
>> best regards,
>>
>> -- daniel
>>
>>> Regards, Peter
>>>
>>
>



From paul.sandoz at oracle.com  Wed Sep 30 10:50:42 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 30 Sep 2015 12:50:42 +0200
Subject: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure
	initialization
In-Reply-To: <560565E6.7090000@gmail.com>
References: <5604EDAE.7080501@gmail.com>
	<79FDF077-226C-4D7A-A452-7D6447C2FB3F@oracle.com>
	<D3AE591C-FF34-4337-8932-6990322F32C5@oracle.com>
	<560565E6.7090000@gmail.com>
Message-ID: <C7FEA5E2-33AC-4D55-B567-321CB7301008@oracle.com>


> On 25 Sep 2015, at 17:19, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi Paul,
> 
> Thanks for looking into this.
> 

Apologies for the late reply.


> On 09/25/2015 04:07 PM, Paul Sandoz wrote:
>> Hi,
>> 
>> This looks like a partial dup of https://bugs.openjdk.java.net/browse/JDK-8076596
> 
> Ah, sorry, I wasn't aware this has already been registered in JIRA. I have linked the two issues together as DUPs.
> 

Thanks.


>> 
>> The changes look ok, but I am concerned post initialization there may be code paths taken that require the system class loader to be used but instead the boot stream class loader is used instead. Is that a legitimate concern?
> 
> It is legitimate, but I have inspected usages and:
> 
> - In java.lang.invoke.BoundMethodHandle.Factory#makeCbmhCtor, null is passed explicitly and this method is used only from java.lang.invoke.BoundMethodHandle.Factory#makeCtors which is used from java.lang.invoke.BoundMethodHandle.SpeciesData#initForBootstrap and java.lang.invoke.BoundMethodHandle.SpeciesData#SpeciesData(java.lang.String, java.lang.Class<? extends java.lang.invoke.BoundMethodHandle>). These usages only deal with erased MH types (Object, long, int, double, float).
> 
> - In java.lang.invoke.MemberName#getMethodType, the result of MemberName.getClassLoader() is passed to the method. This is the class loader of the member's declaring class. Any types referenced from the member declaration should be resolvable from this class loader. A member declared by a bootstrap class (MemberName.getClassLoader() returns null) can only reference types resolvable from bootstrap loader.
> 
> - In java.lang.invoke.MemberName#getFieldType, the result of MemberName.getClassLoader() is passed to the method. Similar applies as above.
> 
> - In java.lang.invoke.MethodHandleNatives#fixMethodType(Class<?> callerClass, Object type), the callerClass.getClassLoader() is passed to the method. This is invoked from:
> java.lang.invoke.MethodHandleNatives#linkMethodImpl(
>                                     Class<?> callerClass, int refKind,
>                                     Class<?> defc, String name, Object type,
>                                     Object[] appendixResult)
> which is called from java.lang.invoke.MethodHandleNatives#linkMethod(same args)
> 
> I suppose this is an upcall from VM to link a call to the @PolymorphicSignature method and callerClass is the class in which the invocation bytecodes are executed. Am I right?

Yes.

And before that there is an upcall to MethodHandleNatives.findMethodHandleType, see SystemDictionary::find_method_handle_invoker in src/share/vm/classfile/systemDictionary.cpp.

AFAICT the ?type? argument passed to the linkMethod should always be of MethodType:

static MemberName linkMethod(Class<?> callerClass, int refKind,
                             Class<?> defc, String name, Object type,
                             Object[] appendixResult) {
    if (!TRACE_METHOD_LINKAGE)
        return linkMethodImpl(callerClass, refKind, defc, name, type, appendixResult);
    return linkMethodTracing(callerClass, refKind, defc, name, type, appendixResult);
}
static MemberName linkMethodImpl(Class<?> callerClass, int refKind,
                                 Class<?> defc, String name, Object type,
                                 Object[] appendixResult) {
    try {
        if (defc == MethodHandle.class && refKind == REF_invokeVirtual) {
            return Invokers.methodHandleInvokeLinkerMethod(name, fixMethodType(callerClass, type), appendixResult);
        }
    } catch (Throwable ex) {
        if (ex instanceof LinkageError)
            throw (LinkageError) ex;
        else
            throw new LinkageError(ex.getMessage(), ex);
    }
    throw new LinkageError("no such method "+defc.getName()+"."+name+type);
}
private static MethodType fixMethodType(Class<?> callerClass, Object type) {
    if (type instanceof MethodType)
        return (MethodType) type;
    else
        return MethodType.fromMethodDescriptorString((String)type, callerClass.getClassLoader());
}

Thus it seems fixMethodType is not necessary. I think this is confirmed when looking at up calls to linkMethodHandleConstant and linkCallSite.


> The reasoning is as follows: if callerClass.getClassLoader() is sufficient for resolving types that appear at the call site in a non-bootstrap callerClass, then bootstrap classloader should be sufficient to resolve types that appear at the call site in a bootstrap callerClass. Does anybody have any other opinion?
> 
> - sun.invoke.util.BytecodeDescriptor#parseMethod(java.lang.String, java.lang.ClassLoader) is only used from the newly introduced java.lang.invoke.MethodType#fromDescriptor
> 

Ok, i think you have things covered, thanks,
Paul.


From miroslav.kos at oracle.com  Wed Sep 30 12:28:30 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Wed, 30 Sep 2015 14:28:30 +0200
Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using
	java.util.ServiceLoader
In-Reply-To: <47E51B07-4FA1-4C13-9F8C-450B44C8FE20@oracle.com>
References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com>
	<56054D74.3070903@oracle.com> <56059161.2010808@oracle.com>
	<560A95E8.30907@oracle.com>
	<47E51B07-4FA1-4C13-9F8C-450B44C8FE20@oracle.com>
Message-ID: <560BD56E.5040708@oracle.com>



On 29/09/15 16:43, Deva Sagar wrote:
> Hi Miran,
>
> Sorry for the delay in responding to this - I was busy with WLS 
> release close down, and now I have moved to a different job in the 
> cloud organization outside of WLS and web services.
>
> Regarding your question in #3 - I think Georgiy made a good 
> observation about SAAJMetaFactory - making a public newInstance method 
> as you suggest would make it agree with the package-info, but does not 
> correspond to the API specification. The package-info in Java SE 8 API 
> docs says "SAAJMetaFactory is a service provider interface. There are 
> no public methods on this class.? If we put in a public newInstance() 
> method, it does not agree with this statement in API Javadoc. It might 
> be better in my opinion to remove SAAJMetaFactory mention from 
> package-info.java unless there is a good reason to keep it.
Agree, let's keep that simple. The updated specdiff is here:
http://cr.openjdk.java.net/~mkos/8131334/specdiff.05/

ApiNote removed, SAAJMetaFactory kept package private.

Thanks
Miran

>
> The rest of your changes look ok to me. Also cc?ing Chen for any 
> additional comments
>
> Deva
>
>
>
>> On Sep 29, 2015, at 9:45 AM, Miroslav Kos <miroslav.kos at oracle.com 
>> <mailto:miroslav.kos at oracle.com>> wrote:
>>
>> On 25/09/15 20:24, Georgiy Rakov wrote:
>>> Hello Miroslav,
>>>
>>> sorry for delay, was busy due to deadlines.
>>>
>>> I think it's just spec I am to review. Some comments for the moment 
>>> please see below:
>>>
>>> 1. package-info.java:
>>>
>>>       *  <li>Checks if a system property with the same name as the factory class is set (/_*i.e.*_/
>>>       *  {@code javax.xml.soap.SOAPFactory}).
>>>
>>> I guess "e.g." is meant, that is "for example"?
>> Sure, thanks.
>>>
>>> 2. SAAJMetaFactory.java:
>>>
>>> Following is specified normatively:
>>>    62      * <p>Property {@code javax.xml.soap.MetaFactory} used in previous
>>>    63      * specifications (up to 1.3) is still supported, but it is strongly recommended to migrate to new property
>>>    64      * {@code javax.xml.soap.SAAJMetaFactory}.
>>> while in package-info.java: the same idea is specified as API note 
>>> that is non-normatively:
>>>   * @apiNote
>>>   * <p>For {@link javax.xml.soap.SAAJMetaFactory}, property {@code javax.xml.soap.MetaFactory} used in previous
>>>   * specifications (up to 1.3) is still supported, but it is strongly recommended to migrate to new property
>>>   * {@code javax.xml.soap.SAAJMetaFactory}.
>>>   */
>>> I believe this idea should be specified everywhere the same way that 
>>> is either normatively or non-normatively. If it's to be defined 
>>> normatively more details should be specified I believe.
>> Made non-normative.
>>>
>>> 3. SAAJMetaFactory.getInstance method is package private. So:
>>> - This method is not supposed to be used by users, is it?
>>> - The javadoc of this method isn't actually a public specification. 
>>> Thus Oracle claims nothing by it and external Java SE implementers 
>>> are not required to follow this JavaDoc, that is this JavaDoc is 
>>> intended to be used internally only, isn't it?
>>> I understand that this was before, but It looks very strange. Is 
>>> this really not a mistake? BTW: this method and spec are not visible 
>>> in API JavaDoc 
>>> <https://docs.oracle.com/javase/8/docs/api/javax/xml/soap/SAAJMetaFactory.html>.
>>>
>>> It looks like a mistake moreover because public specification 
>>> defined in package-info.java being reviewed refers to it:
>>>   * There are several factories defined in the SAAJ API to discover and load specific implementation:
>>>   *
>>>   * <ul>
>>>   *     <li>{@link javax.xml.soap.SOAPFactory}
>>>   *     <li>{@link javax.xml.soap.MessageFactory}
>>>   *     <li>{@link javax.xml.soap.SOAPConnectionFactory}
>>>   /_** <li>{@link javax.xml.soap.SAAJMetaFactory}*_/
>>>   * </ul>
>>>   *
>>>   * These factories define {@code/_*newInstance()*_/} method which uses a common lookup procedure to determine
>>>   * the implementation class:
>> It's good catch - it looks like error. An easy fix would be change 
>> the method to newInstance and make it public - Deva, would you agree?
>> http://cr.openjdk.java.net/~mkos/8131334/specdiff.04/index.html
>>
>> Anyway those are changes to API - should I withdraw 
>> http://ccc.us.oracle.com/8131334 and create new one?
>>
>> Thanks
>> Miran
>>
>>
>>
>>> Thank you,
>>> Goergiy.
>>>
>>> On 25.09.2015 16:34, Miroslav Kos wrote:
>>>> Ping ...
>>>>
>>>> On 11/09/15 17:57, Miroslav Kos wrote:
>>>>> Hi again,
>>>>> would somebody find a time to review?
>>>>>
>>>>> Thanks
>>>>> Miran
>>>>>
>>>>> On 20/08/15 16:17, Miroslav Kos wrote:
>>>>>> Hi everybody,
>>>>>>
>>>>>> I am sending changes for review for
>>>>>> JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader
>>>>>>
>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8131334
>>>>>> webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/
>>>>>>
>>>>>> It's about migrating to standard java.util.ServiceLoader. This 
>>>>>> part of service discovery was implemented previously "own" way. 
>>>>>> There are some changes in javadoc and implementation has been 
>>>>>> refactored in order to use same code as in JAX-WS and JAX-B.
>>>>>>
>>>>>> Testing - I run JAX-WS unit tests (JAX-WS standalone repo), JCK9 
>>>>>> + new tests specificaly developed for testing service discovery 
>>>>>> in SAAJ.
>>>>>>
>>>>>> Thanks
>>>>>> Miran
>>>>>
>>>>
>>>
>>
>



From paul.sandoz at oracle.com  Wed Sep 30 12:59:29 2015
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 30 Sep 2015 14:59:29 +0200
Subject: specdiff <was> Re: RFR: jsr166 openjdk9 integration
In-Reply-To: <CA+kOe08sjbwSVvjRg-=q-xnSdi8EcdBo3pqihoR6uFbdS5afdQ@mail.gmail.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>
	<CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>
	<F57BEACF-282F-41C6-B5CA-5BA9A09BF2C4@oracle.com>
	<6C860453-A0EB-46FB-AB75-CB57FA4E82FE@oracle.com>
	<CA+kOe08sjbwSVvjRg-=q-xnSdi8EcdBo3pqihoR6uFbdS5afdQ@mail.gmail.com>
Message-ID: <AE074295-5B2F-4A2B-8234-3F5B54B9CB93@oracle.com>


> On 30 Sep 2015, at 04:16, Martin Buchholz <martinrb at google.com> wrote:
> 
> Thanks for the specdiff - much easier to review for javadoc changes!.  I went through it.  There were a small number of minor mistakes, which are now corrected.  Now would be a good time to regenerate the specdiff.
> 

Updated.

As you noticed Chris already pushed:

  https://bugs.openjdk.java.net/browse/JDK-8134854 <https://bugs.openjdk.java.net/browse/JDK-8134854>
  http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e043512a2cc5 <http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e043512a2cc5>

I plan to push https://bugs.openjdk.java.net/browse/JDK-8134853 <https://bugs.openjdk.java.net/browse/JDK-8134853> this week.

I expect after the JEP is integrated we will need to do another smaller integration to sweep up any further tweaks.

Paul.

> On Thu, Sep 24, 2015 at 1:35 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
> 
>   http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8132960-166-updates/specdiff/overview-summary.html <http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8132960-166-updates/specdiff/overview-summary.html>
> 
> Paul.
> 



From ralph.goers at dslextreme.com  Wed Sep 30 13:59:31 2015
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Wed, 30 Sep 2015 06:59:31 -0700
Subject: JEP 264: Platform Logging API and Service
In-Reply-To: <560B9370.2080307@gmail.com>
References: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
	<55FEB898.6050106@gmail.com> <560ADB25.801@oracle.com>
	<9A09A754-31CE-4658-8F5B-8DD524729267@dslextreme.com>
	<560B9370.2080307@gmail.com>
Message-ID: <17BFA09E-27E8-4CAD-9F4D-AEA3859625DA@dslextreme.com>

If I understand you correctly, then no that isn?t what I would want. The version and priority are captured in the same properties file where the class name is specified. If the class implements the wrong version or isn?t chosen due to its priority then the class isn?t loaded. To do what you are describing would require that serviceLoader load each class and that methods be called on each class to get that information. While that makes life simpler for the serviceLoader it makes it more complicated for the services being loaded.

Ralph

> On Sep 30, 2015, at 12:46 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> 
> 
> On 09/29/2015 11:17 PM, Ralph Goers wrote:
>> FWIW, I considered using the ServiceLoader to bind the Log4j API to the implementation. However, Log4j also includes the API version and only looks for bindings that implement that version. We also include a ?priority? - the binding with the highest priority wins - at the moment. At some future time we might consider supporting multiple bindings.
>> 
>> It would have been nice if ServlceLoader could be extended by the user to do these sort of checks instead of not being able to use it at all.
>> 
>> Ralph
> 
> Hi Ralph,
> 
> ServiceLoader can be used to load all services that implement a particular type (it's an Iterable). So you can decide which one(s) to use in your own logic. You just have to design the service type in a way where it's implementations expose some attributes that are relevant for selection and initialize the underlying service lazily, after selection is done. This would usually mean that the service interface/abstract class implements a factory for the real service and exposes some properties such as version, priority, etc...
> 
> Would that work for Log4j?
> 
> Regards, Peter
> 
>> 
>>> On Sep 29, 2015, at 11:40 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>> 
>>> On 20/09/15 15:46, Peter Levart wrote:
>>>> 
>>>> On 09/18/2015 06:17 PM, mark.reinhold at oracle.com wrote:
>>>>> New JEP Candidate:http://openjdk.java.net/jeps/264
>>>>> 
>>>>> - Mark
>>>> Hi,
>>>> 
>>>> What is the purpose of exposing a factory for loggers in the generally
>>>> exported package (java.lang) and making it standard Java API as opposed
>>>> to keeping it internal API as it is now
>>>> (sun.util.logging.PlatformLogger)? Is this going to become an official
>>>> front-end for JDK-internal and applications use, available in the
>>>> platform itself?
>>> Hi Peter,
>>> 
>>> sun.util.logging.PlatformLogger is a module private API in
>>> java.base, yet it is used by other modules in the JDK - and
>>> this requires qualified exports to the modules that use it.
>>> Having a public API that JDK modules could use would simplify
>>> the module graph in this respect.
>>> 
>>> In time, I'd hope to see sun.util.logging.PlatformLogger disappear
>>> in favor of the public API.
>>> 
>>>> Otherwise I think it's good to add support for interfacing other
>>>> backends (besides JDK14 Logging and stderr) to platform logger. If one
>>>> wants to interface some other backend to platform logger now, it's
>>>> actually doable, but only via the intermediate JDK14 Logging API, like this:
>>>> 
>>>> PlatformLogger -> j.u.l.Logger -> jul-to-slf4j -> slf4j-WHATEVER-BACKEND
>>>> 
>>>> Adding support to skip JDK14 Logging would simplify configuration and
>>>> make it more lightweight.
>>> Yes - the goal of the LoggerFinder service API is to make it possible
>>> for applications - or frameworks - to provide their own implementation.
>>> 
>>> best regards,
>>> 
>>> -- daniel
>>> 
>>>> Regards, Peter
>>>> 
>>> 
>> 
> 
> 




From pbenedict at apache.org  Wed Sep 30 14:06:18 2015
From: pbenedict at apache.org (Paul Benedict)
Date: Wed, 30 Sep 2015 09:06:18 -0500
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <560B9073.3060507@gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<BN4PR13MB05949FF23A0CFFC9A4E49F2F83460@BN4PR13MB0594.namprd13.prod.outlook.com>
	<DAA0DF24-D174-4A58-ACAF-477E78D6D216@oracle.com>
	<5609D704.4050707@oracle.com>
	<B6E72165-91C2-451A-9929-F5C4CC6440CB@oracle.com>
	<9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>
	<CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com>
	<4B8AD5A1-376F-406B-8A50-44C199CB3471@oracle.com>
	<560AE56E.1020808@gmail.com>
	<8385037B-FB27-4885-802C-00CCE2556FC2@oracle.com>
	<560B9073.3060507@gmail.com>
Message-ID: <CABLGb9zM-NWu-tyE-Ep95ij+6grSM0xGT=eRZ=FojGKHJAtTvA@mail.gmail.com>

Ah, I was going to write about "values" ... glad this was mentioned. With
Valhalla working on value classes, it does raise the question if
range-checking is particular to Objects. Clearly it won't be once values
are introduced.

PS: I am still in favor of using Objects at the time being though just to
get something checked-in.


Cheers,
Paul

On Wed, Sep 30, 2015 at 2:34 AM, Peter Levart <peter.levart at gmail.com>
wrote:

>
>
> On 09/29/2015 10:01 PM, Paul Sandoz wrote:
>
>> >I think it's worth introducing Preconditions class. checkNotNull
>>> overloads are equally well suited for Objects as they are for
>>> Preconditions, so it's not wrong to have them in both, while checkIndex and
>>> friends don't really suit any of the existing classes. If I would have to
>>> search for them in among existing classes, Arrays would be the place to
>>> look first. List interface the 2nd. IndexOutOfBoundsException wouldn't come
>>> to my mind, as Exception(s) are usually not homes for logic, neither would
>>> Integer which is to abstract to mentally associate it with array or list
>>> index checks.
>>> >
>>>
>> The concern i have is once Preconditions is let loose the scope expands
>> with proposals for ?just one more method? (there is even the opportunity to
>> bike shed over the names checkNotNull or requiresNotNull etc. etc.)  I
>> don?t want to discuss such additional methods right now otherwise i will
>> never make progress with the current set.
>>
>> A way forward is to initially include Preconditions with*only*  the check
>> index methods, and in subsequent proposals selectively add more. At the
>> moment i am still leaning towards Objects.
>>
>> Paul.
>>
>>
> I promise I won't discuss any other methods - just checkIndex and friends
> (small steps...)
> But having them in Objects would be very strange. Indexes are not objects
> - they are values.
>
>
> Regards, Peter
>


From forax at univ-mlv.fr  Wed Sep 30 14:13:28 2015
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 30 Sep 2015 16:13:28 +0200 (CEST)
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <CABLGb9zM-NWu-tyE-Ep95ij+6grSM0xGT=eRZ=FojGKHJAtTvA@mail.gmail.com>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>
	<CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com>
	<4B8AD5A1-376F-406B-8A50-44C199CB3471@oracle.com>
	<560AE56E.1020808@gmail.com>
	<8385037B-FB27-4885-802C-00CCE2556FC2@oracle.com>
	<560B9073.3060507@gmail.com>
	<CABLGb9zM-NWu-tyE-Ep95ij+6grSM0xGT=eRZ=FojGKHJAtTvA@mail.gmail.com>
Message-ID: <219933313.1583380.1443622408446.JavaMail.zimbra@u-pem.fr>



----- Mail original -----
> De: "Paul Benedict" <pbenedict at apache.org>
> ?: "Peter Levart" <peter.levart at gmail.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mercredi 30 Septembre 2015 16:06:18
> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> 
> Ah, I was going to write about "values" ... glad this was mentioned. With
> Valhalla working on value classes, it does raise the question if
> range-checking is particular to Objects. Clearly it won't be once values
> are introduced.
> 
> PS: I am still in favor of using Objects at the time being though just to
> get something checked-in.

I am in favor of Objects too,
but I think the name (oh no bikeshedding again) should start with require* too make it clear that it goes with requireNonNull

'requireIndexInBounds' anyone ?

> 
> 
> Cheers,
> Paul

cheers,
R?mi

> 
> On Wed, Sep 30, 2015 at 2:34 AM, Peter Levart <peter.levart at gmail.com>
> wrote:
> 
> >
> >
> > On 09/29/2015 10:01 PM, Paul Sandoz wrote:
> >
> >> >I think it's worth introducing Preconditions class. checkNotNull
> >>> overloads are equally well suited for Objects as they are for
> >>> Preconditions, so it's not wrong to have them in both, while checkIndex
> >>> and
> >>> friends don't really suit any of the existing classes. If I would have to
> >>> search for them in among existing classes, Arrays would be the place to
> >>> look first. List interface the 2nd. IndexOutOfBoundsException wouldn't
> >>> come
> >>> to my mind, as Exception(s) are usually not homes for logic, neither
> >>> would
> >>> Integer which is to abstract to mentally associate it with array or list
> >>> index checks.
> >>> >
> >>>
> >> The concern i have is once Preconditions is let loose the scope expands
> >> with proposals for ?just one more method? (there is even the opportunity
> >> to
> >> bike shed over the names checkNotNull or requiresNotNull etc. etc.)  I
> >> don?t want to discuss such additional methods right now otherwise i will
> >> never make progress with the current set.
> >>
> >> A way forward is to initially include Preconditions with*only*  the check
> >> index methods, and in subsequent proposals selectively add more. At the
> >> moment i am still leaning towards Objects.
> >>
> >> Paul.
> >>
> >>
> > I promise I won't discuss any other methods - just checkIndex and friends
> > (small steps...)
> > But having them in Objects would be very strange. Indexes are not objects
> > - they are values.
> >
> >
> > Regards, Peter
> >
> 


From Alan.Bateman at oracle.com  Wed Sep 30 14:14:10 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 30 Sep 2015 15:14:10 +0100
Subject: JEP 264: Platform Logging API and Service
In-Reply-To: <17BFA09E-27E8-4CAD-9F4D-AEA3859625DA@dslextreme.com>
References: <20150918161737.CF3F171F93@eggemoggin.niobe.net>	<55FEB898.6050106@gmail.com>
	<560ADB25.801@oracle.com>	<9A09A754-31CE-4658-8F5B-8DD524729267@dslextreme.com>	<560B9370.2080307@gmail.com>
	<17BFA09E-27E8-4CAD-9F4D-AEA3859625DA@dslextreme.com>
Message-ID: <560BEE32.4070801@oracle.com>

On 30/09/2015 14:59, Ralph Goers wrote:
> If I understand you correctly, then no that isn?t what I would want. The version and priority are captured in the same properties file where the class name is specified. If the class implements the wrong version or isn?t chosen due to its priority then the class isn?t loaded. To do what you are describing would require that serviceLoader load each class and that methods be called on each class to get that information. While that makes life simpler for the serviceLoader it makes it more complicated for the services being loaded.
>
It should be possible to create a service type that allows you to select 
the appropriate service provider implementation. The service type can 
also work as a factory so that once you select the service provider then 
you invoke some method on it to get the actual logging provider.

-Alan.


From Roger.Riggs at Oracle.com  Wed Sep 30 14:21:34 2015
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 30 Sep 2015 10:21:34 -0400
Subject: RFR 9: 8137313 : TreeTest.java intermittently fails with a timeout
Message-ID: <560BEFEE.20506@Oracle.com>

Please review an enhancement to the test to help diagnose this failure 
in the ProcessHandle TreeTest.

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-treetest-8137313/
Issue:
   https://bugs.openjdk.java.net/browse/JDK-8137313

Thanks, Roger



From chris.hegarty at oracle.com  Wed Sep 30 14:49:25 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 30 Sep 2015 15:49:25 +0100
Subject: RFR 9: 8137313 : TreeTest.java intermittently fails with a timeout
In-Reply-To: <560BEFEE.20506@Oracle.com>
References: <560BEFEE.20506@Oracle.com>
Message-ID: <560BF675.7040409@oracle.com>

Adding additional diagnostic information to help find the root cause of 
the intermittent failures seems like the right thing to do. Reviewed.

-Chris.

On 30/09/15 15:21, Roger Riggs wrote:
> Please review an enhancement to the test to help diagnose this failure
> in the ProcessHandle TreeTest.
>
> Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-treetest-8137313/
> Issue:
>    https://bugs.openjdk.java.net/browse/JDK-8137313
>
> Thanks, Roger
>


From martinrb at google.com  Wed Sep 30 15:05:53 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 30 Sep 2015 08:05:53 -0700
Subject: specdiff <was> Re: RFR: jsr166 openjdk9 integration
In-Reply-To: <AE074295-5B2F-4A2B-8234-3F5B54B9CB93@oracle.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>
	<CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>
	<F57BEACF-282F-41C6-B5CA-5BA9A09BF2C4@oracle.com>
	<6C860453-A0EB-46FB-AB75-CB57FA4E82FE@oracle.com>
	<CA+kOe08sjbwSVvjRg-=q-xnSdi8EcdBo3pqihoR6uFbdS5afdQ@mail.gmail.com>
	<AE074295-5B2F-4A2B-8234-3F5B54B9CB93@oracle.com>
Message-ID: <CA+kOe0-Zg_+ZcsDY3nU-wiQ6Qdto7PPbyrf_ceQrEs68Ut1qng@mail.gmail.com>

Note that the patches are not all independent - each patch was tested with
previous patches applied.  My original intent was to push all the patches
at once, but of course there are testing advantages to pushing them
individually.

On Wed, Sep 30, 2015 at 5:59 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> > On 30 Sep 2015, at 04:16, Martin Buchholz <martinrb at google.com> wrote:
> >
> > Thanks for the specdiff - much easier to review for javadoc changes!.  I
> went through it.  There were a small number of minor mistakes, which are
> now corrected.  Now would be a good time to regenerate the specdiff.
> >
>
> Updated.
>
> As you noticed Chris already pushed:
>
>   https://bugs.openjdk.java.net/browse/JDK-8134854 <
> https://bugs.openjdk.java.net/browse/JDK-8134854>
>   http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e043512a2cc5 <
> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e043512a2cc5>
>
> I plan to push https://bugs.openjdk.java.net/browse/JDK-8134853 <
> https://bugs.openjdk.java.net/browse/JDK-8134853> this week.
>
> I expect after the JEP is integrated we will need to do another smaller
> integration to sweep up any further tweaks.
>
> Paul.
>
> > On Thu, Sep 24, 2015 at 1:35 AM, Paul Sandoz <paul.sandoz at oracle.com
> <mailto:paul.sandoz at oracle.com>> wrote:
> >
> >
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8132960-166-updates/specdiff/overview-summary.html
> <
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8132960-166-updates/specdiff/overview-summary.html
> >
> >
> > Paul.
> >
>
>


From miroslav.kos at oracle.com  Wed Sep 30 15:08:29 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Wed, 30 Sep 2015 17:08:29 +0200
Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using
	java.util.ServiceLoader
In-Reply-To: <1ACCA360-ED4B-4A06-B0AD-52F14E604FCD@oracle.com>
References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com>
	<56054D74.3070903@oracle.com> <56059161.2010808@oracle.com>
	<560A95E8.30907@oracle.com>
	<47E51B07-4FA1-4C13-9F8C-450B44C8FE20@oracle.com>
	<560BE098.7090809@oracle.com>
	<1ACCA360-ED4B-4A06-B0AD-52F14E604FCD@oracle.com>
Message-ID: <560BFAED.4070802@oracle.com>



On 30/09/15 16:20, Deva Sagar wrote:
> Hi Georgiy,
>
> I think both Miran and I are referring to the mention of 
> SAAJMetaFactory in the bullet list about the public newInstance() 
> method. The Javadoc of the SAAJMetaFactory class still describes it as 
> an SPI and it is accessible from package-info. This is no different 
> from the current public Javadocs.
>
> Thanks,
> Deva
>
>
>> On Sep 30, 2015, at 9:16 AM, Georgiy Rakov <georgiy.rakov at oracle.com 
>> <mailto:georgiy.rakov at oracle.com>> wrote:
>>
>>
>>
>> On 29.09.2015 17:43, Deva Sagar wrote:
>>> Hi Miran,
>>>
>>> Sorry for the delay in responding to this - I was busy with WLS 
>>> release close down, and now I have moved to a different job in the 
>>> cloud organization outside of WLS and web services.
>>>
>>> Regarding your question in #3 - I think Georgiy made a good 
>>> observation about SAAJMetaFactory - making a public newInstance 
>>> method as you suggest would make it agree with the package-info, but 
>>> does not correspond to the API specification. The package-info in 
>>> Java SE 8 API docs says "SAAJMetaFactory is a service provider 
>>> interface. There are no public methods on this class.? If we put in 
>>> a public newInstance() method, it does not agree with this statement 
>>> in API Javadoc. It might be better in my opinion to 
>>> remove SAAJMetaFactory mention from package-info.java unless there 
>>> is a good reason to keep it.
>>>
>> Hello,
>>
>> according to my understanding the idea of SAAJMetaFactory is for SPI 
>> developer to subclass it and thus to create a custom SAAJMetaFactory 
>> implementation.
Yes, it's current state - the only description of lookup/instantiation 
user SAAJMetaFactory is statement that it is service provider interaface 
(stays unchanged): 
https://docs.oracle.com/javase/8/docs/api/javax/xml/soap/SAAJMetaFactory.html
Service loader is the only specification here.
>> Afterwards user should configure SAAJ API in order it could use that 
>> custom implementation.
User configuration controls discovery of implementation when used 
newInstance method on other factories (MessageFactory, SOAPFactory, 
SOAPConnectionFactory). If no implementation found, the fallback is user 
(or default) SAAJMetaFactory.newXXXFactory()
>> But if SAAJMetaFactory mention from package-info.java is removed 
>> there will be actually no spec defining how to configure SAAJ API for 
>> using custom SAAJMetaFactory, or do I miss spec defining it?
No, there is still statement about service provider interface.
>> BTW: from this perspective referring to SAAJMetaFactory newInstance 
>> method in spec is not relevant since it's SAAJ API implementation 
>> internal machinery.
Yes, it is internal.

Actually I thing SAAJ API is pretty complicated already, so not adding 
another spec for SAAJMetaFactory discovery is good idea ...

Thanks
Miran


>>
>> So I believe if SAAJMetaFactory mention from package-info.java is 
>> removed the process of SAAJMetaFactory instantiation should be 
>> described somehow in another place and without mentioning newInstance 
>> method. Maybe it's worth rather modifying than removing this 
>> mentioning in package-info.java?
>>
>> Thanks,
>> Georgiy.
>>
>>> The rest of your changes look ok to me. Also cc?ing Chen for any 
>>> additional comments
>>>
>>> Deva
>>>
>>>
>>>
>>>> On Sep 29, 2015, at 9:45 AM, Miroslav Kos <miroslav.kos at oracle.com> 
>>>> wrote:
>>>>
>>>> On 25/09/15 20:24, Georgiy Rakov wrote:
>>>>> Hello Miroslav,
>>>>>
>>>>> sorry for delay, was busy due to deadlines.
>>>>>
>>>>> I think it's just spec I am to review. Some comments for the 
>>>>> moment please see below:
>>>>>
>>>>> 1. package-info.java:
>>>>>
>>>>>       *  <li>Checks if a system property with the same name as the factory class is set (/_*i.e.*_/
>>>>>       *  {@code javax.xml.soap.SOAPFactory}).
>>>>>
>>>>> I guess "e.g." is meant, that is "for example"?
>>>> Sure, thanks.
>>>>>
>>>>> 2. SAAJMetaFactory.java:
>>>>>
>>>>> Following is specified normatively:
>>>>>    62      * <p>Property {@code javax.xml.soap.MetaFactory} used in previous
>>>>>    63      * specifications (up to 1.3) is still supported, but it is strongly recommended to migrate to new property
>>>>>    64      * {@code javax.xml.soap.SAAJMetaFactory}.
>>>>> while in package-info.java: the same idea is specified as API note 
>>>>> that is non-normatively:
>>>>>   * @apiNote
>>>>>   * <p>For {@link javax.xml.soap.SAAJMetaFactory}, property {@code javax.xml.soap.MetaFactory} used in previous
>>>>>   * specifications (up to 1.3) is still supported, but it is strongly recommended to migrate to new property
>>>>>   * {@code javax.xml.soap.SAAJMetaFactory}.
>>>>>   */
>>>>> I believe this idea should be specified everywhere the same way 
>>>>> that is either normatively or non-normatively. If it's to be 
>>>>> defined normatively more details should be specified I believe.
>>>> Made non-normative.
>>>>>
>>>>> 3. SAAJMetaFactory.getInstance method is package private. So:
>>>>> - This method is not supposed to be used by users, is it?
>>>>> - The javadoc of this method isn't actually a public 
>>>>> specification. Thus Oracle claims nothing by it and external Java 
>>>>> SE implementers are not required to follow this JavaDoc, that is 
>>>>> this JavaDoc is intended to be used internally only, isn't it?
>>>>> I understand that this was before, but It looks very strange. Is 
>>>>> this really not a mistake? BTW: this method and spec are not 
>>>>> visible in API JavaDoc 
>>>>> <https://docs.oracle.com/javase/8/docs/api/javax/xml/soap/SAAJMetaFactory.html>.
>>>>>
>>>>> It looks like a mistake moreover because public specification 
>>>>> defined in package-info.java being reviewed refers to it:
>>>>>   * There are several factories defined in the SAAJ API to discover and load specific implementation:
>>>>>   *
>>>>>   * <ul>
>>>>>   *     <li>{@link javax.xml.soap.SOAPFactory}
>>>>>   *     <li>{@link javax.xml.soap.MessageFactory}
>>>>>   *     <li>{@link javax.xml.soap.SOAPConnectionFactory}
>>>>>   /_** <li>{@link javax.xml.soap.SAAJMetaFactory}*_/
>>>>>   * </ul>
>>>>>   *
>>>>>   * These factories define {@code/_*newInstance()*_/} method which uses a common lookup procedure to determine
>>>>>   * the implementation class:
>>>> It's good catch - it looks like error. An easy fix would be change 
>>>> the method to newInstance and make it public - Deva, would you agree?
>>>> http://cr.openjdk.java.net/~mkos/8131334/specdiff.04/index.html
>>>>
>>>> Anyway those are changes to API - should I withdraw 
>>>> http://ccc.us.oracle.com/8131334 and create new one?
>>>>
>>>> Thanks
>>>> Miran
>>>>
>>>>
>>>>
>>>>> Thank you,
>>>>> Goergiy.
>>>>>
>>>>> On 25.09.2015 16:34, Miroslav Kos wrote:
>>>>>> Ping ...
>>>>>>
>>>>>> On 11/09/15 17:57, Miroslav Kos wrote:
>>>>>>> Hi again,
>>>>>>> would somebody find a time to review?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Miran
>>>>>>>
>>>>>>> On 20/08/15 16:17, Miroslav Kos wrote:
>>>>>>>> Hi everybody,
>>>>>>>>
>>>>>>>> I am sending changes for review for
>>>>>>>> JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader
>>>>>>>>
>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8131334
>>>>>>>> webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/
>>>>>>>>
>>>>>>>> It's about migrating to standard java.util.ServiceLoader. This 
>>>>>>>> part of service discovery was implemented previously "own" way. 
>>>>>>>> There are some changes in javadoc and implementation has been 
>>>>>>>> refactored in order to use same code as in JAX-WS and JAX-B.
>>>>>>>>
>>>>>>>> Testing - I run JAX-WS unit tests (JAX-WS standalone repo), 
>>>>>>>> JCK9 + new tests specificaly developed for testing service 
>>>>>>>> discovery in SAAJ.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Miran
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>



From miroslav.kos at oracle.com  Wed Sep 30 15:31:11 2015
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Wed, 30 Sep 2015 17:31:11 +0200
Subject: [9] Review request JDK-8131334: SAAJ Plugability Layer: using
	java.util.ServiceLoader
In-Reply-To: <560BF6AD.60204@oracle.com>
References: <55D5E163.6090905@oracle.com> <55F2F9F4.5090309@oracle.com>
	<56054D74.3070903@oracle.com> <560BF6AD.60204@oracle.com>
Message-ID: <560C003F.8070801@oracle.com>

On 30/09/15 16:50, Georgiy Rakov wrote:
> Hello Miroslav,
>
> could you please see some more comments below:
>
> 1. I believe it's better to say that exactly "fully qualified name" of 
> the provider factory implementation class is assumed to be the value 
> of the property:
>
>       *  {@code javax.xml.soap.SOAPFactory}). If such property exists then its value is assumed to be/_*the provider*_/
>       */_*factory class*_/. This phase of the look up enables per-JVM override of the SAAJ implementation.
>
> This has been done in the next step of lookup procedure and this looks 
> reasonable:
>
>       *  {@code conf} directory of the Java installation. It contains the/_*fully qualified *_/  */_*name*_/  ...
>
Will fix, thanks.
>
> 2. This is not related to ServiceLoader feature, but anyway - 
> SAAJMetaFactory.java:
>
>        30 * SAAJ API./_*All *_//_*of the {@code newInstance} methods defined on factories*_/  in
>        31 * SAAJ 1.3 defer to instances of this class to do the actual object creation.
>
> Namely it says that /_*all*_/**the newInstance methods defined on 
> factories delegate factory creation to SAAJMetaFactory instances, but 
> this seems to be not exactly true because SOAPConnectionFactory is not 
> created by SAAJMetaFactory instance.
Yes, good catch. To fix it, it would be good to add a new abstract method
public abstract SOAPConnectionFactory newSOAPConnectionFactory()
     throws SOAPException, UnsupportedOperationException

Would you agree, Deva, Chen? There is a problem with backwards 
compatibility here ... More defensive would be to name the two factories 
instead of saying "all"?

Thanks
Miran

Btw. I sent this RFR initially to wrong mailing lists, would you check 
when answering that it's to  Core-Libs-Dev 
<core-libs-dev at openjdk.java.net> ?

>
> Thank you,
> Georgiy.
>
> On 25.09.2015 16:34, Miroslav Kos wrote:
>> Ping ...
>>
>> On 11/09/15 17:57, Miroslav Kos wrote:
>>> Hi again,
>>> would somebody find a time to review?
>>>
>>> Thanks
>>> Miran
>>>
>>> On 20/08/15 16:17, Miroslav Kos wrote:
>>>> Hi everybody,
>>>>
>>>> I am sending changes for review for
>>>> JDK-8131334: SAAJ Plugability Layer: using java.util.ServiceLoader
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8131334
>>>> webrev: http://cr.openjdk.java.net/~mkos/8131334/jaxws.01/
>>>>
>>>> It's about migrating to standard java.util.ServiceLoader. This part 
>>>> of service discovery was implemented previously "own" way. There 
>>>> are some changes in javadoc and implementation has been refactored 
>>>> in order to use same code as in JAX-WS and JAX-B.
>>>>
>>>> Testing - I run JAX-WS unit tests (JAX-WS standalone repo), JCK9 + 
>>>> new tests specificaly developed for testing service discovery in SAAJ.
>>>>
>>>> Thanks
>>>> Miran
>>>
>>
>



From joe.darcy at oracle.com  Wed Sep 30 16:23:09 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 30 Sep 2015 09:23:09 -0700
Subject: RFR 9: 8137313 : TreeTest.java intermittently fails with a timeout
In-Reply-To: <560BF675.7040409@oracle.com>
References: <560BEFEE.20506@Oracle.com> <560BF675.7040409@oracle.com>
Message-ID: <560C0C6D.2000804@oracle.com>

+1

-Joe

On 9/30/2015 7:49 AM, Chris Hegarty wrote:
> Adding additional diagnostic information to help find the root cause 
> of the intermittent failures seems like the right thing to do. Reviewed.
>
> -Chris.
>
> On 30/09/15 15:21, Roger Riggs wrote:
>> Please review an enhancement to the test to help diagnose this failure
>> in the ProcessHandle TreeTest.
>>
>> Webrev:
>>     http://cr.openjdk.java.net/~rriggs/webrev-treetest-8137313/
>> Issue:
>>    https://bugs.openjdk.java.net/browse/JDK-8137313
>>
>> Thanks, Roger
>>



From ralph.goers at dslextreme.com  Wed Sep 30 16:30:25 2015
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Wed, 30 Sep 2015 09:30:25 -0700
Subject: JEP 264: Platform Logging API and Service
In-Reply-To: <560BEE32.4070801@oracle.com>
References: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
	<55FEB898.6050106@gmail.com> <560ADB25.801@oracle.com>
	<9A09A754-31CE-4658-8F5B-8DD524729267@dslextreme.com>
	<560B9370.2080307@gmail.com>
	<17BFA09E-27E8-4CAD-9F4D-AEA3859625DA@dslextreme.com>
	<560BEE32.4070801@oracle.com>
Message-ID: <D225E5A9-2A1E-4164-B004-EF3BDCCDB444@dslextreme.com>

Alan, 

Your suggestion is literally the same thing that Peter suggested which is what my reply below was to. So you can take that reply as the reply to your message as well.

What would be preferable is to have the serviceLoader accept ?criteria? (which are callbacks) that can evaluate each of the located services based on any additional properties that are included in the properties file and either eliminate them or return a ?ranking".  The serviceLoader would then end up with a set of eligible services in their preferred order.

Ralph

> On Sep 30, 2015, at 7:14 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 30/09/2015 14:59, Ralph Goers wrote:
>> If I understand you correctly, then no that isn?t what I would want. The version and priority are captured in the same properties file where the class name is specified. If the class implements the wrong version or isn?t chosen due to its priority then the class isn?t loaded. To do what you are describing would require that serviceLoader load each class and that methods be called on each class to get that information. While that makes life simpler for the serviceLoader it makes it more complicated for the services being loaded.
>> 
> It should be possible to create a service type that allows you to select the appropriate service provider implementation. The service type can also work as a factory so that once you select the service provider then you invoke some method on it to get the actual logging provider.
> 
> -Alan.
> 




From daniel.fuchs at oracle.com  Wed Sep 30 16:50:40 2015
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 30 Sep 2015 18:50:40 +0200
Subject: JEP 264: Platform Logging API and Service
In-Reply-To: <D225E5A9-2A1E-4164-B004-EF3BDCCDB444@dslextreme.com>
References: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
	<55FEB898.6050106@gmail.com> <560ADB25.801@oracle.com>
	<9A09A754-31CE-4658-8F5B-8DD524729267@dslextreme.com>
	<560B9370.2080307@gmail.com>
	<17BFA09E-27E8-4CAD-9F4D-AEA3859625DA@dslextreme.com>
	<560BEE32.4070801@oracle.com>
	<D225E5A9-2A1E-4164-B004-EF3BDCCDB444@dslextreme.com>
Message-ID: <560C12E0.3060501@oracle.com>

Hi Ralph,

On 30/09/15 18:30, Ralph Goers wrote:
> What would be preferable is to have the serviceLoader accept ?criteria? (which are callbacks) that can evaluate each of the located services based on any additional properties that are included in the properties file and either eliminate them or return a ?ranking".  The serviceLoader would then end up with a set of eligible services in their preferred order.

I understand you may have another use case in mind, but in
what concerns jep264's LoggerFinder though - I don't think
that would be useful. The JDK can only use one LoggerFinder
service implementation, and if more than one is found, it most
probably indicates a configuration error - where several
implementations have been put by mistake on the classpath.

Just taking the first and silently continue could end up in
strange misbehavior, where the application's developer would
not see the expected debug traces - because she configured
one framework but it's the other that happens to be used.

I believe it's a better idea to fail fast in this case.

best regards,

-- daniel



From pbenedict at apache.org  Wed Sep 30 17:45:42 2015
From: pbenedict at apache.org (Paul Benedict)
Date: Wed, 30 Sep 2015 12:45:42 -0500
Subject: RFR 8135248: Add utility methods to check indexes and ranges
In-Reply-To: <219933313.1583380.1443622408446.JavaMail.zimbra@u-pem.fr>
References: <3235BC5D-AE96-47C5-9295-A306E6CF7CB1@oracle.com>
	<9B6852B9-58C4-41C1-A731-0D5F3F87E9FE@oracle.com>
	<CACzrW9CR9hZt9BEaJSLnX8d7+w8D-5YA409TMjyF-8F+ddOsmQ@mail.gmail.com>
	<4B8AD5A1-376F-406B-8A50-44C199CB3471@oracle.com>
	<560AE56E.1020808@gmail.com>
	<8385037B-FB27-4885-802C-00CCE2556FC2@oracle.com>
	<560B9073.3060507@gmail.com>
	<CABLGb9zM-NWu-tyE-Ep95ij+6grSM0xGT=eRZ=FojGKHJAtTvA@mail.gmail.com>
	<219933313.1583380.1443622408446.JavaMail.zimbra@u-pem.fr>
Message-ID: <CABLGb9xgO4PsRko_ap-f1TC9teV-ahbfw+HdeU7Aa2x_K1P6HA@mail.gmail.com>

+1 for having check methods start with 'require' .. that's a nice and
useful naming pattern.

On Wed, Sep 30, 2015 at 9:13 AM, Remi Forax <forax at univ-mlv.fr> wrote:

>
>
> ----- Mail original -----
> > De: "Paul Benedict" <pbenedict at apache.org>
> > ?: "Peter Levart" <peter.levart at gmail.com>
> > Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoy?: Mercredi 30 Septembre 2015 16:06:18
> > Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges
> >
> > Ah, I was going to write about "values" ... glad this was mentioned. With
> > Valhalla working on value classes, it does raise the question if
> > range-checking is particular to Objects. Clearly it won't be once values
> > are introduced.
> >
> > PS: I am still in favor of using Objects at the time being though just to
> > get something checked-in.
>
> I am in favor of Objects too,
> but I think the name (oh no bikeshedding again) should start with require*
> too make it clear that it goes with requireNonNull
>
> 'requireIndexInBounds' anyone ?
>
>


From steve.drach at oracle.com  Wed Sep 30 18:30:40 2015
From: steve.drach at oracle.com (Steve Drach)
Date: Wed, 30 Sep 2015 11:30:40 -0700
Subject: RFR - 8132734: java.util.jar.* changes to support multi-release
	jar files
In-Reply-To: <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com>
References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com>
	<7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com>
Message-ID: <3FAC60D0-97D6-46E5-A235-075317989275@oracle.com>

Hi Max,

> Can you describe if there is any effect on signed jars? Including:
> 
> 1. Will jarsigner be able to sign such a jar?

The jarsigner from 1.8.0_51 can sign the jar.  The jarsigner from jdk9/dev can not, giving me the error

jarsigner: unable to sign jar: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

I?m unsure what that means, and searching for it has not turned up anything useful except that it might be limited to Mac OS/X.  If anyone can help me here, I?d appreciate it.

> Are all items inside signed?

Yes, according to the manifest and the .sf file

> If you sign a jar using jarsigner from different versions of JDK, will there be any difference?

Not sure yet due to the previously mentioned error I get with JDK 9 jarsigner

> 
> 2. Will jarsigner be able to verify such a jar?

Yes.  Both the JDK 8 and JDK 9 jarsigners can verify the file originally signed by JDK 8 jarsigner

> Will it only verify entries for the current version or all?

It should be all, but of course that depends on how jarsigner accesses the JarFile entries.  If it just opens the JarFile and uses the Enumeration returned by JarFile.entries() or the stream returned by JarFile.stream() then it will see all entries including all versions of entries.  

As a simple test, I modified a versioned entry and then ran both the JDK 8 and JDK 9 jarsigners to verify the jar file.  The modified entry was caught (i.e. verification failed) 


> Will jarsigner from an old JDK verify the new jar?

I can?t sign the jar with the JDK 9 jar signer, so I can?t answer that yet.

> 
> 3. As I know, JarFile has 2 ways to verify a jar file, one using public APIs. One through SharedSecrets.setJavaUtilJarAccess() which can call more methods. Have you confirmed both work?

I?ve only verified it with the jarsigner tool.  Without looking at the code, I suspect the tool uses the public API?s, so I?ll need to come up with something that uses the SharedSecrets API.  I will do that.

> 
> Yes, I'd also like some tests on these.

Sure.



From ralph.goers at dslextreme.com  Wed Sep 30 18:33:26 2015
From: ralph.goers at dslextreme.com (Ralph Goers)
Date: Wed, 30 Sep 2015 11:33:26 -0700
Subject: JEP 264: Platform Logging API and Service
In-Reply-To: <560C12E0.3060501@oracle.com>
References: <20150918161737.CF3F171F93@eggemoggin.niobe.net>
	<55FEB898.6050106@gmail.com> <560ADB25.801@oracle.com>
	<9A09A754-31CE-4658-8F5B-8DD524729267@dslextreme.com>
	<560B9370.2080307@gmail.com>
	<17BFA09E-27E8-4CAD-9F4D-AEA3859625DA@dslextreme.com>
	<560BEE32.4070801@oracle.com>
	<D225E5A9-2A1E-4164-B004-EF3BDCCDB444@dslextreme.com>
	<560C12E0.3060501@oracle.com>
Message-ID: <8B62E7AC-EE9C-45DE-804A-3B30E2376975@dslextreme.com>

You are correct that the discussion on the serviceLoader may be off-topic wrt JEP 264. I believe I mentioned that currently Log4j only supports binding with a single implementation as well. But we don?t take the first, we take the one with the highest priority.

Ralph

> On Sep 30, 2015, at 9:50 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Ralph,
> 
> On 30/09/15 18:30, Ralph Goers wrote:
>> What would be preferable is to have the serviceLoader accept ?criteria? (which are callbacks) that can evaluate each of the located services based on any additional properties that are included in the properties file and either eliminate them or return a ?ranking".  The serviceLoader would then end up with a set of eligible services in their preferred order.
> 
> I understand you may have another use case in mind, but in
> what concerns jep264's LoggerFinder though - I don't think
> that would be useful. The JDK can only use one LoggerFinder
> service implementation, and if more than one is found, it most
> probably indicates a configuration error - where several
> implementations have been put by mistake on the classpath.
> 
> Just taking the first and silently continue could end up in
> strange misbehavior, where the application's developer would
> not see the expected debug traces - because she configured
> one framework but it's the other that happens to be used.
> 
> I believe it's a better idea to fail fast in this case.
> 
> best regards,
> 
> -- daniel
> 
> 




From brian.burkhalter at oracle.com  Wed Sep 30 18:41:32 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 30 Sep 2015 11:41:32 -0700
Subject: JDK 9 RFR of JDK-8136874: Bug in port of fdlibm pow to Java
In-Reply-To: <5605855F.7070907@oracle.com>
References: <5605855F.7070907@oracle.com>
Message-ID: <8EAAB9B6-873D-46DD-991C-390FD4E5D87D@oracle.com>

Hi Joe,

On Sep 25, 2015, at 10:33 AM, joe darcy <joe.darcy at oracle.com> wrote:

> Full webrev of the changes up at
> 
>    JDK-8136874: Bug in port of fdlibm pow to Java - Java Bug System
>    http://cr.openjdk.java.net/~darcy/8136874.0/
> 
> The bulk of the changeset is a new battery of tests including the failing values reported earlier.
> 
> I checked the other replacements of ix in the pow code and they seem okay, but I wouldn't mind another pair of eyes looking over it; webrev of the initial port is at http://cr.openjdk.java.net/~darcy/8134795.6/.

Best I can tell this all looks fine.

> I'll review the port of hypot for analogous problems.
> 
> Thanks again to Jeff Hain for the reporting the incorrect behavior of the port.

I echo the thanks to Jeff. To my mind any and all testing is more than welcome.

Brian

From sean.mullan at oracle.com  Wed Sep 30 18:51:20 2015
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 30 Sep 2015 14:51:20 -0400
Subject: RFR - 8132734: java.util.jar.* changes to support multi-release
	jar files
In-Reply-To: <3FAC60D0-97D6-46E5-A235-075317989275@oracle.com>
References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com>
	<7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com>
	<3FAC60D0-97D6-46E5-A235-075317989275@oracle.com>
Message-ID: <560C2F28.8020603@oracle.com>



On 9/30/15 2:30 PM, Steve Drach wrote:
> Hi Max,
>
>> Can you describe if there is any effect on signed jars? Including:
>>
>> 1. Will jarsigner be able to sign such a jar?
>
> The jarsigner from 1.8.0_51 can sign the jar.  The jarsigner from jdk9/dev can not, giving me the error
>
> jarsigner: unable to sign jar: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
>
> I?m unsure what that means, and searching for it has not turned up anything useful except that it might be limited to Mac OS/X.  If anyone can help me here, I?d appreciate it.

This means it could not find a trusted root CA from the cacerts file to 
validate the certificate chain. By default, OpenJDK includes an empty 
cacerts file. You need to do a jdk9 build with the closed sources, as 
that is where the trusted roots are.

--Sean


From martinrb at google.com  Wed Sep 30 19:13:02 2015
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 30 Sep 2015 12:13:02 -0700
Subject: specdiff <was> Re: RFR: jsr166 openjdk9 integration
In-Reply-To: <CA+kOe0-Zg_+ZcsDY3nU-wiQ6Qdto7PPbyrf_ceQrEs68Ut1qng@mail.gmail.com>
References: <CA+kOe0-4g1st9akQewJX21NG7u0RF0ih3bszjb_q9nQnZaLvcQ@mail.gmail.com>
	<DD91D54A-59D0-4EA4-BA69-9F5BAF3FC736@oracle.com>
	<CA+kOe0_cNc26FsV1aPc9Vw0GS8AAVT41xpdEQd4d50R5dY19gg@mail.gmail.com>
	<F57BEACF-282F-41C6-B5CA-5BA9A09BF2C4@oracle.com>
	<6C860453-A0EB-46FB-AB75-CB57FA4E82FE@oracle.com>
	<CA+kOe08sjbwSVvjRg-=q-xnSdi8EcdBo3pqihoR6uFbdS5afdQ@mail.gmail.com>
	<AE074295-5B2F-4A2B-8234-3F5B54B9CB93@oracle.com>
	<CA+kOe0-Zg_+ZcsDY3nU-wiQ6Qdto7PPbyrf_ceQrEs68Ut1qng@mail.gmail.com>
Message-ID: <CA+kOe08NJiAWGnfhRo9YzRpwX_8B9gBfKHCiEVUBe5XV9rpLUg@mail.gmail.com>

I noticed that the Navigable* class descriptions were incompletely
@link-ified.

Index: src/main/java/util/NavigableMap.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/NavigableMap.java,v
retrieving revision 1.29
diff -u -r1.29 NavigableMap.java
--- src/main/java/util/NavigableMap.java 6 Sep 2015 04:29:42 -0000 1.29
+++ src/main/java/util/NavigableMap.java 30 Sep 2015 19:12:18 -0000
@@ -19,16 +19,18 @@
  * methods are designed for locating, not traversing entries.
  *
  * <p>A {@code NavigableMap} may be accessed and traversed in either
- * ascending or descending key order.  The {@code descendingMap}
+ * ascending or descending key order.  The {@link #descendingMap}
  * method returns a view of the map with the senses of all relational
  * and directional methods inverted. The performance of ascending
  * operations and views is likely to be faster than that of descending
- * ones.  Methods {@code subMap}, {@code headMap},
- * and {@code tailMap} differ from the like-named {@code
- * SortedMap} methods in accepting additional arguments describing
- * whether lower and upper bounds are inclusive versus exclusive.
- * Submaps of any {@code NavigableMap} must implement the {@code
- * NavigableMap} interface.
+ * ones.  Methods
+ * {@link #subMap(Object, boolean, Object, boolean) subMap(K, boolean, K,
boolean)},
+ * {@link #headMap(Object, boolean) headMap(K, boolean)}, and
+ * {@link #tailMap(Object, boolean) tailMap(K, boolean)}
+ * differ from the like-named {@code SortedMap} methods in accepting
+ * additional arguments describing whether lower and upper bounds are
+ * inclusive versus exclusive.  Submaps of any {@code NavigableMap}
+ * must implement the {@code NavigableMap} interface.
  *
  * <p>This interface additionally defines methods {@link #firstEntry},
  * {@link #pollFirstEntry}, {@link #lastEntry}, and
@@ -51,7 +53,7 @@
  * implement {@code NavigableMap}, but extensions and implementations
  * of this interface are encouraged to override these methods to return
  * {@code NavigableMap}.  Similarly,
- * {@link #keySet()} can be overridden to return {@code NavigableSet}.
+ * {@link #keySet()} can be overridden to return {@link NavigableSet}.
  *
  * <p>This interface is a member of the
  * <a href="{@docRoot}/../technotes/guides/collections/index.html">
Index: src/main/java/util/NavigableSet.java
===================================================================
RCS file:
/export/home/jsr166/jsr166/jsr166/src/main/java/util/NavigableSet.java,v
retrieving revision 1.30
diff -u -r1.30 NavigableSet.java
--- src/main/java/util/NavigableSet.java 6 Sep 2015 04:29:42 -0000 1.30
+++ src/main/java/util/NavigableSet.java 30 Sep 2015 19:12:18 -0000
@@ -12,20 +12,24 @@
  * {@link #floor}, {@link #ceiling}, and {@link #higher} return elements
  * respectively less than, less than or equal, greater than or equal,
  * and greater than a given element, returning {@code null} if there
- * is no such element.  A {@code NavigableSet} may be accessed and
- * traversed in either ascending or descending order.  The {@code
- * descendingSet} method returns a view of the set with the senses of
- * all relational and directional methods inverted. The performance of
- * ascending operations and views is likely to be faster than that of
- * descending ones.  This interface additionally defines methods
- * {@link #pollFirst} and {@link #pollLast} that return and remove the
- * lowest and highest element, if one exists, else returning {@code
- * null}.  Methods {@code subSet}, {@code headSet},
- * and {@code tailSet} differ from the like-named {@code
- * SortedSet} methods in accepting additional arguments describing
- * whether lower and upper bounds are inclusive versus exclusive.
- * Subsets of any {@code NavigableSet} must implement the {@code
- * NavigableSet} interface.
+ * is no such element.
+ *
+ * <p>A {@code NavigableSet} may be accessed and traversed in either
+ * ascending or descending order.  The {@link #descendingSet} method
+ * returns a view of the set with the senses of all relational and
+ * directional methods inverted. The performance of ascending
+ * operations and views is likely to be faster than that of descending
+ * ones.  This interface additionally defines methods {@link
+ * #pollFirst} and {@link #pollLast} that return and remove the lowest
+ * and highest element, if one exists, else returning {@code null}.
+ * Methods
+ * {@link #subSet(Object, boolean, Object, boolean) subSet(E, boolean, E,
boolean)},
+ * {@link #headSet(Object, boolean) headSet(E, boolean)}, and
+ * {@link #tailSet(Object, boolean) tailSet(E, boolean)}
+ * differ from the like-named {@code SortedSet} methods in accepting
+ * additional arguments describing whether lower and upper bounds are
+ * inclusive versus exclusive.  Subsets of any {@code NavigableSet}
+ * must implement the {@code NavigableSet} interface.
  *
  * <p>The return values of navigation methods may be ambiguous in
  * implementations that permit {@code null} elements. However, even


From john.r.rose at oracle.com  Wed Sep 30 21:12:16 2015
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 30 Sep 2015 14:12:16 -0700
Subject: RFR: JDK-8073187: Unexpected side effect in Pack200
In-Reply-To: <5602E476.3060309@oracle.com>
References: <5601B834.60900@oracle.com> <5602E476.3060309@oracle.com>
Message-ID: <FF985603-4614-4149-8264-8EE9C3AE1C46@oracle.com>

Reviewed.  Thank you, thank you, Joda-Time!  ? John

On Sep 23, 2015, at 10:42 AM, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
> 
> Hi John, Sherman,
> 
> I noticed a flaw in my fix, ie. in a section of the logic that is present
> but unused,  and reserved for future use, fixed it here anyway, for
> correctness.
> 
> The full webrev:
> http://cr.openjdk.java.net/~ksrini/8073187/webrev.1/ <http://cr.openjdk.java.net/~ksrini/8073187/webrev.1/>
> 
> The delta changes:
> http://cr.openjdk.java.net/~ksrini/8073187/webrev.1/webrev.delta/index.html <http://cr.openjdk.java.net/~ksrini/8073187/webrev.1/webrev.delta/index.html>
> 
> Thanks
> Kumar



From huizhe.wang at oracle.com  Wed Sep 30 21:46:55 2015
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 30 Sep 2015 14:46:55 -0700
Subject: RFR (jaxp) 8136778: SAXParser: support stopping a parsing process
Message-ID: <560C584F.6040805@oracle.com>

Hi,

This is an enhancement to allow a SAX parsing process to be stopped and 
resumed. A SAX process scans through an entire document while making 
callbacks to its handler when defined events are met. The stop and 
resume methods make it easy to stop and subsequently resume the process 
as needed. Until now, the parsing process can only be stopped brutally 
by throwing an Exception.

JBS: http://ccc.us.oracle.com/8136778
Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8136778/webrev/

Thanks,
Joe



From xueming.shen at oracle.com  Wed Sep 30 22:57:57 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 30 Sep 2015 15:57:57 -0700
Subject: RFR: JDK-8073187: Unexpected side effect in Pack200
In-Reply-To: <5602E476.3060309@oracle.com>
References: <5601B834.60900@oracle.com> <5602E476.3060309@oracle.com>
Message-ID: <560C68F5.1020407@oracle.com>

looks good!

sherman

On 09/23/2015 10:42 AM, Kumar Srinivasan wrote:
> Hi John, Sherman,
>
> I noticed a flaw in my fix, ie. in a section of the logic that is present
> but unused,  and reserved for future use, fixed it here anyway, for
> correctness.
>
> The full webrev:
> http://cr.openjdk.java.net/~ksrini/8073187/webrev.1/
>
> The delta changes:
> http://cr.openjdk.java.net/~ksrini/8073187/webrev.1/webrev.delta/index.html
>
> Thanks
> Kumar
>
>> Hello,
>>
>> Pack200 converts the timestamps to UTC for the pack200 archive format,
>>  in order to do so,  the default TimeZone was set to UTC, while reading and
>> writing archives. This is problematic in a multi threaded environment.
>>
>> With the fix for JDK-8075526 in place, the pack200 code is refactored
>> to use the new Jar/Zip APIs, and eliminates issues arising from pack200
>> setting the default TimeZone.
>>
>> http://cr.openjdk.java.net/~ksrini/8073187/webrev.0/
>>
>> Thanks
>> Kumar
>>
>



From weijun.wang at oracle.com  Wed Sep 30 23:35:44 2015
From: weijun.wang at oracle.com (Wang Weijun)
Date: Thu, 1 Oct 2015 07:35:44 +0800
Subject: RFR - 8132734: java.util.jar.* changes to support multi-release
	jar files
In-Reply-To: <560C2F28.8020603@oracle.com>
References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com>
	<7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com>
	<3FAC60D0-97D6-46E5-A235-075317989275@oracle.com>
	<560C2F28.8020603@oracle.com>
Message-ID: <22FF6E94-59B4-4D76-8024-56DB34BA328F@oracle.com>


> ? 2015?10?1????2:51?Sean Mullan <sean.mullan at oracle.com> ???
> 
>> The jarsigner from jdk9/dev can not, giving me the error
>> 
>> jarsigner: unable to sign jar: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
>> 
>> I?m unsure what that means, and searching for it has not turned up anything useful except that it might be limited to Mac OS/X.  If anyone can help me here, I?d appreciate it.
> 
> This means it could not find a trusted root CA from the cacerts file to validate the certificate chain. By default, OpenJDK includes an empty cacerts file. You need to do a jdk9 build with the closed sources, as that is where the trusted roots are.

If this is the problem, I think it's a bug. When jarsigner is signing it uses a key pair inside a keystone specified by -keystore. I don't see a reason why cacerts must be populated.

Can you add a -debug option to show the full exception stack info? I even could not see how SSL is involved here.

Thanks
Max




From steve.drach at oracle.com  Wed Sep 30 23:53:22 2015
From: steve.drach at oracle.com (Steve Drach)
Date: Wed, 30 Sep 2015 16:53:22 -0700
Subject: RFR - 8132734: java.util.jar.* changes to support multi-release
	jar files
In-Reply-To: <7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com>
References: <A12C71A8-59AB-4271-873F-4F3435EB2493@oracle.com>
	<7659C060-0EBC-4FC2-B20E-9CCB3B93A2C5@oracle.com>
Message-ID: <BE0A18A1-CA02-472C-9C61-31982CE4AC0D@oracle.com>

Hi Max,

Here are updated answers to your questions, after I received some help (thank you Sean Mullan).

> Can you describe if there is any effect on signed jars? Including:
> 
> 1. Will jarsigner be able to sign such a jar?

The jarsigner from 1.8.0_51 can sign the jar.  The jarsigner from jdk9/dev can also sign the jar.

> Are all items inside signed?

Yes, according to the manifest and the .sf file

> If you sign a jar using jarsigner from different versions of JDK, will there be any difference?

Yes, there is unfortunately.  This is what I found out:
- JDK 8 jar signer does not work with a JDK 9 created keystore
- JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with JDK 9 keystore
- JDK 8 signed jar with JDK 8 created keystore is not the same size as JDK 9 signed jar with the same JDK 8 keystore

I am not sure what factors are in play here, but something certainly depends on what version of keytool is used to create the keystone.  The last fact above seems to imply the answer to your question is yes, there is a difference as measured by jar file size.  The META-INF/ALIAS.SF and META-INF/ALIAS.DSA files are different sizes in each jar file.

If somebody has an idea on how to analyze this, please let me know.  I?m a bit clueless at the moment.

> 
> 2. Will jarsigner be able to verify such a jar?

Yes.  Both the JDK 8 and JDK 9 jarsigners can verify both the signed files, one from JDK 8 and one from JDK 9

> Will it only verify entries for the current version or all?

It should be all, but of course that depends on how jarsigner accesses the JarFile entries.  If it just opens the JarFile and uses the Enumeration returned by JarFile.entries() or the stream returned by JarFile.stream() then it will see all entries including all versions of entries.  

As a simple test, I modified a versioned entry and then ran both the JDK 8 and JDK 9 jarsigners to verify the jar file.  The modified entry was caught (i.e. verification failed) 


> Will jarsigner from an old JDK verify the new jar?

Yes, see answer to question 2.

> 
> 3. As I know, JarFile has 2 ways to verify a jar file, one using public APIs. One through SharedSecrets.setJavaUtilJarAccess() which can call more methods. Have you confirmed both work?

I?ve only verified it with the jarsigner tool.  Without looking at the code, I suspect the tool uses the public API?s, so I?ll need to come up with something that uses the SharedSecrets API.  I will do that.

> 
> Yes, I'd also like some tests on these.

Sure.